PLNOG14: Network Automation - Sławomir Janukowicz

NETWORK AUTOMATION

Sławomir Janukowicz

[email protected]

2 Copyright © 2015 Juniper Networks, Inc. www.juniper.net

Krótko o czym nie będzie

Automatyczna instalacja

Przegląd narzędzi do automatycznego ładowania konfiguracji

Święty Gral

Około automatyzacji

O CZYM BĘDZIE


Cloud oczywiście wymusza automatyzację

Wszędzie o Cloud Compiting to tutaj akurat nie

AUTOMATYZACJA I CHMURKI (CLOUD)


Puppet

Chef

Urządzenia Junipera posiadają wtyczki do tych narzędzi – wiec

się da

ORKIESTRACJA


Junos Space

Cisco Configuration Assistant

To jednak jest PLNOG

MECHANIZMY JEDNEGO DOSTAWCY


O tym już było na PLNOG sporo

Będzie na pewno też jeszcze więcej

To tutaj akurat nie

SDN


Autoinstall

ZTP – zero touch provisioning

ZTD – zero touch deployment

Dystrybucja urządzeń wykonywana zawczasu

Jedno rozpakowanie urządzenia z pudełka

Obniżenie wymaganych kompetencji od instalatorów

Koszt pracy

Umiejętności budowlane są ważniejsze – tego zdalnie nie da się

zrobić

Umiejętności związane z technologią dostępową – szczególnie w

przypadku instalacji bezprzewodowych

Przyśpieszenie wymiany uszkodzonego urządzenia

AUTOMATYCZNA INSTALACJA – PO CO


Wymagania: (dla małych SRX)

Pamięć flash USB

Partycja FAT/FAT32

Lepiej nie za duża pojemność

Plik z obrazem systemu

Plik z konfiguracją – wynik komendy show configuration

Pusty plik autoinstall.conf

Podłączamy do portu USB, włączamy ruter, diody informują nas

o sukcesie

Podobne rozwiązania dostępne są u innych producentów

AUTOMATYCZNA INSTALACJA – USB


Podłączenie urządzenia do sieci gdzie dostępny jest serwer

DHCP oraz TFTP

Urządzenie uzyskuje własny adres IP oraz adres serwera TFTP

z DHCP

Następuje pobieranie pliku konfiguracyjnego o zdefiniowanej

nazwie i załadowanie go jako aktywnej konfiguracji

Wymagane nazewnictwo dla małych SRX

Nazwa pliku hostname.conf jeśli konfiguracja zawiera wartości

specyficzne dla konkretnego urządzenia

Nazwa pliku router.conf jeśli konfiguracja domyślna – ładowana na

każde urządzenie

AUTOMATYCZNA INSTALACJA – DHCP


Dotyczy małych SRXów

Możliwość zdefiniowania portu wykorzystywanego do

komunikacji w górę sieci

Port

Vlan tag

Tunel – GRE, IPSec

Możliwość ustawienia bezpiecznego sposobu pobierania

konfiguracji

Szyfrowanego

Uwierzytelnianego

„PRAWIE” AUTOMATYCZNA INSTALACJA


Czy ładujemy docelową konfigurację czy tylko uproszczoną

umożliwiającą zdalny dostęp

Konfiguracja uproszczona jest łatwiejsza do dystrybucji i pozwala

uniknąć pomyłki załadowania konfiguracji na niewłaściwe

urządzenie

Konfiguracja docelowa umożliwia szybsze uruchomienie usługi

Jakie dane uwierzytelniające definiujemy globalnie a jakie per

urządzenie

AUTOMATYCZNA INSTALACJA – DO ROZWAŻENIA


Przydzielanie parametrów konfiguracyjnych według sztywnych

reguł

Adresy IP

Pomyśleć o agregacji

Nazwy

Trzeba zrezygnować z mitologii, bohaterów ulubionego serialu i

podobnych

Identyfikatory usług

Zapisywane parametrów w zewnętrznych systemach – bazy

danych

Pobieranie informacji z systemów sprzedażowych

AUTOMATYCZNA INSTALACJA – PRZYDZIELANIE ZASOBÓW


Opisy portów

Nazwy urządzeń

Jedno miejsce konfiguracji parametrów

Ustawienia protokołu routingu: jako część konfiguracji protokołu lub

