6.1 Multiprotocol Label Switching

Úvod

Prudce rostoucí objem přenášených dat na všech úrovních Internetu vedl výrobce směrovačů k hardwarovým řešením, která jsou schopna velmi rychle přepojovat datagramy na základě jednoho pole jejich IP hlavičky - cílové adresy. Modifikace směrovacích rozhodnutí na základě zdrojové adresy či jiných polí IP hlavičky (např. TOS, směrování odesílatelem) pak buď nejsou vůbec podporovány, anebo jsou realizovány jiným, obvykle značně pomalejším mechanismem.

Obecným trendem posledních let je proto přechod na novou komunikační architekturu, která přesouvá podstatnou část operací nad datovými toky - směrování, administrativní strategie, QoS, účtování atd. do okrajových částí sítě (pod pojmem síť je zde třeba rozumět např. autonomní systém). Vnitřní uzly sítě jsou pak optimalizovány pro co nejvyšší přenosové rychlosti - jsou jim ponechány jen jednoduché funkce, které mohou být efektivně implementovány v hardwaru.

Jedním z podstatných prvků této nové architektury je technologie nazývaná Multiprotocol Label Switching (MPLS), původně implementovaná firmou Cisco Systems pod názvem Tag Switching.

Základním principem MPLS je oddělení standardních směrovacích informací, získaných obvykle prostřednictvím některého směrovacího protokolu, od vlastního předávání paketů. Směrovače na okraji domény MPLS pakety přicházející zvenčí (všechny nebo jen definovanou podmnožinu) opatřují značkami pevné délky. K přidělení značky lze kromě směrovací tabulky využít i další informace - požadavky na QoS, administrativní preference apod. K výměně informací o přidělených značkách mezi sousedícími směrovači se používá Label Distribution Protocol (LDP). Každá značka má pouze lokální účinnost na každém spoji mezi dvěma směrovači účastnícími se MPLS (LSR - Label Switching Router).

Jakmile je paketu na okraji domény MPLS přidělena značka, používá se k jeho předávání velmi rychlý algoritmus přepojování na základě jednoduché tabulky: paket se značkou L₁ přicházející přes rozhraní R₁ se opatří novou značkou L₂ a předá se na rozhraní R₂.

MPLS také umožňuje elegantní integraci různých technologií přenosu ve druhé vrstvě modelu ISO OSI, například Ethernet, SDH, DWDM a v neposlední řadě ATM, jež pro účely přenosu IP paketů můžeme zařadit do druhé vrstvy. Pokud daná technologie používá vlastní značky pevné délky (to je třeba případ identifikátorů VPI/VCI v ATM), může MPLS používat tyto značky. Jinak se použije speciální zapouzdření a značka se zapíše do vnější hlavičky.

Kombinace MPLS s ATM tak nabízí cestu k jistému kompromisu v dlouholetém sporu mezi zastánci ATM a IP. Přepínače ATM se účastní výměny směrovacích informací, tj. stávají se z nich LSR. Díky tomu se fyzická topologie ATM sítě objevuje i ve třetí vrstvě, což při jiných realizacích IP nad ATM není obvyklé. Při použití MPLS nad ATM ovšem odpadá signalizace okruhů mezi koncovými stanicemi (end-to-end), okruhy VC pro MPLS - nazývané dosud v dokumentaci firmy Cisco "tag-switched virtual circuit" (TVC) - se sestavují pouze na základě výměny informací o přidělených značkách pomocí protokolu LDP, tedy mezi sousedícími LSR.

Testování MPLS v rámci TF-TANT

V květnu a červnu 1999 jsme se zúčastnili testů technologie MPLS prováděných v rámci mezinárodní pracovní skupiny TF-TANT (Task Force - Testing Advanced Network Technologies). V pražském PoPu sítě TEN-155 jsme instalovali následující zařízení určené pro test MPLS:

ATM přepínač Cisco LS1010
směrovač Cisco 7505
pracovní stanice Sun
síťový analyzátor SmartBits
PC s Windows 98

Analyzátor SmartBits, zapůjčený po dobu trvání testu z Francie od firmy Netcom Systems, sloužil k analýze provozu v síti na úrovni UDP a TCP. Jeho data byla vyhodnocována speciálním programem na připojeném PC.

Obdobným způsobem byly zařízeny další experimentální uzly v Rakousku, Švýcarsku, Německu, Itálii, Řecku a Francii. Mezi nimi byly prostřednictvím služby MBS (Managed Bandwidth Service) zřízeny okruhy PVP. Vznikla tak logická síť nad evropskou páteří TEN-155, jejíž schéma znázorňuje obrázek 6.1.

