Nəzəri əsaslar və memarlıq

Müasir operator şəbəkəsinin idarəsi CLI komandalarını əllə yığmaq və mətn çıxışını təhlil etmək (screen scraping) əvəzinə proqram interfeyslərinə (API) əsaslanır. Bunun üçün NETCONF (RFC 6241) və gNMI (gRPC Network Management Interface) istifadə olunur. 1. NETCONF SSH üzərində işləyir (IANA üzrə port 830, RFC 6242) və XML RPC mesajları daşıyır: <get-config>, <edit-config>, <lock>, <validate>, <commit>, <discard-changes>. Tranzaksiya davranışı cihazın capabilities-dən asılıdır: candidate datastore olan platformalarda dəyişikliklər yığılır və <commit> ilə tətbiq olunur (<commit><confirmed/> isə onları taymerlə geri qaytarır), :writable-running olub :rollback-on-error olmadıqda isə dəyişikliklərin bir hissəsi tətbiq olunmuş qala bilər. Marşrutlaşdırıcının "həmişə özü geri qaytardığı" iddiası yanlışdır. 2. Məlumat modelləşdirməsi: həm NETCONF, həm gNMI YANG dilindən istifadə edir (1.1 versiyası üçün RFC 7950). Modellər standart (IETF, OpenConfig) və vendor modelləri (native) olur; PE konfiqurasiyası adətən yoxlanılmış platformanın native modeli ilə yazılır, vəziyyət isə OpenConfig ilə oxunur. 3. gNMI OpenConfig icması tərəfindən gRPC/HTTP/2 üzərində Protocol Buffers kodlaşdırması ilə hazırlanıb və Capabilities, Get, Set, Subscribe RPC-lərini təqdim edir. Set vahid tranzaksiya kimi tətbiq olunur (ya hamısı, ya heç nə), Subscribe axın telemetriyası verir; IANA gNMI üçün 9339 portunu qeydiyyatdan keçirib, lakin praktikada vendor portları da rast gəlinir, ona görə port cihaz konfiqurasiyasından götürülür.

Nə standartlaşdırılıb, nə yox

Proqramlaşdırıla bilən interfeys üç müstəqil qatdan ibarətdir: nəqliyyat (SSH və ya TLS ilə HTTP/2), əməliyyat protokolu (NETCONF RPC və ya gNMI RPC) və YANG dilində yazılmış məlumat modeli. Hər qat ayrıca dəyişdirilə bilər: eyni YANG modeli həm NETCONF, həm də gNMI üzərindən verilir, eyni NETCONF isə müxtəlif istehsalçıların modelləri ilə işləyir. Bu, L3VPN üçün vacibdir: nəqliyyat və əməliyyatlar daşınandır, amma native modellərlə işlədikdə məzmun (VRF, RD, RT və BGP vpnv4 ağacı) Cisco, Huawei və Juniper-də fərqli görünür.

NETCONF: sessiya, capabilities, datastores

NETCONF (RFC 6241) SSH alt sistemi kimi işləyir. 830 portu IANA tərəfindən netconf-ssh üçün ayrılıb (RFC 6242), bir çox platforma isə əlavə olaraq 22 portunda netconf alt sistemini qəbul edir. SSH qurulduqdan sonra hər tərəf capabilities siyahısı və base versiyası ilə <hello> göndərir: urn:ietf:params:netconf:base:1.0 və ya base:1.1. Hər iki tərəf 1.1 dəstəkləyirsə, chunked framing işə düşür; 1.0-da mesajlar ]]>]]> ardıcıllığı ilə ayrılır. Məhz buna görə xam socket üzərindəki ev istehsalı müştərilər sınır, ncclient, Ansible-ın NETCONF müştəriləri və scrapli-netconf isə işləyir.

Capabilities cihazla nə etmək olduğunu müəyyən edir:

  • :candidate - ayrıca candidate datastore var; dəyişikliklər yığılır və <commit> ilə tətbiq olunur.
  • :writable-running - <edit-config> birbaşa running-ə icazəlidir; commit lazım deyil və hər əməliyyat dərhal qüvvəyə minir.
  • :confirmed-commit - timeout ilə <commit><confirmed/> (susmaya görə 600 saniyə): bu müddətdə ikinci <commit> gəlməsə, cihaz özü geri qayıdır.
  • :validate - <validate> əməliyyatı candidate-i tətbiq etmədən yoxlayır.
  • :rollback-on-error - <edit-config>-in bir elementində xəta olarsa, bütün sorğu geri qaytarılır.
  • :startup, :xpath, :url - startup datastore, XPath filtrləri, URL-dən konfiqurasiya.

