Ugrás a fő tartalomra

Hálózat-virtualizáció EPISODE II

 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.
Jöttemre 2 hét múlva számítsatok

Addig is ajánlott tartalmak:
https://www.99999.hu
https://newman.cloud
https://www.sdxcentral.com 


É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 )

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: 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. 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ó. 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özbe

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