część konfiguracji portu

Konfiguracja VLAN: VLAN i lista dodanych portów lub port i lista

dodanych VLAN

Szablon opisu portu

Nazwa_portu/sąsiad/port_sąsiada/typ_portu/identyfikator_usługi

Typ_portu

NN – pomiędzy urządzeniami w rdzeniu sieci

NNI – z urządzenia dostępowego do urządzenia rdzeniowego

UNI – port kliencki

AUTOMATYCZNA INSTALACJA - SZABLONY


Narzędzia do budowania konfiguracji – każdy sobie coś znajdzie

Języki skryptowe

Excel

Można też użyć C

CLI i wklejanie poleceń

Ładowanie pliku na urządzenie

Skrypt do interaktywnej pracy z urządzeniem

SNMP

BGP

Junos PyEZ

NARZĘDZIA DO AUTOMATYCZNEGO ŁADOWANIA KONFIGURACJI


Logowanie do urządzenia

Kopiowanie wyniku pracy skryptów generujących konfiguracje

do konsoli urządzenia

Duże zmiany mogą nie być poprawnie zaakceptowane w trybie

interaktywnym przez urządzenie

Urządzenie powinno umożliwiać załadowanie konfiguracji przez

konsolę w trybie nieinteraktywnym

Można oczywiście w kolejnym kroku sprawdzić działanie usługi i

wycofać wprowadzone zmiany – opcja rollback jeśli jest

obsługiwana lub skrypt musi generować polecenia wycofujące

zmiany

WKLEJANIE


Ładowanie pliku zawierającego komendy zmian do systemu

plików urządzenia

Załadowanie pliku ze zmianami do aktywnej konfiguracji

Zalogowanie się i wydanie polecenia

Automatyczne logowanie i wydanie polecenia

SSH – uwierzytelnianie za pomocą kluczy

Net::Telnet

ŁADOWANIE DO PLIKU


Oczywiście inne języki programowania mogą być wykorzystane

Ten sposób dostępu umożliwia też weryfikację poprawności

wprowadzonej konfiguracji

Jak ktoś oprogramuje

NET::TELNET PERL MODULE / EXPECT


Najczęściej nadaje się tylko do bardzo prostych zastosowań

Wyłączenie portu klienckiego

Bardziej zaawansowane ustawienia są mocno nietypowe

SNMP


Może być wykorzystane gdy jeden podmiot kontroluje całość

sieci - operator

Także wtedy gdy sieć BGP innego podmiotu transparentnie

przesyła wymagane parametry – klient operatora

Oczywiście wymaga BGP na łączu PE-CE

Możliwość automatyzacji tylko wcześniej przygotowanych

scenariuszy

Przykładowo wybór łącze z lokalizacji zdalnej do lokalizacji

głównej czy w lokalizacji zdalnej dostępna jest usługa od dwóch

operatorów

Rozsyłanie odpowiednich community zmieniających ustawienia

local-preference

BGP


BGP FlowSpec jako narzędzie anty DDoS – tutaj oczywiście też

chodzi o automatyzacje

BGP FlowSpec umożliwia także operacje związane z QoS

Chcemy przenieść jakiś typ ruchu pomiędzy klasami QoS

zakupionymi od dostawcy łącza – wymuszenie innego niż typowo

skonfigurowane znakowania DSCP

Chcemy ograniczyć jakiś rodzaj ruchu – włączenie mechanizmu

policer dla określonego typu danych

BGP flow spec można użyć do szybkiego „prototypowania” a

potem za pomocą innego mechanizmu masowo wdrożyć zmiany

w konfiguracji – tutaj zaletą BGP flowspec jest nietrwałość zmian

QPPB (QoS Policy Propagation via BGP)

BGP FLOWSPEC


Wrapper pozwalający na łatwe wykorzystanie Junos XML API

Jak ktoś zna Pythona

Ale Python prosty jest

Narzędzie posiada wiele bibliotek pozwalających na przykład na

automatyczną instalację oprogramowania na wielu urządzeniach

Można pisać dodatkowe biblioteki ułatwiające realizację

własnych wymagań

JUNOS PYEZ


Instalacja (pip - Python

package manager)

pip install junos-eznc

>>> from pprint import pprint

>>> from jnpr.junos import Device

