Ağ otomasyonu hakkında paylaştığım ilgili makaleler için lütfen "NetDevOps from Scratch" kataloğuna bakın.
Son yıllarda küresel bulut bilişim alanının sürekli gelişmesi ve iş dünyasının sürekli büyümesiyle birlikte ağ teknolojisi de gelişmeye devam etti ve SDN teknolojisi ortaya çıktı. İnsanlar, Openflow'a dayalı olarak yönlendirme ve kontrolün ayrılmasına ilişkin orijinal temel fikri genişletmeye devam ediyor. SDN'nin uzantısında, insanlar şu anda Openflow'un artık gerekli bir koşul olmadığı (ancak yönlendirme ve kontrolün ayrılmasının gerekli olduğu) konusunda fikir birliğine varabiliyor. hala temel bir koşuldur) ve ağ programlanabilirliği yavaş yavaş bir SDN mimarisini ölçmek için önemli kriterlerden biri haline gelmiştir.
Geleneksel ağ ekipmanlarının programlanabilir işlemleri genellikle CLI ve SNMP protokollerine dayanmaktadır. İster komut dosyaları ister ağ yönetim yazılımı olsun, bunların hepsi, bugün konuşacağımız geniş ağ programlanabilirliği aralığını elde etmek için bu temelde geliştirilir. yetenekleri sayesinde birçok senaryonun otomasyonu gerçekleştiriliyor. Bazı cihazlar, bazı web arayüzlerinin yapılandırılmasını ve genel yapılandırmanın xml aracılığıyla değiştirilmesini destekler. Bunlar çok nadirdir ve bu makalede ayrıntılı olarak açıklanmayacaktır.
CLI
CLI (Komut Satırı Arayüzü), insan-bilgisayar etkileşimini komut satırı aracılığıyla gerçekleştirir. Ağ çalışanları için gerekli bir beceridir. İnsanlar her gün cihaza SSH veya Telnet yazılımını açıyor, ardından bir konfigürasyon yapıştırıyor, kaydediyor ve yürürlüğe giriyor. Bir gün, insanlar bu tür tekrarlardan sıkıldılar ve otomatik olarak yapılandırma komut dosyaları oluşturmak, cihazda gruplar halinde oturum açmak ve yapılandırmaların etkili olması için yayınlamak için bir program kullanarak otomasyonu gerçekleştirdiler. Bu ağda programlanabilir bir yöntemdir. İnsanların düşünceleriyle, fikirleriyle ve mevcut teknik sistemlerle son derece tutarlı olan avantajlardan bahsedelim. Ancak sonuçta bu yaklaşım, ağ cihazları yerine insanları tercih ediyor. Aşağıdaki dezavantajları vardır:
-Üreticiler arasında komut setlerinde çok büyük farklılıklar var. Yalnızca üreticiler değil, aynı modelin farklı yazılım versiyonları da çok farklı farklılıklara sahip olabilir.
-Geliştiriciler komut setine ve nasıl kullanılacağına aşina olmalıdır. Yapılandırma düzeyinde güvenlik riskleri vardır. Mesela açmak istediğim port bir el hareketiyle portun kapanmasına dönüştü…
-İletim protokolleri (SSH ve Telnet) için zorunlu gereksinimler yoktur ve üretim güvenliği riskleri vardır.
-Konfigürasyonları ayrıştırma ve oluşturma süreci son derece karmaşıktır. Çoğu durumda, yazılan düzenli kurallar yalnızca "gerçeğe" sonsuz derecede yakın olabilir, ancak "gerçeğin" tamamı olamaz.
-İşlemsellik yoktur ve bir yapılandırma kısmen geçerli olabilir, kısmen geçerli olmayabilir.
-Otomatik bir denetim mekanizması yoktur ve tamamen kişiye bağlıdır. Örneğin oluşturulan betiğin doğru olup olmadığını test etmek istiyorum. Bir yolu var ama kolayca uygulanması çok zor ve çoğu zaman zordur.
-Veri modelleme konusunda hiçbir fikrim yok
CLI her zaman insan-bilgisayar etkileşiminin bir yoludur. Ağa programlar aracılığıyla belirli programlanabilirlik yetenekleri kazandırabilir, ancak sonuçta doğası gereği ağda programlanabilir bir yöntem değildir. Mevcut bulut bilişim ve SDN dalgası altında, ağda büyük ölçekli otomatik dağıtım için uygun değildir ve programlanabilirliği sınırlıdır. Dışarıdan gelenlerin gelişimin zorluğunu anlaması zordur.
SNMP
SNMP (SNMP, Basit Ağ Yönetim Protokolü), bu protokol, ağa bağlı cihazların yönetimin dikkatine neden olacak herhangi bir durumun olup olmadığının izlenmesi için ağ yönetim sistemlerini destekleyebilir. Bir uygulama katmanı protokolü, veritabanı şeması ve bir dizi veri nesnesi dahil olmak üzere bir dizi ağ yönetimi standardından oluşur.
Vikipedi'deki bir içerik için ağ yönetimini, izlemeyi ve veri nesnelerini vurgularız. Ağı yönetmek için kullanılır, yapılandırılabilir ve toplanabilir ve esas olarak izleme için kullanılır. Ağ ekipmanının bazı modüllerini, özelliklerini ve durum verilerini yapılandırmak için veri modellemesine sahiptir. Esas olarak ağ yönetim sistemleri (çoğunlukla izleme) için kullanılır. O zaman eksikliklerinden bahsedelim:
-Zayıf okunabilirlik. İnsan-makinedeki “makine”yi tercih ediyor. Kullanıldığında okunamaz ve modelleme verileri de okunamaz. ASN.1'in bir üst kümesini kullanır.
-Güvenlik sınırlıdır. Üç sürümü vardır: v1, v2c ve v3 ve güvenlik sırayla iyileştirilmiştir. Ancak en yaygın olanı sınırlı güvenliğe sahip olan v2c'dir. V3 sürümü tasarım gereği oldukça güvenlidir ancak evrensel değildir. . .
-Yedekleme, kurtarma veya geri alma mekanizması yoktur. Ayrıca komut satırını yedeklemek için show run ve başka yöntemlerimiz de var, ancak snmp. . .
-Çok az yazar. Çok okuyun, az yazın, çoğunlukla izleme amaçlı kullanılır.
-Toplanabilecek veriler sınırlıdır ve cihazın tamamının konfigürasyonu elde edilememektedir. Çoğu zaman onu toplamak için cli'yi kullanabileceğimizi görüyoruz, ancak onu toplamak için snmp'yi kullanamıyoruz.
-Performans darboğazı var. Toplanan verilerin üst sınırı 64K'dır ve toplama ayrıntı düzeyi çok büyüktür. Büyük ve karmaşık ağlarda dakikalar veya daha uzun sürebilir. Bu aynı zamanda önemli bir noktayı da vurguluyor. Ayrıntı düzeyine ilişkin gereksinimlerimiz de çok katıdır. Çoğu zaman liman trafiğini birkaç saniyede bir toplamayı umuyoruz. Büyük ağlarda geleneksel ağ yönetimi yazılımı sanırım… Bir cümleyi daha genişletecek olursak, mevcut yöntem mikrosaniye seviyesine ulaşabilen Telemetridir (gRPC gibi) ve bazıları yazılım ve donanım kombinasyonu gerektirir. Henüz popüler değil ama gelecekte bir trend olmalı. Bunun gelecekte ne zaman gerçekleşeceğine gelince…
-Doğumundan bu yana SNMP, ağ izleme alanında izleme için veri elde etmek amacıyla büyük ölçüde kullanılmıştır. Yapılandırma yeteneklerinin eksikliği ve karmaşıklığı, ağ yapılandırmasında bu yeteneklerin çok az kullanılmasına yol açmıştır. Salt okunur ağ programlanabilir.
Netconf Protokolü ve YANG Modeli
Yeni nesil ağlarla karşı karşıya kaldığımızda, ağ programlanabilirliğini daha iyi gerçekleştirmek ve otomasyon düzeyini artırmak için ne tür ağ yönetimi protokollerine ihtiyacımız var?
IETF, 2002 yılında RFC3535'te aşağıdaki fikirleri önerdi (aslında bunlardan 33 tane var. Çevrimiçi bilgilere ve yazarın bilgisine dayanarak aşağıdaki fikirleri yazdım):
1. Ağ yapılandırması için programlanabilir bir arayüz vardır
2. Aynı konfigürasyon üreticiler ve modeller arasında kullanılabilir
3. İyi okunabilirliğe sahip bir modelleme dilini birleştirme ihtiyacı
4. Hata kontrolü ve kurtarma işlevlerini tamamlayın
5. İşlemsel
Bir fikriniz varsa hemen uygulayın. 2006 yılında IETF, RFC3535'in ortaya çıkardığı sorunları çözen Netconf protokolünü önerdi. İlk Netconf, yalnızca protokolün temel çerçevesini ve işlemlerini öngördü ve RFC3535'in bazı sorunlarını dikkate alan çözümleri tanımladı. Birleşik bir modelleme dili şart koşmadı. Bu nedenle, bazı eski üreticilerin ekipmanları Netconf'un yalnızca bazı temel işlemlerini destekliyordu ve birleşik bir alt katman kullanmıyordu. Veri modelleme dili.
RFC6020, YANG Model modelleme dilini ve onu NETCONF ile birleştirme yöntemini öneren 2010 yılında piyasaya sürüldü. Tanımlardan biri, üreticiler arasındaki temel kaynak mantığını birleştiren bir veri modelleme dilidir ve diğer tanım, her üreticinin konfigürasyon verileri ve durum verileri üzerindeki işlemleri için birleşik bir komut setidir. YANG modeli tarafından oluşturulan veri örnekleri Netconf protokolüne sarılır. İletimde, YANG modelini temel alan ve Netconf protokolü tarafından yönlendirilen yeni çağ için yeni bir dizi evrensel ağ programlanabilir arayüz oluşturmak üzere bu ikisi birbiriyle birleştirilir.
2016 yılından sonra Netconf protokolü YANG Modeli ile yakından entegre oldu ve popüler hale geldi. Şu ana kadar bazı SDN mimarisi yazılım yönlerine baktığımızda bu iki terimi az çok duymuşuzdur.
YANG ve Netconf, tıpkı yin ve yang gibi biri statik, diğeri dinamik. İkisi bir sonraki çağın ağ üzerinden programlanabilir dünyasını türetmiştir. (Github'daki YANG deposuna baktığımızda simgesinin Tai Chi olduğunu ve adı ile "Yang" arasındaki bağlantının bir nevi orijinal tasarımcının tasarım fikirlerini ortaya çıkardığını da göreceğiz).
Daha sonra YANG Modelinden ve Netconf protokolünden kısaca bahsedeceğiz. Bu ağ dünyasının dijital ikizini nasıl tanımladığını görmek için öncelikle veri modelleme dili YANG'dan bahsedelim.
YANG Modeli
RFC6020 belgesinin açılış bölümünde, Ağ Yapılandırma Protokolü için Bir Veri Modelleme Dili olan YANG açıkça belirtilmektedir. Yet Another Next Generation (Yang) Veri Modelleme Dili'nin kısaltmasıdır. Ağ kavramlarını tanımlamak için kullanılan bir modelleme dilidir.
Listelerin, sözlüklerin ve hatta daha karmaşık veri yapılarının tanımını destekler; kısıtlamaları, numaralandırmaları, referans içe aktarmaları, sürüm yönetimini ve ad alanlarını destekler. Yer darlığı nedeniyle kısa bir açıklama yapacağız. Detaylı bilgi için şu adrese başvurabilirsiniz:
Bu ağ cihazını yapılandırılmış bir dille çok basit bir şekilde tanımlayabilir. Örneğin, bir bağlantı noktasının tanımı için:
Biraz ağ temelleri ve biraz programlama temelleri olan profesyonel bir işletme ve bakım personeli olarak, portun tanımını nispeten net bir şekilde anlayabilirsiniz. Bu bir liste yapısıdır ve birden fazla olabilir. Niteliklerinden biri arayüz adıdır (aynı zamanda bir anahtar). , benzersiz, tekrarlanamaz) ve her ikisi de dize olan hız özelliği ve çift yönlü özelliği.
Bir ağ cihazının konfigürasyon durumu ve çalışma durumu da dahil olmak üzere birçok özelliği YANG Modeli tarafından tanımlanır.
YANG Modeli bu şekilde çevrimiçi dünyayı yapılandırılmış bir dil kullanarak anlatır. İlgileniyorsanız, çok ayrıntılı bir açıklamaya sahip olan yukarıdaki İnternet blog yazısını okuyabilirsiniz.
XML verilerine çok iyi bir şekilde dönüştürülebilir ve iletim için Netconf protokolüne sarılabilir (bunu daha sonra açıklayacağız):
Aynı zamanda satıcılar arasındaki farkları eşitlemek için Google liderliğindeki Openconfig veri modelini standartlaştırdı. Resmi web sitesinde, kullanıcılar tarafından tasarlanan ve platformlar arası "Satıcıdan bağımsız, kullanıcılar tarafından tasarlanan model odaklı ağ yönetimi" sloganını görüyoruz. Satıcının ortak, model odaklı ağ programlaması (önce bunu bu şekilde çevirelim). Basitçe söylemek gerekirse, çeşitli üreticiler arasındaki modellemeyi aynı hale getirmektir, böylece belirli verileri yapılandırdığınızda her üreticinin özel yang modeline tek tek bakmak zorunda kalmazsınız. Ancak İnternet'in her zaman özel protokolleri vardır ve farklı üreticiler her zaman "daha iyi kullanıcı deneyimi" ve "daha iyi iş stratejisi" için yeni ve daha iyi özel protokoller yaratacaktır (bu aslında ağ üreticilerinin ilk günahıdır). Resimde daha sık kullanılan openconfig yang modeli uygulamalarından bazıları gösterilmektedir.
Resimden yola çıkarak, oldukça fazla sayıda olduğunu ve yaygın olarak kullanılan konfigürasyonların nispeten eksiksiz olduğunu düşünüyorum. Ancak pratikte bu, üreticinin de bu yang modellerini destekleyip desteklemediğine bağlıdır. Belirli bir konunun bazı yüksek versiyonlu cihazları temel olarak desteklenmektedir. Henüz yerli olanlara daha yakından bakmadım.
Ağlar tamamen aynı olamaz. Ağ işletimi ve bakım geliştirmeyle uğraşan bir mühendis için aynı hedefe ulaşabilmek bir nimettir!
openconfig https://github.com/openconfig/public/tree/master/release/models adresinde bulunabilir.
Özel yang modellerini çeşitli resmi web sitelerinde bulabilirsiniz.
Netconf protokolü
Yang modelinden bahsettikten sonra Netconf protokolünden bahsedelim. Yang modeli, ağ dünyasının dijital tanımını tanımlar ve Netconf, verilerin edinilmesini (get) ve ayarlanmasını (config) tanımlar.
Netconf, ağ dünyasının yönetimini gerçekleştirmek için yang modeliyle tanımlanan dünyanın verilerini kapsüller.
Yang verileri xml olarak kapsüllenir ve ardından Netconf protokolü aracılığıyla yönetilir. Protokolün bazı ayrıntılarını hiyerarşik bir şekilde açıklayan, harika katmanlı bir fikre sahip bir protokoldür. Yukarıdaki resme bakalım.
-İletim: Netconf, SSH protokolü üzerinden iletilir, bağlantı odaklıdır ve güvenlik garantileri vardır.
-Mesaj: RPC aracılığıyla ağ cihazına uzaktan arama yapın, ağ yöneticisi bir rpc isteği gönderir ve ağ cihazı rpc yanıtını sürdürür.
-Operasyon: Bu Netconf'un ruhudur. Get (yapılandırma ve çalıştırma verileri), get-config (yapılandırma verilerinin alınması ve bir cihazın birden fazla yapılandırma verisi, bir çalışan, bir başlangıç, birden fazla aday adayı olabilir), edit -config (ağ aygıtı parametrelerini yapılandırma, eklemeyi destekler, silme ve değiştirme), delete-config, copy-config (yapılandırmayı hedefe kopyalayın, hedef ftp, dosya veya çalışan yapılandırma vb. olabilir), lock\unlock (yapılandırma çakışmalarını veya yapılandırmanın neden olduğu arızaları önlemek için yapılandırmayı kilitleyin) çok işlemli işlemler) vb.
-Veri: veri, xml'e sarılmış yang verisidir. Yukarıda tanımladığımız bağlantı noktası gibi yapılandırılmış verilerin programlanması kolaydır. Yapılandırılacak, silinecek veya elde edilecek verileri tanımlamak için kullanılır.
Bunlar Netconf'un dört katmanıdır. Kontrol ucu ve ağ cihazı, Netconf alt sistemini kullanarak geleneksel ssh protokolü aracılığıyla Netconf aracılığıyla iletişim kurar ve varsayılan bağlantı noktası 830'dur. Aşağıda gösterildiği gibi:
Bu şekil raw ssh kullanılarak yapılan etkileşimi göstermektedir ancak aslında bu süreci programlama yoluyla gerçekleştiriyoruz. Programlama uygulama yöntemini size daha sonra göstereceğim.
Netconf ağ cihazlarını yapılandırır. Etkileşim süreci kabaca aşağıdaki gibidir:
Bu resim o kadar alçak ki, benim tarafımdan çizildiğini de görebilirsiniz… Benim Netconf anlayışım yukarıdaki gibidir. İnternette doğru olmayan birçok resim olduğunu ve sunucu aracısının birçok davranışının doğru olmadığını düşünüyorum. Cihaza giriş yaptığımda sezgisel olarak hissettiğim şey bu ve elbette resmi belgelerle birebir örtüşüyor.
Bazı Netconf örneklerine bakabiliriz:
Merhaba, bir bağlantı oluşturun.
Birkaç anahtar kelime gördük: Netconf sürümü, desteklenen YANG Modeli, oturum kimliği. Merhaba aynı zamanda hangi ad alanında çalıştığımızı da belirtir. Bu durumda Netconf'un karşılık gelen sürümüdür.
Yapılandırmayı al
Get-cofig'in bir parametresi, yapılandırma verilerinin (çalışıyor, başlatılıyor veya diğer) alındığı kaynaktır. Bir diğer parametre ise filtre yani hangi verinin hangi yang modeliyle açıklanan veri modelinden elde edildiğidir. Bu, ağ cihazı tarafından orijinal olarak gönderilen yeteneğe karşılık gelir. Başarılı olursa ilgili yapılandırma verileri döndürülür.
Yapılandırma veya çalıştırma verilerini alın
Get-config'e benzer, ancak elde edilen şey yapılandırmanın çalıştırılması (kişisel anlayış) veya verilerin çalıştırılmasıdır. Filtre belirtilebilir.
Yapılandırmayı kopyala
Kopyalama işleminin kaynak ve hedef olmak üzere iki parametresi vardır. Başarılı yanıt tamam etiketiyle verilir.
Yapılandırmayı düzenle
Yapılandırmayı düzenlerken düzenlenecek veri öğesini, yeteneğin ad alanını ve karşılık gelen etiketi belirtin. Örneğin bu, http://tail-f.com/ns/example/dhcp yang modeliyle açıklanan dhcp'yi yapılandırmak içindir.
Oturumu zarif bir şekilde kapatın
SSH'de ileri geri iletilen bu tür bir mesajdır. Herkesin anlamasını kolaylaştırmak için mesajın sadece bir kısmını alıyoruz.
Daha sonra referans olarak biraz içerik ekleyin.
-Netconf oturuma dayalıdır ve her başarının bir oturum kimliği olacaktır.
-Her isteğin, yavaş yavaş büyüdüğü sürece bir mesaj kimliği vardır
-Veri yapılandırması kilitlenebilir, özelleştirilebilir ve kilit aracılığıyla çalıştırılabilir.
-Netconf işlemseldir ve işlemler ya tamamı uygulanır ya da hiçbiri uygulanmaz. Aynı zamanda, resmi web sitesi belgelerine göre, bu işlemsellik, N ağ cihazının yapılandırmasına yöneliktir, yani tek seferlik yapılandırma polimorfizmi, işlemselliği destekleyebilir. Ama henüz yapmadım…
-Netconf aboneliği destekler. Cihaz performansı açısından büyüklük sırası yaklaşık 5 seanstır. Belirli bir veri öğesine abone olabilirim ve cihaz, bu veri değiştiğinde beni bilgilendirir.
-Yetenek, ben bunu böyle anlıyorum. Ağ cihazı Netconf ve YANG Modelinin sürümünü gönderir ve kontrol terminali Netconf sürümünü gönderir. Ancak Netconf sürümü bu iki sürümle eşleştiğinde devam edebiliriz. Bu benim sezgisel hissim. Herhangi bir tavsiye memnuniyetle karşılanır.
-Düzenleme gibi işlemler, filtre kullanılarak filtrelenebilecek, değiştirilecek verileri belirleyecektir.
-copy-config, konfigürasyonların tamamının bir yerden bir yere kopyalanmasını destekler. Bir yer, cihazdaki bir FTP Dosyası, çalışan, başlangıç ve aday yapılandırmalar olabilir.
-Netconf ayrıca doğrulama işlemini kullanarak yapılandırmanın doğrulanmasını da destekler.
Bu makale hala bilimi popülerleştirmeyi umuyor ve ben ayrıntılara girmeyeceğim. Aslında çok da uzun olmayan RFC'nin ilgili protokollerini okuyabilirsiniz.
Uygulamada, python'un ncclient'i gibi bazı açık kaynaklı yazılımlara dayanarak, ağ cihazlarını otomatik olarak kolayca yapılandırabilir ve ağ programlanabilirliğine ulaşabiliriz. Netconf ve YANG Modelinin misyonu budur.
Ağ personeli, iyi formatlanmış YANG Modeli tanımlarını okur ve ilgili programlama dillerini kullanarak, Netconf tarafından tanımlanan işlemlere dayalı olarak ağ cihazları üzerinde programlanabilir işlemler gerçekleştirir. Bu şekilde ağ programlanabilirliğine giden yol açılır.
Biraz genişletelim ve YANG Modelinin ağ cihazının veri yapısını tanımladığını hayal edelim. Netconf aracılığıyla çalıştırabiliriz. Başka protokollerle de çalıştırılabilir mi?
Cevap Evet. Aslında RESTConf gibi birçok başka protokol Netconf'tan türetilmiştir. Aşağıda gösterildiği gibi,
YANG Modeli (genel ve yerel), üzerinde yeni ağ yönetimi protokolleri, Netconf, RESTCon, gRPC vb. bulunan veri yapısını tanımlar. Bu şekilde, ağ cihazlarını HTTP RESTful API'sine dayalı RESTConf aracılığıyla çalıştırabiliriz, aynı zamanda ağı da çalıştırabiliriz. cihazları SSH'ye dayalı Netconf üzerinden çalıştırabiliriz veya ağ cihazlarını HTTP2'ye dayalı gRPC aracılığıyla çalıştırabiliriz.0. Hepsi iyi veri yapısına sahip YANG'a dayanmaktadır. Ağ cihazlarını programlamak için modelleyin, ilgili verileri yazın, xml veya json'a kapsülleyin. Ağ programlanabilirliğinin geleceği budur. Daha kesin olmak gerekirse, Model Odaklı Program, model tabanlı ağ programlanabilirliğidir. Ağ mühendisleri yavaş yavaş komut seti yerine cihazın parametrelerine odaklanır ve ilgili veri modelini okuyarak ağ parametrelerini yapılandırır.
Sonunda bu halka açık hesabı neden açayım diye yazıyorum. Okuldayken bilgisayar bilimi ve teknolojisi okudum. İşyerine girdikten sonra network işletme ve bakım işleriyle meşgul oldum. Düşününce takımlara ayrılmamın nedeni Ağ Teknolojileri Araştırma Enstitüsü'nde yüksek lisans öğrencisi olmam olabilir (manuel komik). En başından beri ağ operasyonlarında yer aldım. İşletme ve bakımın sonraki aşamasında, CLI'ye dayalı olarak işi basitleştirmek ve verimliliği artırmak için araçlar kullanıldı. Daha sonra araçlar yavaş yavaş BS yapılı web uygulamalarına dönüştürüldü. Sürekli olarak yeni teknolojilere maruz kaldılar ve yeni işlevleri zenginleştirmeye devam ettiler.
Neyse ki, açık kaynak teknolojisinin ve SDN'nin gelişimini yakaladılar ve ben de yavaş yavaş NetDevOps çalışmasına geçtim ve programlama becerilerimi ekibin operasyon ve bakım yeteneklerini geliştirmek için kullandım. Bu kod satırını yazmaktan da keyif aldım. Yazım ilerledikçe, NetDevOps'un gelecekte her ağ mühendisinin sahip olması gereken bir beceri olması gerektiği (herkes yangına yakıt katıyor), böylece hem üst düzey planlamayı hem de hızlı uygulamayı başarabilecekleri yavaş yavaş keşfediliyor. İnternetteki bazı bilgilere baktığımızda, dürüst olmak gerekirse, Çin'de çok az şey var ve iç atmosfer de pek güçlü değil. Birçok yerli yazılım eski CLI ve snmp'ye dayanmaktadır ve herkes iş için hala metin araçlarını ve SSH araçlarını kullanmaktadır. yani umarımbaşkalarına balık tutmayı öğretebilir, deneyimimi (çukurları) ve becerilerimi daha fazla ağ işletme ve bakım mühendisiyle paylaşabilirimve elimden gelenin en iyisini yapacağım. Xiao Chu, iş yükünüzü azaltmak için bir şeyler öğrenebileceğinizi ve uzak geleceğe odaklanarak yerel ağ işletimi ve bakımının gerçek anlamda otomasyona doğru evrilebileceğini söyledi.
Gelecekte bazı videolar kaydedeceğim ve bazı makaleler yazacağım. Bir belge yazmak gerçekten yorucu bir duygu. Abone olabilir, toplayabilir, beğene tıklayıp izleyebilirsiniz.
ek: Netconf ortak işlemleri
DWDM OTN Çözüm Tasarımı ve Maliyet Teklifi, lütfen benimle bağlantı kurun, Taylor Huang
