Cisco SD-WAN első rész
Bevezető
Élek az alkotói szabadság jogával, és ellentétben az eddigiekkel kicsit rövídítek a post címén.
Eredetileg ez a sorozat
Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS II.rész Cisco (Viptela) 1 címet kapta volna, csak hát:- Kib@#&0tul hosszú lenne.
- Az SD-WAN témakör önmagában megér egy post sorozatot.
- A Cisco SD-WAN-ról sok mindent lehet írni, így ez is megér egy önálló post sorozatot.
Azért hivatkozunk a szakzsargonban Viptela néven a megoldásra, mert a Cisco-nak további SD-WAN megoldásai léteznek, illetve léteztek:
- SD-BRANCH (ENCS platform)
- Meraki SD-WAN
- IWAN (performance routing alapú, APIC-EM vezérelt kezdeményezés, ami sajnos kihalt)
A Cisco-nál elmúlt 3 évben nem csak termékként kínálták a megoldást, kisajtolva a Viptelát, hanem megkezdődött, a hagyományos IOS-XE alapú ISR platformok és viptelaOS vedge platformok integrálása.
IOS-XE 16.10+-os verziói már teljes értékű edge-ként integrálhatók az az SD-WAN hálózat részeként.
Cisco SD-WAN (Viptela) architektúra
 |
