2019 BUÉK..., eltelt egy újabb év, és én már féléve nem
jelentkeztem, ezért elnézést kérek minden kedves olvasótól, aki várta
ezt a bejegyzést, de a hobbi, munka, család háromszögben nagyon nehéz,
optimumot találni, úgy, hogy mind a háromra elegendő idő jusson. Ígérem a
pozitív visszacsatolások, amit néhány olvasó adott a blogról, újabb
lendületet adnak, és kicsit rendszeresebben fogok jelentkezni valamilyen
írással.
Előző bejegyzésemet úgy fejeztem be, hogy „Maradjatok velem és megmutatom milyen mély a nyúl ürege” nos, ez nem csak filmes utalás, ugyanis mind a tradicionális és virtuális hálózatok felépítése – hasonlóan a nyúl üregéhez a földben – különböző rétegeken megy keresztül. „Kicsit gondban vagyok, nem tudom, milyen messziről indítsam a téma kifejtését, ezért” vázlatosan összefoglalom a legalapvetőbb elveket és aztán meglátjuk.
OSI modell
OSI (Open System Interconnection) modellt ISO standardként született meg, hogy a különböző kommunikációs interfészekkel rendelkező rendszerek, között biztosítson szabványosított átjárhatóságot. A kérdés, hogy mit értünk a kommunikációs interfész alatt:
A kommunikációs interfész az, ami biztosítja 2 vagy több informatikai rendszer valamint azok felhasználói közötti információ cserét.
Tehát minden olyan technikai megoldás, ami információ átadásra szolgál interfésznek tekinthető. (Pl: Monitor, Billentyűzet, Switch port, virtual interfész, szoftver interfész, stb).
Nos, az OSI modell alapvetően egy referencia, ami biztosítja a különböző gyártók berendezései szabványos interfészeken keresztül tudjon kommunikálni egymással.
Az OSI modell 7 rétegre bontja a kommunikációt végrehajtó eszközöket, attól függően, hogy a kommunikációban milyen szerepet tölt be:
1. Fizikai réteg (Physical Layer)
A fizikai beli feladatok közé tartozik a szabványos illesztés, a 0 és 1-es kódolása és dekódolása, ilyen fizikai rétegbe tartozó szabvány pl: az RJ45, RS232, LC/SC/ST csatlakozót használó SFP modul vagy a DAC (Twinax) kábel is (csak hogy a hálózatoknál maradjunk).
2. Adatkapcsolati réteg (Data Layer)
Az adatkapcsolati réteg feladata, a 0-k és 1-esek, szabványos kommunikációs keretbe szervezése, a réteg feladata az adatok alacsonyszintű integritásának biztosítása Pl: Ethernet, FC, SDH, ATM
3. Hálózati réteg (Network Layer)
A hálózati rétegben történik a különböző végpontok egyedi azonosítása, címzése, címek alapján a megfelelő útvonal kiválasztása. Pl: IPv4 IPv6, IPX
4. Szállítási réteg (Transport Layer)
A szállítási rétegben történik, a hálózati topológiától függetlenül, a végpontok közti hibamentes átvitel. Pl: TCP/UDP
5. Viszony réteg (Session Layer)
Biztosítja az alkalmazások/programok folyamatainak összekapcsolását, kialakítja az alkalmazások közti viszony kialakulását.
6. Megjelenítési réteg (Presentation Layer)
A kommunikációs felek számára biztosítja az adatok értelmezhetőségét, feldolgozhatóságát.
7. Alkalmazás réteg (Application Layer)
Az alkalmazások és felhasználók számára biztosít olyan protokollokat és szolgáltatásokat, amelyek lehetővé teszik az információ átvitelét két kommunikációs fél között. Pl: http/https, smb, smtp, imap, pop3, stb…
Láthatjuk, hogy minden rétegnek meg van a maga feladata az információ átvitel során. Ez alapján a különböző hálózati berendezéseinket, és eszközeinket is besoroljuk valamilyen rétegbe.
· Layer1 (L1) Média converter, HUB
· Layer2 (L2) Switch
· Layer3 (L3) Router, MultiLayerSwitch
· Layer 4 – 7 (L4 – L7) Firewall, Next Gen Firewall, Web Application Firewall,ESA, Load Balancer
A hálózati protokollokat is úgy osztályozzuk, hogy milyen rétegbeli feladatot látnak el a kommunikáció során:
· Layer1: CSMA/CD, CSMA/CA közeg hozzáférési protokoll
· Layer2: 802.3 Ethernet, 802.3q VLAN, 802.1ad LACP, Spanning-tree: STP, RSTP, PVST, MST
· Layer2.5: MPLS (Multi-Protocol Label Switching)
· L+ayer3: IP routing
· Layer4: TCP/UDP
· L5-L7: http/https, smb, smtp, pop3, imap
Definíciók
Jó, de akkor most mi a helyzet az overlay/underlay fogalmakkal…
Máris rátérünk a lényegre, szóval amikor egy hálózatot felépítünk a távolság és a komplexitás függvényében kialakítunk egy topológiát. A topológiától és komplexitástól függően, pedig meghatározzuk, hogy az egyes hálózati elemek milyen réteg béli feladatokat lássanak el, milyen protokollokkal dolgozzanak. Az így felépített fizikai rendszer az underlay hálózat, ami felett attól függően, hogy milyen logikai rendszert akarunk felépíteni, kialakítjuk az overlay topológiát…
Szóval akkor nem csak az OTV/VXLAN/Geneve protokollok az overlay eszközök?
Hát nem csak, például, egy full Layer2 eszközökből álló hálózaton hierarchikusan kialakított topológián VLAN overlay-el kialakíthatok broadcast domain-enként más-más topológiát…. Egy router-ekből álló fullmes-hed IP hálózaton, MPLS overlay segítségével, kialakíthatok sok-sok virtuális topológiát, amik szinte bármilyen alakzatba szervezhetők (fizikai határokon belül). Az overlay nézőpont kérdése csupán.
Akkor most mi? Elvesztettem a fonalat… Akkor most mi ez a hálózat-virtualizáció körüli felhajtás?
Semmi, nem most találták ki az overlay technológiát, csak most már olyan igényeket támasztunk felé, amik közel teljesen függetlenné teszik az underlay-ben kialakult skálázási problémáktól.
A tendencia azt mutatja, hogy egy alacsony rétegbeli funkciót, minél magasabb rétegbe tolva valósítunk meg, annál nagyobb a valószínűsége annak, hogy robusztus, jól skálázható rendszert építünk.
Nézzünk néhány felületes példát a hálózat-virtualizációban is alkalmazott Overlay networking-re:
Service Provider / TELCO
MPLS overlay + NFV, NSO
Igen az MPLS, mint overlay protokoll a hálózat-virtualizációnak jelen formájában is használt eszköze. A szolgáltatók jelenlegi gerinchálózatában egy közel full-meshed jellegű topológiára ültetik rá a MPLS szolgáltatásokat, amelyek az ügyfelek számára biztosítanak Layer2 és Layer3 szolgáltatásokat, a szolgáltatói gerinc topológiától közel függetlenül. Az MPLS protokoll alapelve az, hogy függetlenül attól, hogy milyen adatkapcsolati réteget alkalmazunk, kialakíthatunk a végpontok számára egységesnek látszó kapcsolatokat (AToM – Any Transport over MPLS). Az MPLS az adatkapcsolati réteg header-je és a hálózati réteg header-je, közé beszúrt, úgynevezett shim header-t illeszt be, amelynek tartalma (Label) alapján a MPLS-t futtató eszközök meghozzák az útválasztási döntést. Normál hálózatok esetén ez a feladat a 3. rétegben történne az IP header alapján, de a útválasztási/routing folyamat nem biztosított gyors és konvergens csomagkapcsolást (főként a múlt évtizedben). A gyors csomagkapcsolási mechanizmust az úgynevezett címkekapcsolási tábla biztosítja, amelyet az MPLS-t futtató eszközök a FIB (routing) tábla alapján állítanak össze, és LDP vagy Segment Routing segítségével továbbítják a többi MPLS router felé.
DataCenter
VXLAN + BGP-EVPN, Multicast, Unicast replication….
A VXLAN protokollt a nagy kiterjedésű Layer2-es hálózatok skálázhatósági problémái miatt fejlesztették, hogy Layer2 átvitelt biztosítson route-olt hálózat felett. Joggal merül fel a kérdés, hogy erre most miért van szükség? Nos egy kiterjedt adatközpontban a VLAN-ok (4094) számossága igen csak korlátozza azoknak a domain-eknek a számát amin belül az alkalmazásokat kiszolgáló szerverek kommunikálnak egymással, persze kis hazánkban nem ez szokott feltételen problémát okozni. A sokkal égetőbb probléma az lehet, hogy számottevő adatforgalom orientációja megváltozott a megszokott Észak-Déli irányról, és már Kelet-Nyugati irányban nagyobb. Ez azt jelenti, hogy az alkalmazás szerverek, amik különböző Layer2-es domain-ben kommunikálnak egymással, már sokkal jobban terhelik a disztribúciós vagy a core réteg hálózati eszközeit. Ezt önmagában a VXLAN vagy overlay nem oldja meg, hanem az Spine-Leaf architektúrában kialakított IP fabric, amely ECMP támogatással, kvázi load-balance-olja a Layer2 forgalmat, így egy könnyebben skálázható, robusztus adatközponti hálózatot lehet kialakítani. A VXLAN header úgy van kialakítva, hogy ECMP-hez szükséges IP hash érték mindig más-és-más legyen, így a VXLAN-ban utazó adatok, redundáns útvonal felhasználással kerülnek továbbításra.
Enterprise Networking
L2 VXLAN + LISP vs trational L2 + SDN controller
L3 SD-WAN (IPSec)
Nos Enterprise Networking világban a kommunikáció iránya főként kliensektől a szerverek felé irányul, tehát Kelet-Nyugat irányú forgalom nem számottevő, itt az overlay bevezetését leginkább az indokolja, hogy szeretnénk, ha dinamikusan, automatizált módon alakítanánk ki, a hozzáférési pontokat a felhasználóink számára, továbbá szeretnénk biztosítani a különböző üzleti alkalmazásokkal történő integrációt.
Tradicionális Layer2 (VLAN) megoldás, mint overlay már egy bevált technika a felhasználók elkülönítésére, de nehezebb az automatizáció megvalósítása. Így tehát bizonyos gyártók az adatközpontban már bevált VXLAN enkapszulációt használják LISP control plane alkalmazása mellett, ami egy kontroller bevonásával képes dinamikus hálózatok felépítésére.
A Layer3-as kapcsolatok esetében pedig a telephelyek összekötésére
IPSec mint overlay került kiválasztásra, ami már jól ismert sokat
tesztelt protokoll, jelenleg is alkalmazzuk, csak nem automatizált és
orkesztrált módon DMVPN hálózatok esetén. SD-WAN-ban alkalmazott IPSec
nem csak két pont 1 vonalon (vagy Internet felett) történő összekötését
biztosíthatja, hanem redundáns/load balance-olt kapcsolat, valamint
dinamikus topológia kialakítást a telephelyeink között.
Összefoglalva:
Nehéz egységes referencia pontot találni és azt mondani, hogy ettől a pontól már overlay hálózatról beszélünk, és ami az alatt van az underlay.
Általánosan általam megfogalmazva
Overlay hálózatnak tekinthetőek az olyan hálózatok, ahol a fizikai topológia – kellő redundancia mellett – közvetlenül nem befolyásolja az overlay-en történő adatátvitel forgalmat. Minden fizikai és az ezen összekötéséhez szükséges logikai kapcsolat, ami az overlay működtetéséhez szükséges underlay-nek tekinthető az overlay szempontjából. Maga overlay szó borítást jelent és az ilyen technológiák lényege, hogy absztrakt módon elfedje a fizikai és logikai infrastruktúrát.
A tendenciák az IP fabric feletti overlay kialakítása felé mutatnak, így hasznos ha már most úgy tervezünk hálózatot, hogy belekerülő hálózati eszközök támogassanak jól működő és nagyméretekre skálázható routing protokollokat (RIP önmagában kizárva J)… Overlay bevezetésére, kis hazánkban nem méretek miatt lesz majd szükség, hanem az automatizáció adta lehetőség fogja csábítani az embereket.
A teljesség igénye nélkül bemutatott Overlay technológiákról még szó lesz részletesebben a későbbi bejegyzések során, amikor eljutunk oda, hogy egy-egy gyártó hálózat-virtualizációs/automatizációs megoldását, fogjuk áttekinteni.
Addig is ajánlott tartalmak:
https://www.99999.hu
https://newman.cloud
https://www.sdxcentral.com
Előző bejegyzésemet úgy fejeztem be, hogy „Maradjatok velem és megmutatom milyen mély a nyúl ürege” nos, ez nem csak filmes utalás, ugyanis mind a tradicionális és virtuális hálózatok felépítése – hasonlóan a nyúl üregéhez a földben – különböző rétegeken megy keresztül. „Kicsit gondban vagyok, nem tudom, milyen messziről indítsam a téma kifejtését, ezért” vázlatosan összefoglalom a legalapvetőbb elveket és aztán meglátjuk.
OSI modell
OSI (Open System Interconnection) modellt ISO standardként született meg, hogy a különböző kommunikációs interfészekkel rendelkező rendszerek, között biztosítson szabványosított átjárhatóságot. A kérdés, hogy mit értünk a kommunikációs interfész alatt:
A kommunikációs interfész az, ami biztosítja 2 vagy több informatikai rendszer valamint azok felhasználói közötti információ cserét.
Tehát minden olyan technikai megoldás, ami információ átadásra szolgál interfésznek tekinthető. (Pl: Monitor, Billentyűzet, Switch port, virtual interfész, szoftver interfész, stb).
Nos, az OSI modell alapvetően egy referencia, ami biztosítja a különböző gyártók berendezései szabványos interfészeken keresztül tudjon kommunikálni egymással.
Az OSI modell 7 rétegre bontja a kommunikációt végrehajtó eszközöket, attól függően, hogy a kommunikációban milyen szerepet tölt be:
1. Fizikai réteg (Physical Layer)
A fizikai beli feladatok közé tartozik a szabványos illesztés, a 0 és 1-es kódolása és dekódolása, ilyen fizikai rétegbe tartozó szabvány pl: az RJ45, RS232, LC/SC/ST csatlakozót használó SFP modul vagy a DAC (Twinax) kábel is (csak hogy a hálózatoknál maradjunk).
2. Adatkapcsolati réteg (Data Layer)
Az adatkapcsolati réteg feladata, a 0-k és 1-esek, szabványos kommunikációs keretbe szervezése, a réteg feladata az adatok alacsonyszintű integritásának biztosítása Pl: Ethernet, FC, SDH, ATM
3. Hálózati réteg (Network Layer)
A hálózati rétegben történik a különböző végpontok egyedi azonosítása, címzése, címek alapján a megfelelő útvonal kiválasztása. Pl: IPv4 IPv6, IPX
4. Szállítási réteg (Transport Layer)
A szállítási rétegben történik, a hálózati topológiától függetlenül, a végpontok közti hibamentes átvitel. Pl: TCP/UDP
5. Viszony réteg (Session Layer)
Biztosítja az alkalmazások/programok folyamatainak összekapcsolását, kialakítja az alkalmazások közti viszony kialakulását.
6. Megjelenítési réteg (Presentation Layer)
A kommunikációs felek számára biztosítja az adatok értelmezhetőségét, feldolgozhatóságát.
7. Alkalmazás réteg (Application Layer)
Az alkalmazások és felhasználók számára biztosít olyan protokollokat és szolgáltatásokat, amelyek lehetővé teszik az információ átvitelét két kommunikációs fél között. Pl: http/https, smb, smtp, imap, pop3, stb…
Láthatjuk, hogy minden rétegnek meg van a maga feladata az információ átvitel során. Ez alapján a különböző hálózati berendezéseinket, és eszközeinket is besoroljuk valamilyen rétegbe.
· Layer1 (L1) Média converter, HUB
· Layer2 (L2) Switch
· Layer3 (L3) Router, MultiLayerSwitch
· Layer 4 – 7 (L4 – L7) Firewall, Next Gen Firewall, Web Application Firewall,ESA, Load Balancer
A hálózati protokollokat is úgy osztályozzuk, hogy milyen rétegbeli feladatot látnak el a kommunikáció során:
· Layer1: CSMA/CD, CSMA/CA közeg hozzáférési protokoll
· Layer2: 802.3 Ethernet, 802.3q VLAN, 802.1ad LACP, Spanning-tree: STP, RSTP, PVST, MST
· Layer2.5: MPLS (Multi-Protocol Label Switching)
· L+ayer3: IP routing
· Layer4: TCP/UDP
· L5-L7: http/https, smb, smtp, pop3, imap
Definíciók
Jó, de akkor most mi a helyzet az overlay/underlay fogalmakkal…
Máris rátérünk a lényegre, szóval amikor egy hálózatot felépítünk a távolság és a komplexitás függvényében kialakítunk egy topológiát. A topológiától és komplexitástól függően, pedig meghatározzuk, hogy az egyes hálózati elemek milyen réteg béli feladatokat lássanak el, milyen protokollokkal dolgozzanak. Az így felépített fizikai rendszer az underlay hálózat, ami felett attól függően, hogy milyen logikai rendszert akarunk felépíteni, kialakítjuk az overlay topológiát…
Szóval akkor nem csak az OTV/VXLAN/Geneve protokollok az overlay eszközök?
Hát nem csak, például, egy full Layer2 eszközökből álló hálózaton hierarchikusan kialakított topológián VLAN overlay-el kialakíthatok broadcast domain-enként más-más topológiát…. Egy router-ekből álló fullmes-hed IP hálózaton, MPLS overlay segítségével, kialakíthatok sok-sok virtuális topológiát, amik szinte bármilyen alakzatba szervezhetők (fizikai határokon belül). Az overlay nézőpont kérdése csupán.
Akkor most mi? Elvesztettem a fonalat… Akkor most mi ez a hálózat-virtualizáció körüli felhajtás?
Semmi, nem most találták ki az overlay technológiát, csak most már olyan igényeket támasztunk felé, amik közel teljesen függetlenné teszik az underlay-ben kialakult skálázási problémáktól.
A tendencia azt mutatja, hogy egy alacsony rétegbeli funkciót, minél magasabb rétegbe tolva valósítunk meg, annál nagyobb a valószínűsége annak, hogy robusztus, jól skálázható rendszert építünk.
Nézzünk néhány felületes példát a hálózat-virtualizációban is alkalmazott Overlay networking-re:
Service Provider / TELCO
MPLS overlay + NFV, NSO
Igen az MPLS, mint overlay protokoll a hálózat-virtualizációnak jelen formájában is használt eszköze. A szolgáltatók jelenlegi gerinchálózatában egy közel full-meshed jellegű topológiára ültetik rá a MPLS szolgáltatásokat, amelyek az ügyfelek számára biztosítanak Layer2 és Layer3 szolgáltatásokat, a szolgáltatói gerinc topológiától közel függetlenül. Az MPLS protokoll alapelve az, hogy függetlenül attól, hogy milyen adatkapcsolati réteget alkalmazunk, kialakíthatunk a végpontok számára egységesnek látszó kapcsolatokat (AToM – Any Transport over MPLS). Az MPLS az adatkapcsolati réteg header-je és a hálózati réteg header-je, közé beszúrt, úgynevezett shim header-t illeszt be, amelynek tartalma (Label) alapján a MPLS-t futtató eszközök meghozzák az útválasztási döntést. Normál hálózatok esetén ez a feladat a 3. rétegben történne az IP header alapján, de a útválasztási/routing folyamat nem biztosított gyors és konvergens csomagkapcsolást (főként a múlt évtizedben). A gyors csomagkapcsolási mechanizmust az úgynevezett címkekapcsolási tábla biztosítja, amelyet az MPLS-t futtató eszközök a FIB (routing) tábla alapján állítanak össze, és LDP vagy Segment Routing segítségével továbbítják a többi MPLS router felé.
DataCenter
VXLAN + BGP-EVPN, Multicast, Unicast replication….
A VXLAN protokollt a nagy kiterjedésű Layer2-es hálózatok skálázhatósági problémái miatt fejlesztették, hogy Layer2 átvitelt biztosítson route-olt hálózat felett. Joggal merül fel a kérdés, hogy erre most miért van szükség? Nos egy kiterjedt adatközpontban a VLAN-ok (4094) számossága igen csak korlátozza azoknak a domain-eknek a számát amin belül az alkalmazásokat kiszolgáló szerverek kommunikálnak egymással, persze kis hazánkban nem ez szokott feltételen problémát okozni. A sokkal égetőbb probléma az lehet, hogy számottevő adatforgalom orientációja megváltozott a megszokott Észak-Déli irányról, és már Kelet-Nyugati irányban nagyobb. Ez azt jelenti, hogy az alkalmazás szerverek, amik különböző Layer2-es domain-ben kommunikálnak egymással, már sokkal jobban terhelik a disztribúciós vagy a core réteg hálózati eszközeit. Ezt önmagában a VXLAN vagy overlay nem oldja meg, hanem az Spine-Leaf architektúrában kialakított IP fabric, amely ECMP támogatással, kvázi load-balance-olja a Layer2 forgalmat, így egy könnyebben skálázható, robusztus adatközponti hálózatot lehet kialakítani. A VXLAN header úgy van kialakítva, hogy ECMP-hez szükséges IP hash érték mindig más-és-más legyen, így a VXLAN-ban utazó adatok, redundáns útvonal felhasználással kerülnek továbbításra.
Enterprise Networking
L2 VXLAN + LISP vs trational L2 + SDN controller
L3 SD-WAN (IPSec)
Nos Enterprise Networking világban a kommunikáció iránya főként kliensektől a szerverek felé irányul, tehát Kelet-Nyugat irányú forgalom nem számottevő, itt az overlay bevezetését leginkább az indokolja, hogy szeretnénk, ha dinamikusan, automatizált módon alakítanánk ki, a hozzáférési pontokat a felhasználóink számára, továbbá szeretnénk biztosítani a különböző üzleti alkalmazásokkal történő integrációt.
Tradicionális Layer2 (VLAN) megoldás, mint overlay már egy bevált technika a felhasználók elkülönítésére, de nehezebb az automatizáció megvalósítása. Így tehát bizonyos gyártók az adatközpontban már bevált VXLAN enkapszulációt használják LISP control plane alkalmazása mellett, ami egy kontroller bevonásával képes dinamikus hálózatok felépítésére.
Összefoglalva:
Nehéz egységes referencia pontot találni és azt mondani, hogy ettől a pontól már overlay hálózatról beszélünk, és ami az alatt van az underlay.
Általánosan általam megfogalmazva
Overlay hálózatnak tekinthetőek az olyan hálózatok, ahol a fizikai topológia – kellő redundancia mellett – közvetlenül nem befolyásolja az overlay-en történő adatátvitel forgalmat. Minden fizikai és az ezen összekötéséhez szükséges logikai kapcsolat, ami az overlay működtetéséhez szükséges underlay-nek tekinthető az overlay szempontjából. Maga overlay szó borítást jelent és az ilyen technológiák lényege, hogy absztrakt módon elfedje a fizikai és logikai infrastruktúrát.
A tendenciák az IP fabric feletti overlay kialakítása felé mutatnak, így hasznos ha már most úgy tervezünk hálózatot, hogy belekerülő hálózati eszközök támogassanak jól működő és nagyméretekre skálázható routing protokollokat (RIP önmagában kizárva J)… Overlay bevezetésére, kis hazánkban nem méretek miatt lesz majd szükség, hanem az automatizáció adta lehetőség fogja csábítani az embereket.
A teljesség igénye nélkül bemutatott Overlay technológiákról még szó lesz részletesebben a későbbi bejegyzések során, amikor eljutunk oda, hogy egy-egy gyártó hálózat-virtualizációs/automatizációs megoldását, fogjuk áttekinteni.
Jöttemre 2 hét múlva számítsatok
https://www.99999.hu
https://newman.cloud
https://www.sdxcentral.com