Ugrás a fő tartalomra

Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS I. epizód Fortigate


SD-WAN vagy SD-NINCS I. rész


Ez a bejegyzés sorozat ötlete, akkor merült fel bennem, amikor különböző gyártók SD-WAN-nak titulált megoldásait próbáltam összegezni magamban... Figyelemebe véve az alap elképzelést és a technikai megvalósíthatóságot, három kategóriát állítottam fel ezekre megoldásokra:
  1. SD-WAN megoldások - melyek biztosítják a transzport agnosztikus átvitelt, lehetőséget adnak a szolgáltatótól független topológia kialakítására központi orkesztráció és kontroll segítségével, továbbá az üzleti alkalmazások számára északi irányú API integrációra adnak lehetőséget.
  2. SD-NINCS megoldások - melyek marketing anyagokban szerepeltetik az SD-WAN-t, viszont technikai oldalról csak egy jól komponált policy based routing, ami  maximum megvalósítható.
  3. SD-LESZ megoldás - valahol a kettő között...


Fortigate SD-WAN

Március 13-ka óta HOME-OFFICE-ban dolgozom. Nem volt egyszerű az átállás, legalábbis mentálisan mindenképpen megterhelő a napi feladatok elvégzése úgy, hogy közben a gyerekek is itt szaladgálnak köztünk, és együtt kell élnünk, hogy szinte 0-24-ben be vagyunk zárva a lakásban.


Közben technikai oldalról sem egyszerű a helyzet, hiszen gondoskodni kell itthon is arról, hogy megfelelő Internet kapcsolatom legyen a folyamatos munkavégzés és gyerekek lekötése érdekében.

Abban a szerencsés helyzetben vagyok, hogy itthon meg tudtam oldani a redundáns csatlakozást az Internet-re, jelenleg az alábbi csatlakozási lehetőségek állnak rendelkezésre:
  1. KOAX alapú ED kapcsolat
  2. Mobil alapú LTE kapcsolat

Persze a "dual-home" csatlakozás nem minden, kell egy olyan eszköz is amellyel megvalósítható az egyidejű kétirányú csatlakozás, és nem árt, ha a kimenő forgalmak köz nem is végez terheléselosztást, legalább gyorsan tud váltani a két kapcsolat között. Csak erre a célra tökéletes megfelel bármilyen 10-20e forintos kategóriába eső eszköz, amiket ezen linken is elérhettek.

Most inkább üzleti célú, high-end eszközökkel foglalkoznék, nem csak azért mert ezek integrációjával foglalkozom a munkám során, hanem azért is, mert ezek a high-end eszközök, amik több szempontból is magasabb rendelkezésre állást biztosíthatnak:
  1. Hardver architektúra
  2. Szoftver követés
  3. Gyártói támogatás 
  4. Nem mellesleg olyan megoldások állnak rendelkezésre, mint például az SD-WAN.

SD-WAN alatt minden gyártó mást és mást ért, egyben viszont mindenki egyetért, ez pedig, hogy foglalkozni kell a témakörben a WAN kapcsolatok összefogásával és a terheléselosztás lehetőségével.
Ebben nekem van már személyes tapasztalatom, ugyanis 99999 Informatika jóvoltából lehetőségem nyílt rá, hogy itthon teszteljem a Fortigate SD-WAN képességeit.
Fortinet SD-WAN alatt sajnos csak a redundáns WAN kapcsolatok közti terheléselosztást érti, és kifejezetten SD-WAN orkesztráció nem áll rendlékezesre, pontosabban csak FortiManager bevonásával, ami azért a semminél mégis több.
Az SD-WAN feature Forti-OS 5.6 óta érhető el, az én "laboromban" jelenleg 6.0.9-es verzión fut egy FGT-60D amely mobil és vezetékes irányban biztosít stabil Internet kapcsolatot.

SD-WAN beállítása nem egy rocket science ennél a típusnál, de fontos, hogy beüzemelés első lépése legyen, ugyanis később szívhatunk a policy kialakításoknál
(mint ahogy én is tettem, amikor utólag csináltam meg az SD-WAN-t)

STEP 1 WAN kapcsolatok

A FGT-60D-nél rendelkezésre áll két dedikált WAN port, amiből ebben az install-ban 1-et használtam fel az KOAX alapú internet csatlakozás terminálására (értsd KábelNet).
Sajnos a szolgáltató eszköze - az IPTV szolgáltatás miatt - csak NAT módban tudja biztosítani az Internet szolgáltatást és nincs lehetőség bridge módra, így egy privát IP-t kapok a wan1 porton.
A szolgáltató DHCP-n biztosítja a privát IP-t, amit az IPTV miatt megint nem célszerű átállítani statikusra, szóval a szolgáltatói eszközben foglaltam fixen 1 db címet. (DHCP reservation)