| forrás |
A Cisco SD-WAN nem csak egy csilli-villi feature, ami jól mutat a marketing bullS*#&-ben, hanem egy igazi SDN alapú megoldás, ahol Control Plane működése tényleg egy központi kontrolleren keresztül valósul meg a hálózatban.
(Nem kell megijedni, az eszközökből nem vették ki teljesen a Control Plane-t)
Külön elem felel a control plane-ért, az orkesztrációért és a management-ért, ami ráadásul az északi-irányú integráció lehetőségét is magában hordozza.Alapvetően 4 különböző architektúra elemet különböztetünk meg a viptela, akarom mondan Cisco SD-WAN megoldásában:
- vManage - Management, North-bound API
- vSmart - Control Plane
- vBond - Orchestration
- vEdge, cEdge - Data Plane
Első ránézésre, az architektúra bonyolult képest fest, de ha az ember elkezdi felépíteni, akkor egyre egyszerűbbé és barátságosabbá válik.
(Persze ez a legtöbb architektúrára igaz, ha megépítettük és tudjuk üzemeltetni, akkor már nem annyira bonyolult.)
A Cisco segít nekünk abban, hogy 2 controll és a management elemet nem kell felépíteni 0-ról, ha ehhez nekünk nincs erőforrásunk, vagy megfelelő kompetenciánk. Igénybe lehet venni a vManage, vSmart, és vBond funkciókat felhőben is, így csak a vEdge implementációja és integrációja a hátra maradt feladatunk.Tudom, hogy sok cégnél way to the on-prem cloud policy miatt ez annyira nem szerencsés megoldás, így én az on-prem verziót fogom megmutatni.
(Az ilyen pillanatoknál mindig elbizonytalanodom, mert egy ilyen rendszer bemutatása felér egy diplomamunka és szakdolgozat írással, azokon már túl vagyok így megpróbálom nagy vonalakban érthetően összefoglalni az egyes elemek építését/működését.
Ha valaki szakdolgozati témát keres éppen, annak javaslom SD-WAN témakört kezdje kutatni.)
vManage
Röviden: a vManage az az architektúra elem, amely biztosítja számunkra a hálózat feletti vizibilitást, lehetővé teszi az egyes Data Plane (vEdge, cEdge) elemek konfigurációját akár template-en, akár cli-n (a vManage felületén) keresztül. Egyszerűen megfogalmazva: központi management rendszer.A központi kontroll kialakításában is nagy szerepet játszik, hiszen ezen a felületen keresztül lehet az egyes eszközök on-boarding-jét elvégezni...
(Hűha most menjünk bele az on-boarding működésébe? Hát megpróbálom rövidre fogni.)
On-boarding alatt azt kontroll kommunikációt érjük, ami során az egyes architektúra elemek beregisztrálnak a vManage-be. Ehhez dtls protokollt használnak, certificate alapú autentikációval.
A vManage virtuális formában futtatható és támogatott kvm, vmware, és hyperV környezetekben egyaránt.
vSmart
Röviden: a vSmart, amely a Control Plane funkcionalitásért felel. A Cisco SD-WAN megértéséhez, ezen a ponton kicsit többet kell elidőznünk, ugyanis meg kell érteni azt, hogy egy architektúra elem, hogyan befolyásolja a teljes hálózati architektúra működését. A kulcsszerep az OMP azaz az Overlay Management Protocol-nak jut, hiszen ez az ami meghatározza a DataPlane entitások számára azt, hogy milyen szabályok mentén alakítsák ki egymás közt az overlay hálózatot.OMP az alábbi feladatokat látja el a hálózatban:
Overlay kommunikáció kontrollja, beleértve a site közötti transzport kommunikációt, a szolgáltatás lánc kialakítását (service chaining), a VPN topológiák kialakítását, továbbá
- Biztosítja a VPN szolgáltatásokhoz kapcsolódó routing információ terítését,
- Biztosítja a Dataplane Security kialakításához szükséges paramétereket terítését,
- Biztosítja Routing policy kialakítását a hálózatban.
vEdge, cEdge
Végre megérkeztünk a lényeghez, hiszen ezek az elemek terminálják a WAN oldali kapcsolatokat, és teremtik meg a hőn áhított fizikai konnektivitást a WAN és LAN között valamint a site-ok között. Noha az SDN referencia modell elképzelése szerint ezek csak "buta" switch-ek, amelyek nem rendelkeznek saját Control Plane-el, azoknak akik ebben hittek, hogy központi intelligencia hoz majd döntést egy-egy csomagtovábbítás esetén, van egy rossz hírem.
Ez sem így működik és ez az SDN elképzelés szerintem hibás is önmagában. Központi kontroll és orkesztráció feladata a csomagtovábbítási szabályok kialakítása (routing policy) és hattatása a hálózaton, de ha nincs kapcsolat a központi inteligenciával, akkor is kell csomagtovábbítási döntést hozni.
Miért létezik kapásból kétféle architektúra elem?
Mert a Cisco a saját portfóliójába is szeretné beépíteni az SD-WAN-t , mint funkcionalitást, amit egyenlőre csak át firmware-eléssel tudunk megvalósítani, de a mostani virtual techtoriál-on megtudtam, hogy októberben várható olyan IOS-XE verzió amiben már addicionális feaute-ként fog megjelenni az sdwan, addig viszont be kell érnünk azzal, hogy vagy IOS vagy viptela módba tudjuk firware-elni meglévő ASR1k, ISR4k-es vagy ISR1k-es sorozatba tartozó kedvenc routerünket.
Lets build the Network!
Többszörösen nekifutottam már a Cisco SD-WAN témakörnek, mind architektúra megismerését, mind a labor megépítését tekintve, ezért néhány kellemes és kellemetlen tapasztalatom is van a megoldással kapcsolatban, amelyet igyekszem megjegyezni a leírás során.
Maga az architektúra felépítése a management/control/policy plane és az orkesztráció kialakításával kezdődik. Cloud vagy hybrid cloud kivitelben ezeknek a lépéseknek a nagy részét a cisco vagy a partner megteszi helyettünk így az alábbi lépéseken kifejezetten az on-prem verziót igyekszem megmutatni.
Mivel érdemes kezdeni?
El kell döntenünk, hogy ha on-prem szeretnénk megépíteni, akkor milyen virtualizáció felett szeretnénk megvalósítani, persze az IT-sok nagy része rögtön rávágja, hogy vmware mi más, de nemcsak vmware létezik produktív környezetben erre célra.
Mivel alapvetően ez egy hálózati megoldás lesz, el kell gondolkozni azon, hogy mennyire vagyunk DevOPs üzemmódban ahhoz, hogy ugyanazon virtuális platformon futtassuk a hálózathoz kapcsolódó Control/Policy/Management elemeket, amin egyébként WebServer, Windows AD, vagy Horizon és hozzátartozó gépek futnak.... Nem is beszélve a vMotion-ról, ami okozhat kellemetlen pillanatokat számunkra.
Nem lenne szerencsés, ha megállna a Control Plane azért, mert a vmware ballon technológiát alkalmaz, vagy mert valaki a horizon-os gépen futtatja a torrentet stb...
A Cisco egyébként erre is ad a kezünkbe megoldás hiszen létezik a portfólióban dedikált NFV appliance CSP platform képében.
Az éles infrastruktúrában javaslom, hogy ennek legyen dedikált erőforráskészlete, mert csúnya következmények elé nézhetünk a hálózatra nézve, ha kontrol vagy az orkesztráció megáll.
Ezt a LAB-ot én vcenter-ben raktam össze, így ha valami elmegy, akkor összerakom újra, és újra és ... újra!
Első lépésként 3 összetevő image-ét kell leszednünk, amik együtt fogják alkotni a Management/Control/Policy Plane-t valamint biztosítják az orkesztrációt, a Data Plane számára.
vManage
vSmart
vBond - ami egy vEdge vBond üzemmódban és IGEN! lehet virtuális is.
Most nem sokszorosítanám az oldal terjedelmét azzal ,hogy vCenter deployment-et bemutatom, mert sokat nem adna hozzá a megértéshez, inkább néhány tipp-re térnék csak ki:
vManage
alapesetben 2 vCPU 32GB RAM a ova deployment - a virtualizációs mérnök ettől még nem dob hanyatt - de javaslom, hogyha jó lab-ot akarunk építeni és van kraft, akkor emeljük meg 4-8 vCPU-ra processzort, mert úgy nem lesz probléma például akkor, amikor a központi upgrade-hez töltünk fel fájlt. (Nem derült ki egyértelműen, de szerintem ilyenkor hash ellenőrzést végez a fájlon, amitől CPU kilő) A boot időt is szignifikánsan csökkenti, ha elég professzort rakunk alá.
RAM-al nem volt gond, a vmanage teljesítményét még a disk I/O tudja befolyásolni, ugyanis, mindenféle hálózathoz kapcsolódó log, config-template stb. itt keletkezik, kiértékelődik, és tárolódik el, mondjuk nem derült ki számomra, hogy ebből mennyit tart on the fly a memóriában és mi az amit disk-re ír real-time, de maradjunk annyiban, hogy nem raktam SSD-re (főleg hogy lab), és 6-8 node-al még nem volt ebből gond, viszont produktív környezetben lehet, hogy felmerül igényként a gyors disk.
vSmart, vBond, vEdge, cEdge
Mindent az ova template alapján hagytam default-ban, eddig nem volt probléma belőle, kivéve, hogy időnként elszáll a CPU igény és vmware erről riasztást küld. Ha nem szeretnénk, hogy a virtualizációs mérnök a haját tépje miattunk a riasztások miatt, akkor állítsunk be CPU limitet, ha labor környezetről van szó, ha produktív akkor pedig valóban fontoljuk meg, hogy külön vcenter/host álljon rendelkezésre az NFV appliance-ek számára, vagy válasszunk erre a célra más virtualizációs platformot: Hajrá CSP! ;-).
 |
