Tunel RSVP-TE beží, ale zákaznícka L3VPN nemá cestu

Dva tímy môžu mať pravdu súčasne, keď zákazník hlási, že VPN nefunguje, a dopravný tím hlási, že tunel je v poriadku. LSP s traffic engineeringom a MPLS L3VPN odpovedajú na rôzne otázky: jedno prenáša označené pakety cez jadro, druhé rozhoduje, do akého smerovacieho kontextu paket patrí. Keď sa oboje zmieša, debata sa točí v kruhu, pretože každá strana meria iný objekt a obe merania sú platné.

Doprava beží a služba nie – to je normálny stav

LSP môže byť zriadený, prenášať prevádzku a byť viditeľný v každom monitorovacom systéme, zatiaľ čo zákaznícka služba zostáva nepoužiteľná. Na tejto kombinácii nie je nič protirečivé, pretože tunel nemá názor na to, či vzdialený prefix existuje, či ho importná politika prijala alebo či pripojený okruh prepúšťa rámce.

Príznak, ktorý zvyčajne odhalí zmätok, je asymetrický: pingy z PE loopbacku prechádzajú, zatiaľ čo hostiteľ v zákazníckej LAN nedostane nič, alebo naopak. Zapíšte, ktoré adresy fungovali, skôr než vytvoríte teóriu. Hneď ako si všimnete, že testujete dva rôzne objekty, ďalším krokom je prečítať zásobník značiek, namiesto hádania sa, ktorý graf je správny. Dve adresy, dvaja vlastníci a zvyčajne dvaja rôzni ľudia, z ktorých každý verí, že ten druhý niečo pokazil.

Čítajte zásobník ako dve zodpovednosti

Spodná značka patrí službe a horná značka patrí ceste. RFC 4364 opisuje sled jednoducho: najprv sa vloží značka VPN trasy, potom sa tento označený paket tuneluje k ďalšiemu skoku BGP, kde tunel s traffic engineeringom pridá navrch svoju vlastnú značku.

Na vzdialenom PE vyberá značka služby spracovanie, ktoré môže byť vyhľadanie vo VRF alebo rozhodnutie o pripojení. Túto značku nemožno nahradiť značkou, ktorá iba prechádza jadrom, a obe nie sú zameniteľné, aj keď sa obe objavia v tom istom zásobníku na tom istom rozhraní.

Čo úspech RSVP dokazuje a čo nie

RSVP-TE zriaďuje LSP s explicitne určenou trasou, s rezerváciou prostriedkov alebo bez nej, čo je konkrétna a užitočná záruka o ceste, ktorou paket prechádza jadrom. Nie je to tvrdenie o zákazníckych trasách a nakonfigurovaný názov tunela nie je vôbec trasa.

Ani prítomnosť RSVP neprináša sľub výkonu od konca ku koncu. Rezervácia šírky pásma na jednom LSP nehovorí nič o pripojenom okruhu, vlastnej prístupovej linke zákazníka ani o správaní fronty na vzdialenom okraji. Považovať to za záruku vedie k sebavedomým odpovediam na otázky, ktoré nikto nepoložil. Ak je požiadavka skutočne záväzkom na šírku pásma, musí sa zostaviť z dielov, ktoré ho skutočne vynucujú, a LSP je len stredom tohto reťazca.

Kontrolujte poporadí, potom prestaňte

Postupujte od dopravy smerom von a zastavte sa pri prvom kroku, ktorý zlyhá, pretože každý ďalší krok predpokladá, že predchádzajúce obstáli. Najprv potvrďte, že LSP je zriadený a že záznam preposielania pre prefix služby naň skutočne ukazuje. Potom potvrďte, že trasa VPN existuje v správnej tabuľke, že jej väzba značky je prítomná a že ju importná politika prijala. Potom potvrďte pripojenie: rozhranie, zapuzdrenie a tam, kde to platí, identifikátor VLAN, ktorý patrí k tejto zmluve.

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

Syntax príkazov sa líši podľa platformy, takže s týmito štyrmi riadkami zaobchádzajte ako so štyrmi otázkami, nie ako so skriptom. Dôležité je, že každý z nich sa dopytuje iného objektu, a práve preto zlyhanie ukazuje na konkrétneho vlastníka.

Sledujte jednu povolenú požiadavku a uchovajte dobré dôkazy

Skončite jedinou skutočnou zákazníckou požiadavkou povolenou politikou a jej odpoveďou. Jeden funkčný tok od konca ku koncu vyrieši viac než stránka odpočtov počítadiel a precvičí kombináciu, nie každý diel izolovane.

Keď neskoršia fáza zlyhá, uchovajte úspešné pozorovanie LSP namiesto prestavby dopravy. Prestavba funkčného tunela nemôže opraviť chýbajúci vzdialený prefix, nesprávne pripojenie VRF alebo pravidlo prístupu k cieľu a ničí dôkaz, ktorý vám pôvodne hovoril, že doprava je zdravá.