Hálózat-virtualizáció EPISODE V - PART II South-bound APIs

South-bound APIs



Déli-irányú API-k esetén nem olyan "egyszerű" a helyzet mint északi-irányban. Ugyanis még nincs - és talán sosem lesz - olyan egységes, kvázi sztenderdizált protokoll mint a REST API. Hogy miért? Hát kérdezzük meg a gyártókat! Miért nem a NETCONF, vagy a SNMPv3, vagy az OpenFlow mellett tették le a voksukat egységesen. Mint a korábbi bejegyzésemben írtam már, a gyártók az SDN megoldásaikat sokkal inkább csomagolt termékként kínálják, mint egymással együtt működő standardoknak megfelelő részegységeket. Ezért van az, hogy a déli-irányú SDN integrációt nem lehet, egy protokollal megvalósítani egy heterogén rendszerben. Déli-irányban, így gyakorlatilag bármi lehet API, amit az SDN kontroller és a hálózati eszköz is támogat...

Azért próbáljunk meg néhány protokollt kiemelni, mert azokban megvan minden olyan funkcionalitás, ami alkalmassá teszi az orkesztráció megvalósítására.

 YANG adatmodell RFC6020 - Yet Another Next Generation...

A fenti kép YIN-ét már mindenki érti, de mi a helyzet a YANG-al...

A YANG egy adatleíró model, ami abból a célból készült, hogy támogassa azokat a hálózat konfiguráló protokollokat, melyek a SDN orkesztrációt hivatottak megvalósítani kvázi standard módon. (NETCONF, RESTCONF)

RFC-ben kifejezetten úgy definiálták a YANG-ot, hogy NETCONF-hoz készült adatmodell, amit kiegészítenék azzal, hogy REST-API (RESTCONF) hívások is ezen adatmodell alapján történhetnek.
Továbbá felépítése igen hasonló az SNMP protokollhoz. Szóval a YANG adatmodell úgy lett felépítve hogy támogassa a NETCONF alapú működést, melyek az alábbiak:

• configuration data (konfigurációs paraméterek)
• state data (állapot információk)
• RPC (távoli eljárások)
• notification (figyelmeztetések: pl. állapotváltozásokról)

Az adatmodellben az adatok hierarchikusan épülnek fel, úgy kell elképzelni mint egy fa struktúrát, ahol a YANG modul (pl interfaces modul) adja a fának törzsét, modulon belüli információ (interface Gi1/1) pedig a leágazások, melyek további ágai/levelei (ip address) lehetnek.
Például:

Tehát a YANG úgy épül fel majden mint egy eszközkonfiguráció?
Igen és Nem teljesen, a lényeg, hogy eszközökön futó konfigurációt, állapotot, változtatásokat, és üzeneteket, át lehet forgatni YANG adatstruktúrába, így NETCONF-al vagy RESTCONF segítségével, egy központi helyre tudunk információt, gyűjteni, kiértékelni.. majd akár beavatkozni, módosítani a hálózat működését.

Akkor most hogy néz ki egy konfig YANG struktúrában (JSON formátumban)?

##########################################

'{
"interface-configuration":
{
"interface-name": "Loopback99",
"active": "act",
"interface-virtual": [
null
],
"Cisco-IOS-XR-ipv4-io-cfg:ipv4-network": {
"addresses": {
"primary": {
"address": "99.99.99.99",
"netmask": "255.255.255.255"
}
}
},
"description": "configured-via-NETCONF"
}
]
}'

##########################################

A fenti YANG konfigurációt az alábbi módokon lehet végrehajtani IOS-XR CLI-ben:
##########################################

configuration

 interface Loopback99

 description configured-via-NETCONF
 ipv4 address 99.99.99.99/32
exit
commit 

end

##########################################

Szemünk egyszerűbbnek, könnyebbnek, és érthetőbbnek látja CLI konfigurációt, és igen, sokkal egyszerűbb, de akkor mégis minek vesződünk az egész API témával NETCONF-al és társaival?

Mert ugyanez a konfiguráció azonos gyártón belül más platformon már így néz ki:
##########################################

configuration terminal
 interface Loopback99
 description configured-via-NETCONF
 ip address 99.99.99.99 255.255.255.255
exit
end
wr

##########################################

Más gyártóknál pedig akár így is nézhet ki:
##########################################

system view
 interface Loopback99
 description configured-via-NETCONF
 ip address 99.99.99.99 255.255.255.255
exit
end
save

##########################################

Persze sajnos van ilyen is:
##########################################

/interface bridge add name=Loopback99
/ip address add address=99.99.99.99/32 interface=Loopback99

##########################################

És ne felejtkezzünk meg erről sem:
##########################################

edit interfaces lo0 unit 0 family inet
 set address 99.99.99.99/32
exit
commit

vagy

set interfaces lo0 unit 0 family inet address 99.99.99.99/32
commit
vagy

[edit interfaces]
lo0 {
 unit 0 {
  family inet {
   address 99.99.99.99/32
   }
  }
 }
}

##########################################Rövidre zárva, a CLI nem standard, még gyártón belül sem, így nem alkalmas, vagy csak nagyon nehezen alkalmazható, központi orkesztráció esetében, főleg ha egy heterogén hálózati megoldásom van.
YANG adatmodell egyik fontos érdeme, hogy konfigurációs állapot egyfajta absztrakcióját valósítja meg.

innen folytatjuk...