| forrás |
Egyébként a Cisco által javasolt paraméterek az alábbiak:
 |
| forrás |
Miután végeztünk az egyes elemek virtuális deployment-jével, első lépésként csináljunk egy saját tanusítvány kiállító elemet (rootCA). Ez lehet Microsoft CA is, viszont a laborkörnyezetben tökéletesen elmegy openSSL alapon egy linux alapú rootCA. Talán ebben témában időztem el legtöbben, úgyhogy a Cisco SD-WAN kapcsán, amit lehet azt itt megosztok veletek.
OpenSSL-el CA-t kiállítani nem egy agysebészet, ha tudjuk megfelelő lépéseket, ha nem akkor viszont véres-verejtékes gúglizások árán lehet jól kivitelezni, néha fájdalmasan és reménytelen módon, de nem lehetetlen.
RootCA kilakítása
Első lépés kell egy linux.
Én erre a célra a nálam már jól bevált Ubuntu 18.04-es disztribúciót alkalmaztam, amiben by default benne van az openSSL.
Második lépésként hozzunk létre vele egy privát kulcsot, amelyet a ca alapjaként fogunk használni:
openssl genrsa -out ca.key 2048
Harmadik lépésként állítsunk ki a kulcsból egy tanusítványt:
openssl req -new -x509 -key ca.key -out ca.crt
Hozzunk létre, konfig fájlt, amely a további tanúsítványok kiállításához biztosít számunkra olyan paramétereket, mint pl érvényességi idő, tanusítvány tartalma stb...
nano ca.conf
[ ca ]
default_ca = $yourCA
[ CA_lab ]
dir = /home/$username/rootCA/
certs = $dir/certs
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = ./serial
RANDFILE = $dir/private/.rand
private_key = ./ca.key
certificate = ./ca.crt
default_md = sha256
name_opt = ca_default
cert_opt = ca_default
default_days = $valid
preserve = no
policy = sdwan_policy
[ sdwan_policy ]
countryName = optional
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
default_ca = $yourCA
[ CA_lab ]
dir = /home/$username/rootCA/
certs = $dir/certs
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = ./serial
RANDFILE = $dir/private/.rand
private_key = ./ca.key
certificate = ./ca.crt
default_md = sha256
name_opt = ca_default
cert_opt = ca_default
default_days = $valid
preserve = no
policy = sdwan_policy
[ sdwan_policy ]
countryName = optional
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Tanúsítványok nyilvántartására, hozzunk létre, egy index fájl, és sorszámok kiosztására egy serial-t.
touch index.txt
echo '01' > serial
echo '01' > serial
A könyvtár struktúra az alábbi módon nézzen ki:
./
../
ca.conf
ca.crt
ca.key
index.txt
newcerts/
serial
../
ca.conf
ca.crt
ca.key
index.txt
newcerts/
serial
Ez követően tudunk innen kiállítani tanusítványt a Control Plane és Data Plane elemek számára egyaránt.
openssl ca -config ca.conf -out vSmart.pem -infiles vSmart.csr
Az egyes elemek a dtls kommunikáció során ezt a tanusítványt fogják használni a későbbiekben, szóval fontos hogy ez rendben legyen.
vDevices initial setup
Az első és legfontosabb a tanusítványok rendbetétele után, hogy vManage-t beállítsuk, hiszen ez lesz majd ahonnan az összes többi elemet konfigurálni tudjuk. Az alapbeállításokat CLI-ben kell kialakítani, miután azzal megvagyunk már csak a GUI-t kell használnunk.
VGA console-al nem szívesen időzik az ember, szóval elsőnek javaslom, hogy a menedzsmentet alakítsuk ki:
!
vpn 512
interface eth0
ip address $mgmt_ip
no shutdown
!
ip route $prefix $gateway
!
interface eth0
ip address $mgmt_ip
no shutdown
!
ip route $prefix $gateway
!
commit
!
Miután elérhető ssh-n az eszköz, a legfontosabb, hogy system paramétereket beállítsuk:
!
system
host-name $hostname
system-ip $system_ip
site-id $site_id
host-name $hostname
system-ip $system_ip
site-id $site_id
organization-name $org_name
clock timezone $timezone
vbond $vbond_ip
clock timezone $timezone
vbond $vbond_ip
!
ntp
server $ntp_server_ip
version 4
exit
!
server $ntp_server_ip
version 4
exit
!
exit
!
Ahol:
$hostname - remélem ebben a körben nem kell magyarázni sokat
$system_ip - ez egy sem a tranzit-on, sem a service-en nem route-olandó IP cím, amely azonosítja a hálózati eszközt, ha úgy tetszik, egy loopback IP, de inkább olyan mint az OSPF, vagy BGP router-id.
$site_id - szintén nagyon fontos paraméter, amely alapján az egyes hálózati pontok azonosítva lesznek, ahhoz hogy a site-ok közötti overlay hálózatot ki tudjuk alakítani, különböző id-kat kell meghatároznunk.
$ org_name - szintén nagyon fontos paraméter, hiszen a dtls kommunikáció csak azonos organization-ok között működik, itt fontos megjegyezni, hogy ugyanazt a a paramétert kell megadni, mint certificate OU-ban adtunk meg.
$timezone - dtls kommunikációhoz fontos tényező az idő, és habár nem a timezone paraméteren múlik, hogy pontos legyen az óra, hanem az ntp-n, de ha már csinálunk valamit az legyen jó alapon ne feledkezzünk meg a megfelelő régió kiválasztásáról.
$vbond_ip - a vbond lesz az az eszköz amely az egyes hálózati elemek közti kommunikációt levezényli, elengedhetetlen az SD-WAN működéséhez. Ez a paraméter minden eszközben ugyanaz kell, hogy legyen, olyannyira, hogy az onboarding során a vmanage, és vedge cert-ekbe is bekerül paraméterként.
$ntp_server_ip - Eistein szerint az idő relatív, de az ő korában még nem voltak NTP szerverek, amik meghatározták volna a hálózat számára a pontos időt... Mivel már a 21. században élünk, ezért nekünk nem feltétlenül kell az idő relativitásán elmélkednünk, főleg a tanusítvány alapú dtls kommunikáció miatt, ahol az időnek minden ponton pontosnak kell lennie, tehát alkalmazzunk közös NTP szervert.
Ezután következzen a magic, a tunnel interface kialakításával:
!
vpn 0
interface eth1
ip address $data_ip
tunnel-interface
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0 $default_gateway
!
commit and-quit
Ahol:
$data_ip - az az a IP cím amelyet vBond-nak és vSmart-nak egyaránt el kell érnie L3 kapcsolaton.
$ default_gateway - remélem ezt sem kell túl magyarázni.
A vBond és vSmart konfigja kb ugyanez, kivéve, hogy vBond-nál a system konfig egy picit más:
!
system
host-name $hostname
system-ip $system_ip
site-id $site_id
host-name $hostname
system-ip $system_ip
site-id $site_id
organization-name $org_name
clock timezone $timezone
vbond $vbond_ip local
!clock timezone $timezone
vbond $vbond_ip local
A vBond tulajdonképpen egy vEdge, akinek meg kell mondani, hogy most te barátom vBond leszel.
A ezután már tényleg mindent is a vManage-ben kell beállítani, kivéve az v/cEdge-ek kezdeti paramétereit, de arra tudunk olyan day0 konfig template-t csinálni mint ez:
!
system
host-name $hostname
system-ip $system_ip
site-id $site_id
host-name $hostname
system-ip $system_ip
site-id $site_id
organization-name $org_name
clock timezone $timezone
vbond $vbond_ip
clock timezone $timezone
vbond $vbond_ip
!
ntp
server $ntp_server_ip
version 4
exit
!
server $ntp_server_ip
version 4
exit
!
exit
!
!
!
vpn 0
interface ge0/0
ip address dhcp
tunnel-interface
allow-service dhcp
allow-service dns
allow-service icmp
allow-service sshd
allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0 $default_gateway
!
!
vpn 0
interface ge0/0
ip address dhcp
tunnel-interface
allow-service dhcp
allow-service dns
allow-service icmp
allow-service sshd
allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0 $default_gateway
!
!
vpn 512
interface eth0
ip address $mgmt_ip
no shutdown
!
ip route $prefix $gateway
!
interface eth0
ip address $mgmt_ip
no shutdown
!
ip route $prefix $gateway
!
commit and-quit
És minden elemre fel kell töltenünk a fentebb elkészített ca.crt-t, hogy automatikusan tudjanak tanusítványt aláírni egymásközt az egyes elemek, manuális tanusítvány kezeléssel csak a kontrol összeállításánál kell egy kicsit vesződni.
request root-cert-chain install /home/admin/ca.crt
Néhány screenshotban összefoglaltam, azokat a lépésket, amelyek kontrol elemek vManage konfoguriációit tartalmazzák:
Mindegyik kontrol elemnek elkészítjük a megefelelő feature template-ek alapján a eszköz template-et majd hozzáadjuk. Fontos, hogy a meglévő CLI beállításokat ezzel felülírhatjuk, egy nem megfelelő kattintás, vagy lépés kihagyás esetén elveszthetjük a menedzsmentet az eszköz felett, így tehát csak óvatosan, érdemes ellenőrizni a létrejött konfigot, és azt is amit esetleg felül ír. Az utolsó képen látható, hogy ebben azért kapunk segítséget a vManage-től configDiff formájában.
A képeken csak a vManage konfigját láthatjátok, de lépések kb ugyanazok vSmart és vBond esetében is, csak létre kell hozni a megfelelő feature template-eket, majd összerakni egy eszköz template-ben.
Összegezve
Cisco-nak megint sikerült belenyúlnia a jóba :), tényleg egy olyan SDN megoldást tálalnak WAN kapcsolatok kezelésére, amely képes "igazi" SDN architektúraként működni úgy, hogy közben a nem veszett ki a berendezésekből a teljes kontrol, de mégis egységes felületen template-ek alkalmazásával tudunk hálózatot építeni. Természetesen ebben az esetben sem fenékig tejfel az élet, mert ha tanusítvány hiba miatt szétesik a dtls kommunikáció, akkor komoly üzembiztonsági problémák elé nézhetünk, ezért mindenképp javasolt a körültekintő tervezés és teszt véghezvitele, akár ON-PREM, akár Cloud managed verziók esetén. Ha ON-PREM verziót építünk fontos végig gondolni, hogy virtualizáció, amit jelenleg alkalmazunk alkalmas-e a ezen hálózati funkciók virtualizálására, vagy építsünk erre egy cél környezetet.
A továbbiakban még visszatérek ehhez a témához és egy-egy újabb postban fogom megmutani azokat a képességeket, amelyek érdemessé teszik a cisco SD-WAN-t a jelen és jövő beli WAN hálózatok építésére.
Addig is a tanuljatok és kitartást a pandémia alatt!
