Az utóbbi időben a WAN technológiák tekintetében nagy hangsúlyt kapott az SD-WAN (Software Defined WAN). Az alábbi írásban megvizsgáljuk, hogy milyen előnyökkel jár az ügyfeleknek ennek bevezetése.
Először tekintsük át a régi, „hagyományos” megoldásokat, majd nézzük meg hogy miben más az SD-WAN.
A vállalat méretétől függően több routing megoldás jöhet szóba az internet kijárat tekintetében.
Egy kisvállalat esetében, ahol általában egy telephely van sok esetben csak statikus route-k vannak használatban, hiszen minden olyan útvonal, amely nem az ügyfél hálózatán belül van hirdetve az internet felé kell, hogy mutasson. Ebben az esetben nem (feltétlenül) szükséges dinamikus routing protokoll használata a PE-CE eszközök között. A redundancia több módon biztosítható az ügyfél oldalán amennyiben két CE eszköz van, de adott subneten belüli dinamikus forgalom szabályozás nem történik, gyakorlatilag active/standby megoldásról van szó. Ezeknél az ügyfeleknél jellemzően site-to-site VPN sincs kialakítva. Az SD-WAN ez esetben leginkább az eszközök menedzselésében, kliensek kapcsolatainak vizsgálatában tud segíteni, illetve pl. a vonalak kiterheltségétől függően gyors konvergenciát biztosítani az adott forgalmak számára, illetve a felhőben lévő szolgáltatások felé. Sok esetben elég lehet a Cisco Meraki termékcsalád használata, amelynek segítségével távolról, egy webes felületen vagy mobilalkalmazáson keresztül kezelhetők az eszközök.
Egy nagyobb ügyfelet tekintve sokszor már több telephellyel kell kalkulálni, amelyek között általában VPN kapcsolat van kialakítva. Ennek megvalósítása történhet többek között szolgáltatói közreműködéssel (L3VPN, L2VPN) vagy publikus internet felett, pl. IPSec VPN vagy DMVPN segítségével. Lehetséges design, hogy csak a központi site-n keresztül léphessen ki a forgalom az internetre (hub and spoke topológia), de lehet minden telephelynek önálló internet kijárata is, ez tervezés, security és természetesen költség kérdése is lehet.
A fenti esetek közül mindkét esetben közös tulajdonság azonban, hogy ügyfél oldalon csak statikus (bandwidth, cost, delay, prefix stb.) paraméterek alapján hozható routing döntés, nehézkes vagy egyáltalán nem lehetséges traffic engineering (ez alatt nem a QoS-t hanem a tényleges forgalomirányítást értjük).
Többek között ebben hoz változást az SD-WAN, amely gyorsabb konvergenciát és magasabb szintű szegmentációt tesz lehetővé, és szolgáltatói vonaltól független traffic engineering-et biztosít különböző forgalmak számára akár subneten belül is (App-Aware Routing), hiszen egy overlay hálózatot alakít ki az ISP kapcsolatok felett (underlay), hasonló elven, mint a GRE vagy éppen a CAPWAP Tunnelek.
Ha megnézzük a hagyományos routing protokollokat láthatjuk, hogy mindegyik különböző statikus paraméterek alapján hoz döntést.
IGP-k közül pl. az OSPF a metric és route type (intra-area, inter-area, internal, external), az EIGRP bandwidth/delay, a RIP hop count alapján választja ki a legjobb útvonalat. Hiába nagy például egy adott kimenő vonalon a tényleges késleltetés vagy csomagdobás, a routing protokoll önmagában ezt nem fogja figyelembe venni, hiszen nem képezi részét az algoritmusnak ezen paraméterek vizsgálata. Fontos megemlíteni, hogy ezek a protokollok a megjelenésük idejében (az első OSPF standard pl. 1989-ben került publikálásra) nem készülhettek ilyen szempontok alapján. Az EIGRP a „K értékek” definiálásával próbált elindulni ezen az úton, azonban közel sem a mai kor igényeinek megfelelő eredmény született. Nyilván más funkciók bevonásával (IP SLA, tracking, BFD) ez a probléma részben orvosolható.
Cisco oldalról az első olyan megoldás, ami ténylegesen próbálta ezt orvosolni az OER (Optimized Edge Routing) majd később a PfR (Performance Routing) volt.
Ennek segítségével már dinamikus paramétereket (a vonalon történt csomagvesztés, késleltetés, tényleges sávszélesség stb.) vett figyelembe a routing. Megoldható volt például, hogy a késleltetésre érzékeny hang forgalom alapértelmezetten a szolgáltatói vonalon menjen, a nagy sávszélesség igényű, de késleltetésre és csomagdobásra kevésbé érzékeny adatforgalom pedig a jóval olcsóbb publikus interneten keresztül (hibrid WAN). Ha viszont a késleltetés az első vonalon megnőtt vagy a vonal leszakadt akkor a forgalom átterhelésre került a másodlagos kijáratra. Ennek a megoldásnak a segítségével bizonyos esetekben lemondható volt a drága másodlagos bérelt szolgáltatói vonal, helyette 4G mobil kapcsolatot vagy publikus internetet használva, ezzel jelentős OPEX csökkenést okozva.
A Cisco iWAN (Intelligent WAN) a következő lépcső, amely továbbra is a PfR-re (v3) építve, de már más technológiákat is bevonva (pl. DMVPN). Fontos megemlíteni , hogy az iWAN nem egy adott célra kifejlesztett „termék”, hanem több technológia (PfRv3, DMVPN, AVC, WAAS) felhasználásával megvalósított SD-WAN megoldás.
A Cisco legújabb SD-WAN megoldása a Viptela alapjaira épül (ezt a céget két ex-Cisco-s alapította, majd felvásárolta őket a Cisco 2017-ben), amely az intelligens routing következő generációja, és komplett megoldást nyújt, hiszen mint SD-WAN megoldás lett tervezve és kifejlesztve. Ez nem jelenti azt, hogy az iWAN már nem támogatott a gyártó oldaláról, a két megoldás jelenleg párhuzamosan fut, hiszen az eddig iWAN-t programkód szinten támogató ISR/ASR eszközök szoftverfrissítés (és DNA licensz vásárlás) után Viptela SD-WAN képesek lesznek, hardvercsere ezért nem (feltétlenül) szükséges, jelentősen csökkentve a CAPEX mutatót és lehetővé téve a migrációt a már meglévő eszközpark felhasználásával.
A Viptela SD-WAN architektúrában a control-plane funkciót a vSmart kontrollerek látják el, amelyeknek ezáltal teljes képe van a hálózatról, hiszen minden vEdge velük kommunikál és fogadja a routing döntéseket, policy-kat. Az SD-WAN segítségével a vManage felületről akár VPN-enként (VRF) különböző topológiák (full-mesh, partial-mesh, hub and spoke) vagy data-plane szabályok definiálhatók, template-k segítségével kezelhetők az eszközök, lehetőség nyílik a tényleges ZTP (Zero Touch Provisioning) megoldásra. A fabric-on belül tanúsítvány alapon történik a hitelesítés, ezért nagyon biztonságos megoldásról van szó. Ráadásul a Cloud onRamp segítségével az IaaS/SaaS forgalmak (pl. Office365, AWS, Dropbox) is a legoptimálisabb útvonalon folynak, hiszen a kapcsolat feléjük folyamatosan monitorozva van.
A Viptela menedzsment felülete (vManage) már teljes értékűen kezeli a meglévő ISR/ASR eszközöket (ahogy fent említettük).
Ahogy tehát a cikkben bemutattuk az ügyfelek mérettől függetlenül profitálhatnak az SD-WAN megoldásból, amely a folyamatos fejlesztéseknek és más termékekkel való integrációknak köszönhetően egyre robusztusabb megoldássá válik úgy, hogy közben hatékonyabb üzemeltetést és jelentős OPEX csökkentést lehet elérni.
