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.
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:
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"
}
]
}'
##########################################
configuration
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)
Például:
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
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
system view
interface Loopback99
description configured-via-NETCONF
ip address 99.99.99.99 255.255.255.255
exit
end
save
/interface bridge add name=Loopback99
/ip address add address=99.99.99.99/32 interface=Loopback99
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...
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...