Obrázek 6.1: Síť MPLS v experimentu TF-TANT

Podrobná zpráva o výsledcích experimentu je k dispozici na WWW - viz [Uzé99]. Pro naše úvahy o nasazení MPLS v páteřní síti TEN-155 CZ bylo nejzávažnější zjištění o pomalé konvergenci směrovacích informací při změně topologie vyžadující přesměrování části provozu alternativními cestami. Po vypnutí některého z okruhů (např. IT-CH) trvalo přibližně 4,5 minuty, než byl přesměrován provoz využívající původně vypnutou linku. Stejnou dobu pak trvalo i zpětné přesměrování poté, co byl okruh znovu zapojen.

Příčinou těchto pomalých reakcí je skutečnost, že protokol BGP, využívaný pro výměnu externích směrovacích informací mezi jednotlivými uzly, skutečně konverguje takto pomalu. Rychlost konvergence lze v současné době zlepšit úpravou minimální délky intervalu mezi BGP aktualizacemi, například

neighbor <adresa> advertisement-interval <sekundy>

Podle sdělení firmy Cisco Systems by měla budoucí verze IOS 12.0(6)T obsahovat nástroje pro změnu dalších důležitých časových intervalů. Tím by tento problém měl být odstraněn.

Velmi zajímavou součástí experimentu TF-TANT byly testy virtuálních privátních sítí nad MPLS. Na rozdíl od obvyklých metod realizace VPN (pomocí tunelů) jsou VPN nad MPLS nespojované. K jejich realizaci se využívá multiprotokolového rozšíření směrovacího protokolu BGP-4 [BCK98]. Ukázalo se, že konfigurace těchto VPN je velmi jednoduchá a všech požadovaných vlastností - zejména nezbytné izolace směrovacích informací - je dosaženo.

MPLS na páteři TEN-155 CZ

Nasazení nových směrovačů Cisco GSR12000 na lince Praha-Brno, k němuž dojde v nejbližší době, znamená mimo jiné i narušení dosavadní homogenity páteře. Pro tyto směrovače totiž není k dispozici LAN emulace, takže pro přenos IP na této lince bude použito přímo SDH a v budoucnosti DWDM. MPLS se zde ukazuje jako velmi výhodná náhrada za LAN emulaci, neboť umožňuje integrovat obě technologie druhé vrstvy - ATM a SDH - a navíc dovoluje v ATM síti provozovat vedle MPLS i dosud používané signalizační protokoly UNI a PNNI a nad nimi i LAN emulaci. Tím se velmi zjednodušuje přechod páteřní sítě na MPLS.

Testy technologie MPLS jsme uskutečnili ještě před nasazením GSR12000. Pro tento účel jsme zkonfigurovali novou logickou síť nad ATM páteří podle obrázku 6.2. Vyznačené IP adresy byly nastaveny na rozhraních Loopback0. Na rozdíl od experimentu TF-TANT je naše uspořádání zajímavé tím, že síť MPLS přesně odráží skutečnou fyzickou topologii páteřní sítě.

Obrázek 6.2: Logická síť MPLS

Každý ATM přepínač v mimopražských lokalitách využívá pro připojení k centrálním přepínačům SW1 a SW11 vyhrazený okruh ATM PVP s unikátním VPI. Na spojích mezi směrovačem a ATM přepínačem v každé lokalitě se obvykle využívá implicitní nastavení - VPI/VCI=0/32 pro řídící VC a VPI=1 pro všechna TVC. To znamená, že každý ze směrovačů má zkonfigurováno takovéto podrozhraní:

interface ATM1/0.17 tag-switching
 ip unnumbered Loopback0
 no ip directed-broadcast
 tag-switching ip

a konfigurace ATM přepínačů LS1010 obsahují následující fragmenty:

interface ATM0/0/1
 description TEN-155 backbone
 ip unnumbered Loopback0
 no ip directed-broadcast
 load-interval 30
 no atm ilmi-keepalive
 atm pnni admin-weight 2000 all
 atm pnni link-selection admin-weight-minimize
 clock source free-running
 tag-switching atm control-vc 103 32
 tag-switching atm vpi 103
 tag-switching ip
!
interface ATM0/1/0
 description Cisco 7507 @ rozvodna slaboproud
 ip unnumbered Loopback0
 no ip directed-broadcast
 no atm ilmi-keepalive
 tag-switching ip

Použití MPLS s původní směrovací architekturou

