YANG, NETCONF i RESTCONF
YANG (Yet Another Next Generation)
YANG (Yet Another Next Generation) jest językiem służącym do modelowania danych czy też inaczej opisywania danych. Został opisany w dokumentach RFC 7950 (YANG) i RFC 6020 (YANG+NETCONF). Model danych standaryzuje dane oraz sposób ich organizacji, zachowania i wzajemnego powiązania.
W przypadku urządzeń sieciowych nie pracuje się bezpośrednio na plikach czy bazie danych. Konfiguracja dostępna jest poprzez odpowiedni interfejs, jak m.in. WebUI czy CLI. Każdy z nich udostępnia w stronę zarządzającego jakiś model danych, na którym musi on dalej pracować. Jest on tak zaprojektowany, aby był wygodny w użytkowaniu oraz intuicyjny dla osoby pracującej na nim. W przypadku WebUI może być to jakaś tabelka lub formularz, a w przypadku CLI określona składania poleceń.
Każde z urządzeń posiada także jakiś wewnętrzny model danych, którego celem jest przechowywanie i przetwarzanie danych w sposób najwygodniejszy dla urządzenia.
Najczęściej na urządzeniach sieciowych konfigurujemy te same zestawy standardowych i otwartych protokołów. W związku z tym, ten wewnętrzny model danych jest na tyle podobny pomiędzy urządzeniami różnych producentów, że bez względu na to, czy korzystamy z urządzenia firmy Cisco Systems czy firmy Juniper Networks, to do skonfigurowania tej samej funkcjonalności musimy dostarczyć ten sam zbiór parametrów i danych. Dostarczamy go za pomocą wygodnego dla nas modelu danych (najczęściej WebUI lub CLI), jaki jest udostępniany przez urządzenia w naszą stronę. Natomiast docelowo i tak ten zbiór parametrów i danych zostanie umieszczony wewnątrz struktury modelu danych, który jest wygodny w przetwarzaniu dla urządzenia.
Na rysunku poniżej, z użyciem kolorowego tła zostały oznaczone trzy niezbędne parametry, jakie należy dostarczyć urządzeniu, aby skonfigurowało dodatkową sesję BGP. W zależności od urządzenia, dokonać tego można na różne sposoby i przy użyciu różnych składni. Po lewej widać składnię Cisco, a po prawej składnię Juniper. Każda z nich obudowuje te trzy niezbędne parametry odpowiednią strukturą, która pozwala lepiej zrozumieć powiązania i relacje pomiędzy nimi.
W związku z tym, że różne urządzenia sieciowe potrzebują tych samych danych do realizacji tego samego zadania, wewnętrzny model danych może zostać zestandaryzowany i znormalizowany w taki sposób, aby był spójny dla rozwiązań różnych producentów. Oczywiście takich urządzeń czy rozwiązań, które oferują w jakimś stopniu tą samą funkcjonalność.
I tak też się stało, kiedy powstały otwarte modele danych IETF i OpenConfig. Wykorzystują one język modelowania danych YANG. Ich celem jest normalizacja zarówno danych, jak i ich struktury oraz gramatyki. Dzięki temu, nie trzeba się przejmować różną składnią i sposobem powiązania ze sobą poszczególnych obiektów u każdego z producentów.
Model YANG normalizuje wartości danych konfiguracyjnych i stanów operacyjnych, a także ich strukturę, składnię oraz gramatykę. Dane modelu YANG zapisywane są w kilku formatach:
- XML (eXtensible Markup Language): "<tag>value</tag>".
- JSON (JavaScript Object Notation): "{ „key”: „value” }".
- YAML (YAML Ain’t Markup Language): "key: value".
Model danych YANG tworzy jakby szablon, na podstawie którego dopiero generowane są dane w formacie XML, JSON lub YAML. Zapisane w którymś z tych formatów dane modelu YANG przesyłane są za pomocą:
- NETCONF (SSHv2, XML) – 830/TCP,
- RESTCONF/API (HTTP, XML/JSON) – 443/TCP.
O ile do typowych urządzeń sieciowych dane są wysyłane za pomocą NETCONF lub RESTCONF, to niektóre systemy diagnozowania, monitorowania czy zarządzania oferują na tyle zróżnicowane zbiory funkcjonalności, że dostęp do nich odbywa się poprzez specyficzne dla nich REST API.
Model YANG organizuje dane w strukturze drzewa, w którym każdy węzeł ma nazwę i odpowiadającą jej wartość lub zestaw węzłów potomnych. Da się w nim opisać ograniczenia i obostrzenia dla danych, a także zależności pomiędzy nimi. Jest on rozszerzalny i umożliwia warunkowe dołączanie do hierarchii dodatkowych struktur danych.
Każde z rozwiązań może posiadać dodatkowe funkcjonalności, których dane składowane są w natywnym dla niego modelu danych YANG. Zwykle model otwarty jest oddzielnym drzewem lub fragmentem drzewa modelu natywnego, który pozwala w ten sam sposób odwoływać się do tych samych danych na różnych urządzeniach.
Istnieje w nim także rozgraniczenie pomiędzy danymi konfiguracyjnymi, a stanami operacyjnymi i statystykami. Jest to coś, czego brakowało w drzewie MIB (Management Information Base) protokołu SNMP (Simple Network Management Protocol). Dane te były tam wymieszane, co utrudniało pobieranie konfiguracji czy możliwość jej łatwego porównania. To sprawiało, że protokół SNMP stosowany był głównie tylko do monitorowania i zbierania statystyk.
Zainteresowanych automatyzacją sieci, systemów IT, centrów danych i środowisko DevOps, a także zakupem i ew. potem wdrożeniem Cisco NSO lub platformy Red Hat Ansible Automation Platform zapraszamy do
NETCONF (NETwork CONFiguration)
NETCONF (NETwork CONFiguration) został opisany w dokumencie RFC 6241. Za jego pośrednictwem możemy modyfikować konfigurację, wykonywać różne operacje oraz odpytywać urządzenia sieciowe o aktualny stan. Definiuj on możliwe do wykonania na urządzeniach operacje i dostępne przestrzenie konfiguracji. Model YANG opisuje dane, które możemy za pomocą protokołu NETCONF ustawiać, konfigurować, monitorować i zbierać oraz możliwe do wykonania operacje i obsługiwane powiadomienia. YANG jest przyjętym i jednoznacznym sposobem opisu danych przenoszonych za pomocą protokołu NETCONF.
NETCONF wymienia wiadomości RPC (Remote Procedure Call) w formacie XML (eXtensible Markup Language) za pomocą protokołu SSH (Secure Shell) i portu 830/TCP. W ten sposób cała komunikacja oraz wymiana danych opisanych w modelu YANG odbywa się bezpiecznie, wewnątrz szyfrowanego połączenia.
NETCONF/YANG separuje stany operacyjne oraz statystyki od konfiguracji, dzięki czemu możemy łatwo odczytywać i sprawdzać tylko to co nas interesuje. Ułatwia to okresową weryfikację zgodności oraz kontrolę spójności konfiguracji.
Można pobrać całą konfigurację urządzenia, czy dzięki funkcji selektywnego filtrowania tylko specyficzne jej fragmenty. Dzięki temu możemy porównać interesujący nas fragment konfiguracji i wygenerować minimalny zbiór modyfikacji, jaki trzeba wysłać do urządzenia, w celu doprowadzenia go do żądanego stanu.
Istnieje także możliwość różnicowania dostępów do poszczególnych fragmentów drzewa modelu YANG, w skład którego wchodzą też odpowiednie operacje, jakie można wykonać na urządzeniu.
Dzięki obsłudze wielu przestrzeni konfiguracji (candidate, startup, running), mamy możliwość jej wcześniejszego przetestowania przed trwałym zapisaniem oraz ewentualnego wycofania i powrotu do poprzedniej wersji w razie niepowodzenia czy problemów. Proces dystrybucji konfiguracji jest odseparowany od jej aktywacji i przywracania. Daje to możliwość wykonywania zmian w sposób atomowy zarówno na pojedynczych urządzeniach, jak i w ramach całej sieci, składającej się z wielu różnych urządzeń.
Jest to jedną z większych zalet NETCONF, która sprawia że idealnie nadaje się on do zarządzania, modyfikacji i uruchamiania nowych usług w ramach wielu urządzeń. Uruchomienie lub modyfikacja danej usługi realizowana jest w ramach jednej transakcji, która musi prawidłowo przebiec na wszystkich urządzeniach.
Sposób konfiguracji zorientowany na usługi jest tym, o czym marzy większość operatorów. Przy kreowaniu usług w dużych sieciach nikt nie chce za każdym razem przechodzić przez specyfikę konfiguracji każdego z urządzeń z osobna. Jest ich zbyt dużo, a ewentualna pomyłka jest zbyt kosztowna. O wiele lepiej jest działać z wyższego poziomu i tak modnie mówiąc orkiestrować (ang. orchestration) takie zmiany, do czego NETCONF jest idealny.
Na rynku jest zbyt dużo sprzętu z szarego kanału. Dlatego koniecznie sprawdzaj, czy firma sprzedająca produkty danego producenta jest na 100% jego partnerem handlowym. Sprawdź, jakie ryzyko niesie ze sobą szary kanał.
RESTCONF (REST CONFiguration)
RESTCONF (REST CONFiguration) umożliwia dostęp do danych opisanych modelem YANG za pośrednictwem REST API. Jest protokołem bezstanowym, który do identyfikacji operacji CRUD (Create, Read, Update, Delete) używa wbudowany metod w protokół HTTP. Wykorzystuje protokół HTTPS do przesyłania konfiguracji, stanów oraz procedur RPC (Remote Procedur Call). Dane wiadomości HTTP zakodowane są z użyciem formatu XML lub JSON. Do działania wykorzystuje port 443/TCP.
RESTCONF ma zastosowanie przy prostych zmianach konfiguracji, które realizowane są sekwencyjnie jedna po drugiej, przy odpytywaniu o stan oraz zbieraniu danych statystycznych. Tak samo jak NETCONF, obsługuje powiadomienia o zdarzeniach. Jest on o wiele prostszy od NETCONF i udostępnia mniejszą funkcjonalność. W praktyce obsługuje jedną przestrzeń konfiguracji i brak w nim możliwości nakładania na nią blokad. RESTCONF nie udostępnia funkcji walidacji konfiguracji z opcją zatwierdzenia zmian. Nie obsługuje również transakcji w ramach wielu urządzeń. Zapewnia jedynie transakcje na poziomie pojedynczej operacji w ramach jednego urządzenia. RESTCONF opisany został w RFC 8040.
Efektywna i niezawodna automatyzacja oraz bardzo elastyczna programowalność są dziś naprawdę bardzo ważne. Do tego dochodzi kwestia zgodności z przyjętym na rynku ekosystemem DevNet. Dlatego jeszcze przed zakupem warto upewnić się, czy wybrany sprzęt sieciowy na pewno obsługuje YANG, NETCONF i RESTCONF. Nie jesteś pewny? Skontaktuj się z
Niemniej, jeżeli dany producent nie zatrzymał się technologicznie i nadąża za zmieniającym się światem IT, to za pewne jego produkty będą radzić sobie z obsługą YANG, NETCONF i RESTCONF bez najmniejszych problemów. Szczególnie, że są one z nami już od bardzo dawna i powinny być dostępne w urządzeniach sprzedawanych na rynku już od dobrych paru lat.