A második WAN linknek a Fortigate 60D USB portján alakítottam ki.
FortiOS 5.4-től van lehetőség arra, hogy ne csak 4G-s mobil stick-et használjunk külső modemként, hanem egy MIFI routert használjunk erre a célra.
A MIFI routeren hasonlóan a KOAX modemnél csak privát IP beállítására van lehetőség, úgyhogy DHCP reservation 1 db fix cím, mellesleg ezen a porton a FGT-n sem lehet beállítani statikus IP-t csak DHCP kliensként tud működni.
A lakossági mobilnet ennél a szolgáltatónál Carrier Grade NAT mögött van, szóval ebben a kapcsolatban 3-as NAT-olás történik, a felhasználótól az Internetig. (Nem jó, de nem is tragikus)
 



STEP 2 SD-WAN interface

A következő lépés az, hogy ezeket a WAN kapcsolatokat összefogjuk 1 logikai entitássá, amit a FortiOS SD-WAN interface-nek hív.
  

Beállítjuk a default route-ot az SD-WAN interface-re és felvesszük a kimenő és bejövő policy-ket úgy, hogy SD-WAN interface-t használjuk...


A policy-król nem rakok fel képet - az már elég szenzitív információt tartalmaz - mindenkinek a saját képzeletére bízom a beállításokat.

Ez mind nagyon egyszerűnek tűnik eddig a pontig és valóban nem kell elbonyolítania konfigurációt, főleg otthoni felhasználásban és BRANCH-eknél sem feltétlenül, ha két egyforma SLA-val rendelkező és két egyforma átviteli kapacitást biztosító Internet vonalunk lenne.
DE
Alap esetben (round robin alapon) Source-Destination IP hash alapján csinálja a terheléselosztást az SD-WAN alkalmazás, ami nekem annyira nem jött be ebben a felállásban. Szerencsére van lehetőség arra, hogy performace SLA (PSLA) alapján, finom hangoljuk a terheléselosztást.

STEP3 Performace SLA

Ezt a pontot FortiOS 6.2-vel majd megnézzük újra, mert változott, de a lényeg nagyjából ugyanaz.
Lehetőségünk van mérni a különböző szolgáltatói irányokban az Interneten elérhető erőforrások minőségi paramétereit.
Milyen minőségi paramétereket?

  • Packet Loss - Csomagvesztési arány
  • Latency -  Késleltetés
  • Jitter - Késleltetés változása

Önmagában a Performance SLA-val lehetőségünk van a különböző irányok elosztására SD-WAN nélkül, ami azt jelenti, hogy a Performace SLA képes a routing táblát a minőségi paraméterek változása esetén frissíteni, de felhasználható SD-WAN szabály alapjaként is.
(vagy az első, vagy a második legyen, mert ha mindkettőt alkalmazzuk, abból furcsa anomáliák keletkezhetnek)


Hogy milyen erőforrások elérhetőségét szeretném vizsgálni, az attól függ, hogy üzleti szempontból mi a fontos, például számomra az 99999 Informatikában fellelhető publikus erőforrások elérése kritikus, de a feleségem is home-office-ban van, szóval az ő munkájához szükséges publikus hálózaton keresztül elérhető erőforrás mérése is ide tartozik.
Üzleti szempontokat nekünk ezek határozzák mert innen jönnek a fizetések...


Amikor létrehozzuk a Performance SLA mérést, akkor lehetőségünk van több távoli szervert beállítani, a mérési eredmények meghatározásánál.
Úgy tapasztaltam, hogy ez torzíthatja a mérési eredményt és indokolatlanul ronthatja a minőségi mutatókat, tehát a kritikus alkalmazások esetében, csak 1 szervert állítottam be mérési alapként. Fontos, hogy ahány szervert beállítunk minimum annyi SLA célt kell meghatároznunk, több lehet, kevesebb nem és mivel SD-WAN rule összeállításánál használom fel a PSLA-t, ezért nem engedélyezem a static route update-et. Szóval ezeknek a mért SLA paramétereire bízom majd a döntést az SD-WAN rule-ok összeállításánál során.

STEP4 SD-WAN rulez ;-)


