Saistītos rakstus, kurus es kopīgoju par tīkla automatizāciju, lūdzu, skatiet katalogā "NetDevOps no nulles"
Pēdējos gados, nepārtraukti attīstoties globālajai mākoņdatošanas jomai un nepārtraukti augot biznesam, ir turpinājusi attīstīties arī tīkla tehnoloģija, un ir parādījusies SDN tehnoloģija. No sākotnējās pamatidejas par pārsūtīšanas un kontroles atdalīšanu, pamatojoties uz Openflow, cilvēki turpina paplašināties SDN paplašinājumā cilvēki šobrīd var panākt vienprātību, ka Openflow vairs nav nepieciešams nosacījums (bet pārsūtīšanas un kontroles nodalīšana ir joprojām ir galvenais nosacījums), un tīkla programmējamība lēnām ir kļuvusi par vienu no svarīgiem kritērijiem SDN arhitektūras mērīšanai.
Tradicionālo tīkla iekārtu programmējamās darbības parasti balstās uz CLI un SNMP protokoliem. Neatkarīgi no tā, vai tie ir skripti vai tīkla pārvaldības programmatūra, tie visi ir izstrādāti uz šī pamata, lai sasniegtu plašu tīkla programmējamības klāstu, par kuru mēs šodien runāsim. iespējas, tādējādi realizējot daudzu scenāriju automatizāciju. Dažas ierīces atbalsta dažu tīmekļa saskarņu konfigurēšanu un vispārējās konfigurācijas aizstāšanu, izmantojot xml. Tie ir ļoti reti sastopami, un šajā rakstā tie netiks detalizēti aprakstīti.
CLI
CLI (Command-line Interface) realizē cilvēka un datora mijiedarbību, izmantojot komandrindu. Tīkla darbiniekiem tā ir nepieciešama prasme. Cilvēki katru dienu atver ierīcē programmatūru SSH vai Telnet, pēc tam ielīmē konfigurāciju, saglabā to un stājas spēkā. Kādu dienu cilvēkiem apnika šāda veida atkārtošanās un viņi izmantoja programmu, lai automātiski ģenerētu konfigurācijas skriptus, pieteiktos ierīcē pa partijām un izdotu konfigurācijas, lai tās stātos spēkā, realizējot automatizāciju. Šī ir tīkla programmējama metode. Parunāsim par priekšrocībām, kas ļoti saskan ar cilvēku domāšanu, idejām un esošajām tehniskajām sistēmām. Bet galu galā šī pieeja dod priekšroku cilvēkiem, nevis tīkla ierīcēm. Tam ir šādi trūkumi:
- Starp ražotājiem komandu kopās ir milzīgas atšķirības. Ne tikai ražotājiem, bet arī viena un tā paša modeļa dažādām programmatūras versijām var būt ļoti atšķirīgas atšķirības.
-Izstrādātājiem ir jāzina komandu kopa un tās izmantošana. Konfigurācijas līmenī pastāv drošības riski. Piemēram, ar rokas vēzienu ports, kuru gribēju atvērt, pārvērtās par porta aizvēršanu…
-Nav obligātu prasību pārraides protokoliem (SSH un Telnet), un pastāv ražošanas drošības riski.
-Parsēšanas un konfigurāciju ģenerēšanas process ir ārkārtīgi sarežģīts. Daudzos gadījumos regulāri rakstītie noteikumi var būt tikai bezgalīgi tuvu "patiesībai", bet ne visai "patiesībai".
- Nav transakciju, un konfigurācija var daļēji stāties spēkā un daļa nestāties spēkā.
-Nav automatizēta pārbaudes mehānisma un tas ir pilnībā atkarīgs no cilvēkiem. Piemēram, es vēlos pārbaudīt, vai ģenerētais skripts ir pareizs. Ir veids, bet tas ir ļoti grūti un bieži vien grūti viegli īstenojams.
- Nav ne jausmas par datu modelēšanu
CLI vienmēr ir cilvēka un datora mijiedarbības veids. Tas var nodrošināt tīklam noteiktas programmējamības iespējas, izmantojot programmas, taču galu galā tā nav metode, kas pēc būtības ir tīkla programmējama. Pašreizējā mākoņdatošanas un SDN viļņa apstākļos tas nav piemērots liela mēroga automatizētai izvietošanai tīklā, un tā programmējamība ir ierobežota. Ārējiem ir grūti saprast attīstības grūtības.
SNMP
SNMP (SNMP, Simple Network Management Protocol), šis protokols var atbalstīt tīkla pārvaldības sistēmas, lai pārraudzītu, vai tīklam pievienotajās ierīcēs ir situācija, kas izraisa vadības uzmanību. Tas sastāv no tīkla pārvaldības standartu kopas, tostarp lietojumprogrammas slāņa protokola, datu bāzes shēmas un datu objektu kopas.
Daļai Wikipedia satura mēs izceļam tīkla pārvaldības, uzraudzības un datu objektus. To izmanto tīkla pārvaldībai, to var konfigurēt un apkopot, un to galvenokārt izmanto uzraudzībai. Tam ir datu modelēšana, lai strukturētu dažus tīkla aprīkojuma moduļus, raksturlielumus un statusa datus. To galvenokārt izmanto tīkla pārvaldības sistēmām (galvenokārt monitoringam). Tad parunāsim par tā trūkumiem:
- Slikta lasāmība. Tā dod priekšroku "mašīnai" cilvēkā-mašīnā. Lietojot tos nevar nolasīt, un arī modelēšanas dati nav nolasāmi. Tas izmanto ASN.1 superkopu.
-Drošība ir ierobežota. Ir trīs versijas: v1, v2c un v3, un drošība tiek uzlabota secīgi. Tomēr visizplatītākā ir v2c, kurai ir ierobežota drošība. V3 versija ir ļoti droša pēc konstrukcijas, taču tā nav universāla. . .
-Nav dublēšanas, atkopšanas vai atcelšanas mehānisma. Mums ir arī parādīt palaist un citas metodes komandrindas dublēšanai, bet snmp. . .
- Ļoti maz raksta. Daudz lasi, maz raksti, pārsvarā izmanto monitoringam.
-Datu vienumi, kurus var apkopot, ir ierobežoti, un nevar iegūt visas ierīces konfigurāciju. Daudzas reizes mēs atklājam, ka mēs varam izmantot cli, lai to savāktu, bet mēs nevaram izmantot snmp, lai to savāktu.
-Ir darbības sašaurinājums. Apkopoto datu augšējā robeža ir 64 000, un vākšanas precizitāte ir pārāk liela. Lielos un sarežģītos tīklos tas var aizņemt minūtes vai ilgāk. Tas arī izceļ svarīgo punktu. Arī mūsu prasības attiecībā uz precizitāti ir ļoti stingras. Daudzas reizes mēs ceram apkopot ostas satiksmi ik pēc dažām sekundēm. Lielos tīklos, manuprāt, tradicionālā tīkla pārvaldības programmatūra ir… Lai izvērstu vēl vienu teikumu, pašreizējā metode ir telemetrija (piemēram, gRPC), kas var sasniegt mikrosekundes līmeni, un dažām ir nepieciešama programmatūras un aparatūras kombinācija. Pagaidām tas nav populārs, bet nākotnē tai ir jābūt tendencei. Runājot par to, kad tas notiks nākotnē…
-Kopš tā dzimšanas SNMP ir plaši izmantots tīkla uzraudzības jomā, lai iegūtu datus monitoringam. Konfigurācijas iespēju trūkums un sarežģītība ir ļāvusi to maz izmantot tīkla konfigurācijā. Programmējams tikai lasāms tīkls.
Netconf protokols un YANG modelis
Saskaroties ar nākamās paaudzes tīkliem, kādi tīkla pārvaldības protokoli mums ir nepieciešami, lai labāk realizētu tīkla programmējamību un uzlabotu automatizācijas līmeni?
IETF 2002. gadā RFC3535 piedāvāja šādas idejas (patiesībā tās ir 33. Pamatojoties uz tiešsaistes informāciju un autora zināšanām, es uzrakstīju šādas idejas):
1. Tīkla konfigurēšanai ir programmējams interfeiss
2. To pašu konfigurāciju var izmantot dažādiem ražotājiem un modeļiem
3. Nepieciešams unificēt modelēšanas valodu ar labu lasāmību
4. Pabeigt kļūdu pārbaudes un atkopšanas funkcijas
5. Darījums
Ja jums ir ideja, vienkārši īstenojiet to. 2006. gadā IETF ierosināja Netconf protokolu, kas atrisināja RFC3535 radītās problēmas. Sākotnējā Netconf noteica tikai protokola pamata ietvaru un darbības, kā arī noteica risinājumus, kuros tika ņemtas vērā dažas RFC3535 problēmas. Tajā nebija noteikta vienota modelēšanas valoda. Tāpēc dažu sākotnējo ražotāju aprīkojums atbalstīja tikai dažas Netconf pamatdarbības un neizmantoja vienotu apakšējo slāni. Datu modelēšanas valoda.
RFC6020 tika izlaists 2010. gadā, piedāvājot YANG modeļa modelēšanas valodu un metodi tās apvienošanai ar NETCONF. Viena definīcija ir datu modelēšanas valoda, kas apvieno pamatā esošo resursu loģiku starp ražotājiem, bet otra definīcija ir vienota komandu kopa katra ražotāja darbībām ar konfigurācijas datiem un statusa datiem. YANG modeļa izveidotie datu gadījumi tiek ietīti Netconf protokolā. Pārraide, abas tiek apvienotas viena ar otru, lai izveidotu jaunu universālo tīkla programmējamo saskarņu komplektu jaunajam laikmetam, pamatojoties uz YANG modeli un ko virza Netconf protokols.
Pēc 2016. gada Netconf protokols tika cieši integrēts YANG modelī un kļuva populārs. Līdz šim, aplūkojot dažus SDN arhitektūras programmatūras aspektus, mēs esam vairāk vai mazāk dzirdējuši šos divus terminus.
YANG un Netconf, viens ir statisks, bet otrs ir dinamisks, tāpat kā iņ un jaņ. Abi ir atvasinājuši nākamā laikmeta tīkla programmējamo pasauli. (Aplūkojot YANG noliktavu vietnē github, mēs arī atklāsim, ka tās ikona ir Tai Chi, un saikne starp tās nosaukumu un "Yang" nedaudz atklāj sākotnējā dizainera dizaina idejas).
Tālāk mēs īsi runāsim par YANG modeli un Netconf protokolu. Vispirms parunāsim par datu modelēšanas valodu YANG, lai redzētu, kā tā raksturo šīs tīkla pasaules digitālo dvīņu.
YANG modelis
RFC6020 dokumenta sākuma nodaļā ir skaidri norādīts, YANG, datu modelēšanas valoda tīkla konfigurācijas protokolam. Tas ir saīsinājums no Yet Another Next Generation (Yang) datu modelēšanas valodas. Tā ir modelēšanas valoda, ko izmanto, lai aprakstītu tīkla koncepcijas.
Atbalsta sarakstu, vārdnīcu un vēl sarežģītāku datu struktūru definēšanu, atbalsta ierobežojumus, uzskaitījumus, atsauču importēšanu, versiju pārvaldību un nosaukumvietas. Vietas trūkuma dēļ sniegsim īsu skaidrojumu. Lai iegūtu detalizētu informāciju, varat skatīt:
Tas var ļoti vienkārši aprakstīt šo tīkla ierīci strukturētā valodā. Piemēram, ostas definīcijai:
Kā profesionāls ekspluatācijas un apkopes personāls, kuram ir mazliet tīkla pamati un nedaudz programmēšanas pamati, jūs varat samērā skaidri saprast porta definīciju. Tā ir saraksta struktūra, un to var būt vairākas. Viens no tā atribūtiem ir interfeisa nosaukums (arī atslēga). , unikāls, neatkārtojams), kā arī ātruma atribūts un dupleksa atribūts, kas abi ir virknes.
YANG modelī ir aprakstīti daudzi tīkla ierīces atribūti, tostarp konfigurācijas statuss un darbības statuss.
Tādā veidā YANG modelis apraksta tiešsaistes pasauli, izmantojot strukturētu valodu. Ja jūs interesē, varat izlasīt iepriekš minēto interneta emuāra ierakstu, kurā ir ļoti padziļināts apraksts.
To var ļoti labi pārvērst XML datos un ietīt Netconf protokolā pārraidei (mēs to paskaidrosim vēlāk):
Tajā pašā laikā, lai izlīdzinātu atšķirības starp pārdevējiem, Google vadītais Openconfig ir standartizējis datu modeli. Oficiālajā vietnē mēs redzam saukli "Vendor-neutral, model-driven network management, design by users", ko izstrādājuši lietotāji un starpplatformu. Pārdevēju izplatīta, modeļu vadīta tīkla programmēšana (vispirms tulkosim šādā veidā). Vienkāršoti sakot, tas nozīmē, ka modelēšana starp dažādiem ražotājiem ir vienāda, lai, konfigurējot noteiktus datus, jums nav jāmeklē katra ražotāja privātais yang modelis pa vienam. Taču internetā vienmēr ir privātie protokoli, un dažādi ražotāji vienmēr radīs jaunus un labākus privātos protokolus "labākai lietotāju pieredzei" un "labākai biznesa stratēģijai" (tas tiešām ir tīkla ražotāju sākotnējais grēks). Attēlā ir redzamas dažas biežāk izmantotās openconfig yang modeļa implementācijas.
Spriežot pēc bildes, manuprāt, to ir diezgan daudz, un arī parasti lietotās konfigurācijas ir salīdzinoši komplektētas. Bet praksē tas ir atkarīgs no tā, vai ražotājs atbalsta arī šos yang modeļus. Pamatā tiek atbalstītas dažas noteikta priekšmeta augstākas versijas ierīces. Pašmāju tuvāk vēl neesmu apskatījis.
Tīkli nevar būt pilnīgi vienādi. Inženierim, kurš nodarbojas ar tīklu ekspluatācijas un uzturēšanas izstrādi, tā ir svētība, ka viņš spēj sasniegt vienu un to pašu mērķi!
Openconfig var atrast vietnē https://github.com/openconfig/public/tree/master/release/models
Privātus jaņ modeļus varat atrast dažādās oficiālajās vietnēs.
Netconf protokols
Pēc runāšanas par jaņ modeli, parunāsim par Netconf protokolu. Jaņ modelis definē tīkla pasaules digitālo aprakstu, un Netconf definē datu iegūšanu (get) un pielāgošanu (konfigurāciju).
Netconf iekapsulē yang modeļa aprakstītās pasaules datus, lai realizētu tīkla pasaules pārvaldību.
Yang dati tiek iekapsulēti xml un pēc tam tiek pārvaldīti, izmantojot Netconf protokolu. Tas ir protokols ar lielisku slāņveida ideju, kas hierarhiskā veidā apraksta dažas protokola detaļas. Apskatīsim attēlu augstāk.
-Pārsūtīšana: Netconf tiek pārraidīts, izmantojot SSH protokolu, ir orientēts uz savienojumu, un tam ir drošības garantijas.
-Ziņojums: veiciet attālo zvanu uz tīkla ierīci, izmantojot RPC, tīkla pārvaldnieks izdod RPC pieprasījumu, un tīkla ierīce atsāk RPC-reply.
-Darbība: šī ir Netconf dvēsele. Tā atbalsta get (konfigurācijas un darbības dati), get-config (konfigurācijas datu iegūšana, un ierīcei var būt vairāki konfigurācijas dati, viens darbojas, viena startēšana, vairāki kandidāti), rediģēšana -config (konfigurēt tīkla ierīces parametrus, atbalsta pievienošanu, dzēšana un modificēšana), delete-config, copy-config (kopējiet konfigurāciju galamērķī, galamērķis var būt ftp, fails vai darbojas konfigurācija utt.), bloķēt/atbloķēt (bloķēt konfigurāciju, lai novērstu konfigurācijas konfliktus vai kļūmes, ko izraisa vairāku procesu operācijas) un tā tālāk.
-Dati: dati ir yang dati, kas iesaiņoti xml formātā. Tāpat kā iepriekš aprakstīto portu, strukturētos datus ir viegli programmēt. Izmanto, lai aprakstītu konfigurējamos, dzēšamos vai iegūstamos datus.
Šie ir četri Netconf slāņi. Vadības gals un tīkla ierīce sazinās, izmantojot Netconf, izmantojot tradicionālo ssh protokolu, izmantojot Netconf apakšsistēmu, un noklusējuma ports ir 830. Kā parādīts tālāk:
Šis attēls parāda mijiedarbību, izmantojot neapstrādātu ssh, bet patiesībā mēs šo procesu īstenojam, izmantojot programmēšanu. Programmēšanas ieviešanas metodi es jums parādīšu vēlāk.
Netconf konfigurē tīkla ierīces. Mijiedarbības process ir aptuveni šāds:
Šis attēls ir tik zems, jūs varat arī redzēt, ka to esmu zīmējis es... Mana izpratne par Netconf ir tāda pati kā iepriekš. Es domāju, ka internetā ir daudz attēlu, kas nav pareizi, un daudzas servera aģenta darbības nav pareizas. Tas ir tas, ko es intuitīvi jūtu, piesakoties ierīcē, un, protams, tas atbilst oficiālajai dokumentācijai.
Mēs varam apskatīt dažus Netconf piemērus:
Sveiki, izveidojiet saiti.
Mēs redzējām vairākus atslēgvārdus, Netconf versiju, atbalstīto YANG modeli, sesijas ID. Tajā pašā laikā hello norāda, kurā nosaukumvietā mēs darbojamies. Šajā gadījumā tā ir atbilstošā Netconf versija.
Iegūstiet konfigurāciju
Viens no get-cofig parametriem ir avots, kur tiek iegūti konfigurācijas dati (palaišana, palaišana vai cits). Vēl viens parametrs ir filtrs, tas ir, kuri dati tiek iegūti no datu modeļa, ko apraksta kāds jaņ modelis. Tas atbilst tīkla ierīces sākotnēji nosūtītajai iespējai. Ja tas izdosies, tiks atgriezti atbilstošie konfigurācijas dati.
Iegūstiet konfigurācijas vai darbības datus
Līdzīgi kā get-config, bet iegūtais ir darbības konfigurācija (personiskā izpratne) vai darbības dati. Filtru var norādīt.
Kopēt konfigurāciju
Kopēšanas darbībai ir divi parametri: avots un galamērķis. Veiksmīga atbilde ir ar atzīmi ok.
Rediģēt konfigurāciju
Rediģējot konfigurāciju, norādiet rediģējamo datu vienumu, iespējas nosaukumvietu un atbilstošo etiķeti. Piemēram, tas ir paredzēts, lai konfigurētu dhcp, ko apraksta yang modelis http://tail-f.com/ns/example/dhcp.
Graciozi noslēdziet sesiju
Tas ir šāda veida ziņojums, kas tiek pārraidīts uz priekšu un atpakaļ ssh. Mēs tikai izvilkām daļu no ziņojuma, lai atvieglotu ikviena izpratni.
Pēc tam vienkārši pievienojiet saturu atsaucei.
-Netconf pamatā ir sesija, un katram panākumam būs sesijas ID.
-Katram pieprasījumam ir ziņojuma ID, ja vien tas pakāpeniski kļūst lielāks
-Datu konfigurāciju var bloķēt, ekskluzīvu un darbināt, izmantojot bloķēšanu.
- Netconf ir transakcija, un visas darbības ir ieviestas vai nav nevienas. Tajā pašā laikā saskaņā ar oficiālās vietnes dokumentāciju šī transakcija ir paredzēta N tīkla ierīču konfigurācijai, tas ir, vienreizējais konfigurācijas polimorfisms var atbalstīt transakciju. Bet es to vēl neesmu izdarījis…
- Netconf atbalsta abonēšanu. Runājot par ierīces veiktspēju, lieluma secība ir aptuveni 5 sesijas. Es varu abonēt noteiktu datu vienumu, un ierīce man paziņos, kad tas mainīsies.
- Spēja, tā es to saprotu. Tīkla ierīce nosūta Netconf un YANG modeļa versiju, un vadības terminālis nosūta Netconf versiju. Tikai tad, kad Netconf versija atbilst abiem, mēs varam turpināt. Tā ir mana intuitīvā sajūta. Jebkurš padoms ir apsveicams.
- Operācijas, piemēram, rediģēšanas iegūšana, norādīs maināmos datus, kurus var filtrēt, izmantojot filtru.
-copy-config atbalsta pilna konfigurāciju kopuma kopēšanu no kaut kurienes uz kaut kur. Kaut kur var būt FTP fails, kas darbojas, tiek startēts un ierīces kandidātkonfigurācijas.
-Netconf atbalsta arī konfigurācijas pārbaudi, izmantojot pārbaudes darbību.
Šis raksts joprojām cer popularizēt zinātni, un es neiedziļināšos. Jūs varat izlasīt attiecīgos RFC protokolus, kas patiesībā nav ļoti garš.
Praksē, pamatojoties uz kādu atvērtā pirmkoda programmatūru, piemēram, python's ncclient, mēs varam viegli automātiski konfigurēt tīkla ierīces un panākt tīkla programmējamību. Tā ir Netconf un YANG modeļa misija.
Tīkla darbinieki lasa labi formatētās YANG modeļa definīcijas un izmanto attiecīgās programmēšanas valodas, lai veiktu programmējamas darbības tīkla ierīcēs, pamatojoties uz Netconf definētajām darbībām. Tādā veidā tiek izveidots ceļš uz tīkla programmējamību.
Izvērsīsimies un iedomāsimies, ka YANG modelis ir definējis tīkla ierīces datu struktūru. Mēs to varam darbināt, izmantojot Netconf. Vai to var darbināt arī ar citiem protokoliem?
Atbilde ir jā. Faktiski daudzi citi protokoli ir atvasināti no Netconf, piemēram, RESTConf. Kā parādīts zemāk,
YANG modelis (publiskais un vietējais) nosaka datu struktūru, virs kuras atrodas jauni tīkla pārvaldības protokoli, Netconf, RESTCon, gRPC utt. Tādā veidā mēs varam darbināt tīkla ierīces, izmantojot RESTConf, pamatojoties uz HTTP RESTful API, mēs varam arī darbināt tīklu. ierīces, izmantojot Netconf, kuras pamatā ir SSH, vai mēs varam darbināt tīkla ierīces, izmantojot gRPC, pamatojoties uz HTTP2.{1}}. Tie visi ir balstīti uz YANG ar labu datu struktūru. Modelējiet, ierakstiet atbilstošos datus, iekapsulējiet tos xml vai json, lai programmētu tīkla ierīces. Šī ir tīkla programmējamības nākotne. Precīzāk sakot, tā ir uz modeļiem balstīta tīkla programmējamība. Tīkla inženieri pakāpeniski pievērš uzmanību ierīces parametriem, nevis komandu kopai, un konfigurē tīkla parametrus, nolasot atbilstošo datu modeli.
Beigās es rakstu, kāpēc man vajadzētu atvērt šo publisko kontu. Es mācījos datorzinātnes un tehnoloģijas, kad mācījos skolā. Pēc ienākšanas darba vietā nodarbojos ar tīkla ekspluatācijas un uzturēšanas darbiem. Padomājot par to, iemesls, kāpēc es tiku sadalīts komandās, varētu būt tāpēc, ka biju Tīkla tehnoloģiju pētniecības institūta maģistrants (smieklīgi rokasgrāmata). Jau no paša sākuma biju iesaistīts tīkla darbībā. Vēlākajā darbības un apkopes posmā tika izmantoti rīki, lai vienkāršotu darbu un uzlabotu efektivitāti, pamatojoties uz CLI. Vēlāk rīki pakāpeniski tika izstrādāti BS strukturētās tīmekļa lietojumprogrammās. Viņi pastāvīgi tika pakļauti jaunām tehnoloģijām un turpināja bagātināt jaunas funkcijas.
Par laimi viņi panāca atvērtā pirmkoda tehnoloģiju un SDN attīstību, un pakāpeniski es pārgāju uz NetDevOps darbu un izmantoju savas programmēšanas prasmes, lai uzlabotu komandas darbības un uzturēšanas iespējas. Man arī patika rakstīt šo koda rindiņu. Rakstīšanas gaitā pamazām atklājas, ka NetDevOps ir jābūt prasmei, kurai nākotnē vajadzētu būt katram tīkla inženierim (katrs pielej eļļu ugunij), lai viņi varētu sasniegt gan augsta līmeņa plānošanu, gan ātru ieviešanu. Atskatoties uz kādu informāciju internetā, godīgi sakot, Ķīnā ir ļoti maz, un arī sadzīves atmosfēra nav īpaši spēcīga. Daudzas vietējās programmatūras ir balstītas uz veco CLI un snmp, un visi joprojām izmanto teksta rīkus un SSH rīkus darbam. Tāpēc es ceru, ka esvaru iemācīt citiem makšķerēt, dalīties pieredzē (bedres) un prasmēs ar vairāk tīkla darbības un apkopes inženieriem, un daru visu iespējamo. Xiao Chu teica, ka jūs varat kaut ko iemācīties, lai samazinātu savu darba slodzi, un, koncentrējoties uz tālo nākotni, vietējā tīkla darbība un uzturēšana var patiešām attīstīties automatizācijas virzienā.
Nākotnē es ierakstīšu dažus video un uzrakstīšu dažus rakstus. Rakstīt dokumentu šķiet ļoti grūti. Aicinām abonēt, savākt, spiest patīk un skatīties.
pielikums: Netconf kopējās darbības
DWDM OTN risinājumu dizains un izmaksu piedāvājums, lūdzu, saite ar mani, Teilori Huanu
