Tunel RSVP-TE běží, ale zákaznická L3VPN nemá cestu

Dva týmy mohou mít pravdu zároveň, když zákazník hlásí, že VPN nefunguje, a dopravní tým hlásí, že tunel je v pořádku. LSP s traffic engineeringem a MPLS L3VPN odpovídají na různé otázky: jedno přenáší značkované pakety přes jádro, druhé rozhoduje, do jakého směrovacího kontextu paket patří. Když se obojí slije, debata se točí v kruhu, protože každá strana měří jiný objekt a obě měření jsou platná.

Doprava běží a služba ne – to je normální stav

LSP může být zřízený, přenášet provoz a být viditelný v každém monitorovacím systému, zatímco zákaznická služba zůstává nepoužitelná. Na této kombinaci není nic protichůdného, protože tunel nemá názor na to, zda vzdálený prefix existuje, zda jej importní politika přijala nebo zda připojený okruh propouští rámce.

Příznak, který obvykle zmatek odhalí, je asymetrický: pingy z PE loopbacku procházejí, zatímco hostitel v zákaznické LAN nedostane nic, nebo naopak. Než si vytvoříte teorii, zapište, které adresy fungovaly. Jakmile si všimnete, že testujete dva různé objekty, je dalším krokem přečíst zásobník značek, místo abyste se hádali, čí graf je správný. Dvě adresy, dva vlastníci a obvykle dva různí lidé, z nichž každý věří, že ten druhý něco rozbil.

Čtěte zásobník jako dvě odpovědnosti

Spodní značka patří službě a horní značka patří cestě. RFC 4364 popisuje sled jednoduše: nejprve se vloží značka VPN trasy, poté se tento označený paket tuneluje k dalšímu skoku BGP, kde tunel s traffic engineeringem přidá navrch svou vlastní značku.

Na vzdáleném PE vybírá značka služby zpracování, což může být vyhledání ve VRF nebo rozhodnutí o připojení. Tuto značku nelze zaměnit za značku, která pouze prochází jádrem, a obě nejsou zaměnitelné, i když se obě objeví ve stejném zásobníku na stejném rozhraní.

Co úspěch RSVP dokazuje a co ne

RSVP-TE zřizuje LSP s explicitně určenou trasou, s rezervací prostředků nebo bez ní, což je konkrétní a užitečná záruka o cestě, kterou paket prochází jádrem. Není to tvrzení o zákaznických trasách a nakonfigurovaný název tunelu není vůbec trasa.

Ani přítomnost RSVP nepřináší slib výkonu od konce ke konci. Rezervace šířky pásma na jednom LSP neříká nic o připojeném okruhu, vlastní přístupové lince zákazníka ani o chování fronty na vzdáleném okraji. Považovat to za záruku vede k sebejistým odpovědím na otázky, které nikdo nepoložil. Pokud je požadavek skutečně závazkem na šířku pásma, musí se sestavit z dílů, které jej skutečně vynucují, a LSP je jen středem tohoto řetězce.

Kontrolujte popořadě, pak přestaňte

Postupujte od dopravy směrem ven a zastavte se u prvního kroku, který selže, protože každý další krok předpokládá, že předchozí obstály. Nejprve potvrďte, že LSP je zřízený a že záznam předávání pro prefix služby na něj skutečně ukazuje. Poté potvrďte, že trasa VPN existuje ve správné tabulce, že její vazba značky je přítomná a že ji importní politika přijala. Poté potvrďte připojení: rozhraní, zapouzdření a tam, kde to platí, identifikátor VLAN, který k této smlouvě patří.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

Syntaxe příkazů se liší podle platformy, takže s těmito čtyřmi řádky zacházejte jako se čtyřmi otázkami, ne jako se skriptem. Důležité je, že každý z nich se dotazuje jiného objektu, a právě proto selhání ukazuje na konkrétního vlastníka.

Sledujte jeden povolený požadavek a uchovejte dobré důkazy

Skončete jediným skutečným zákaznickým požadavkem povoleným politikou a jeho odpovědí. Jeden funkční tok od konce ke konci vyřeší víc než stránka odečtů čítačů a procvičí kombinaci, nikoli každý díl izolovaně.

Když pozdější fáze selže, uchovejte úspěšné pozorování LSP, místo abyste dopravu stavěli znovu. Přestavba funkčního tunelu nemůže opravit chybějící vzdálený prefix, špatné připojení VRF nebo pravidlo přístupu k cíli a ničí důkaz, který vám původně říkal, že doprava je v pořádku.