Potřebuje VPNv4 ve jádru MPLS? Ne nutně

BGP VPNv4 vyjednává kontext distribuce tras, nikoli cestu předávání. Oddělte import, rozlišení dalšího skoku a zapouzdření, které můžete provozovat.

Zapnutí adresové rodiny VPNv4 mezi dvěma směrovači vytvoří jen kontext distribuce tras a nic víc. Neinstaluje cestu předávání a neříká, které zapouzdření přenese zákaznický paket do vzdáleného koncového bodu. Jakmile se tyto dva fakty oddělí, otázka „potřebuje toto ve jádru MPLS“ se změní na užší a zodpověditelnou otázku o datové rovině, kterou platforma podporuje.

Co adresová rodina ve skutečnosti vyjednává

Multiprotokolové BGP přenáší informace o dosažitelnosti síťové vrstvy VPNv4 pod AFI 1 a SAFI 128 a každý záznam spojuje rozlišovač trasy s prefixem a štítkem. Relace vyjednává, že obě strany umějí tyto informace kódovat a dekódovat. Co nevyjednává, je datová rovina. Vše po tomto odstavci se týká předávání a nic z toho není vyřešeno vzestupem relace.

Úspěšná relace je tedy důkazem schopnosti řídicí roviny, ne předávání. Směrovač může držet tisíce záznamů VPNv4 a přesto zahodit každý zákaznický paket, a právě proto se tyto dvě třídy poruch na prvním místě pletou.

Všimněte si štítku v NLRI. Je to servisní štítek vázaný na prefix uvnitř VRF a má roli v předávání, jakmile paket dorazí do výstupního koncového bodu. Zda jej čte nějaké tranzitní zařízení, je samostatné designové rozhodnutí.

Příjem, import a předávání jsou tři kroky

Příjem trasy, povolení ji používat a schopnost s ní předávat vykonávají různé části zařízení. BGP ukládá to, co slyší; zásady importu a shoda cíle trasy rozhodují, které VRF ji může zvažovat; poté musí rovina předávání přeložit inzerovaný další skok na něco, co skutečně dokáže poslat na drát.

Step in the chainWhat has to be trueHow it fails quietly
NLRI exchangeBoth speakers negotiate the VPNv4 capabilitySession stays up while the family is never activated
Import eligibilityA route target on the received route matches the VRF import policyThe route exists in the table but never enters the VRF
Next-hop resolutionThe advertised next hop resolves to a usable tunnel or label pathBest path is selected, then marked unreachable or unusable
EncapsulationThe egress endpoint can decapsulate what the ingress producedPackets arrive and are discarded for a format mismatch

Právě v tomto prostředním kroku žijí nejpřekvapivější poruchy. Trasa může být v tabulce BGP, platná a dokonce nejlepší, zatímco tabulka tras VRF zůstává prázdná, protože žádný cíl trasy neodpovídal seznamu importu. Nic nezaznamená chybu protokolu, protože žádná chyba protokolu nenastala.

Poslední krok je místem, kde se ukazuje podpora platformy. Další skok dostupný v podkladové síti není automaticky rozlišitelný jako transport služby VPN a zařízení může vyžadovat konkrétní typ tunelu, konkrétní operaci se štítkem, nebo obojí. Čtení stavu rozlišení je informativnější než čtení počtu tras.

IP jádro může nést zásobník, který nikdy nepřepíná

Rozdíl, který stojí za to zachovat, je mezi „jádro neprovozuje MPLS“ a „v službě nikde neexistuje štítek“. To jsou různá tvrzení a jen první se týká tranzitních zařízení. RFC 4023 definuje přenos MPLS přes tunely IP nebo GRE, a to je mechanismus, který činí druhé tvrzení možným na čistě IP jádře.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Tranzitní směrovače předávají podle vnějšího cíle IP a nepotřebují ani zákaznické prefixy, ani nativní přepínání štítků. Na vzdáleném konci se vnější tunel odstraní a servisní štítek pokračuje ve své práci. Jádro přeneslo neprůhledný užitečný náklad, což je přesně to, v čem je IP síť silná.

Co vám tento návrh nedává, je univerzální záruka. Není důkazem, že každý směrovač rozliší každý další skok VPNv4 přes jakékoli rozhraní GRE, a není důvodem smazat fungující nativní konfiguraci MPLS. Je protipříkladem univerzálnímu tvrzení a praktická otázka zůstává lokální pro platformu. Zapište tuto otázku jako omezení platformy, nikoli jako pravidlo protokolu.

Projděte řetězec na zařízení, dokud se nerozbije

Začněte u přijaté trasy a zastavte se u prvního kroku, který selže, protože pozdější kroky nelze diagnostikovat, dokud je dřívější rozbitý. Čtyři příkazy pokrývají většinu toho v typické implementaci.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Čtěte je jako posloupnost, ne jako čtyři nezávislé kontroly. První potvrzuje, že rodina je aktivní a soused vyměňuje trasy; druhý ukazuje, zda prefix dorazil s použitelným dalším skokem; třetí dokazuje způsobilost k importu; čtvrtý ukazuje, zda k němu rovina předávání připojila štítek nebo tunel.

Poté otestujte cestu pracovní zátěže v obou směrech, s MTU, které přežije zapouzdření. GRE přidává bajty záhlaví a cesta, která projde malými sondami, může selhat u paketů plné velikosti jen v jednom směru, což vypadá jako porucha aplikace, ne transportu.

Dvě provozní poznámky uzavírají smyčku. GRE je zapouzdření, ne důvěrnost, takže nedůvěryhodná tranzitní síť potřebuje navrch podporované bezpečnostní uspořádání, ne předpoklad. A poznamenejte si, které zapouzdření platforma skutečně podporuje, ještě před návrhovou revizí, protože tato jediná odpověď rozhoduje, zda je čistě IP jádro platná volba, nebo plán, který nedokáže předávat.

Související články