Vi fortsätter fördjupa oss i de de tekniska detaljer inom Cisco NSO och dess användning inom nätverksautomation. Dagens ämne är NETCONF/YANG, med svar på alla frågor om när, var och hur. Det kommer vara många jämförelser med SNMP, speciellt version 2c, så en god förståelse av SNMP, dess historik och design är kanske inte ett måste, men definitivt ett en bra grund för att få ut så mycket som möjligt av denna artikel om Cisco NSO och nätverksautomation.
Vad är NETCONF/YANG?
NETCONF och YANG är två olika men sammanlänkade teknologier: NETCONF är ett protokoll som vi kommer titta närmare på, YANG är ett modellspråk som används för att beskriva attribut som en nätverksenhet kan ha, exempelvis dess konfiguration. De två skrivs ofta samman inom nätverksautomation för att det används ofta tillsammans, men det är inte ett krav.
NETCONF
NETCONF är ett XML baserat protokoll som använder sig av RPC-stil för kommunikation. Till skillnad från SNMP är NETCONF en session där ena sidan identifierar sig som server och andra sidan som klient. Med funktionen ”NETCONF call home”, där till skillnad från SNMP (vi ignorerar trappar tills vidare), utrustningen kan ansluta ut till managementsystemet istället för att vara passiv och endast ta emot anslutningar måste NETCONF veta vem som är server och klient. Cisco NSO drar nytta av denna funktion inom nätverksautomation, genom att automatiskt hantera utrustningen som “ringer hem”.
NETCONF call home har två omedelbara fördelar: istället för att peta hål i brandväggar och annat för inkommande trafik till säkrade miljöer kan anslutningen gå ut.Det gör att managementsystemet blir mer effektivt, då det inte behöver testa anslutningar till inaktiva noder som kanske inte svarar beroende på situation.
Sessioner i NETCONF, oavsett om de sätts upp genom call home eller inte, måsteuppfylla en rad krav som inte finns i SNMP. Sessioner måste vara autentiserade, konfidentiella och därför krypterade, samt garantera både leverans och ordningen på de kommandon som skickas och svaren som kommer tillbaka. Precis som i HTTP kan man skicka nästa kommando innan man fått svar på det tidigare, det vill säga 'pipelining', men den som svarar måste skicka svaren i den ordning som kommandona togs emot. Detta är en markant skillnad från exempelvis en SNMP-walk, där UDP-paket kan omordnas utan att bryta mot protokollstandarden.
Utöver detta finns en sista viktig sak att veta om NETCONF, och det är hur protokollet hanterar utrustningens funktioner. En NETCONF-session startar med att båda sidor identifierar sig som antingen server, som tar emot kommandon, eller klient, som skickar kommandon för att utföras. Precis som i BGP annonserar båda sidor vilka extra funktioner de stödjer, utöver de grundfunktioner som måste ingå i NETCONF. Om båda sidor stödjer en extra funktion, kan den användas inom den sessionen. Varför är denna detalj viktig?Jo, för det är inte ovanligt med utrustning på marknaden som säger sig stödja NETCONF men bara har basfunktionerna, och ibland inte ens det. Så bara för att det står NETCONF på produktbladet så måste man alltid kolla lite närmare och ställa frågorna om vad de stödjer och inte,något som är kritiskt för Cisco NSO-konsulter och deras arbete med nätverksautomation.
YANG
Yet Another Next Generation (YANG) är ett modellspråk som används för att definiera var och hur data hanteras i ett system som talar NETCONF. YANG skapar en trädstruktur av data, likt hur SNMP fungerar. En YANG-fil för en utrustning fyller samma roll som en MIB-fil gör i SNMP, genom att ange var i trädet en specifik datavariabel finns och hur den ska tolkas, samt vilka värden som är acceptabla och vilka som inte är det.
Precis som MIB-filer i SNMP, där variabelns position och värde konverteras till ASN.1/SNI-format, konverteras YANG-data till en XML-representation av modellen när det transporteras över NETCONF. Denna representation kallas ibland för YIN. Denna process är central för hur Cisco NSO hanterar konfigurationer inom nätverksautomation, då XML-representation används av de NEDs som vi talat om i tidigare artikel.
En markant skillnad från SNMP är dock att en utrustning som stödjer NETCONF/YANG även ska komma med YANG-modellfilerna tillgängliga direkt från utrustningen så att en NETCONF klient kan ladda ner dem direkt från utrustningen istället för som i SNMP där MIB-filer ibland endast är tillgängliga från leverantören och ej publika.
Varför NETCONF/YANG?
Med ovan beskrivning så borde det vara rätt uppenbart att det är en förbättring jämfört med SNMP, speciellt för utrustningar som stöder NETCONF extra funktioner, såsom kandidatkonfigurationer och automatisk rollback vid fel. För system som endast stödjer grundfunktioner är den stora fördelen att konfigurationen kan låsas från andra sessioner, vilket inte är möjligt i SNMP exempelvis.
Men som alltid är det inte så enkelt. En av de största nackdelarna är att det fortfarande finns väldigt varierande stöd för funktioner hos utrustning som påstår sig ha NETCONF-stöd. Även om det står, som tidigare noterat, på produktbladet att det finns en funktion måste den testas först för att se att den verkligen fungerar i praktiken, särskilt i samband med nätverksautomation och Cisco NSO.
Det finns även saker som RESTCONF, som ibland använder YANG, men över REST istället för NETCONF, för att skapa ett protokoll som är någonstans mitt emellan SNMP och NETCONF när det gäller hantering av data.En sista notis om NETCONF/YANG är att det, precis som i SNMP, finns försök att skapa standardmodeller som ska fungera överallt och med alla leverantörer. I NETCONF/YANG kommer dessa från OpenConfig, men även om många leverantörer rapporterar stöd för dem, så slutar det precis som i SNMP med att man kommer behöva använda leverantörens YANG-modeller. För om alla gjorde exakt samma funktioner med samma modeller, skulle de endast kunna konkurrera på pris vilket inte är en önskvärd situation för någon leverantör. En skillnad från SNMP där RFC MIB-filer är specificerade för protokoll och om man inte följer dem så gör man egentligen inte SNMP korrekt, så finns det sällan eller aldrig sådana RFC -specificerade länkar för YANG-modeller.
Ett sidospår, Streaming Telemetry och larm
Om du har läst så här långt, först och främst, bra jobbat! Sedan har du nog ställt dig en eller annan fråga om SNMP-trappar för larm då jag gymnastiskt hoppade över den punkten tidigare. Och hur kan vi hämta in mätvärden från utrustningen som ersätter SNMP? En viktig funktion inom nätverksautomation är hur NETCONF hanterar larm och telemetri vilket är centralt för Cisco NSO. När det kommer till SNMP-trappar, har NETCONF en liknande funktion kallad ”event notifications”. Till skillnad från SNMP, där utrustningen skickar trappar till ett konfigurerat system oavsett om systemet har bett om det eller ens existerar, så prenumererar en NETCONF-klient på en lista av events. Denna lista kan omfatta allt från något specifikt till bokstavligen alla events som stöds av utrustningen, och NETCONF-servern skickar sedan meddelanden precis som SNMP-trappar gör.
Samma sak gäller mätdata. En NETCONF-klient kan sätta upp en eller flera prenumerationer på data från servern, exempelvis mängden paket per sekund över ett interface. Data kan antingen skickas med ett intervall, precis som SNMP poll tider, eller så kan man specificera att data ska skickas när den ändras, vilket kanske inte är vad vi vill ha när det kommer till en paketräknare på ett interface. Däremot kan det vara användbart om vi vill veta mängden prefix som vi tar emot på en BGP-session, det borde vara rätt stabilt om vi inte tar full tabell utan exempelvis en default plus kunder från vår leverantör.
Behöver ni hjälp att komma igång med nätverksautomation och Cisco NSO?
Oavsett om du behöver hjälp med analys, implementering eller långsiktigt stöd, kan våra erfarna Cisco NSO-konsulter guida dig genom varje steg i processen. Med rätt stöd kan du maximera fördelarna med nätverksautomation, minska kostnaderna och förbättra den övergripande effektiviteten i ditt nätverk. Kontakta oss idag för att få reda på hur vi kan hjälpa ditt företag att lyckas med nätverksautomation och Cisco NSO!
Bình luận