Přestože jsme již předem věděli, že v konečné podobě použijeme "kanonickou" směrovací architekturu kombinující OSPF a IBGP, pro účely testování MPLS pod zátěží jsme se rozhodli nejprve je použít v původním směrovacím schématu pouze s OSPF. K tomu stačilo na každém směrovači zaměnit v definici procesu OSPF původní podrozhraní páteřní emulované sítě za výše uvedené podrozhraní MPLS.

Postup přidělování značek podél předávací cesty je označován v dokumentaci firmy Cisco jako "downstream on demand". Tento název je ovšem poněkud zavádějící: ukazuje se, že okrajové směrovače vyžadují přidělení značek okamžitě pro všechny směrovací cesty, které získají prostřednictvím OSPF. V našem případě tedy bylo sestaveno zhruba 700 okruhů TVC mezi každým okrajovým směrovačem a přilehlým ATM přepínačem.

Toto chování okrajových směrovačů bylo pozorováno již v rámci experimentu TF-TEN [UF98], v jehož závěrech je také správně uvedeno, že při úplné směrovací tabulce a za podmínek v Internetu obvyklých (překlápění směrovacích cest) není tato konfigurace prakticky použitelná. Proto byla navržena speciální architektura, která v okrajových směrovačích filtruje všechny externí směrovací cesty. Interní proces OSPF, jehož směrovací informace jsou podkladem pro přidělování značek, je tak omezen pouze na vlastní doménu MPLS. Externí směrovací cesty jsou pak vyměňovány mezi okrajovými směrovači pomocí IBGP. Následkem toho se v doméně MPLS vytváří jen malý - a hlavně pevný - počet okruhů TVC. Této architektuře se budeme ještě dále podrobněji věnovat.

Je ovšem třeba poznamenat, že aktuální specifikace architektury MPLS (IETF draft [RVC99]) popisuje v oddílu 4.1.6 tzv. "Egress-Targeted Label Assignment", který představuje přímočarou cestu k dosažení téhož výsledku jako výše zmíněná kombinace OSPF a IBGP. Tato možnost však zatím nebyla v softwaru firmy Cisco implementována.

Jsou-li ATM přepínače LS1010 vybaveny rozšiřující kartou PFQ-FC, což je případ všech páteřních přepínačů TEN-155 CZ, aktivuje se automaticky sdružování okruhů TVC (VC merge): pokud přepínač přijímá po dvou či více okruzích TVC data, jejichž značky odpovídají stejnému směrovacímu prefixu, jsou na výstupu vysílána jediným okruhem TVC. Tím se podstatně snižuje počet sestavených TVC, v našem případě zejména mezi přepínači SW1 a SW11.

Ukázalo se ovšem, že problémem ve skutečnosti není velký počet TVC, nýbrž naopak skutečnost, že některým existujícím směrovacím prefixům nejsou značky přiděleny. Pokud k tomu dojde, je provoz odpovídající těmto prefixům směrován v softwaru ATM přepínačů. To vede k přetížení jejich hlavního procesoru a následnému kolapsu.

První případ tohoto druhu, s nímž jsme se setkali, byl zjevnou chybou v IOS verze 12.0(5)T1. V protokolu o činnosti směrovačů se projevovala těmito záznamy:

Sep 27 08:39:08: %ATM-3-FAILCREATEVC: ATM failed to create VC(VCD=1397, VPI=1, VCI=197) on Interface ATM1/0, (Cause of the failure: vpi/vci pair already in use)

S verzemi 12.0(6) a 12.0(7) již tato chyba nebyla pozorována, problém přetížení CPU však zůstával. Po opakovaných konzultacích se střediskem TAC firmy Cisco Systems v Bruselu jsme dospěli ke zjištění, že v tomto případě jde o implicitní směrovací cestu (default route), jíž se značka nepřiděluje. Vzhledem k tomu, že implicitní cesta se v páteřní síti TEN-155 CZ používá pro veškerý externí provoz, bylo zatížení přepínačů opět kritické. Tuto situaci lze zjistit ve výpisu přidělených značek na okrajovém směrovači:

TEN34_R6_CB#sh tag-switching tdp bindings
tib entry: 0.0.0.0/0, rev 74419
    local binding:  tag: imp-null(1)
...

Zkratka imp-null znamená právě tu skutečnost, že odpovídající prefix není směrován pomocí mechanismu MPLS. Nepodařilo se nám zjistit důvod, proč je s implicitní směrovací cestou nakládáno jinak, než s ostatními prefixy. V každém případě lze tento problém odstranit přidáním následující (nedokumentované) deklarace do konfigurace směrovači:

tag-switching ip default-route

S touto konfigurací jsme dosáhli stabilního fungování MPLS se stejnými nebo mírně lepšími odezvami ve srovnání s původním páteřním ELANem. Zátěž procesoru ve směrovačích a ATM přepínačích setrvávala na nízkých hodnotách s maximem zhruba 25 %.

