För relaterade artiklar som delas av mig om nätverksautomation, se katalogen "NetDevOps from Scratch"
Under de senaste åren, med den kontinuerliga utvecklingen av det globala cloud computing-området och den kontinuerliga tillväxten av affärer, har även nätverkstekniken fortsatt att utvecklas och SDN-tekniken har vuxit fram. Från den ursprungliga kärnidén om separation av vidarebefordran och kontroll baserad på Openflow, fortsätter människor att expandera I förlängningen av SDN kan människor för närvarande nå en konsensus om att Openflow inte längre är ett nödvändigt villkor (men separationen av vidarebefordran och kontroll är fortfarande ett kärnvillkor), och nätverksprogrammerbarhet har sakta blivit ett av de viktiga kriterierna för att mäta en SDN-arkitektur.
Programmerbar drift av traditionell nätverksutrustning baseras i allmänhet på CLI- och SNMP-protokoll. Oavsett om skript eller programvara för nätverkshantering, de är alla utvecklade på denna grund för att uppnå det breda utbudet av nätverksprogrammerbarhet vi ska prata om idag. kapacitet, och därigenom realisera automatiseringen av många scenarier. Vissa enheter stöder konfigurationen av vissa webbgränssnitt och ersättning av den övergripande konfigurationen genom xml. Dessa är mycket sällsynta och kommer inte att beskrivas i detalj i den här artikeln.
CLI
CLI (Command-line Interface) realiserar interaktion mellan människa och dator via kommandoraden. Det är en nödvändig färdighet för nätverksarbetare. Människor öppnar programvaran SSH eller Telnet till enheten varje dag, klistrar sedan in en konfiguration, sparar den och träder i kraft. En dag tröttnade folk på den här typen av upprepningar och använde ett program för att automatiskt generera konfigurationsskript, logga in på enheten i omgångar och utfärda konfigurationer för att träda i kraft, förverkliga automatisering. Detta är en nätverksprogrammerbar metod. Låt oss prata om fördelarna, som är mycket förenliga med människors tänkande, idéer och befintliga tekniska system. Men i slutändan gynnar detta tillvägagångssätt människor framför nätverksenheter. Det har följande nackdelar:
-Det finns enorma skillnader i kommandouppsättningar mellan tillverkare. Inte bara tillverkare, utan olika programvaruversioner av samma modell kan ha mycket olika skillnader.
-Utvecklare måste vara bekanta med kommandouppsättningen och hur man använder den. Det finns säkerhetsrisker på konfigurationsnivån. Till exempel, med ett snärt förvandlades porten jag ville öppna till att stänga porten...
-Det finns inga obligatoriska krav på överföringsprotokoll (SSH och Telnet), och det finns produktionssäkerhetsrisker.
- Processen att analysera och generera konfigurationer är extremt komplicerad. I många fall kan de vanliga reglerna som skrivs bara vara oändligt nära "sanningen", men inte hela "sanningen".
-Det finns ingen transaktionalitet, och en konfiguration kan delvis träda i kraft och delvis inte träda i kraft.
-Det finns ingen automatiserad inspektionsmekanism och den är helt beroende av människor. Jag vill till exempel testa om det genererade skriptet är korrekt. Det finns ett sätt, men det är väldigt svårt och ofta svårt att genomföra enkelt.
-Ingen aning om datamodellering
CLI är alltid ett sätt att interagera mellan människa och dator. Det kan ge nätverket vissa programmerbarhetsmöjligheter genom program, men trots allt är det inte en metod som i sig är nätverksprogrammerbar. Under den nuvarande vågen av cloud computing och SDN är den inte lämplig för storskalig automatiserad distribution i nätverket, och dess programmerbarhet är begränsad. Det är svårt för utomstående att förstå svårigheten med utveckling.
SNMP
SNMP (SNMP, Simple Network Management Protocol), detta protokoll kan stödja nätverkshanteringssystem för att övervaka om enheterna som är anslutna till nätverket har någon situation som orsakar hanteringsuppmärksamhet. Den består av en uppsättning nätverkshanteringsstandarder, inklusive ett applikationslagerprotokoll, databasschema och en uppsättning dataobjekt.
För ett stycke innehåll i Wikipedia lyfter vi fram nätverkshantering, övervakning och dataobjekt. Den används för att hantera nätverket, kan konfigureras och samlas in och används främst för övervakning. Den har datamodellering för att strukturera vissa moduler, egenskaper och statusdata för nätverksutrustning. Det används främst för nätverkshanteringssystem (mestadels övervakning). Låt oss sedan prata om dess brister:
-Dålig läsbarhet. Den föredrar "maskinen" i människa-maskin. Den är inte läsbar när den används, och modelleringsdata är inte heller läsbar. Den använder en superset av ASN.1.
-Säkerheten är begränsad. Det finns tre versioner: v1, v2c och v3, och säkerheten förbättras i följd. Den vanligaste är dock v2c, som har begränsad säkerhet. V3-versionen är mycket säker genom designen, men den är inte universell. . .
-Det finns ingen mekanism för säkerhetskopiering, återställning eller återställning. Vi har också show run och andra metoder för att säkerhetskopiera kommandoraden, men snmp. . .
-Väldigt få skriver. Läs mycket, skriv lite, används mest för övervakning.
-Dataobjekten som kan samlas in är begränsade och konfigurationen av hela enheten kan inte erhållas. Många gånger upptäcker vi att vi kan använda cli för att samla in det, men vi kan inte använda snmp för att samla in det.
-Det finns en prestationsflaskhals. Den övre gränsen för insamlad data är 64K och insamlingsgranulariteten är för stor. I stora och komplexa nätverk kan det ta minuter eller längre. Detta belyser också den viktiga punkten. Våra krav på granularitet är också mycket stränga. Många gånger hoppas vi kunna samla hamntrafik med några sekunders mellanrum. I stora nätverk tror jag att traditionell programvara för nätverkshantering är... För att utöka en mening till är den nuvarande metoden Telemetri (som gRPC) som kan uppnå mikrosekundnivå, och vissa kräver en kombination av mjukvara och hårdvara. Det är ännu inte populärt, men i framtiden måste det vara en trend. Om när detta kommer i framtiden...
-Sedan dess födelse har SNMP använts mycket inom nätverksövervakning för att få data för övervakning. Avsaknaden av och komplexiteten hos konfigurationsmöjligheter har lett till liten användning av den i nätverkskonfiguration. Skrivskyddat nätverksprogrammerbart.
Netconf-protokoll och YANG-modell
Inför nästa generations nätverk, vilken typ av nätverkshanteringsprotokoll behöver vi för att bättre förverkliga nätverksprogrammerbarhet och förbättra automationsnivån?
IETF föreslog följande idéer i RFC3535 2002 (det finns faktiskt 33 av dem. Baserat på information online och författarens kunskap skrev jag följande idéer):
1. Det finns ett programmerbart gränssnitt för nätverkskonfiguration
2. Samma konfiguration kan användas mellan tillverkare och modeller
3. Behöver förena ett modelleringsspråk med god läsbarhet
4. Slutför felkontroll och återställningsfunktioner
5. Transaktionell
Om du har en idé är det bara att implementera den. 2006 föreslog IETF Netconf-protokollet, som löste problemen som RFC3535 tog upp. Den initiala Netconf angav bara det grundläggande ramverket och operationerna för protokollet, och definierade lösningar som tog hänsyn till vissa problem med RFC3535. Det föreskrev inte ett enhetligt modelleringsspråk. Därför stödde vissa tidiga tillverkares utrustning bara vissa grundläggande funktioner för Netconf, och använde inte ett enhetligt bottenskikt. Datamodelleringsspråk.
RFC6020 släpptes 2010 och föreslår modellspråket YANG Model och en metod för att kombinera det med NETCONF. En definition är ett datamodelleringsspråk som förenar den underliggande resurslogiken mellan tillverkare, och den andra definitionen är en enhetlig kommandouppsättning för varje tillverkares operationer på konfigurationsdata och statusdata. Datainstanserna som skapas av YANG-modellen är inslagna i Netconf-protokollet. Transmission, de två kombineras med varandra för att bygga en ny uppsättning universella nätverksprogrammerbara gränssnitt för den nya eran baserat på YANG-modellen och drivs av Netconf-protokollet.
Efter 2016 var Netconf-protokollet nära integrerat med YANG-modellen och blev populärt. Hittills, när vi tittar på några SDN-arkitekturprogramvaruaspekter, har vi hört dessa två termer mer eller mindre.
YANG och Netconf, den ena är statisk och den andra är dynamisk, precis som yin och yang. De två har härlett den nätverksprogrammerbara världen från nästa era. (När vi tittar på YANG-lagret på github kommer vi också att upptäcka att dess ikon är Tai Chi, och kopplingen mellan dess namn och "Yang" avslöjar något den ursprungliga designerns designidéer).
Därefter kommer vi kort att prata om YANG-modellen och Netconf-protokollet. Låt oss först prata om datamodelleringsspråket YANG för att se hur det beskriver den digitala tvillingen i denna nätverksvärld.
YANG modell
I RFC6020-dokumentet står det tydligt i det inledande kapitlet, YANG, A Data Modeling Language for the Network Configuration Protocol. Det är förkortningen av Yet Another Next Generation (Yang) Data Modeling Language. Det är ett modelleringsspråk som används för att beskriva nätverkskoncept.
Stöder definition av listor, ordböcker och ännu mer komplexa datastrukturer, stöder begränsningar, uppräkningar, referensimport, versionshantering och namnutrymmen. På grund av utrymme kommer vi att ge en kort förklaring. För detaljerad information kan du hänvisa till:
Den kan beskriva denna nätverksenhet mycket enkelt i ett strukturerat språk. Till exempel, för definitionen av en port:
Som professionell drift- och underhållspersonal, med lite nätverksgrunder och lite programmeringsgrunder, kan du förstå definitionen av en port relativt tydligt. Det är en liststruktur och det kan finnas flera. Ett av dess attribut är gränssnittsnamn (även en nyckel). , unik, icke-repeterbar), såväl som hastighetsattributet och duplexattributet, som båda är strängar.
Många attribut för en nätverksenhet beskrivs av YANG-modellen, inklusive konfigurationsstatus och driftstatus.
På så sätt beskriver YANG Model onlinevärlden med hjälp av ett strukturerat språk. Om du är intresserad kan du läsa ovanstående internetblogginlägg som har en mycket djupgående beskrivning.
Det kan konverteras till XML-data mycket väl och lindas in i Netconf-protokollet för överföring (vi kommer att förklara det senare):
Samtidigt, för att utjämna skillnaderna mellan leverantörer, har Openconfig, med Google i spetsen, standardiserat datamodellen. Från den officiella hemsidan ser vi sloganen "Leverantörsneutral, modelldriven nätverkshantering designad av användare", som är designad av användare och plattformsoberoende. Leverantörsgemensam, modelldriven nätverksprogrammering (låt oss översätta det så här först). Enkelt uttryckt är det att göra modelleringen mellan olika tillverkare lika, så att när du konfigurerar vissa data behöver du inte titta igenom varje tillverkares privata yang-modell en efter en. Men Internet har alltid privata protokoll, och olika tillverkare kommer alltid att skapa nya och bättre privata protokoll för "bättre användarupplevelse" och "bättre affärsstrategi" (detta är egentligen nätverkstillverkarnas ursprungssynd). Bilden visar några av de mer vanliga implementeringarna av openconfig yang-modeller.
Av bilden att döma tror jag att det finns ganska många av dem, och de vanliga konfigurationerna är relativt kompletta. Men i praktiken beror det på om tillverkaren också stödjer dessa yang-modeller. Vissa enheter i högre versioner av ett visst ämne stöds i princip. Jag har inte tittat närmare på de inhemska än.
Nätverk kan inte vara exakt samma. För en ingenjör som sysslar med nätdrift och underhållsutveckling är det en välsignelse att kunna uppnå samma mål!
openconfig finns på https://github.com/openconfig/public/tree/master/release/models
Du kan hitta privata yang-modeller på olika officiella webbplatser.
Netconf-protokoll
Efter att ha pratat om yang-modellen, låt oss prata om Netconf-protokollet. Yang-modellen definierar den digitala beskrivningen av nätverksvärlden, och Netconf definierar insamling (get) och justering (config) av data.
Netconf kapslar in världens data som beskrivs av yang-modellen för att förverkliga hanteringen av nätverksvärlden.
Yang-data är inkapslade i xml och hanteras sedan genom Netconf-protokollet. Det är ett protokoll med en fantastisk idé, som beskriver vissa detaljer i protokollet på ett hierarkiskt sätt. Låt oss titta på bilden ovan.
-Sändning: Netconf överförs genom SSH-protokollet, är anslutningsorienterat och har säkerhetsgarantier.
-Meddelande: Ring ett fjärrsamtal till nätverksenheten via RPC, nätverkshanteraren utfärdar en rpc-begäran och nätverksenheten återupptar rpc-svar.
-Operation: Det här är själen i Netconf. Den stöder get (konfigurations- och kördata), get-config (hämtar konfigurationsdata, och en enhet kan ha flera konfigurationsdata, en igång, en start, flera kandidatkandidater), edit -config (konfigurera nätverksenhetsparametrar, stöder tillägg, radering och modifiering), delete-config, copy-config (kopiera konfigurationen till destinationen, destinationen kan vara ftp, fil eller körkonfiguration, etc.), lock\unlock (låsa konfigurationen för att förhindra konfigurationskonflikter eller fel orsakade av flera processer) och så vidare.
-Data: data är yang-data inslagna i xml. Liksom porten vi beskrev ovan är strukturerad data lätt att programmera. Används för att beskriva data som ska konfigureras eller raderas eller erhållas.
Dessa är de fyra lagren av Netconf. Kontrolländen och nätverksenheten kommunicerar via Netconf, genom det traditionella ssh-protokollet, med hjälp av Netconf-delsystemet, och standardporten är 830. Som visas nedan:
Denna figur visar interaktionen med rå ssh, men i själva verket implementerar vi denna process genom programmering. Jag kommer att demonstrera implementeringsmetoden för programmering för dig senare.
Netconf konfigurerar nätverksenheter. Interaktionsprocessen är ungefär som följer:
Den här bilden är så låg, du kan också se att den ritades av mig... Min förståelse av Netconf är som ovan. Jag tror att det finns många bilder på Internet som inte stämmer, och många beteenden hos serveragenten är inte korrekta. Detta är vad jag intuitivt känner när jag loggar in på enheten, och det överensstämmer naturligtvis en-till-en med den officiella dokumentationen.
Vi kan titta på några Netconf-exempel:
Hej, skapa en länk.
Vi såg flera nyckelord, Netconf-version, stödd YANG-modell, sessions-id. Samtidigt indikerar hej vilket namnområde vi arbetar i. I det här fallet är det motsvarande version av Netconf.
Hämta konfiguration
En parameter för get-cofig är source, vilket är där konfigurationsdata erhålls (körning, start eller annat). En annan parameter är filter, det vill säga vilken data som erhålls från datamodellen som beskrivs av vilken yang-modell. Detta motsvarar den förmåga som ursprungligen skickades av nätverksenheten. Om det lyckas kommer motsvarande konfigurationsdata att returneras.
Hämta konfigurations- eller kördata
Liknar get-config, men det som erhålls är att köra konfiguration (personlig förståelse) eller köra data. Filter kan anges.
Kopiera konfiguration
Kopieringsoperationen har två parametrar, källa och destination. Det lyckade svaret är med ok-taggen.
Redigera konfiguration
När du redigerar konfigurationen, ange dataobjektet som ska redigeras, kapacitetens namnområde och motsvarande etikett. Detta är till exempel för att konfigurera dhcp, vilket beskrivs av yang-modellen http://tail-f.com/ns/example/dhcp.
Avsluta sessionen graciöst
Det är den här typen av meddelanden som sänds fram och tillbaka i ssh. Vi tar bara ut en del av budskapet för att underlätta förståelsen för alla.
Lägg sedan till lite innehåll som referens.
-Netconf är baserat på session, och varje framgång kommer att ha ett sessions-ID.
-Varje begäran har ett meddelande-id, så länge det gradvis blir större
-Datakonfiguration kan låsas, exklusivt och manövreras genom lås.
-Netconf är transaktionsbaserat, och operationer är antingen alla implementerade eller ingen. Samtidigt, enligt den officiella webbplatsdokumentationen, är denna transaktionalitet för konfiguration av N nätverksenheter, det vill säga engångskonfigurationspolymorfism kan stödja transaktionalitet. Men jag har inte gjort det än...
-Netconf stöder prenumeration. När det gäller enhetens prestanda är storleksordningen cirka 5 sessioner. Jag kan prenumerera på en viss datapost och enheten kommer att meddela mig när den ändras.
-Förmåga, det är så jag förstår det. Nätverksenheten skickar versionen av Netconf och YANG Model, och kontrollterminalen skickar versionen av Netconf. Först när Netconf-versionen matchar de två kan vi fortsätta. Detta är min intuitiva känsla. Alla råd är välkomna.
-Operationer som get edit kommer att specificera data som ska ändras, som kan filtreras med filter.
-copy-config stöder kopiering av en komplett uppsättning konfigurationer från någonstans till någonstans. Någonstans kan vara en FTP-fil, kör, start och kandidatkonfigurationer på enheten.
-Netconf stöder också verifiering av konfigurationen med hjälp av valideringsoperationen.
Den här artikeln hoppas fortfarande på att popularisera vetenskapen, och jag kommer inte att gå in på detaljer. Du kan läsa de relevanta protokollen för RFC, som faktiskt inte är särskilt långa.
I praktiken kan vi, baserat på viss programvara med öppen källkod, såsom pythons ncclient, enkelt konfigurera nätverksenheter automatiskt och uppnå nätverksprogrammerbarhet. Detta är uppdraget för Netconf och YANG Model.
Nätverkspersonal läser de välformaterade YANG-modelldefinitionerna och använder relevanta programmeringsspråk för att utföra programmerbara operationer på nätverksenheter baserat på operationerna definierade av Netconf. På så sätt skapas vägen till nätverksprogrammerbarhet.
Låt oss expandera och föreställa oss att YANG-modellen har definierat datastrukturen för nätverksenheten. Vi kan använda det via Netconf. Kan det också drivas genom andra protokoll?
Svaret är ja. Faktum är att många andra protokoll har härletts från Netconf, såsom RESTConf. Enligt nedanstående,
YANG Model (public och native) definierar datastrukturen, ovanför vilka finns nya nätverkshanteringsprotokoll, Netconf, RESTCon, gRPC, etc. På så sätt kan vi driva nätverksenheter genom RESTConf baserat på HTTP RESTful API, vi kan även driva nätverk enheter via Netconf baserat på SSH, eller så kan vi driva nätverksenheter via gRPC baserat på HTTP2.0. De är alla baserade på YANG med bra datastruktur. Modellera, skriv motsvarande data, kapsla in den i xml eller json för att programmera nätverksenheter. Detta är framtiden för nätverksprogrammerbarhet. För att vara exakt är det Model Driven Program, modellbaserad nätverksprogrammerbarhet. Nätverksingenjörer fokuserar gradvis på enhetens parametrar istället för kommandouppsättningen och konfigurerar nätverksparametrarna genom att läsa motsvarande datamodell.
I slutet skriver jag, varför ska jag öppna detta offentliga konto. Jag studerade datavetenskap och teknik när jag gick i skolan. Efter att ha kommit in på arbetsplatsen höll jag på med nätverksdrift och underhållsarbete. När jag tänker efter kan anledningen till att jag delades in i team bero på att jag var doktorand på Network Technology Research Institute (manual funny). Redan från början var jag involverad i nätverksdrift. I det senare skedet av drift och underhåll användes verktyg för att förenkla arbetet och förbättra effektiviteten baserat på CLI. Senare utvecklades verktygen successivt till BS-strukturerade webbapplikationer. De exponerades ständigt för ny teknik och fortsatte att berika nya funktioner.
Lyckligtvis kom de ikapp utvecklingen av öppen källkodsteknik och SDN, och gradvis övergick jag till NetDevOps-arbete och använde mina programmeringskunskaper för att förbättra teamets drift- och underhållskapacitet. Jag tyckte också om att skriva denna kodrad. Allt eftersom skrivandet fortskrider upptäcks det gradvis att NetDevOps borde vara en färdighet som alla nätverksingenjörer borde ha i framtiden (alla lägger bränsle på elden), så att de kan uppnå både planering på hög nivå och snabb implementering. Om man ser tillbaka på lite information på Internet, för att vara ärlig, finns det väldigt lite i Kina, och den inhemska atmosfären är inte särskilt stark. Många inhemska program är baserade på det gamla CLI och snmp, och alla använder fortfarande textverktyg och SSH-verktyg för arbetet. Så jag hoppas att jagkan lära andra att fiska, dela mina erfarenheter (gropar) och kunskaper med fler nätverksdrifts- och underhållsingenjörer, och gör mitt bästa. Xiao Chu sa att du kan lära dig något för att minska din arbetsbelastning, och genom att fokusera på en avlägsen framtid kan drift och underhåll av det inhemska nätverket verkligen utvecklas mot automatisering.
I framtiden kommer jag att spela in några videos och skriva några artiklar. Det känns riktigt ansträngande att skriva ett dokument. Du är välkommen att prenumerera, samla, klicka gilla och titta.
bilaga: Netconf vanliga operationer
DWDM OTN-lösningsdesign och kostnadsförslag, länka gärna till mig, Taylor Huang
