Protokol MPLS se v operátorských řešeních úspěšně používá již od počátku století. Během dvou desetiletí si dokázal uhájit své „místo na slunci“ a dnes jej zná každý, kdo je s telekomunikačním sektorem byť jen vzdáleně spojen. Proto jsme se rozhodli vám o něm říci více.
MPLS je tedy zkratka, která znamená multi-protocol label switching nebo multi-protocol label switching. V podstatě se jedná o osvědčenou technologii, která pohání IP překryvné sítě již více než dvě desetiletí. Klíčovým rysem technologie je proces přepínání paketů po předem určených trasách. V tomto případě není nutné nahlížet do balíčku nebo analyzovat směrovací tabulky. Výstupní rozhraní je předem určeno štítkem paketu.
Síť MPLS se skládá z mnoha směrovačů propojených linkami druhé vrstvy, jako jsou ethernetové linky. Směrovače zapojené do operací štítků se nazývají Label Switch Routers (LSR).
Když paket vstoupí do sítě MPLS, Ingress LSR umístěný na okraji sítě přidá záhlaví MPLS a sendvičí mezi hlavičku vrstvy XNUMX a IP. Záhlaví MPLS se skládá ze čtyř pododdílů:
Label – jednoznačně určuje trasu, po které paket projde. Tato cesta se nazývá Label Switched Path (LSP). Takových cest může být mnoho. V závislosti na požadavcích na úroveň služeb může být paket identifikován požadovanému LSP přiřazením příslušného návěští.
Třída provozu – Tři bity použité k určení požadované úrovně kvality služeb (QoS), kterou by měl mít označený paket.
Spodní část zásobníku – Hodnota 1 označuje, že neexistují žádné další záhlaví MPLS, 0 označuje přítomnost vnořených záhlaví.
Time to live je úplnou analogií IP TTL, určuje, kolik přechodů může paket provést, než je další odesílání odmítnuto. Potřebné pro boj se směrovacími smyčkami.
Jakmile je v síti MPLS, paket na vstupním LSR je spojen s požadovanou třídou ekvivalence předávání (FEC), každý FEC má svou vlastní cestu LSP již předdefinovanou v síti MPLS. Veškerá rozhodnutí o třídě služby a odpovídající cestě jsou tedy učiněna okamžitě na vstupním směrovači. Jádro sítě funguje jako vysoce výkonná mlátička značek a není zatíženo úkoly na vysoké úrovni. Třídy FEC vám umožňují poskytovat různé podmínky pro přepravu provozu různých služeb. Například hlasové služby mohou být poskytovány s kanály s minimálním zpožděním, pro video – s garantovanou šířkou pásma a současně pro provoz při surfování na internetu lze zbývající zdroje alokovat podle principu služby třídy Best-Effort.
Obecně se schopnost ovládat, jak se dostupná kapacita kanálu dostupná dostupná dostupná, nazývá technologie MPLS TE (dopravní inženýrství).
Je MPLS řešením vrstvy 2 nebo vrstvy 3? Značka MPLS je zabudována mezi ethernetový rámec a IP, takže MPLS je konvenčně označována jako Layer 2.5 a jednou z hlavních výhod protokolu je, že izoluje přenositelný zapouzdřený protokol poskytováním transportních služeb. Z hlediska MPLS transportu je jedno, co je uvnitř: IP, Ethernet, ATM atd. Tito. MPLS je docela vhodný pro přenos IP i protokoly vrstvy XNUMX. Nyní je nejdůležitější zapouzdření Ethernetu v MPLS.
MPLS je tedy vhodné pro organizaci L3VPN i L2VPN.
Vnitřní část sítě MPLS je izolována od uživatelských sítí. Fungují zde interní směrovací protokoly OSPF nebo ISIS, se kterými spolupracují protokoly distribuce štítků LDP nebo RSVP-TE. Pro interakci s klientskými sítěmi se obvykle používá MP-BGP, rozšíření protokolu BGP pro práci s MPLS-L3VPN.
Výhody a nevýhody MPLS
Hlavní výhody MPLS:
podpora pro různé třídy služeb;
schopnost zapouzdřit provoz L2/L3;
L3VPN podporuje různé topologie: mesh, star, overlapping, Hub-n-spoke, hybrid;
škálovatelnost a výkon díky zjednodušeným přepínacím mechanismům;
schopnost efektivně distribuovat dostupnou šířku pásma (MPLS-TE), snížit přetížení sítě a zlepšit zážitek koncového uživatele
Protokol MPLS je považován za bezpečný způsob přenosu dat, ale neposkytuje šifrování: izolace provozu a uživatelských adresových prostorů od sebe navzájem a od samotné páteřní sítě MPLS je implementována na úrovni logiky provozu protokolu. Využití infrastruktury MPLS k organizaci vnitřních uzavřených sítí je otázkou úrovně důvěry v operátora. V případě potřeby si klient může nainstalovat vlastní kryptografické nástroje pro šifrování provozu.
MPLS IP VPN byla navržena pro organizace s více geograficky rozptýlenými pobočkami a jedním nebo více firemními centry. Většina provozu je přesměrována na firemní datová centra. Dnes společnosti přesměrovaly většinu svého provozu na poskytovatele cloudu az poskytovatelů cloudu, čímž se MPLS suboptimální. V takových situacích jsou sítě MPLS doplněny infrastrukturou IP Fabric pro optimalizaci dodávání provozu do cloudových služeb.
MPLS je efektivní technologie pro určitý rozsah úkolů. Nyní se však spolu s (nebo místo) MPLS objevily nové technologie, jako je VxLAN, které byly vyvinuty speciálně pro moderní síťové architektury.
Softwarově definované rozlehlé sítě (SD-WAN) jsou navrženy s ohledem na cloudovou konektivitu, a proto tolik společností nahrazuje nebo doplňuje své sítě MPLS SD-WAN.
MPLS a SD-WAN
SD-WAN je aplikace konceptů softwarově definovaných sítí (SDN) pro rozlehlou síť. To znamená automatizované nasazení okrajových zařízení SD-WAN, která používají pravidla a zásady k odesílání provozu po nejlepší cestě.
SD-WAN je vhodný pro přenos jakéhokoli typu provozu, včetně MPLS. Výhoda SD-WAN spočívá v tom, že při použití jediného zajišťovacího systému mohou být transportní politiky centrálně a dynamicky aplikovány na všechna zařízení WAN. Podobně v MPLS jsou přenosové kanály definovány na vstupním LSR, ale ve výchozím nastavení neexistuje žádné centrální zajišťování, takže celkové zatížení může být nutné plánovat nezávisle. Je třeba mít na paměti, že prioritní doprava vyžaduje implementaci ve všech uzlech podél své trasy. Pokud se tedy ukáže, že jedna ze sekcí je síť, která takové mechanismy nepodporuje, například veřejný internet, pak již nelze zaručit doručování provozu po této cestě.
Konečně,
Mnozí považují MPLS a SD-WAN za návrh buď/nebo. Stane se MPLS v příštích letech minulostí? Odborníci tvrdí, že obě technologie mohou koexistovat, přičemž se role MPLS mění. Malé a střední podniky pravděpodobně opustí MPLS a rozhodnou se pro širokopásmovou síť WAN, protože mnoho z nich přešlo na celocloudový IT model.
Velké podniky, které mohly snížit náklady na budování sítí MPLS, si pravděpodobně vyberou hybridní přístup, kde si zachovávají MPLS pro starší aplikace spuštěné v síti a poté přenášejí internetový provoz, jako je cloudový provoz, do SD-Wan.
MPLS bude i nadále hrát roli jako konektory pro konkrétní přístupové body, jako jsou velké regionální kanceláře, maloobchodní zařízení a systémy v místě prodeje, regionální výrobní závody a datová centra. MPLS se dobře hodí například pro videokonferenční aplikace. Síla technologie SD-WAN spočívá v tom, že dynamicky směruje síťový provoz tím nejefektivnějším možným způsobem, aby splnila požadavky na kvalitu služeb pro různé aplikace, a samozřejmě k tomu může využít připojení MPLS.
Ti, kdo budují podnikovou rozlehlou síť, musí zvážit riziko versus přínos používání spolehlivé, ale drahé technologie MPLS. Vylepšení dalších síťových technologií a protokolů učinilo internetový provoz stabilnější, ale nezapomínejte na vysokou spolehlivost MPLS, protože vždy existuje riziko selhání kritické infrastruktury.
***
PS: přihlaste se k odběru našeho telegramového kanálu, abyste nezmeškali další článek.
Pokud jste pracovali s MPLS na lavičce nebo v živé síti, pak asi budete souhlasit, že samotná technologie je vcelku jednoduchá. I v tak jednoduché věci však můžete schovat smečku hrábí, které zkomplikují život. Většina těchto zemědělských překvapení je popsána v četných článcích na internetu, ale existuje také několik nedostatečně pokrytých aspektů. Dnes bych rád přispěl k obecné znalostní bázi o MPLS tím, že pohovořím o několika málo známých vlastnostech této technologie, které si samy o sobě nezaslouží samostatný článek, ale mohou být zajímavé.
Topologie je jednoduchá jako hůl:
MPLS v síti ISP plní pouze funkci zapouzdření tranzitního provozu (chybí L3VPN, TE a podobně). IGP je banální OSPF, ale rozdělení do zón vám umožní následně manipulovat s prefixy na PE. Níže jsou uvedena počáteční nastavení routerů:
Příběh 1: Vyznání PHP
Teorie stojící za předposledním hop poppingem (PHP) je na internetu poměrně široce pokryta; Zde si můžete v případě potřeby osvěžit paměť. Většina autorů však vynechává řadu výrazných nuancí, aby zjednodušila ponor do tématu.
LDP přiděluje štítky pro všechny předpony kromě těch, které jsou přijímány přes BGP. V druhém případě je to BGP, kdo je zodpovědný za přidělení požadovaného počtu štítků, například v případě VPNv4 AF, labeled unicast a dalších vhodných scénářů.
Obecně PHP eliminuje jednu iteraci vyhledávání v tabulce štítků, ale toto chování se týká pouze připojených a agregovaných cest; tranzitní trasy stále dostávají označení. Důvod je prostý: připojené a agregované prefixy stále vyžadují hledání dalšího uzlu v odpovídajících tabulkách, zatímco provoz na tranzitních trasách může být přesměrován na základě přijatého štítku.
Podívejme se na poslední tvrzení v praxi:
Všimněte si, že přidělené štítky se od sebe liší kvůli režimu přidělování štítků na prefiku, který je ve výchozím nastavení povolen. Připojené trasy vyžadují vyhledávání v tabulce ARP, protože není možné určit nezbytné informace L2 z příchozího štítku; Podobné pozorování platí pro agregované trasy. Paket do 1.1.1.1/32 však lze předat do dalšího chmele bez zapojení směrovací tabulky:
Příběh 2: neobvyklá smyčka
Další zajímavé chování souvisí s „nesprávným“ nastavením masky zpětné smyčky. Pro adresování zpětné smyčky je běžné používat masku /32. A vlastně, proč platit víc? Při nastavování obvyklé masky /24 na lavici se mi však nejednou ukázaly prsty příliš tlusté pro klávesnici. Následky nemusí být na první pohled patrné, což následně komplikuje hledání chyb. Udělejme změnu v našem diagramu:
Nic významného, že? Naše LSP však již zkolabovala:
Důvodem odmítnutí je absence odpovídajícího štítku na P. Možná byla trasa přenesena nesprávně?
Ne, vše je přesně tak, jak jsme zamýšleli, až na absenci štítku v CEF. LDP je zodpovědný za štítky, takže se podívejme, co přesně P přijímá z PE1:
Označení pro 2.2.2.0/24 je správné – je implicitní-null. Заметили уже что-либо необычное?
Síťové masky se neshodují! OSPF ve výchozím nastavení ignoruje masky Loopback jiné než hostitelská maska a nadále inzeruje /32. LDP na druhé straně hraje podle rozumných pravidel a distribuuje přesně to, co je nakonfigurováno. P nemůže odpovídat trase z žebra k štítku v lib, takže neexistuje žádný odchozí štítek. Lék je docela jednoduchý, zvláště pokud jste strávili dost času s OSPF v laboratoři:
Příběh 3: zrušená smyčka
Překryvná schémata VPN obvykle používají zpětnou smyčku jako další skok BGP. Kromě zřejmých důvodů (balancování, tolerance transportních chyb atd.) existuje i závažnější důvod nepoužívat fyzické rozhraní pro uzel L3VPN – PHP. PE2, umístěný jeden uzel od PE1, nezmění štítky pro pakety směrem k 192.168.23.2; místo toho odstraní horní štítek, protože P inzeruje pro svou připojenou trasu implicitní hodnotu null.
V důsledku toho by v případě L3VPN směrovač P obdržel paket se štítkem VPN na vrcholu zásobníku, takže by byl paket zahozen nebo bychom viděli skutečné zázraky hodné Bradavic.
Co když nemůžete použít zpětnou smyčku k vytvoření sousedství BGP? Upřímně řečeno, jediný scénář, který mě napadá, je velmi zvláštní problém na úrovni CCIE, takže tato diskuse je docela abstraktní. Tak či onak je v tomto případě nutné zajistit, aby router P nepovažoval adresu PE1 za přímo spojenou. Nový IOS používá trasy na adresy svých rozhraní v RIB /32 (říká se mu Local route), ale tyto prefixy nespadají do OSPF. Nicméně OSPF inzeruje /32 adresy rozhraní v případě P2M:
Voila! Položky v OSPF RIB a v tabulce LDP jsou vytvořeny, takže LSP opět funguje:
Závěr
V tomto článku jsme probrali několik charakteristik sítě MPLS obecně: fungování PHP, „špatnou“ konfiguraci zpětné smyčky s OSPF, důsledky takového žertu a scénář pro ty, kteří jsou posedlí CCIE+. Doufám, že sis to užil ne hluboko, nepřepínejte!