Nová směrovací architektura

Ačkoliv by bylo zřejmě možno používat MPLS s původní směrovací architekturou, rozhodli jsme se přesto převést páteřní síť TEN-155 CZ na novou architekturu kombinující OSPF uvnitř domény MPLS s IBGP mezi okrajovými směrovači. Hlavní důvody, které nás k tomuto kroku vedou, jsou:

Počet okruhů TVC bude malý a nezávislý na rozsahu směrovací tabulky.
Bude možno daleko účinněji filtrovat a agregovat směrovací informace šířené z metropolitních sítí do páteře TEN-155 CZ.
Bude možné sestavovat virtuální privátní sítě nad MPLS.

Nová směrovací architektura je založena na následujících principech:

Všechny přepínače v ATM páteři jsou konfigurovány jako LSR.
Páteřní směrovače ve všech akademických metropolitních sítích (viz obrázek 6.2) slouží jako okrajové směrovače MPLS.
Každý LSR provozuje jeden OSPF proces, v němž se šíří pouze směrovací informace interní pro doménu MPLS.
Okrajové směrovače si navzájem pomocí IBGP vyměňují informace o prefixech v připojených metropolitních sítích.
Kvůli zmenšení počtu relací IBGP budou zřízeny dva BGP reflektory.
Směrovač PRG1 inzeruje externím sousedům sumarizované prefixy.
V opačném směru směrovač PRG1 blokuje veškeré externí směrovací informace a inzeruje do páteře TEN-155 CZ pouze implicitní cestu.

Páteřní OSPF proces

Ve všech LSR je páteřní OSPF proces definován velmi jednoduše:

router ospf 200
 network <adresa Loopback0> 0.0.0.0 area 0

Znamená to, že jsou do tohoto procesu OSPF zahrnuta všechna rozhraní s MPLS, neboť jsou konfigurována jako

ip unnumbered Loopback0

V tomto procesu není propagována implicitní směrovací cesta, takže deklarace

tag-switching ip default-route

zde není nezbytná.

Uvnitř každé metropolitní sítě je obyčejně používán ještě další OSPF proces, jehož se může okrajový směrovač účastnit svými dalšími rozhraními. Tyto dva OSPF procesy jsou však zcela izolované - žádné informace se mezi nimi nepřenášejí.

Konfigurace interního BGP

Typická definice IBGP procesu v okrajovém směrovači vypadá takto:

router bgp 2852
 no synchronization
 network 147.231.248.0 mask 255.255.254.0
 network 160.217.0.0
 network 195.113.100.0
 network 195.113.101.0 mask 255.255.255.128
 network 195.113.101.128 mask 255.255.255.192
 neighbor 195.113.144.1 remote-as 2852
 neighbor 195.113.144.1 update-source Loopback0

Konfigurační příkazy network definují prefixy příslušné metropolitní sítě (příklad je pro České Budějovice). Předpokládá se přitom jejich maximální možná sumarizace. Pokud tyto sumarizované prefixy nejsou směrovači známy přímo, třeba z OSPF metropolitní sítě, zavádíme tzv. "kotevní" směrovací cestu, např.

ip route 160.217.0.0 255.255.0.0 Null0

Jiné způsoby vnášení směrovacích informací do IBGP, jako například redistribuce z jiných směrovacích procesů, nejsou povoleny. Tímto opatřením jsme dosáhli rapidního snížení velikosti směrovací tabulky šířené v páteři TEN-155 CZ: z původního počtu více než 700 prefixů jich zbylo zhruba 50.

Prozatím jsme testovali konfiguraci pouze s jedním BGP reflektorem PRG1. Z důvodu zálohování a rozložení zátěže máme v úmyslu zřídit ještě druhý - zřejmě jím bude R7 v Brně.

Potenciální problémy této směrovací architektury vyplývají mimo jiné z toho, že se v ní využívá interní BGP nestandardním způsobem, protože

IBGP se obvykle provozuje zároveň s nějakým vnitřním směrovacím protokolem, např. OSPF.
Protokol BGP nebyl navržen s cílem rychlé konvergence a nepředpokládá se u něj tudíž okamžitá propagace změn v síťové topologii.

V našem případě jsou množiny prefixů šířených v OSPF a IBGP striktně disjunktní, takže konfigurace IBGP musí obsahovat deklaraci

no synchronization

