For relaterte artikler delt av meg om nettverksautomatisering, vennligst se katalogen "NetDevOps from Scratch"
De siste årene, med den kontinuerlige utviklingen av det globale cloud computing-feltet og den kontinuerlige veksten av virksomheten, har også nettverksteknologi fortsatt å utvikle seg, og SDN-teknologi har dukket opp. Fra den opprinnelige kjerneideen om separasjon av videresending og kontroll basert på Openflow, fortsetter folk å utvide I forlengelsen av SDN kan folk for tiden nå en konsensus om at Openflow ikke lenger er en nødvendig betingelse (men separasjonen av videresending og kontroll er fortsatt en kjernebetingelse), og nettverksprogrammerbarhet har sakte blitt et av de viktige kriteriene for å måle en SDN-arkitektur.
Programmerbare operasjoner av tradisjonelt nettverksutstyr er vanligvis basert på CLI- og SNMP-protokoller. Enten skript eller programvare for nettverksadministrasjon, de er alle utviklet på dette grunnlaget for å oppnå det brede spekteret av nettverksprogrammerbarhet vi skal snakke om i dag. evner, og dermed realisere automatiseringen av mange scenarier. Noen enheter støtter konfigurasjonen av enkelte nettgrensesnitt og erstatning av den generelle konfigurasjonen gjennom xml. Disse er svært sjeldne og vil ikke bli beskrevet i detalj i denne artikkelen.
CLI
CLI (Command-line Interface) realiserer menneske-datamaskin-interaksjon gjennom kommandolinjen. Det er en nødvendig ferdighet for nettverksarbeidere. Folk åpner programvaren SSH eller Telnet til enheten hver dag, limer deretter inn en konfigurasjon, lagrer den og trer i kraft. En dag ble folk lei av denne typen repetisjon, og brukte et program til å generere konfigurasjonsskript automatisk, logge på enheten i grupper og utstede konfigurasjoner for å tre i kraft, og realisere automatisering. Dette er en nettverksprogrammerbar metode. La oss snakke om fordelene, som er veldig i samsvar med folks tenkning, ideer og eksisterende tekniske systemer. Men til syvende og sist favoriserer denne tilnærmingen folk fremfor nettverksenheter. Det har følgende ulemper:
-Det er store forskjeller i kommandosett mellom produsenter. Ikke bare produsenter, men ulike programvareversjoner av samme modell kan ha svært forskjellige forskjeller.
-Utviklere må være kjent med kommandosettet og hvordan man bruker det. Det er sikkerhetsrisikoer på konfigurasjonsnivå. For eksempel, med et håndgrep ble porten jeg ønsket å åpne til å lukke porten...
-Det er ingen obligatoriske krav til overføringsprotokoller (SSH og Telnet), og det er produksjonssikkerhetsrisikoer.
-Prosessen med å analysere og generere konfigurasjoner er ekstremt komplisert. I mange tilfeller kan de vanlige reglene som er skrevet bare være uendelig nær "sannheten", men ikke hele "sannheten".
-Det er ingen transaksjonalitet, og en konfigurasjon kan delvis tre i kraft og delvis ikke tre i kraft.
-Det er ingen automatisert inspeksjonsmekanisme og den er helt avhengig av folk. For eksempel vil jeg teste om det genererte skriptet er riktig. Det er en måte, men det er veldig vanskelig og ofte vanskelig å implementere enkelt.
- Ingen anelse om datamodellering
CLI er alltid en måte for menneske-datamaskin-interaksjon. Det kan gi nettverket visse programmerbarhetsmuligheter gjennom programmer, men tross alt er det ikke en metode som iboende er nettverksprogrammerbar. Under den nåværende bølgen av cloud computing og SDN er den ikke egnet for storskala automatisert distribusjon i nettverket, og programmerbarheten er begrenset. Det er vanskelig for utenforstående å forstå vanskeligheten med utvikling.
SNMP
SNMP (SNMP, Simple Network Management Protocol), denne protokollen kan støtte nettverksadministrasjonssystemer for å overvåke om enhetene som er koblet til nettverket har en situasjon som forårsaker oppmerksomhet fra ledelsen. Den består av et sett med nettverksadministrasjonsstandarder, inkludert en applikasjonslagsprotokoll, databaseskjema og et sett med dataobjekter.
For et stykke innhold i Wikipedia fremhever vi nettverksadministrasjon, overvåking og dataobjekter. Den brukes til å administrere nettverket, kan konfigureres og samles inn, og brukes hovedsakelig til overvåking. Den har datamodellering for å strukturere noen moduler, egenskaper og statusdata for nettverksutstyr. Den brukes hovedsakelig til nettverksstyringssystemer (for det meste overvåking). Så la oss snakke om dens mangler:
- Dårlig lesbarhet. Den foretrekker "maskinen" i menneske-maskin. Den er ikke lesbar når den brukes, og modelleringsdataene er heller ikke lesbare. Den bruker et supersett av ASN.1.
- Sikkerheten er begrenset. Det er tre versjoner: v1, v2c og v3, og sikkerheten forbedres i rekkefølge. Den vanligste er imidlertid v2c, som har begrenset sikkerhet. V3-versjonen er veldig sikker utformet, men den er ikke universell. . .
-Det er ingen mekanisme for sikkerhetskopiering, gjenoppretting eller tilbakeføring. Vi har også show run og andre metoder for å sikkerhetskopiere kommandolinjen, men snmp. . .
-Svært få skriver. Les mye, skriv lite, brukes mest til overvåking.
-Dataelementene som kan samles inn er begrenset, og konfigurasjonen av hele enheten kan ikke oppnås. Mange ganger finner vi ut at vi kan bruke cli til å samle det, men vi kan ikke bruke snmp til å samle det.
-Det er en ytelsesflaskehals. Den øvre grensen for innsamlede data er 64K, og innsamlingsgranulariteten er for stor. I store og komplekse nettverk kan det ta minutter eller lenger. Dette fremhever også det viktige poenget. Våre krav til granularitet er også svært strenge. Mange ganger håper vi å samle havnetrafikk med noen sekunders mellomrom. I store nettverk tror jeg tradisjonell programvare for nettverksadministrasjon er... For å utvide med en setning til, er den nåværende metoden Telemetri (som gRPC) som kan oppnå mikrosekundnivå, og noen krever en kombinasjon av programvare og maskinvare. Det er ennå ikke populært, men i fremtiden må det være en trend. Når det gjelder når dette kommer i fremtiden...
-Siden fødselen har SNMP blitt mye brukt innen nettverksovervåking for å skaffe data for overvåking. Mangelen og kompleksiteten til konfigurasjonsevner har ført til liten bruk av den i nettverkskonfigurasjon. Skrivebeskyttet nettverk programmerbar.
Netconf-protokoll og YANG-modell
Når vi står overfor neste generasjon nettverk, hva slags nettverksadministrasjonsprotokoller trenger vi for bedre å realisere nettverksprogrammerbarhet og forbedre automatiseringsnivået?
IETF foreslo følgende ideer i RFC3535 i 2002 (faktisk er det 33 av dem. Basert på nettinformasjon og forfatterens kunnskap, skrev jeg følgende ideer):
1. Det er et programmerbart grensesnitt for nettverkskonfigurasjon
2. Den samme konfigurasjonen kan brukes på tvers av produsenter og modeller
3. Behov for å forene et modelleringsspråk med god lesbarhet
4. Fullfør funksjonene for feilkontroll og gjenoppretting
5. Transaksjonsmessig
Hvis du har en idé, bare implementer den. I 2006 foreslo IETF Netconf-protokollen, som løste problemene RFC3535 reiste. Den første Netconf fastsatte bare det grunnleggende rammeverket og operasjonene til protokollen, og definerte løsninger som tok hensyn til noen problemer med RFC3535. Det fastsatte ikke et enhetlig modelleringsspråk. Derfor støttet noen tidlige produsenters utstyr bare noen grunnleggende operasjoner av Netconf, og brukte ikke et enhetlig bunnlag. Datamodelleringsspråk.
RFC6020 ble utgitt i 2010, og foreslår modelleringsspråket YANG Model og en metode for å kombinere det med NETCONF. Den ene definisjonen er et datamodelleringsspråk som forener den underliggende ressurslogikken mellom produsenter, og den andre definisjonen er et enhetlig kommandosett for hver produsents operasjoner på konfigurasjonsdata og statusdata. Dataforekomstene opprettet av YANG-modellen er pakket inn i Netconf-protokollen. Overføring, de to er kombinert med hverandre for å bygge et nytt sett med universelle nettverksprogrammerbare grensesnitt for den nye æraen basert på YANG-modellen og drevet av Netconf-protokollen.
Etter 2016 ble Netconf-protokollen tett integrert med YANG-modellen og ble populær. Så langt, når vi ser på noen SDN-arkitekturprogramvareaspekter, har vi hørt disse to begrepene mer eller mindre.
YANG og Netconf, den ene er statisk og den andre er dynamisk, akkurat som yin og yang. De to har avledet den nettverksprogrammerbare verdenen til neste æra. (Når vi ser på YANG-varehuset på github, vil vi også finne at ikonet er Tai Chi, og forbindelsen mellom navnet og "Yang" avslører noe av den originale designerens designideer).
Deretter vil vi kort snakke om YANG-modellen og Netconf-protokollen. La oss først snakke om datamodelleringsspråket YANG for å se hvordan det beskriver den digitale tvillingen til denne nettverksverdenen.
YANG modell
I RFC6020-dokumentet står det tydelig i åpningskapittelet YANG, A Data Modeling Language for the Network Configuration Protocol. Det er forkortelsen for Yet Another Next Generation (Yang) Data Modeling Language. Det er et modelleringsspråk som brukes til å beskrive nettverkskonsepter.
Støtter definisjon av lister, ordbøker og enda mer komplekse datastrukturer, støtter begrensninger, oppregninger, referanseimport, versjonsadministrasjon og navnerom. På grunn av plass vil vi gi en kort forklaring. For detaljert informasjon kan du se:
Den kan beskrive denne nettverksenheten veldig enkelt i et strukturert språk. For eksempel, for definisjonen av en port:
Som et profesjonelt drifts- og vedlikeholdspersonell, med litt grunnleggende nettverk og litt grunnleggende programmering, kan du forstå definisjonen av en port relativt klart. Det er en listestruktur, og det kan være flere. En av dens attributter er interface-name (også en nøkkel). , unik, ikke-repeterbar), samt hastighetsattributtet og dupleksattributtet, som begge er strenger.
Mange attributter til en nettverksenhet er beskrevet av YANG-modellen, inkludert konfigurasjonsstatus og driftsstatus.
På denne måten beskriver YANG-modellen nettverdenen ved hjelp av strukturert språk. Hvis du er interessert, kan du lese ovenstående internettblogginnlegg, som har en svært utdypende beskrivelse.
Det kan konverteres til XML-data veldig godt og pakkes inn i Netconf-protokollen for overføring (vi vil forklare det senere):
Samtidig, for å utjevne forskjellene mellom leverandørene, har Openconfig, ledet av Google, standardisert datamodellen. Fra den offisielle nettsiden ser vi slagordet "Leverandørnøytral, modelldrevet nettverksadministrasjon designet av brukere", som er designet av brukere og på tvers av plattformer. Leverandør-vanlig, modelldrevet nettverksprogrammering (la oss oversette det på denne måten først). For å si det enkelt er det å gjøre modelleringen mellom ulike produsenter lik, slik at når du konfigurerer visse data, trenger du ikke å se gjennom hver produsents private yang-modell en etter en. Men Internett har alltid private protokoller, og forskjellige produsenter vil alltid lage nye og bedre private protokoller for «bedre brukeropplevelse» og «bedre forretningsstrategi» (dette er egentlig nettverksprodusentenes arvesynd). Bildet viser noen av de mer brukte openconfig yang-modellimplementeringene.
Ut fra bildet å dømme tror jeg det er ganske mange av dem, og de vanlig brukte konfigurasjonene er relativt komplette. Men i praksis avhenger det av om produsenten også støtter disse yang-modellene. Noen høyere versjonsenheter av et bestemt emne støttes i utgangspunktet. Jeg har ikke sett nærmere på de innenlandske ennå.
Nettverk kan ikke være nøyaktig det samme. For en ingeniør som driver med nettverksdrift og vedlikeholdsutvikling er det en velsignelse å kunne nå samme mål!
openconfig finner du på https://github.com/openconfig/public/tree/master/release/models
Du kan finne private yang-modeller på forskjellige offisielle nettsteder.
Netconf-protokoll
Etter å ha snakket om yang-modellen, la oss snakke om Netconf-protokollen. Yang-modellen definerer den digitale beskrivelsen av nettverksverdenen, og Netconf definerer innhenting (get) og justering (config) av data.
Netconf kapsler inn dataene i verden beskrevet av yang-modellen for å realisere styringen av nettverksverdenen.
Yang-data er innkapslet i xml og administreres deretter gjennom Netconf-protokollen. Det er en protokoll med en flott lagdelt idé, som beskriver noen detaljer i protokollen på en hierarkisk måte. La oss se på bildet ovenfor.
-Overføring: Netconf overføres gjennom SSH-protokollen, er tilkoblingsorientert og har sikkerhetsgarantier.
-Melding: Foreta et eksternt anrop til nettverksenheten via RPC, nettverksadministratoren utsteder en rpc-forespørsel, og nettverksenheten gjenopptar rpc-svar.
-Operasjon: Dette er sjelen til Netconf. Den støtter get (konfigurasjons- og kjøredata), get-config (henter konfigurasjonsdata, og en enhet kan ha flere konfigurasjonsdata, én kjører, én oppstart, flere kandidatkandidater), edit -config (konfigurer nettverksenhetsparametere, støtter tillegg, sletting og modifikasjon), delete-config, copy-config (kopier konfigurasjonen til destinasjonen, destinasjonen kan være ftp, fil eller kjørende konfigurasjon, etc.), lock\unlock (lås konfigurasjonen for å forhindre konfigurasjonskonflikter eller feil forårsaket av multiprosessoperasjoner) og så videre.
-Data: data er yang-data pakket inn i xml. I likhet med porten vi beskrev ovenfor, er strukturerte data enkle å programmere. Brukes til å beskrive dataene som skal konfigureres eller slettes eller innhentes.
Dette er de fire lagene til Netconf. Kontrollenden og nettverksenheten kommuniserer gjennom Netconf, gjennom den tradisjonelle ssh-protokollen, ved å bruke Netconf-delsystemet, og standardporten er 830. Som vist nedenfor:
Denne figuren viser interaksjonen ved å bruke rå ssh, men faktisk implementerer vi denne prosessen gjennom programmering. Jeg vil demonstrere programmeringsimplementeringsmetoden for deg senere.
Netconf konfigurerer nettverksenheter. Interaksjonsprosessen er omtrent som følger:
Dette bildet er så lavt, du kan også se at det ble tegnet av meg... Min forståelse av Netconf er som ovenfor. Jeg tror det er mange bilder på Internett som ikke er riktige, og mange oppførsel til serveragenten er ikke korrekte. Dette er hva jeg intuitivt føler når jeg logger inn på enheten, og det samsvarer selvfølgelig en-til-en med den offisielle dokumentasjonen.
Vi kan se på noen Netconf-eksempler:
Hei, lag en link.
Vi så flere nøkkelord, Netconf-versjon, støttet YANG-modell, økt-ID. Hallo indikerer samtidig hvilket navneområde vi opererer i. I dette tilfellet er det den tilsvarende versjonen av Netconf.
Få konfigurasjon
En parameter for get-cofig er kilde, som er der konfigurasjonsdataene hentes (kjøring, oppstart eller annet). En annen parameter er filter, det vil si hvilke data som hentes fra datamodellen beskrevet av hvilken yang-modell. Dette tilsvarer muligheten som opprinnelig ble sendt av nettverksenheten. Hvis det lykkes, vil de tilsvarende konfigurasjonsdataene bli returnert.
Få konfigurasjons- eller kjøredata
Ligner på get-config, men det som oppnås er kjørekonfigurasjon (personlig forståelse) eller kjørende data. Filter kan spesifiseres.
Kopier konfigurasjonen
Kopieringsoperasjonen har to parametere, kilde og mål. Det vellykkede svaret er med ok-taggen.
Rediger konfigurasjon
Når du redigerer konfigurasjonen, spesifiser dataelementet som skal redigeres, navneområdet til funksjonen og den tilsvarende etiketten. Dette er for eksempel for å konfigurere dhcp, som er beskrevet av yang-modellen http://tail-f.com/ns/example/dhcp.
Lukk økten elegant
Det er denne typen meldinger som overføres frem og tilbake i ssh. Vi trekker bare ut en del av meldingen for å lette forståelsen for alle.
Deretter legger du bare til noe innhold for referanse.
-Netconf er basert på økt, og hver suksess vil ha en sesjons-ID.
-Hver forespørsel har en meldings-id, så lenge den gradvis blir større
-Datakonfigurasjon kan låses, eksklusivt og betjenes gjennom lås.
-Netconf er transaksjonsbasert, og operasjoner er enten alle implementert eller ingen. Samtidig, i henhold til den offisielle nettsidedokumentasjonen, er denne transaksjonaliteten for konfigurasjon av N nettverksenheter, det vil si at engangskonfigurasjonspolymorfisme kan støtte transaksjonalitet. Men jeg har ikke gjort det enda...
-Netconf støtter abonnement. Når det gjelder enhetsytelse, er størrelsesordenen omtrent 5 økter. Jeg kan abonnere på et bestemt dataelement, og enheten vil varsle meg når den endres.
-Cabilitet, det er slik jeg forstår det. Nettverksenheten sender versjonen av Netconf og YANG Model, og kontrollterminalen sender versjonen av Netconf. Først når Netconf-versjonen matcher de to kan vi fortsette. Dette er min intuitive følelse. Alle råd er velkomne.
-Operasjoner som get edit vil spesifisere dataene som skal endres, som kan filtreres ved hjelp av filter.
-copy-config støtter kopiering av et komplett sett med konfigurasjoner fra et sted til et sted. Et sted kan være en FTP-fil, kjører, oppstart og kandidatkonfigurasjoner på enheten.
-Netconf støtter også verifisering av konfigurasjon ved å bruke valideringsoperasjonen.
Denne artikkelen håper fortsatt å popularisere vitenskapen, og jeg vil ikke gå inn på detaljer. Du kan lese de relevante protokollene til RFC, som faktisk ikke er veldig lange.
I praksis, basert på noen åpen kildekode-programvare, som pythons ncclient, kan vi enkelt konfigurere nettverksenheter automatisk og oppnå nettverksprogrammerbarhet. Dette er oppdraget til Netconf og YANG Model.
Nettverkspersonell leser de godt formaterte YANG-modelldefinisjonene og bruker relevante programmeringsspråk for å utføre programmerbare operasjoner på nettverksenheter basert på operasjonene definert av Netconf. På denne måten blir veien til nettverksprogrammerbarhet smidd.
La oss utvide og forestille oss at YANG-modellen har definert datastrukturen til nettverksenheten. Vi kan betjene det gjennom Netconf. Kan den også betjenes gjennom andre protokoller?
Svaret er ja. Faktisk har mange andre protokoller blitt avledet fra Netconf, for eksempel RESTConf. Som vist under,
YANG Model (offentlig og native) definerer datastrukturen, over hvilke er nye nettverksadministrasjonsprotokoller, Netconf, RESTCon, gRPC, etc. På denne måten kan vi betjene nettverksenheter gjennom RESTConf basert på HTTP RESTful API, vi kan også drive nettverk enheter gjennom Netconf basert på SSH, eller vi kan betjene nettverksenheter gjennom gRPC basert på HTTP2.0. De er alle basert på YANG med god datastruktur. Modeller, skriv de tilsvarende dataene, kapsler inn i xml eller json for å programmere nettverksenheter. Dette er fremtiden for nettverksprogrammerbarhet. For å være presis er det Model Driven Program, modellbasert nettverksprogrammerbarhet. Nettverksingeniører fokuserer gradvis på parametrene til enheten i stedet for kommandosettet, og konfigurerer nettverksparametrene ved å lese den tilsvarende datamodellen.
På slutten skriver jeg, hvorfor skal jeg åpne denne offentlige kontoen. Jeg studerte informatikk og teknologi da jeg gikk på skolen. Etter å ha kommet inn på arbeidsplassen var jeg engasjert i nettverksdrift og vedlikeholdsarbeid. Når jeg tenker på det, kan grunnen til at jeg ble delt inn i team være fordi jeg var hovedfagsstudent ved Network Technology Research Institute (manual funny). Helt fra starten var jeg involvert i nettverksdrift. I det senere stadiet av drift og vedlikehold ble det brukt verktøy for å forenkle arbeidet og forbedre effektiviteten basert på CLI. Senere ble verktøyene gradvis utviklet til BS-strukturerte webapplikasjoner. De ble stadig utsatt for ny teknologi og fortsatte å berike nye funksjoner.
Heldigvis tok de igjen utviklingen av åpen kildekode-teknologi og SDN, og gradvis gikk jeg over til NetDevOps-arbeid og brukte programmeringsferdighetene mine til å forbedre teamets drift- og vedlikeholdsevner. Jeg likte også å skrive denne kodelinjen. Etter hvert som skrivingen skrider frem, oppdages det gradvis at NetDevOps bør være en ferdighet som enhver nettverksingeniør bør ha i fremtiden (alle legger bensin på bålet), slik at de kan oppnå både planlegging på høyt nivå og rask implementering. Ser vi tilbake på litt informasjon på Internett, for å være ærlig, er det veldig lite i Kina, og den hjemlige atmosfæren er ikke særlig sterk. Mange innenlandsk programvare er basert på den gamle CLI og snmp, og alle bruker fortsatt tekstverktøy og SSH-verktøy for jobben. Så jeg håper at jegkan lære andre å fiske, dele min erfaring (groper) og ferdigheter med flere nettverksdrifts- og vedlikeholdsingeniører, og gjør mitt beste. Xiao Chu sa at du kan lære noe for å redusere arbeidsmengden din, og ved å fokusere på en fjern fremtid kan drift og vedlikehold av hjemmenettverk virkelig utvikle seg mot automatisering.
I fremtiden skal jeg spille inn noen videoer og skrive noen artikler. Det føles veldig anstrengende å skrive et dokument. Du er velkommen til å abonnere, samle, klikke liker og se.
vedlegg: Netconf vanlige operasjoner
DWDM OTN-løsningsdesign og pristilbud, vennligst lenke til meg, Taylor Huang