Cisco IOS-XE susmaya görə yalnız running verir, candidate isə netconf-yang feature candidate-datastore ilə aktivləşdirilir (bundan sonra CLI konfiqurasiyası funksiya söndürülənə qədər bloklanır). Junos həmişə candidate ilə işləyir. Huawei VRP-də dəst proqram versiyasından asılıdır; sənədləşmə yox, <hello>-dakı capabilities-ə baxın.

Əməliyyatlar və edit-config semantikası

  • <get> konfiqurasiyanı və operativ vəziyyəti, <get-config> isə seçilmiş datastore-un yalnız konfiqurasiyasını oxuyur. Filtr subtree və ya XPath ilə verilir.
  • <edit-config> datastore-u dəyişir. Elementin operation atributu merge (susmaya görə), replace, create (artıq varsa xəta), delete (yoxdursa xəta) və remove (xətasız) qəbul edir. default-operation elementi bütün sorğunun davranışını təyin edir. Klassik səhv yuxarı səviyyəli konteynerdə replace-dir: o, siz sadalamadığınız bütün qonşu elementləri silir.
  • <lock>/<unlock> tranzaksiya müddətində datastore-u bloklayır; kənar sessiya lock-denied alır. <kill-session> ilişmiş sessiyanı söndürür.
  • <validate>, <commit> və <discard-changes> candidate ilə işləyir. <copy-config> və <delete-config> bütöv datastore-lar üzərində işləyir.

Atomarlıq həmişə təmin olunmur. :rollback-on-error varsa və ya candidate-commit uğursuzluğu özü geri qaytarırsa, <edit-config> bir sorğu daxilində atomardır. Routerin "həmişə özü geri qayıdır" iddiası yanlışdır: :writable-running olduqda və rollback-on-error olmadıqda dəyişikliklərin yarısı qalır.

Candidate platformasında minimal təhlükəsiz dövr:

xml
<!-- lock, edit candidate, validate, confirmed commit, final commit -->
<lock><target><candidate/></target></lock>
<edit-config><target><candidate/></target><config>...</config></edit-config>
<validate><source><candidate/></source></validate>
<commit><confirmed/><confirm-timeout>120</confirm-timeout></commit>
<commit/>
<unlock><target><candidate/></target></unlock>

Confirmed commit-dən sonra kontrollerlə əlaqə itərsə, son <commit> gəlmir və 120 saniyədən sonra PE əvvəlki konfiqurasiyanı bərpa edir.

YANG: native, IETF, OpenConfig

YANG (1.1 versiyası üçün RFC 7950, 1.0 üçün RFC 6020) container, açarlı list, leaf, leaf-list, choice, tiplər, must/when məhdudiyyətləri və identity ağacını təsvir edir. Modul revision ilə versiyalanır (revision 2023-07-01), augment ilə genişlənir və istehsalçı tərəfindən deviation ilə dəqiqləşdirilir. Üç model ailəsi var:

  • Native (Cisco-IOS-XE-native, huawei-*, junos-conf-root) istehsalçının CLI-ni təkrarlayır, hər şeyi əhatə edir, lakin platformalar arasında daşınmır.
  • IETF (ietf-interfaces RFC 8343, ietf-routing, ietf-bgp) standartlaşdırılıb, lakin istehsalçılarda əhatə qismən olur.
  • OpenConfig (openconfig-interfaces, openconfig-network-instance, openconfig-bgp) operatorlar tərəfindən yazılır. VRF və L3VPN L3VRF tipli network-instance-da təsvir olunur, RD config/route-distinguisher-də yerləşir, RT-lər isə inter-instance-policies və import siyasətləri ilə verilir. L3VPN əhatəsi istehsalçılar arasında qeyri-bərabərdir, ona görə PE üçün konfiqurasiyada adətən native model, OpenConfig isə yalnız telemetriya üçün (interfeyslər, BGP qonşuları) istifadə olunur.

Praktik qayda: PE konfiqurasiyasını yoxladığınız platformanın native modeli ilə yazın, vəziyyəti isə OpenConfig ilə oxuyun.