>>> dev1 = Device(host='172.16.49.136', user='dgee',

password='Passw0rd')

>>> dev1.open()

Device(172.16.49.136)

>>> pprint( dev1.facts )

{'2RE': False,

'HOME': '/cf/var/home/dgee',

'RE0': {'last_reboot_reason': 'Router rebooted after a normal

shutdown.',

'model': 'JUNOSV-FIREFLY RE',

'status': 'Testing',

'up_time': '18 minutes, 54 seconds'},

'domain': None,

'fqdn': 'Amnesiac',

'hostname': 'Amnesiac',

'ifd_style': 'CLASSIC',

'model': 'JUNOSV-FIREFLY',

'personality': 'SRX_BRANCH',

'serialnumber': 'ee9e0c8e09cd',

'srx_cluster': False,

'switch_style': 'VLAN',

'version': '12.1X44-D20.3',

'version_info': junos.version_info(major=(12, 1), type=X,

minor=(44, 'D', 20), build=3),

'virtual': True}

>>> dev1.close()

PYEZ – PRZYKŁAD


>>> tbl = RouteTable(dev1)

>>> tbl.get('10.207.64.0/24')

RouteTable:your_device_name: 1 items

find = tbl['10.207.64.0/24']

>>> find.to

'10.160.248.2'

>>> find.via

'xe-1/3/0.0'

>>> find.lsp

'LSP-ABC-123'

PYEZ – PRZYKŁAD


Można wykonywać polecenia

na liście urządzeń

>>> devilist = ['mx240.lab','mx480.lab','srx240.lab']

>>> devs = [Device(host,user='admin',password='tajne') for

host in devlist]

>>> for d in devs: d.open()

...

Device(LAB-MX240-1)

Device(LAB-MX480-re0)

Device(Lab-srx240-middle)

>>> from jnpr.junos.op.xcvr import *

>>> xcvr_db = [XcvrTable(dev) for dev in devs]

>>> for t in xcvr_db: t.get()

...

XcvrTable:LAB-MX240-1: 4 items

XcvrTable:LAB-MX480-re0: 6 items

XcvrTable:Lab-srx240-middle: 1 items

>>>pprint ( xcvr_db[2].items() )

[(('FPC 1','PIC 0','Xcvr 0'),

[('ver','version'),

('pn','740-011782'),

('sn','PB8219J'),

('type','SFP-SX')])]

>>>

PYEZ


Archeologia

Epoką kamienia się nie będziemy zajmować

Epoka brązu – sierpień 1988 – RFC 1067 – SNMP

Brak jednolitych narzędzi do zarządzania sprzętem różnego typu jak

widać uwierał już starożytnych

Wykopaliska świadczą że początkowo szło w dobrym kierunku

Kolejne RFC

Standardowe MIBy

ŚWIĘTY GRAL


Katastrofa promu kosmicznego Columbia

Uruchomiono portal MySpace

Afera Rywina

Adam Małysz trzeci raz z rzędu zdobył puchar świata

RFC 3535

Opis stanu dostępnych narzędzi konfiguracyjnych

Zdefiniowanie wymagań operatorów

Analiza SNMP – nie standardu ale stanu faktycznego

Pomysły na przyszłość

PAMIĘTNY ROK 2003


SNMP

CLI/TELNET/SSH

HTTP

Inne o których dowiedziałem się dopiero z tego dokumentu

COPS [RFC2748]

Common Information Model, policy extensions of CIM [RFC3060]

RFC 3535 – NARZĘDZIA ADMINISTRACYJNE


Dla ludzi

Można korzystać za pomocą skryptów

Można pobierać, edytować ręcznie lub automatycznie, wgrywać

część lub całość na to samo lub inne urządzenie

Co dostawca to działa inaczej, te same polecenia mogą mieć

inne skutki

Nie ma gwarancji stałości składni ani wyników wyświetlanych

przez polecenia

RFC 3535 – OPINIA O CLI


Dla ludzi, czasami zbyt mocno zorientowane na użytkowniku

końcowym

Automatyczne parsowanie stron HTML – to dopiero jest

wyzwanie

Nie ma gwarancji stałości obiektów konfiguracyjnych ani

wyświetlanych wyników

