A Segment Routing hálózatok kapcsán már írtam egy szösszenet arról, hogy mi a különbség a source-routing és hagyományos routing megoldások között. Azt gondolhatjátok az Segment Routing egy újabb forwarding mechanizmus csupán, ami optimalizálhatja az IP csomagok szállítási módját a nagyteljesítményű szolgáltatói és adatközponti hálózatokban, de ez korántsem ilyen egyszerű. Az SR megoldásoknak két alapvető csoportja létezik, annak függvényében milyen architektúrára szeretnénk támaszkodni a jövőben.
- Segment Routing MPLS - SR-MPLS
- Segment Routing IPv6 - SRv6
SR-MPLS
MPLS hálózatok felépítése, szolgáltató modell függvényében, rengeteg kontrol protokollt tartalmazhatnak, kezdve a link-state alapú IGP protokolltól (ami lehet OSPF vagy ISIS) a szolgáltatások kialakításáért felelős BGP-n át egészen a RSVP-TE-ig és ne feledkezzünk meg a címkék terjesztésért felelős LDP protokollról sem.
Ez számszakilag is 4 protokoll, aminek folyamatosan kell futni, ami azt jelenti, hogy háttérben a rendszerek számára kell a megbízható adatbázisokat biztosítani, mindezt azért, hogy végén bekerüljön az útvonal az LFIB-be (Label Forwarding Information dataBase)
Ez üzemeltetési szempontból igen erős kihívás ugyanis probléma esetén akár 4 protokollt kell egyszerre vizsgálni, hogy megállapítsuk, hogy A és B pont között mi lehet a hiba adott esetben.
Nos, SR-MPLS egy jó lehetőség arra, hogy ezt a nagy mennyiségű control overhead-et csökkentsük és egyszerűsítsünk a már meglévő gerinchálózatunk komplexitásán.
A Segment Routing RFC-k ugyanis nem még 1 új control csatorna kialakításáról szólnak, hanem a meglévő hálózatokban is használ routing protokollok és forwarding mechanizmusok kiterjesztése van bennük kifejtve.
Az RFC fundamentumaiban határozza meg a SR működését MPLS és IPv6 esetekre, továbbá definiálja azokat az architektúrális elemeket és fogalmakat amiket ismerni kell a hálózat tervezése és kialakítása során.
SR-MPLS esetben az egyik ilyen lényeges pont az, hogy a MPLS forwarding mechanizmusa gyakorlatilag semmit nem változik, ugyanis az SR architektúrában alkalmazott SID-ek (Segment Identifier) gyakorlatban MPLS címkék lesznek.
Ahhoz, hogy a fenti mondtatnak értelme legyen, definiálni kell, hogy mit, merre és hol:
Azt már az előző cikkben leírtam, hogy mi a szegmens szerepe, illetve milyen szegmens azonosítók lehetnek, annyival egészíteném ki röviden, hogy szegmens egy olyan topológiai vagy szolgáltatás instrukció, amit a routerek feldolgoznak a forwarding során (SDN ready).
SID ezek alapján lehet a hálózatban NODE-t vagy LINK-et jelelő azonosítók, jelenthet csomag feldolgozási szabályt vagy algoritmust is.
Alkalmazásuk helye alapján lehetnek lokális azonosító SRLB, vagy globális azonosítók SRGB.
SRGB
Az SRGB MPLS esetén azon címkék tartománya, amit a hálózat minden eleme azonos állapotba tart hiszen ezek határozzák meg az egyes elemek szerepét a topológiában, ez alapján az adatbázis alapján történik prefix-SID-hez az MPLS címkék kalkulációja. Fontos hogy minden NODE-on azonos módon történjen a SID-ek értelmezése.
Az SRLB pedig a routerek kapcsolataihoz rendelt Adjacency-SID-ek címke tartománya.
Az MPLS forwarding táblában a prefix-SID-ek lesznek a router-hez képesti távoli irányok, és adjacency-SID-ek pedig adják a kilépő interface-hez kapcsolódó helyi címkét.
IGP-Node-SID
Routert azonosító prefix-SID ami gyakorlatban az a loopback, ami a routert azonosítja.
IGP-Adjacency-SID
IGP routing protokoll szomszédsági viszonyát reprezentáló SID, tehát a linkeket azonosítja.
A Node-SID / prefix-SID a SRGB tartományból kerül definiálásra, az Adjacency-SID pedig az SRLB-ből..
Egy router konfigurálása ebben az esetben például IOS-XR esetén:
JunOS esetén pedig:
A fenti JunOS minta a legérthetőbb lab-szintű formát mutatja, de a konkrét szintaxis platformon és JunOS verziónként eltérhet, különösen ha policy-alapú prefix-segment hirdetésről van szó. IOS XR-en is lehetnek eltérések release és platform szerint, de a logika ugyanaz: IS-IS, SR-MPLS, SRGB, majd prefix-SID a loopbacken
Az RFC-ben hosszú sorokon keresztül az van kifejtve, hogy meglévő ISIS implementációhoz képest a Segment Routing képesség, hogyan integrálódik be a routing protokollba.
Rövident, egy új sub-TLV került definiálásra, ami hordozza a SR releváns információt és ezen információk kerülnek be a LSDB-be.
Mit kell figyelni a kimenteken például egy LSDB esetén?
IOS XR:
RP/0/RP0/CPU0:XR1#show isis database verbose
IS-IS BB2 Level-2 Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
XR1.00-00 0x00000031 0x8fd7 1140 0/0/0
Extended IS Reachability TLV:
Neighbor: XR2, Metric: 10
Neighbor: XR3, Metric: 10
SR Capability TLV:
SRGB Base: 16000
SRGB Range: 8000
Prefix-SID TLV:
Prefix: 10.0.0.1/32
SID Index: 1
Flags: N, P
Adj-SID TLV:
Interface: Gi0/0/0/0
SID Index: 100
Flags: B, V
JunOS:
root@R1> show isis database extensive
IS-IS level 2 link-state database:
LSP ID: R1.00-00
Sequence: 0x31
Checksum: 0x8dd8
Lifetime: 1162
Attributes: L1 L2
Router Capability TLV:
SR Capability
SRGB: 16000-23999
Prefix-SID Sub-TLV:
Prefix: 10.0.0.1/32
SID Index: 1
Flags: P, N
Adjacency-SID Sub-TLV:
Interface: ge-0/0/0.0
SID Index: 100
Flags: B, V
A lényeg, hogy a SID / label információt a Segment Routing extension-nek hála az IGP hordozza, tehát nincs szükség LDP-re, továbbá az MPLS traffic engineering alkalmazásához RSVP-TE protokollra.
Elérkeztünk abba a fázisba, hogy nem szaporítom a karakterek számát, így az alábbi sokkal izgalmasabb képpel zárom ezt a cikket, bevezetőnek most elég legyen ennyi egyelőre.
A lenti képen próbáltam összegyűjteni, azokat a Magyarországon meghatározó gyártókat, akik alkalmasak lehetnek TELCO hálózatok kialakítására, és amelyekben ilyen vagy olyan módon jó magam is kapcsolódom, a képen minden SR-hez kapcsolódó lényegi információt elérhettek.
További cikkekben megpróbálom még néhány gyakorlati példán megmutatni az SR-MPLS OSPF IGP-n történő alkalmazhatóságát, azért az ISIS-el kezdtem, mert a gyártók az SR-hez kapcsolódó fejlesztéseik nagy részét ISIS protokollon hajtották végre hamarabb (pl: TI-LFA).
Addig is kitartást, remélem nem kell sokat várni :)
Csoki cső!