Zjistili jsme také, že v IOS není povolena redistribuce směrovacích informací z IBGP do kteréhokoliv OSPF procesu. Za normálních okolností, když IBGP a OSPF běží nad stejnou sítí, by taková redistribuce byla skutečně velmi problematická, neboť by nutně vznikaly směrovací smyčky. V našem případě jsme ovšem měli dobrý důvod k přenosu informací z IBGP do OSPF - chtěli jsme totiž původně převést pouze část páteřní sítě pod MPLS a zbytek ponechat na LAN emulaci. Ukázalo se, že toto nebylo možné, protože směrovač PRG1 nebyl schopen (bez komplikované manuální konfigurace) inzerovat prefixy z části páteře pod MPLS do původního OSPF procesu nad páteřním ELANem. Proto jsme byli nuceni uskutečnit přechod od LAN emulace k MPLS v jediném kroku.

Konečně je zde problém s velmi pomalou konvergencí směrovacích informací v případě změny síťové topologie, který byl zmíněn v oddílu o experimentu TF-TANT. Tuto záležitost bude ještě nutno důkladně prověřit v podmínkách páteřní sítě TEN-155 CZ.

Externí BGP

Směrovač PRG1 má celkem 16 sousedů, s nimiž si vyměňuje informace v EBGP. Vzhledem k tomu, že PRG1 je jediným oficiálním rozhraním mezi sítí TEN-155 CZ a ostatními autonomními systémy, lze všechny externí směrovací cesty ponechat jen ve směrovači PRG1 a interním sousedům v IBGP posílat pouze implicitní cestu.

Jistým problémem se ukázala být potřeba různého rozlišení agregovaných prefixů směrem k interním a externím BGP sousedům. Například směrovač R6 inzeruje do IBGP prefix 160.217.0.0/16 a jiný směrovač R7 inzeruje prefix 160.216.0.0/16. Směrovač PRG1 je zkonfigurován tak, aby oba tyto prefixy sumarizoval do jediného: 160.216.0.0/15. Protože je také BGP reflektorem, musí prefixy zjištěné od R6 a R7 předávat jiným svým klientům. Zjistili jsme, že je předává v sumarizované formě a směrované na sebe. Tím bychom do interní komunikace mezi páteřními směrovači zbytečně vnesli další skok.

Možným řešením tohoto problému by bylo přenesení funkce BGP reflektoru na jiný směrovač. To se nám nezdálo výhodné vzhledem k centrálnímu postavení směrovače PRG1, a proto jsme jej řešili zavedením selektivní filtrace inzerovaných prefixů.

Problémy s nestabilitou IOS

Po poměrně dlouhém testovacím období jsme se rozhodli pro převedení celé páteře TEN-155 CZ z LAN emulace na MPLS během posledního víkendu v říjnu 1999. Nová směrovací architektura se jevila jako plně funkční, bohužel se však ukázalo, že směrovač PRG1 je schopen v dané konfiguraci fungovat bez restartu pouze zhruba 5 hodin, neboť mu plynule mizela volná operační paměť. Tato zjevná chyba verzí IOS 12.0(6a) a 12.0(7) vede ke kolapsu MPLS, neboť při nedostatku paměti směrovač Cisco 75xx nejprve vypíná funkci distribuovaného CEF předávání, které je pro MPLS nezbytné.

Snažili jsme se tuto chybu odstranit různými změnami v konfiguraci směrovače PRG1, nakonec jsme však museli tyto pokusy ukončit, neboť na směrovači PRG1 je životně závislá celá síť TEN-155 CZ. Další pokračování proto předpokládáme až po zprovoznění směrovače Cisco GSR12000, který má být náhradou za PRG1. To nám také umožní omezit rozsah funkcí tohoto nového centrálního směrovače na minimum nezbytné pro páteřní provoz - směrovač PRG1 totiž vykonává v současné době příliš mnoho funkcí i pro pražské sítě, které jsou k němu připojeny.

Závěry

Své zkušenosti s MPLS můžeme shrnout do následujících dočasných závěrů:

MPLS je v současné době k dispozici i v produkčních verzích IOS a jeho základní funkce jsou v podstatě stabilní.
Nejzáludnější problémy MPLS (a stejně tak i jiných komplikovaných technologií) se projevují až při nasazení v reálné situaci a se skutečným provozem. Nelze předpokládat, že po jakkoli dlouhém testování v umělých podmínkách proběhne implementace v produkční síti hladce.
Operační systém IOS velmi vážně trpí tzv. problémem rozbujelého softwaru. Je téměř nemožné spustit jakoukoli netriviální funkci bez toho, aby se narušila některá jiná funkce, popřípadě stabilita zařízení jako celku. I přes účinnou spolupráci techniků firmy Cisco je řešení takových problémů obvykle velmi náročné a zdlouhavé.

předchozí

obsah

následující