Susijusius straipsnius, kuriais dalinuosi apie tinklo automatizavimą, rasite kataloge „NetDevOps nuo nulio“
Pastaraisiais metais, nuolat tobulėjant pasaulinei debesų kompiuterijos sričiai ir nuolat augant verslui, tinklo technologijos taip pat toliau vystėsi, atsirado SDN technologija. Iš pradinės pagrindinės idėjos atskirti persiuntimą ir valdymą, pagrįstą „Openflow“, žmonės ir toliau plečiasi Išplėtę SDN, žmonės šiuo metu gali pasiekti sutarimą, kad „Openflow“ nebėra būtina sąlyga (tačiau persiuntimo ir valdymo atskyrimas yra vis dar yra pagrindinė sąlyga), o tinklo programuojamumas pamažu tapo vienu iš svarbių SDN architektūros matavimo kriterijų.
Tradicinės tinklo įrangos programuojamos operacijos paprastai yra pagrįstos CLI ir SNMP protokolais. Nesvarbu, ar tai būtų scenarijai, ar tinklo valdymo programinė įranga, jie visi sukurti šiuo pagrindu, kad būtų pasiektas platus tinklo programavimo diapazonas, apie kurį šiandien kalbėsime. galimybes, taip įgyvendinant daugelio scenarijų automatizavimą. Kai kurie įrenginiai palaiko kai kurių žiniatinklio sąsajų konfigūraciją ir bendros konfigūracijos pakeitimą naudojant xml. Tai labai reti ir šiame straipsnyje nebus išsamiai aprašyti.
CLI
CLI (komandinės eilutės sąsaja) realizuoja žmogaus ir kompiuterio sąveiką per komandinę eilutę. Tai būtinas įgūdis tinklo darbuotojams. Žmonės kiekvieną dieną atidaro programinę įrangą SSH arba Telnet įrenginyje, tada įklijuoja konfigūraciją, išsaugo ją ir įsigalioja. Vieną dieną žmonės pavargo nuo tokio kartojimo ir naudojo programą, kuri automatiškai generavo konfigūracijos scenarijus, prisijungė prie įrenginio paketais ir išduoda konfigūracijas, kad įsigaliotų, realizuodami automatizavimą. Tai tinklo programuojamas metodas. Pakalbėkime apie privalumus, kurie labai atitinka žmonių mąstymą, idėjas ir esamas technines sistemas. Tačiau galiausiai šis metodas teikia pirmenybę žmonėms, o ne tinklo įrenginiams. Jis turi šiuos trūkumus:
- Yra didžiuliai skirtumai tarp gamintojų komandų rinkinių. Ne tik gamintojai, bet ir skirtingos to paties modelio programinės įrangos versijos gali labai skirtis.
-Kūrėjai turi būti susipažinę su komandų rinkiniu ir kaip jį naudoti. Konfigūracijos lygiu kyla saugumo rizikos. Pavyzdžiui, rankos paspaudimu prievadas, kurį norėjau atidaryti, virto prievado uždarymu...
-Perdavimo protokolams (SSH ir Telnet) nėra privalomų reikalavimų, kyla gamybos saugumo rizikos.
- Konfigūracijų analizavimo ir generavimo procesas yra labai sudėtingas. Daugeliu atvejų parašytos taisyklingos taisyklės gali būti tik be galo artimos „tiesai“, bet ne visai „tiesai“.
- Nėra sandorio, o konfigūracija gali iš dalies įsigalioti, o dalis neįsigalioti.
-Nėra automatizuoto tikrinimo mechanizmo ir jis visiškai priklauso nuo žmonių. Pavyzdžiui, noriu patikrinti, ar sugeneruotas scenarijus yra teisingas. Būdas yra, bet labai sunkus ir dažnai sunkiai įgyvendinamas.
- Neturi jokio supratimo apie duomenų modeliavimą
CLI visada yra žmogaus ir kompiuterio sąveikos būdas. Jis gali suteikti tinklui tam tikras programavimo galimybes per programas, bet juk tai nėra metodas, kuris iš prigimties yra programuojamas tinkle. Esant dabartinei debesų kompiuterijos ir SDN bangai, jis nėra tinkamas didelio masto automatizuotam diegimui tinkle, o programuojamumas yra ribotas. Pašaliniams sunku suprasti vystymosi sunkumą.
SNMP
SNMP (SNMP, Simple Network Management Protocol), šis protokolas gali palaikyti tinklo valdymo sistemas, kad būtų galima stebėti, ar prie tinklo prijungtuose įrenginiuose nėra situacijų, dėl kurių vadovybė turėtų atkreipti dėmesį. Jį sudaro tinklo valdymo standartų rinkinys, įskaitant taikomojo lygmens protokolą, duomenų bazės schemą ir duomenų objektų rinkinį.
Dalyje Vikipedijos turinio paryškiname tinklo valdymo, stebėjimo ir duomenų objektus. Jis naudojamas tinklui valdyti, gali būti konfigūruojamas ir renkamas, daugiausia naudojamas stebėjimui. Jis turi duomenų modeliavimą, kad susistemintų kai kuriuos tinklo įrangos modulius, charakteristikas ir būsenos duomenis. Jis daugiausia naudojamas tinklo valdymo sistemoms (dažniausiai stebėjimui). Tada pakalbėkime apie jo trūkumus:
- Prastas skaitomumas. Jis teikia pirmenybę „mašinai“ žmoguje-mašinoje. Jis neįskaitomas, kai naudojamas, o modeliavimo duomenys taip pat neįskaitomi. Jis naudoja ASN.1 superrinkinį.
- Apsauga yra ribota. Yra trys versijos: v1, v2c ir v3, o saugumas gerinamas iš eilės. Tačiau labiausiai paplitęs yra v2c, kurio saugumas yra ribotas. V3 versija yra labai saugi pagal dizainą, tačiau ji nėra universali. . .
-Nėra atsarginio kopijavimo, atkūrimo ar atkūrimo mechanizmo. Taip pat turime „show run“ ir kitus metodus, kaip sukurti atsarginę komandų eilutės kopiją, bet snmp. . .
- Labai mažai rašo. Skaitykite daug, rašykite mažai, dažniausiai naudojamas stebėjimui.
- Duomenų elementai, kuriuos galima rinkti, yra riboti, todėl negalima gauti viso įrenginio konfigūracijos. Daug kartų pastebime, kad rinkti galime naudoti cli, bet negalime naudoti snmp.
-Yra veiklos kliūtis. Viršutinė renkamų duomenų riba yra 64 KB, o rinkimo detalumas per didelis. Dideliuose ir sudėtinguose tinkluose tai gali užtrukti kelias minutes ar ilgiau. Tai taip pat pabrėžia svarbų dalyką. Mūsų reikalavimai detalumui taip pat labai griežti. Daug kartų tikimės surinkti uosto srautus kas kelias sekundes. Dideliuose tinkluose, manau, tradicinė tinklo valdymo programinė įranga yra… Norėdami išplėsti dar vieną sakinį, dabartinis metodas yra telemetrija (pvz., gRPC), kuri gali pasiekti mikrosekundžių lygį, o kai kurioms reikia programinės įrangos ir aparatinės įrangos derinio. Tai dar nėra populiari, bet ateityje tai turi būti tendencija. Kalbant apie tai, kada tai ateis ateityje…
-Nuo pat gimimo SNMP buvo plačiai naudojamas tinklo stebėjimo srityje, siekiant gauti stebėjimo duomenis. Dėl konfigūravimo galimybių trūkumo ir sudėtingumo jos mažai naudojamos tinklo konfigūracijoje. Programuojamas tik skaitymo tinklas.
Netconf protokolas ir YANG modelis
Atsižvelgdami į naujos kartos tinklus, kokių tinklo valdymo protokolų mums reikia, kad geriau suvoktume tinklo programuojamumą ir pagerintume automatizavimo lygį?
IETF 2002 m. RFC3535 pasiūlė tokias idėjas (iš tikrųjų jų yra 33. Remdamasis informacija internete ir autoriaus žiniomis, parašiau tokias idėjas):
1. Yra programuojama tinklo konfigūravimo sąsaja
2. Ta pati konfigūracija gali būti naudojama visiems gamintojams ir modeliams
3. Reikia suvienodinti modeliavimo kalbą, kuri būtų gerai skaitoma
4. Atlikite klaidų tikrinimo ir atkūrimo funkcijas
5. Sandoris
Jei turite idėją, tiesiog įgyvendinkite ją. 2006 m. IETF pasiūlė Netconf protokolą, kuris išsprendė RFC3535 iškeltas problemas. Pradiniame „Netconf“ buvo nustatyta tik pagrindinė protokolo struktūra ir operacijos bei nustatyti sprendimai, kuriuose buvo atsižvelgta į kai kurias RFC3535 problemas. Jame nebuvo nustatyta vieninga modeliavimo kalba. Todėl kai kurių ankstyvųjų gamintojų įranga palaikė tik kai kurias pagrindines Netconf operacijas ir nenaudojo vieningo apatinio sluoksnio. Duomenų modeliavimo kalba.
RFC6020 buvo išleistas 2010 m., siūlantis YANG modelio modeliavimo kalbą ir jos derinimo su NETCONF metodą. Vienas apibrėžimas yra duomenų modeliavimo kalba, sujungianti pagrindinių gamintojų išteklių logiką, o kitas apibrėžimas yra vieningas komandų rinkinys, skirtas kiekvieno gamintojo operacijoms su konfigūracijos duomenimis ir būsenos duomenimis. YANG modelio sukurti duomenų egzemplioriai yra suvynioti į Netconf protokolą. Perdavimas, abu yra derinami vienas su kitu, kad būtų sukurtas naujas universalių tinklo programuojamų sąsajų rinkinys naujajai erai, paremtas YANG modeliu ir valdomas Netconf protokolu.
Po 2016 m. Netconf protokolas buvo glaudžiai integruotas su YANG modeliu ir išpopuliarėjo. Iki šiol, kai žiūrime į kai kuriuos SDN architektūros programinės įrangos aspektus, daugiau ar mažiau girdėjome šiuos du terminus.
YANG ir Netconf, vienas yra statinis, o kitas dinamiškas, kaip ir yin ir yang. Jiedu sukūrė kitos eros tinklo programuojamą pasaulį. (Pažvelgę į YANG sandėlį github platformoje taip pat pamatysime, kad jo ikona yra Tai Chi, o jo pavadinimo ir „Yang“ ryšys šiek tiek atskleidžia originalias dizainerio dizaino idėjas).
Toliau trumpai pakalbėsime apie YANG modelį ir Netconf protokolą. Pirmiausia pakalbėkime apie duomenų modeliavimo kalbą YANG, kad pamatytume, kaip ji apibūdina šio tinklo pasaulio skaitmeninį dvynį.
YANG modelis
RFC6020 dokumento pradiniame skyriuje aiškiai nurodyta, YANG, tinklo konfigūracijos protokolo duomenų modeliavimo kalba. Tai dar vienos naujos kartos (Yang) duomenų modeliavimo kalbos santrumpa. Tai modeliavimo kalba, naudojama tinklo sąvokoms apibūdinti.
Palaiko sąrašų, žodynų ir dar sudėtingesnių duomenų struktūrų apibrėžimą, palaiko apribojimus, išvardijimus, nuorodų importavimą, versijų valdymą ir vardų sritis. Dėl vietos pateiksime trumpą paaiškinimą. Norėdami gauti išsamios informacijos, galite kreiptis į:
Jis gali labai paprastai apibūdinti šį tinklo įrenginį struktūrine kalba. Pavyzdžiui, prievado apibrėžimui:
Kaip profesionalus eksploatavimo ir priežiūros personalas, turėdamas šiek tiek tinklo pagrindų ir šiek tiek programavimo pagrindų, galite gana aiškiai suprasti prievado apibrėžimą. Tai yra sąrašo struktūra ir gali būti kelios. Vienas iš jo atributų yra sąsajos pavadinimas (taip pat raktas). , unikalus, nepakartojamas), taip pat greičio atributas ir dvipusis atributas, kurie abu yra eilutės.
Daugelis tinklo įrenginio atributų yra aprašyti YANG modelyje, įskaitant konfigūracijos būseną ir veikimo būseną.
Tokiu būdu YANG modelis aprašo internetinį pasaulį naudodamas struktūrinę kalbą. Jei susidomėjote, galite perskaityti aukščiau esantį interneto tinklaraščio įrašą, kuriame yra labai išsamus aprašymas.
Jį galima labai gerai konvertuoti į XML duomenis ir suvynioti į Netconf protokolą perdavimui (paaiškinsime vėliau):
Tuo pačiu metu, siekdama išlyginti skirtumus tarp tiekėjų, „Google“ vadovaujama „Openconfig“ standartizavo duomenų modelį. Oficialioje svetainėje matome šūkį „Pardavėjo atžvilgiu neutralus, modeliu pagrįstas tinklo valdymas, sukurtas vartotojų“, kurį sukūrė vartotojai ir įvairiose platformose. Tiekėjų paplitęs, modeliu pagrįstas tinklo programavimas (pirmiausia išverskime taip). Paprasčiau tariant, modeliavimas tarp įvairių gamintojų yra vienodas, kad konfigūruojant tam tikrus duomenis nereikėtų po vieną peržiūrėti kiekvieno gamintojo privatų yang modelį. Tačiau internetas visada turi privačius protokolus, o skirtingi gamintojai visada sukurs naujus ir geresnius privačius protokolus, siekdami „geresnės vartotojo patirties“ ir „geresnės verslo strategijos“ (tai tikrai yra pirminė tinklo gamintojų nuodėmė). Paveikslėlyje parodyta keletas dažniausiai naudojamų openconfig yang modelių įgyvendinimo.
Sprendžiant iš nuotraukos, manau, kad jų yra gana daug, o dažniausiai naudojamos konfigūracijos yra gana išbaigtos. Tačiau praktiškai tai priklauso nuo to, ar gamintojas palaiko ir šiuos yang modelius. Kai kurie aukštesnės versijos tam tikro dalyko įrenginiai iš esmės palaikomi. Į buitines dar neatidžiau apžiūrėjau.
Tinklai negali būti visiškai vienodi. Inžinieriui, kuris užsiima tinklo eksploatavimo ir priežiūros plėtra, yra laimė pasiekti tą patį tikslą!
„Openconfig“ galima rasti adresu https://github.com/openconfig/public/tree/master/release/models
Privačių yang modelių galite rasti įvairiose oficialiose svetainėse.
Netconf protokolas
Pakalbėkime apie yang modelį, pakalbėkime apie Netconf protokolą. Yang modelis apibrėžia skaitmeninį tinklo pasaulio aprašymą, o Netconf apibrėžia duomenų gavimą (gauti) ir koregavimą (konfigūraciją).
Netconf apima pasaulio duomenis, aprašytus yang modeliu, kad būtų galima realizuoti tinklo pasaulio valdymą.
„Yang“ duomenys yra įterpiami į xml ir tvarkomi naudojant Netconf protokolą. Tai protokolas su puikia daugiasluoksne idėja, hierarchiškai aprašantis kai kurias protokolo detales. Pažiūrėkime į paveikslėlį aukščiau.
-Perdavimas: Netconf perduodamas per SSH protokolą, yra orientuotas į ryšį ir turi saugumo garantijas.
-Pranešimas: Skambinkite nuotoliniu būdu į tinklo įrenginį per RPC, tinklo tvarkyklė pateikia RPC užklausą, o tinklo įrenginys atnaujina RPC-reply.
-Operacija: Tai yra Netconf siela. Jis palaiko get (konfigūravimo ir veikimo duomenis), get-config (konfigūracijos duomenų gavimas, o įrenginys gali turėti kelis konfigūracijos duomenis, vienas veikia, vienas paleidimas, keli kandidatai), redaguoti -config (konfigūruoti tinklo įrenginio parametrus, palaiko papildymą, trynimas ir modifikavimas), delete-config, copy-config (nukopijuokite konfigūraciją į paskirties vietą, paskirties vieta gali būti ftp, failas arba veikianti konfigūracija ir pan.), užrakinti/atrakinti (užrakinti konfigūraciją, kad išvengtumėte konfigūracijos konfliktų ar gedimų, kuriuos sukelia kelių procesų operacijos) ir pan.
-Duomenys: duomenys yra yang duomenys, supakuoti į xml. Kaip ir anksčiau aprašytą prievadą, struktūrinius duomenis lengva programuoti. Naudojamas apibūdinti duomenims, kuriuos reikia konfigūruoti, ištrinti arba gauti.
Tai yra keturi Netconf sluoksniai. Valdymo galas ir tinklo įrenginys bendrauja per Netconf, per tradicinį ssh protokolą, naudojant Netconf posistemį, o numatytasis prievadas yra 830. Kaip parodyta toliau:
Šiame paveikslėlyje parodyta sąveika naudojant neapdorotą ssh, tačiau iš tikrųjų šį procesą įgyvendiname programuodami. Programavimo įgyvendinimo būdą jums pademonstruosiu vėliau.
Netconf konfigūruoja tinklo įrenginius. Sąveikos procesas yra maždaug toks:
Šis paveikslėlis yra toks žemas, kad taip pat matote, kad jį nupiešiau aš… Mano supratimas apie Netconf yra toks, kaip aukščiau. Manau, kad internete yra daug neteisingų nuotraukų, o daugelis serverio agento veiksmų yra neteisingi. Tai intuityviai jaučiu prisijungęs prie įrenginio ir, žinoma, tai vienas su kitu atitinka oficialią dokumentaciją.
Galime pažvelgti į keletą Netconf pavyzdžių:
Sveiki, sukurkite nuorodą.
Matėme kelis raktinius žodžius, Netconf versija, palaikomas YANG modelis, sesijos ID. Tuo pačiu metu hello nurodo, kokioje vardų erdvėje dirbame. Šiuo atveju tai yra atitinkama Netconf versija.
Gaukite konfigūraciją
Vienas iš get-cofig parametrų yra šaltinis, iš kurio gaunami konfigūracijos duomenys (veikia, paleidžiama ar kita). Kitas parametras yra filtras, tai yra, kurie duomenys gaunami iš duomenų modelio, aprašyto kokiu yang modeliu. Tai atitinka iš pradžių tinklo įrenginio išsiųstą galimybę. Jei pavyks, bus grąžinti atitinkami konfigūracijos duomenys.
Gaukite konfigūracijos arba veikimo duomenis
Panašiai kaip get-config, bet gaunama paleidžiama konfigūracija (asmeninis supratimas) arba vykdomi duomenys. Filtras gali būti nurodytas.
Kopijuoti konfigūraciją
Kopijavimo operacija turi du parametrus: šaltinį ir paskirties vietą. Sėkmingas atsakymas yra su žyma ok.
Redaguoti konfigūraciją
Redaguodami konfigūraciją nurodykite redaguojamą duomenų elementą, galimybių vardų sritį ir atitinkamą etiketę. Pavyzdžiui, sukonfigūruoti dhcp, kuris aprašytas yang modeliu http://tail-f.com/ns/example/dhcp.
Grakščiai uždarykite sesiją
Būtent toks pranešimas yra perduodamas pirmyn ir atgal ssh. Mes tik ištraukiame dalį pranešimo, kad visi suprastų.
Tada tiesiog pridėkite šiek tiek informacijos.
„Netconf“ yra pagrįsta seansu, o kiekviena sėkmė turės seanso ID.
-Kiekviena užklausa turi pranešimo ID, jei jis palaipsniui didėja
- Duomenų konfigūracija gali būti užrakinta, išskirtinė ir valdoma per užraktą.
-Netconf yra transakcinė, o visos operacijos yra įgyvendintos arba jų nėra. Tuo pačiu metu, remiantis oficialia svetainės dokumentacija, šis sandoris skirtas N tinklo įrenginių konfigūravimui, tai yra, vienkartinis konfigūracijos polimorfizmas gali palaikyti sandorius. Bet aš to dar nepadariau…
- Netconf palaiko prenumeratą. Kalbant apie įrenginio veikimą, tai yra maždaug 5 seansai. Galiu užsiprenumeruoti tam tikrą duomenų elementą ir įrenginys man praneš, kai jis pasikeis.
- Pajėgumas, aš tai suprantu taip. Tinklo įrenginys siunčia Netconf ir YANG modelio versijas, o valdymo terminalas siunčia Netconf versiją. Tik tada, kai „Netconf“ versija atitinka šias dvi versijas, galime tęsti. Tai mano intuityvus jausmas. Bet koks patarimas laukiamas.
- Tokios operacijos kaip gauti redaguoti nurodys keistinus duomenis, kuriuos galima filtruoti naudojant filtrą.
-copy-config palaiko viso konfigūracijų rinkinio kopijavimą iš kažkur į kažkur. Kai kur gali būti FTP failas, veikiantis, paleidžiamas ir galimos konfigūracijos įrenginyje.
-Netconf taip pat palaiko konfigūracijos patikrinimą, naudojant patvirtinimo operaciją.
Šiuo straipsniu vis dar tikimasi populiarinti mokslą, todėl į smulkmenas nesileisiu. Galite perskaityti atitinkamus RFC protokolus, kurie iš tikrųjų nėra labai ilgi.
Praktiškai, remdamiesi kai kuria atvirojo kodo programine įranga, pvz., Python's ncclient, galime lengvai automatiškai sukonfigūruoti tinklo įrenginius ir pasiekti tinklo programuojamumą. Tai yra Netconf ir YANG modelio misija.
Tinklo darbuotojai skaito gerai suformatuotus YANG modelio apibrėžimus ir naudoja atitinkamas programavimo kalbas, kad atliktų programuojamas operacijas tinklo įrenginiuose pagal Netconf apibrėžtas operacijas. Tokiu būdu nutiesiamas kelias į tinklo programuojamumą.
Išplėskime ir įsivaizduokime, kad YANG modelis apibrėžė tinklo įrenginio duomenų struktūrą. Galime valdyti per Netconf. Ar jis taip pat gali būti valdomas naudojant kitus protokolus?
Atsakymas yra taip. Tiesą sakant, daugelis kitų protokolų buvo gauti iš Netconf, pavyzdžiui, RESTConf. Kaip parodyta žemiau,
YANG modelis (viešasis ir vietinis) apibrėžia duomenų struktūrą, virš kurios yra nauji tinklo valdymo protokolai, Netconf, RESTCon, gRPC ir kt. Tokiu būdu tinklo įrenginius galime valdyti per RESTConf, pagrįstą HTTP RESTful API, taip pat galime valdyti tinklą. įrenginius per Netconf, pagrįstą SSH, arba galime valdyti tinklo įrenginius per gRPC, pagrįstą HTTP2.{1}}. Jie visi yra pagrįsti YANG su gera duomenų struktūra. Modeliuokite, parašykite atitinkamus duomenis, įdėkite juos į xml arba json, kad programuotų tinklo įrenginius. Tai tinklo programavimo ateitis. Tiksliau sakant, tai modeliu pagrįsta programa, modeliu pagrįstas tinklo programavimas. Tinklo inžinieriai palaipsniui sutelkia dėmesį į įrenginio parametrus, o ne į komandų rinkinį, o tinklo parametrus konfigūruoja skaitydami atitinkamą duomenų modelį.
Pabaigoje rašau, kodėl turėčiau atidaryti šią viešąją sąskaitą. Mokydamasis mokykloje studijavau informatiką ir technologijas. Įėjęs į darbovietę užsiėmiau tinklo eksploatavimo ir priežiūros darbais. Pagalvojus apie tai, priežastis, kodėl buvau suskirstyta į komandas, gali būti ta, kad buvau Tinklo technologijų tyrimų instituto magistrantas (juokingas vadovas). Nuo pat pradžių dalyvavau tinklo veikloje. Vėlesniame eksploatavimo ir priežiūros etape buvo naudojami įrankiai darbui supaprastinti ir efektyvumui gerinti remiantis CLI. Vėliau įrankiai palaipsniui buvo sukurti į BS struktūros žiniatinklio programas. Jie nuolat buvo veikiami naujomis technologijomis ir toliau praturtino naujas funkcijas.
Laimei, jie pasivijo atvirojo kodo technologijų ir SDN plėtrą, todėl palaipsniui perėjau prie NetDevOps darbo ir panaudojau savo programavimo įgūdžius, kad pagerinčiau komandos veikimo ir priežiūros galimybes. Man taip pat patiko rašyti šią kodo eilutę. Rašant pamažu atrandama, kad „NetDevOps“ turėtų būti įgūdis, kurį ateityje turėtų turėti kiekvienas tinklo inžinierius (kiekvienas pila žibalo į ugnį), kad galėtų pasiekti aukšto lygio planavimą ir greitą įgyvendinimą. Žvelgiant atgal į tam tikrą informaciją internete, atvirai pasakius, Kinijoje yra labai mažai, o buitinė atmosfera nėra labai stipri. Daugelis vietinės programinės įrangos yra pagrįstos senuoju CLI ir snmp, o visi darbui vis dar naudoja teksto įrankius ir SSH įrankius. Taigi tikiuosi, kad ašgaliu išmokyti kitus žvejoti, pasidalinti savo patirtimi (duobėmis) ir įgūdžiais su daugiau tinklo eksploatavimo ir priežiūros inžinierių, ir daryti viską, ką galiu. Xiao Chu teigė, kad galite išmokti ko nors, kad sumažintumėte savo darbo krūvį, o sutelkus dėmesį į tolimą ateitį, vidaus tinklo eksploatavimas ir priežiūra iš tikrųjų gali išsivystyti į automatizavimą.
Ateityje įrašysiu keletą vaizdo įrašų ir parašysiu keletą straipsnių. Labai sunku rašyti dokumentą. Kviečiame prenumeruoti, rinkti, spausti patinka ir žiūrėti.
priedas: Netconf bendrosios operacijos
DWDM OTN sprendimo projektavimas ir sąnaudų citata, susisiekite su manimi, Taylor Huang