SD-WAN rule-ok, szabályok határozzák meg azt, hogy a belső felhasználói vagy szerver zónáim, melyik WAN interface-en érhetik el a publikus erőforrásokat.




A szabályok sorrendjének is fontos szerepe van, főleg abban az esetben, ha a szabály konkrét forrás és cél hálózati címeket is tartalmaz, ezeket célszerű a sor elejére rakni.
Maga szabály összeállítása, igazából egy static route beállításhoz hasonlítható:
  • Meg kell határozni a forrásokat, legalább IP cím/tartomány vagy FQDN szinten, de szűkíthetek felhasználói csoportokra is.
  • Meg kell határozni a cél címet, vagy címeket, és lehetőség van konkrét alkalmazásra szűrni.
  • Meg kell határozni a kimenő interface-ket, amelyek felé mehet a forgalom (minimum 1)
  • Ki kell választanunk a PSLA-t ami alapján az SD-WAN route alakul, és meg kell határozni, hogy milyen minőségi paraméter alapján hozzunk döntést.
Ha semmilyen szabályt nem állítunk be, akkor is van egy implicit sor, ami alapján a terheléselosztás történik. A fentebbi képen pirossal bekeretezve.
Ennek a szabálynak a hangolása az, amely az összes forgalomra ami SD-WAN interface felé policy-ben engedélyezve van, hatással lesz.

Alap beállítás, hogy source és destination IP hash alapján csinálja az elosztást, de van másik 4 szempont ami alapján oszthatjuk az erőforrásokat. Például session számra súlyozhatunk:
Vagy átviteli sebességre elosztásra:
Éppenséggel adatmennyiséget is figyelembe vehetünk:

Terhelés elosztás algoritmusát, lehet csak kizárólag  a Source IP hash alapján alakítani, ennek nem sok értelmét látom egy round-robin jellegű terhelés elosztásnál.

Monitorozás

Az eredmény az SD-WAN szabályok mentén történő terheléselosztás, amiről SD-WAN monitoringban is meggyőződhetünk, ami két interface esetén,elég kevésnek tűnhet, de nem csak két WAN interface-t vonhatunk be SD-WAN megoldásba, hanem többet is, a maximum-ot az adott eszköz hardver kapacitása limitálja.


A működés/üzemeltetés ebben az installban egy kicsit problémás, ugyanis, ha valamilyen okból megszakad a MIFI routerrel a kapcsolat, akkor eddig csak újraindítással sikerült az SD-WAN interface részévé tenni újra. Sem CLI sem GUI beállítások nem hozták vissza a mobil irányú WAN kapcsolatot. Ezt majd 6.2+-ban újra meg fogom vizsgálni...

Summázva

Fortigate esetében az SD-WAN vagy SD-NINCS-re az a válaszom, hogy igen. Sok olyan megoldás elérhető benne, amely az SD-WAN általános architektúra elképzelésében is szerepel, viszont hiányzik belőle néhány elem amely teljes SD-WAN megoldássá teheti.
Ezeket a hiányosságokat is tudjuk pótolni, például ADVPN-nel és FortiManager-el, szóval ha befoltozzuk a hiányt kézzel, akkor SD-WAN, de önmagában a Fortigate egy nagyon jól megkomponált policy based router, ami SDN API segítségével automatizálható (6.2+), de még inkább SD-LESZ majd.

A következő bejegyzésig a legkevesebb amit tehetsz a jelenlegi pandémiás helyzetben:
stay@HOME
folding@HOME
https://newman.cloud/en/2020/03/28/foldinghome-in-your-datacenter/

Érdekesebb bejegyzések

Hálózat-virtualizáció a gyakorlatban - ACI fabric E01

Cisco ACI Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új. Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot. Mint azt egy korábbi be

SD-WAN vagy SD-NINCS II. epizód Cisco (Viptela) 1

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. Cisco SD-WAN-nak nem kis történelmi háttere van már, hiszen a megoldást szakmai berkekben leánykori néven viptelának is hívják. A Cisco 2017 májusában fejezte be a Viptela akvizícióját, és termékeit saját megoldásként, immáron 3 éve Cisco SD-WAN megoldás részeként kínálja az ügyfelei felé. 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 )

IPAR 4.0 - Okos megoldások, hülyén megvalósítva

IPAR 4.0 Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak. Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban. Nos eddigi tapasztalataim alapján az IoT és/vagy SMART termékek terén az, hogy minél olcsóbban, minél több szolgáltatást legyenek képesek nyújtani a végfelhasználó felé. A ipari plc-k vezérlő szoftvere - amin keresztül menedzs