Pobieranie i odtwarzanie konfiguracji jest mocno utrudnione (nie

chodzi o pobranie pliku z konfiguracją za pomocą HTTP)

Plik z konfiguracją często ma formę binarną

RFC 3535 – OPINIA O HTTP


Działa dobrze jako Simple Network MONITORING Protocol

Już monitoring większych obiektów (tablica routingu na

przykład) jest problematyczny

Występują parametry konfiguracyjne na wielu urządzeniach,

których przez SNMP nie da się ustawić – tylko za pomocą CLI

Nie ma możliwości pobrania i potem odtworzenia całości

konfiguracji (nie chodzi tu o wywołanie za pomocą SNMP zrzutu

czy pobrania konfiguracji jako pliku komend CLI)

Z opisu MIB nie wynika jak użyć zawartych w nim obiektów do

osiągnięcia konkretnego celu

Zdarza się, że urządzenia raportują po SNMP błędne dane (po

CLI prawidłowe)

RFC 3535 – OPINIA O SNMP


Zadarza się, że intensywne korzystanie z SNMP potrafi

spowodować awarię rutera (zbyt duże zajęcie pamięci lub

procesora a nawet restart)

Pozyskanie informacji niedostępnych jawnie w jednym OID jest

bardzo zasobochłonne – który port jest wykorzystywany do

routingu pakietów do określonego adresu docelowego

AAA w SNMP – niespójne z innymi mechanizmami i dość

skomplikowane dla SNMP v3

SNMP Traps dają często dużo mniej informacji niż logi Syslog

RFC 3535 – OPINIA O SNMP


Narzędzie proste do użycia przez administratorów – a nie proste

w implementacji

Jasne rozróżnienie pomiędzy konfiguracją, poleceniami

operacyjnymi i statystykami

Pobrany stan konfiguracji, stan operacyjni i statystyki muszą dać

się porównać pomiędzy urządzeniami

Pożądane jest konfigurowanie sieci jako całości a nie jako

pojedynczych elementów

Konfiguracja urządzeń powinna działać w trybie transakcyjnym –

albo wprowadzane są wszystkie wymagane zmiany albo żadna

Standard umożliwiający pobierania i ładowania na urządzenia

całości konfiguracji

RFC 3535 – WYMAGANIA OPERATORÓW


Składnia konfiguracji powinna być identyczna na wszystkich

urządzeniach – niezależnie od dostawcy i typu urządzenia

Konfiguracja jako plik tekstowy nie binarny

Rozróżnienie pomiędzy ładowaniem konfiguracji i jej

aktywowaniem

Docelowy standard musi obsługiwać wszystko co jest dostępne

poprzez CLI

Tekstowe pliki konfiguracyjne powinny obsługiwać znaki

spotykane w innych językach niż tylko angielski

Standard musi umożliwiać ustalanie jakie jego elementy są

obsługiwane przez konkretne urządzenie

RFC 3535 – WYMAGANIA OPERATORÓW


Wszystkie uwagi wynikające ze specyfikacji protokołu tak samo

prawdziwe teraz jak w 2003 roku

SNMP bardziej stabilne – ale dalej zdarzają się problemy

Ubyło trochę dostawców sprzętu sieciowego, część istniejących

wzoruje swoje CLI na „tym znanym” – trochę mniejsza

różnorodność niż w 2003

Ogólnie nie jest znacząco lepiej

RFC 3535 - DZISIAJ


Adresuje część wymagać zgłoszonych w RFC 3535

Ujęcie w standard mechanizmów dostępnych w Junos

Junos obsługuje Netconf – „od początku”

Główny autor Phil Shafer

Pierwszy standard

RFC 4741

Obecny standard

RFC 6241

NETCONF


Junos like

Konfiguracja robocza – czyli ta z którą pracuję urządzenie

Konfiguracja kandydacka – czyli ta na której dokonujemy zmian

Commit, commit-confirmed, rollback

Poziomy zagnieżdżenia konfiguracji

Model prosty

Jedna wersja konfiguracji – ta z która obecnie pracuje urządzenie

Zmiany są wprowadzane od razu

Netconf potrafi pracować z oboma modelami

MODELE KONFIGURACJI


Filter (filtry) – konfiguracja jest zbudowana w sposób

hierarchiczny i możliwe jest wybranie tylko jej określonego

