Продолжуваме да навлегуваме во техничките детали за Cisco NSO и неговата употреба во автоматизацијата на мрежи. Денешната тема е NETCONF/YANG, со одговори на сите прашања за кога, каде и како. Ќе има многу споредби со SNMP, особено со верзија 2c, па затоа добро разбирање на SNMP, неговата историја и дизајнможеби не е задолжително, но дефинитивно претставува одлична основа за да се извлече максимумот од оваа статија за Cisco NSO и автоматизација на мрежи.
Што е NETCONF/YANG?
NETCONF и YANG се две различни, но поврзани технологии:
NETCONF е протокол кој ќе го разгледаме подетално.
YANG е јазик за моделирање што се користи за да се опишат атрибутите што може да ги има мрежен уред, како што е неговата конфигурација.
Овие две технологии често се спомнуваат заедно во автоматизацијата на мрежи бидејќи најчесто се користат заедно, но нивната употреба не е задолжителна.
NETCONF
NETCONF е XML-базиран протокол што користи RPC-стил на комуникација. За разлика од SNMP, NETCONF е сесија каде што едната страна се идентификува како сервер, а другата како клиент.
Со функцијата „NETCONF call home“, за разлика од SNMP (за сега ги игнорираме traps), уредот може да се поврзе со системот за управување наместо пасивно да чека дојдовни конекции. Затоа, NETCONF мора да знае кој е сервер, а кој клиент. Cisco NSO ја искористува оваа функција во автоматизацијата на мрежи со автоматско управување со уреди што „се јавуваат дома“.
NETCONF call home нуди две главни предности:
Наместо отворање порти на заштитени мрежи за дојдовен сообраќај, уредот воспоставува врска кон системот.
Го подобрува управувањето, бидејќи не е потребно тестирање на врски со неактивни јазли што можеби нема да одговорат.
Сесиите во NETCONF, без разлика дали се воспоставени преку call home или не, мора да исполнуваат одредени барања што SNMP не ги има:
Автентикација
Конфиденцијалност (енкрипција)
Гарантирана испорака и редослед на команди
Исто како кај HTTP, постои pipelining, што значи дека може да се испрати нова команда пред да се добие одговорот на претходната. Но, одговорите мора да пристигнат во истиот редослед како што се испратени командите. Ова е клучна разлика од SNMP-walk, каде што UDP-пакетите може да се преподредат без да го прекршат протоколот.
Друга важна карактеристика на NETCONF е начинот на кој ги управува функциите на уредот. Сесијата започнува со тоа што двете страни се идентификуваат како сервер или клиент. Потоа, како во BGP, обете страни најавуваат дополнителни функции што ги поддржуваат.
Зошто е ова важно?Затоа што не е невообичаено опремата да тврди дека поддржува NETCONF, но всушност да ги има само основните функции, или дури ни нив. Само затоа што „NETCONF“ е наведен на производен лист, секогаш е потребна дополнителна проверка. Ова е критично за Cisco NSO консултантите и нивната работа со автоматизација на мрежи.
YANG
Yet Another Next Generation (YANG) е јазик за моделирање што се користи за да се дефинира каде и како се управува со податоците во систем што комуницира преку NETCONF.
YANG создава дрвовидна структура на податоци, слично како SNMP. YANG-датотека за даден уред има иста улога како MIB-датотека во SNMP, бидејќи:
Дефинира каде во хиерархијата се наоѓа одредена променлива
Како треба да се толкува нејзината вредност
Кои вредности се дозволени, а кои не
Исто како кај MIB-датотеките во SNMP, каде што позицијата и вредноста на променливите се конвертираат во ASN.1/SNMP формат, YANG податоците се конвертираат во XML-репрезентација на моделот кога се пренесуваат преку NETCONF. Оваа XML-репрезентација понекогаш се нарекува YIN.
Овој процес е централен за тоа како Cisco NSO управува со конфигурациите во автоматизацијата на мрежи, бидејќи NED-модулите што ги користи NSO ја обработуваат токму оваа XML-форма.
Клучна разлика од SNMP:
Уред што поддржува NETCONF/YANG треба директно да ги обезбеди YANG-моделите, така што NETCONF клиентот може да ги преземе директно од уредот.
Кај SNMP, MIB-датотеките често не се јавно достапни и мора да се добијат од добавувачот.
Оваа разлика ја прави NETCONF/YANG пофлексибилна и транспарентна опција за автоматизација на мрежи.
Зошто NETCONF/YANG?
Од горенаведеното, јасно е дека NETCONF/YANG претставува значително подобрување во однос на SNMP, особено за уреди што поддржуваат напредни NETCONF функции, како што се:
Кандидат-конфигурации (candidate configurations)
Автоматски rollback при грешки
Дури и за системи што поддржуваат само основни функции, главната предност е што конфигурацијата може да се заклучи (lock) од други сесии, што не е возможно со SNMP.
Но како и секогаш не е толку едноставно една од најголемите недостатоци е дека сè уште постои многу различна поддршка за функциите кај опрема што тврди дека има поддршка за NETCONF дури и ако стои како што претходно беше наведено на производниот лист дека постои одредена функција таа мора прво да се тестира за да се види дали навистина функционира во практика особено во контекст на автоматизација на мрежи и Cisco NSO
Постојат и работи како RESTCONF кој понекогаш користи YANG но преку REST наместо NETCONF за да се создаде протокол што е некаде помеѓу SNMP и NETCONF кога станува збор за управување со податоци една последна забелешка за NETCONF/YANG е дека исто како во SNMP постојат обиди за создавање на стандардни модели што треба да функционираат насекаде и со сите добавувачи во NETCONF/YANG овие доаѓаат од OpenConfig но иако многу добавувачи пријавуваат поддршка за нив тоа завршува исто како во SNMP со тоа што ќе мора да се користат YANG-моделите на добавувачот бидејќи ако сите правеа точно исти функции со истите модели ќе можеа да се натпреваруваат само во цената што не е посакувана состојба за ниту еден добавувач разликата од SNMP каде што RFC MIB-датотеките се специфицирани за протоколот и ако не се следат тогаш во суштина не се прави SNMP правилно е тоа што кај YANG-моделите ретко или никогаш не постојат такви RFC-специфицирани врски
Едно мало отстапување, Streaming Telemetry и аларми
Ако си стигнал до тука, пред сè, браво! Веројатно си се запрашал нешто за SNMP-traps за алармирање, бидејќи вешто ја избегнав таа тема претходно. Како можеме да собираме метрики од уредите како замена за SNMP?
Еден клучен дел од автоматизацијата на мрежи е како NETCONF управува со аларми и телеметрија, што е централен дел за Cisco NSO.
Кога станува збор за SNMP-traps, NETCONF има слична функција наречена „event notifications“. За разлика од SNMP, каде што уредот испраќа traps кон однапред конфигуриран систем без разлика дали тој систем го побарал тоа или дури и постои, кај NETCONF клиентот се претплатува на листа на настани.
Оваа листа може да содржи сè, од специфични настани до буквално сите настани што ги поддржува уредот, а NETCONF серверот потоа испраќа известувања на ист начин како SNMP-traps.
Истото важи и за метриките. NETCONF клиентот може да постави една или повеќе претплати за податоци од серверот, на пример количината на пакети во секунда преку интерфејс. Податоците може да се испраќаат на одреден интервал, како кај SNMP polling, или да се конфигурираат да се испраќаат само кога ќе се променат, што можеби не е идеално за броење пакети на интерфејс, но може да биде корисно за следење на бројот на префикси во BGP-сесија.
Потребна ви е помош за започнување со автоматизација на мрежи и Cisco NSO?
Без разлика дали ви треба помош со анализа, имплементација или долгорочна поддршка, нашите искусни Cisco NSO консултанти можат да ве водат низ секој чекор од процесот.
Со правилна поддршка, можете максимално да ги искористите придобивките од автоматизацијата на мрежи, да ги намалите трошоците и да ја подобрите севкупната ефикасност на вашата мрежа.
Контактирајте нè денес за да дознаете како можеме да му помогнеме на вашето претпријатие да постигне успех со автоматизација на мрежи и Cisco NSO!
Comments