CCIE felkészülésem végső szakaszában, egy új szolgáltatói technológiát kellett magamévá tennem, ugyanis még ideje korán, az első időszakokban, a BGP/MPLS IPVPN / L3VPN és L2VPN technológiák önmagukban "elegendőek" voltak egy kis RSVP-TE és MPLS traffic engineering-el, hogy v4.0-át vagy v3.0-át elérjem.... Nos igen, azóta addig halogattam az intenzívebb felkészülést, hogy hip-hop v5.0 lett belőle...
A v5.0-val megjelent az MPLS technológia új generációja a vizsgán is. A transzport technológiák új -Ferrárija a Segment Routing, ami kapásból két technológiai stack-et sűrít magában:
IPv4 - Segment Routing MPLS
IPv6 - Segment Routing v6
Természetes olyan marketing hívó szavak mentén 5. generációs mobilhálózathoz SDN ready transzport és egyéb bullshit-ek tengerében... amikre természetesen a vizsgán is rákérdeznek, érdemes átgondolni, hogy milyen régen várt újításokat, pontosabban paradigma váltást lehet elérni ezen új technológia alkalmazásával.
Röviden ez egy source routing technika... Oké... de hogy működik routing folyamata?
A routing mint "elméletileg" állapotmentes adattovábbítási feladatot úgy kell elképzelni, mint amikor Móricka az iskola első napján keresi az osztálytermét, Móricka ebben az esetben az IP csomag, ő két információval rendelkezik: 1 honnan jött , és mi a célállomása - csak pontosság kedvéért Móricka vak, és nem átkozták meg a tudás és a tanulás átkával, így csak arra képes, hogy elindul arra amerre irányítják - tegyük fel, hogy az alapértelmezett átjárója az iskola bejárata, ahol ott ül Józsi bácsi a portás, aki sosem járt a portán kívül, de Gizitől a takarítótól nagyjából ismeri az útvonalak, de termek pontos helyét nem. Józsi bácsi ebben az esetben a router akinek van információja a hálózatról, de csak a főirányokat és következő információs pontokat ismeri. Józsi bácsi elirányítja Móriczkát a 2. emeleti tanáriba, ahol pontosabb információt kap a terme helyéről, így Móricka felmegy a másodikra, ahol tanárok közül mindenki csak a saját termének pontos helyét ismeri meg azt, hogy merre van a következő tanári szoba, mivel Móricka terme nem itt van ezért tovább irányítják a következőhöz éssatöbi ésatöbbi... Szóval Móricka addig járja a tanárikat míg meg nem találja azt a tanárit, ahol ismerik az ő termének pontos pozícióját vagy amíg be nem csengettek és el nem zavarják. Igen az IP csomagok esetén egy "természetes" hurok elkerülési technológia áll rendelkezésre, ami megakadályozza azt, hogy egy csomag vagy esetünkben Móricka végtelen ideig keringjen a rendszerben és ez a hurok elkerülési technológia az IP header TTL mezője azaz time-to-live értéke, ha pontosak akarunk maradni az analógia esetén, amikor becsengettek - tehát lejárt a TTL értéke (ami maximum 255 lehet) - akkor a Mórickát a következő tanáriban ki dobják az ablakon. A TTL értéke Mórickának tanáriról, tanárira csökken egészen a portától a teremig vagy maximum 255-ig terjed.
A fenti Móricka példából sejthetjük, hogy a "hagyományos IP routing" folyamata nem túl hatékony főleg, ha nem jó útvonal választási stratégiát választunk meg. A jó útvonal választási stratégia pedig függ attól, hogy milyen és mennyi információ áll rendelkezésre a lehetséges útvonalakról, irányítási pontokról és célállomásokról.
Oké, Oké dinamikus routing protokollok ilyen információk átvitelére / terjesztésére képesek, és meghatározhatók velük a legrövidebb útvonal, ezek kizárólagos alkalmazása esetén, minden csomag számára csak a legrövidebb útvonal áll rendelkezésre, ami jól hangzik, de visszatérve az eredeti példánkhoz, ha az iskolában az elsősök terme legrövidebb úton mondjuk a jobb oldali lépcsőn keresztül érhető el, és Józsi bácsi az összes elsőst egyszerre irányítja abba az irányba (3 osztály esetén 30 gyerek per osztállyal számolva) 90 gyerek a lépcső alján torlódást alakíthat ki a maximális (szélesség) kapacitás miatt, illetve ha nem elég széles a lépcső, könnyen leeshet róla bárki így komoly veszteségek alakulhatnak ki az osztály létszámban. Szóval Józsi bácsinak, úgy kell irányítani a forgalmat a bejáratnál, hogy lehetőleg az összes diák megérkezzen a termébe, a lehető legjobb és és legbiztosabb útvonalon, persze ezek a feladatok még a "hagyományos MPLS és RSVP-TE" hálózatokban megvalósíthatók. Ez még "csak" traffic engineering probléma köre és nem kiállt source routing megoldásért hiszen egy felokosított intelligens belépő pont ezt képes lekezelni megfelelő információval (MP-BGP + IGP MPLS + LDP és RSVP).
A nehézséget a speciális igények okozzák, például van olyan gyerek aki a legrövidebb úton akar elérni a termébe, van olyan aki a legszélesebb utakat szeretné használni, van olyan aki pedig legkevesebb időt szeretné a folyosón tölteni, van aki előbb a tanárikba igyekezne, majd ezt követően szeretne a termébe jutni. Tehát, ha úgy testszik egyénenként változnak az igények és ezekhez az igényekhez kell igazítani az átviteli paramétereket úgyhogy belépési ponton kell meghatározni a célállomáshoz való eljutás útvonalát, tehát a forrás oldalon kell útvonalat meghatározni, ezt nevezzük source routing technológiának.
Mitől szegmens routing a SR?
Akármilyen meglepő a nevéből fakadóan rájöhetünk arra, hogy a szegmens routing eljárás lényege, hogy a hálózatot "elemi" összetevőkre szegmensekre osztjuk, amikhez szegmens azonosítót rendelünk hozzá. A szegmens azonosítók lehetnek:
- node segment : azaz eszköz/router-hez tartozó szegmens azonosító.
- adjacency segment : azaz szomszédsági viszonyhoz, összeköttetéshez tartozó azonosító.
- prefix segment : azaz egy meghatározott célhoz tartozó szegmens azonosító
Ezen szegmens azonosítók felhasználásával alakítható ki a szegmens lista a belépési ponton, és ezen szegmens lista fogja meghatározni az útvonalat a hálózatban a cél eléréséig.
Jó kérdés, hogy most akkor egy újabb kontroll protokoll kell hogy ezeket az azonosítókat és listákat továbbítsuk? (Mi az hogy újabb, miért hány van?)
Szerencsére nem, a segment routing funkciók vezérlési síkon (Control Plane) a már eddig is használt IGP-kbe (Interior Gateway Protocols) az OSPF-be (v2 és v3) és a IS-IS-be épül be, tehát a fent leírt szegmens azonosító információk a OSPF v2 esetén a opaqe LSA-k (Type 9 , 10 , 11) hordoznak "extra" szegmens azonosítót OSPF v3 esetén más Type1 Type2 is hordozhat ilyen információt, de a Type 9 opaqe-ra szintén szükség van. IS-IS esetén a egy speciális sub-TLV került bevezetésre a standard TLV alatt, ami ezt az információt hordozhatja.
Visszatérve a Móricka példához a belépési ponton, Józsi bácsi olyan informácikat ragaszt Móricka táskájára, amik a tanárikban vagy egyéb közbelső pontokon kiértékelődnek, így Móricka az igényeinek megfelelő legjobb útvonalon tud haladni, az iskolai programjának megfelelően.
Ezzel a forwarding technikával és egy központi vezérlő és orchesztrátor beépítésével el is készítettük a szolgáltatói hálózatok SDN megoldását.
Mivel már rég elértem azt karakterszámot, ahol az érdeklődés meredeken csökken, itt most befejezem, de majd ha több időm lesz még kifejtem a témát bővebben.... esetleg konkrét példákkal.
Puszi Pá...
Frissítés:
Kérdés: Miben különbözik a source routing egy policy-based routing megoldástól?
A kérdés igen jó, egy cigi szünet idejében jutott eszembe, hogy tulajdonképpen a példámban az egyedi igényeket akár PBR-el is meg lehet valósítani.
PBR esetén az IP csomag nem hordoz magáról útválasztással kapcsolatos extra információt, csak a forrás és cél cím információk állnak rendelkezésre, tehát a szabály rendszert, ami alapján a csomag továbbítás kiértékelődik, az összes érintett node-nak ismernie kell. Ez túl sok statikus konfigurációt és annak módosítását eredményezheti ami egy 3 node-os hálózatnál is üzemeltetési kockázatot jelent.
Segment Routing esetén az IP csomag SR-MPLS esetben MPLS stack-ben több címkével hordoz útvonallal kapcsolatos információt, amely közbelső node-okon dinamikusan frissülő forwarding táblák alapján értékelődhet ki. SRv6 esetben a SRH (Segment Routing Header) mező tartalmazza a SID-ek listáját, amik ugyanezt (és ennél többet is) eredményeznek.
Erről bővebben majd a további cikkekben lehet szó...