fragmentu dotyczącego wybranego zagadnienia

Datastore (wersje konfiguracji) – na urządzeniu istnieje wiele

różnych wersji konfiguracji.

:running, :candidate, :startup – wersje konfiguracji o specjalnym

znaczeniu

Wersje dodatkowe – o dowolnej nazwie, ułatwiające operacje, nie

mają żadnej specjalnej funkcji

Session – sesje – każde połączenie użytkownika ma nadany

indywidualny numer, można powrócić do przerwanej sesji

NETCONF - ZAŁOŻENIA


<get> - pozyskanie konfiguracji urządzenia oraz jego stanu (na

przykład liczniki na portach, stan sąsiedztwa OSPF) –

opcjonalnie dodany filtr

<get-config> - pozyskanie konfiguracji urządzenia – z jakiego

datastore, opcjonalne dodany filtr

<copy-config> - skopiowanie całości konfiguracji z jednego

datastore do drugiego

<commit> - użycie konfiguracji z datastore :candidate jako

konfiguracji roboczej

<discard-changes> - odrzucenie zmian wprowadzonych w

konfiguracji :candidate

NETCONF – OPERACJE BAZOWE


<cancel-commit> - odwołanie ostatniej komendy commit,

opcjonalnie można odwołać commit z określonej sesji

<delete-config> - skasowanie określonego datastore

<lock> - zablokowanie zmian w określonym datastore tylko dla

obecnej sesji (blokuje także zmiany przez inne mechanizmy jak

CLI i SNMP)

<unlock> - odblokowanie określonego datastore

<close-session> - zamknięcie bieżącej sesji, powoduje

zwolnienie wszystkich blokad

<kill-session> - wymuszenie zamknięcia sesji (także innej niż

bieżąca), zwalnia blokady, powoduje przywrócenie konfiguracji

wprowadzonej w trybie commit-confirmed



<edit-config> - zmienia wartości w określonym datastore

Operacje – ustawiane oddzielnie dla każdego z filtrów

merge – dołączenie zmian do istniejącej konfiguracji

replace – zamienia wartości, lub tworzy jeśli nie istnieją

create – tworzy obiekty, jeśli istniały wcześniej zostanie zgłoszony błąd

delete – kasuje obiekty, zgłasza błąd jeśli nie istnieją

remove – kasuje obiekty, nie zgłasza błędu jeśli nie istnieją

Operacja domyślna

merge, replace, none

Test – głównie dla urządzeń bez opcji :candidate

Test-then-set – sprawdź czy się da i jeśli ok to ustaw

Set – ustaw bezwzględnie

Test-only – tylko sprawdź



<edit-config>

Obsługa błędów

stop-on-error – wartość domyślna, operacja edit jest przerywana po

wystąpieniu pierwszego błędu

continue-on-error – kontynuuje mimo błędu, błędy są zapamiętywane i

w odpowiedzi wysyłane są wszystkie

rollback-on-error – wystąpienie błędu powoduje odwołanie całej operacji

edit



Klient i serwer wysyłają wiadomość <hello> gdzie specyfikują

Wersję protokołu

Rozszerzenia

Obsługiwane modele danych

Serwer przydziela numer sesji

NETCONF – NAWIĄZANIE SESJI


Candidate

Confirmed commit

Rollback on error

Validate – serwer może przeprowadzić sprawdzenie konfiguracji

z dowolnego datastore

Startup – serwer obsługuje datastore :startup

Url – można skopiować konfiguracje z lub do zewnętrznego

pliku

Partial-lock – komeda lock może obejmować tylko część

konfiguracji

Netconf monitoring – pobieranie przez Netconf statystyk o

Netconf

NETCONF – ROZSZERZENIA


With-defaults – umożliwia jawne operacje na obiektach nie

występujących w konfiguracji – ustawionych na wartości

domyślnie

Report-all – wszystkie obiekty w konfiguracji są zawsze

prezentowane, tak jakby nie było obiektów o wartościach

domyślnych

Trim – wszystkie obiekty, które mają ustawiona wartość na taką

samą jak wartość domyślna są traktowane jakby ich nie było w

konfiguracji

Explicit – wszystkie obiekty, które mają przypisaną w konfiguracji

wartość istnieją niezależnie czy jest ona taka sama jak domyślna

czy też nie

NETCONF – ROZSZERZENIA


Wartości domyślne: A=1, B=2, C – brak, D=4, E – brak

Plik konfiguracyjny: A=2, C=3,D=4

NETCONF – WITH DEFAULTS - PRZYKŁAD

Report-all Report-all-

tagged

Trim Explicit

A=2

B=2

C=3

D=4

E-nieustawiona

A=2

B=2 (wartość

domyślna)

C=3

D=4 (wartość

domyślna)

E-nieustawiona

A=2

C=3

A=2

C=3

D=4


Logowanie przez Netconf

Serwer może w ramach sesji netconf wysyłać do klienta logi

Klient może zdefiniować jakie logi chce otrzymywać

Zarówno wybrać z grup oferowanych przez serwer

Filtrować logi za pomocą wyrażeń XPATH (wyrażenia regularne,

warunkowe)

Klient może pobrać logi archiwalne

Sesja Netconf może być dedykowana do obsługi logów albo jeśli

obsługiwana jest opcja :interleave to pobieranie logów może

odbywać się jednocześnie z innymi operacjami

Klient otrzymuje informacje czy jest to log czy też odpowiedź na

wysłane polecenie – może wyświetlać to w różny sposób (różne

okna na przykład)

NETCONF – ROZSZERZENIA - NOTIFICATION


Obecnie tylko SSH

TLS – ale nie używany

SOAP, BEEP – nieużywane, wycofane

NETCONF – PROTOKÓŁ TRANSPORTOWY


Możliwość załadowania konfiguracji na wszystkie urządzenia

Sprawdzanie czy wszystkie urządzenia mogą przyjąć

przeznaczoną dla nich konfigurację

Jeśli tak to aktywacja na wszystkich urządzeniach

Jeśli coś się nie powiedzie to wycofanie zmian ze wszystkich

urządzeń

NETCONF – TRANSAKCJE NA POZIOMIE SIECI


Transakcje

Wprowadzenie wszystkich zmian albo żadnych

Nie ma znaczenia kolejność zdefiniowania poleceń

Konfiguracja z którą pracuje urządzenie jest automatycznie

zapamiętywana jako startowa

Standard pozwalający na jednakowy dostęp do urządzeń wielu

dostawców

Standaryzacja wielu zachowań CLI

Tworzenie obiektów nadrzędnych

Nadpisywanie

Usuwanie nieistniejących elementów

Jakie wartości muszą/nie mogą być podane przy usuwaniu

Praca z wartościami domyślnymi

NETCONF – CO TO TAK NAPRAWDĘ DAJE


Składnia poleceń konfiguracyjnych jest dalej całkowicie zależna

od konkretnego urządzenia

Jednak i na to jest odpowiedź

NETCONF – CZEGO TO NIE DAJE


Zdefiniowany standard

Model opisu konfiguracji pozwala na abstrakcję składni konfiguracji

niezależnie od modelu urządzenia

Pojawienie się standardowych opisów pozwala na konfigurację w

jednakowy sposób niezależnie od modelu urządzenia

Interface RFC 7223

IP Management RFC 7277

System Management RFC 7317

SNMP Configuration RFC 7407

Junos – od wersji 14.2

Można pobrać moduł YANG z urządzenia

show system schema module configuration format yang

YANG – JĘZYK OPISU KONFIGURACJI


Narzędzie konfiguracyjne bazujące na modelach Yang mogą

sprawdzać poprawność konfiguracji przed wysłaniem jej na

urządzenie

Możliwość zdefiniowania obsługiwanych trybów pracy

Prędkości obsługiwane przez miedziany port Ethernet

Family obsługiwane przez Multiprotocol BGP

Referencje

Możliwość odwołania do zdefiniowanych obiektów

konfiguracyjnych – co pozwala na przykład na zabezpieczenie ich

przed usunięciem

Management Vlan

YANG – DODATKOWE ZALETY


SNMP NETCONF

Pobieranie statystyk TAK TAK – ale szybciej

Ustawianie wielu zmiennych TAK (limit

64kB)

TAK

Transakcje NIE TAK

Polecenia operacyjne TROCHE TAK

Kopia zapasowa i odtwarzanie

konfiguracji

Z REGUŁY

NIE

TAK

Bezpieczeństwo W wersji 3 -

TAK

TAK

Test konfiguracji przed aktywacją NIE TAK

NETCONF PORÓWNANIE DO SNMP


SNMP NETCONF SOAP REST

Pochodzenie

standardu

IETF IETF W3C

Obiekty OIDs Paths URLs

Model danych MIBs Yang Core

Models

Protokół SNMP NETCONF XML Schema –brak standardu

HTTP

Format

danych

Binarny XML XML XML,

JSON

Transport UDP SSH SSLHTTP

SSLHTTP

NETCONF ORAZ ALTERNATYWY


Jesteśmy naprawdę blisko

Klienci mają już o co pytać dostawców

ŚWIĘTY GRAL


Narzędzia workflow

Ile razy można przepisywać dane z maili do tabelek w excelu

Opisane i zdefiniowane produkty

Nie mnożyć bytów – najlepiej korzystać ze wspólnych szablonów

opisujących poszczególne elementy składowe usługi

Lepiej aby szablon zawierał więcej opcji niż mniej (chociaż wtedy

trzeba dopilnować rozsądnych wartości domyślnych)

W OKOLICACH AUTOMATYZACJI


Przygotowanie zmian w konfiguracji urządzeń:

Uwzględniając nowo wprowadzaną lub zmienianą usługę

Uwzględniając stan obecny

Wgranie zmian na urządzenia

Sprawdzenie poprawności wprowadzanych zmian

Mechanizmy po stronie sieci – warstwa kontrolna

Mechanizmy po stronie sieci – warstwa danych

Mechanizmy po stronie klienta

Zapamiętanie wprowadzanych zmian

Lub przywrócenie sieci do stanu pierwotnego w przypadku

niepowodzenia

MASOWA ZMIANA KONFIGURACJI – NIEZBĘDNE KROKI


Obsługiwane mechanizmy zależne od konkretnego urządzenia

Wersji oprogramowania

Posiadanych licencji

Czy uruchamiamy usługę, czy kasujemy usługę czy zmieniamy

usługę

Kasowanie: quick and dirty vs slow and clean

Czy ma tylko nie działać, czy mają zostać usunięte wszystkie ślady

Zmiana: kasowanie starej i tworzenie nowej usługi ze zmienionymi

parametrami, czy też zmiana określonych parametrów

Kasowanie i tworzenie może generować przerwę w działaniu usługi dla

klienta jeśli urządzenia nie obsługują mechanizmu typu „commit” dla

konfiguracji

DOSTARCZANIE ZMIAN


Ręczne połączenie do urządzeń i wklejanie poleceń

Automatyczne połączenie do urządzeń i ładowanie zmian

konfiguracyjnych


konfiguracyjnych wraz z weryfikacją lokalną ich poprawności


konfiguracyjnych wraz z weryfikacją lokalną ich poprawności i

powrotem do stanu poprzedniego w wypadku wykrycia błędu.


konfiguracyjnych wraz z weryfikacją globalną ich poprawności i

powrotem do stanu poprzedniego w wypadku wykrycia błędu.

DOSTARCZANIE ZMIAN – ROZWÓJ SYSTEMÓW


Jak różne mechanizmy współgrają ze sobą

Czy zmiany są widoczne w standardowej konfiguracji

urządzenia

Czy będą nadal aktywne po restarcie

Czy zostaną zapamiętane przez mechanizm archiwizacji

konfiguracji

Mnie mechanizmów – lepiej

DOSTARCZANIE ZMIAN – DO ROZWAŻENIA


To TRZEBA dobrze sprawdzić

Jasno zdefiniować jakie parametry będzie mógł zmieniać

automatyczny mechanizm

Jeśli urządzenia to umożliwiają to należy udostępnić dla

mechanizmu automatycznego tylko cześć parametrów

konfiguracyjnych

Logowanie na prawach innego użytkownika niż normalny

administrator

Dla urządzeń obsługujących mechanizm commit/rollback –

wprowadzenie zmian w jednym przebiegu narzędzia i ich

zatwierdzanie na stałe po weryfikacji

DOSTARCZANIE ZMIAN - TESTOWANIE

PLNOG14: Network Automation - Sławomir Janukowicz

Internet

Transcript of PLNOG14: Network Automation - Sławomir Janukowicz