Laboratoř MPLS L3VPN nepingá? Zkontrolujte těchto pět bodů

Dva zákaznické směrovače, dvojice směrovačů poskytovatele a ping, který zemře bez chybové zprávy. V malé laboratoři MPLS L3VPN sedí závada téměř vždy na jednom z pěti kontrolních bodů a každý z nich má příkaz, který buď ukáže, že závislost funguje, nebo že chybí. Chybou je restartovat BGP při každém selhání pingu místo toho, abyste závislosti testovali popořadě. Když skočíte rovnou do konfigurace VRF, můžete strávit hodinu na problému, který začal nevyřešeným next hopem o dvě zařízení dál.

Seznam procházejte zdola nahoru. Kontrolní bod, který projde, zůstává v pořádku, a první selhání je to, které stojí za ladění.

První kontrolní bod: směrovače PE na sebe dosáhnou

Každý PE potřebuje trasu k loopbacku druhého PE a tato trasa se musí rozložit přes něco skutečného. Zvyklostí je použít protokol vnitřní brány, ale statická trasa funguje také, pokud rekurzivní vyhledání skončí na živé sousednosti. Na zařízeních ve stylu IOS vám show ip route 10.0.0.2 a po něm show ip cef 10.0.0.2 řekne, zda prefix existuje a zda má vyřešenou sousednost. Trasa v tabulce bez sousednosti za sebou není dosažitelnost.

Kontrolujte oba směry. Nesouměrné ceny IGP, pasivní rozhraní na špatné straně nebo distribuční seznam, který filtruje loopback, každý z nich rozbije jen jeden směr a jeden směr stačí k zabití relace. Pokud loopbacky odpovídají na ping, ale relace BGP zůstává ve stavu Active, podívejte se na zdroj aktualizací, než se dotknete čehokoli jiného.

Druhý kontrolní bod: existuje cesta se značkami

Trasa IP k vzdálenému loopbacku nedokazuje, že transport vtlačí značku. V návrhu s LDP ověřte, že vzdálený loopback má místní i vzdálenou vazbu a že odchozí značka je ve forwardovací tabulce. show mpls ldp bindings 10.0.0.2 32 ukáže dvojice značek a show mpls forwarding-table 10.0.0.2 ukáže, co linková karta skutečně vloží. Když druhý příkaz hlásí „no label“ nebo posílá paket do IP, transport nenese provoz VPN tak, jak návrh předpokládá.

Rozdíl plyne z toho, jak MPLS odděluje forwardovací stav od cílových prefixů, což je model popsaný v RFC 3031. Pokud vaše laboratoř používá RSVP-TE nebo značky sousedící s BGP místo LDP, zkontrolujte stav onoho mechanismu; předpokládat, že LDP distribuuje každou značku underlay, je častý způsob, jak honit fantomovou chybu. Přerušená cesta se značkami se obvykle projeví později jako trasa VPN, která je přítomná, ale nepoužitelná.

Třetí kontrolní bod: trasa VPN dorazila vcelku

Dívejte se na trasu VPNv4 nebo VPNv6 pro přesný zákaznický prefix, ne na souhrn relace. show bgp vpnv4 unicast all 10.10.1.0/24 má ukázat rozlišovač trasy, next hop nastavený na vzdálený loopback PE a značku. Pokud prefix chybí, prvním podezřelým je exportní politika na výchozím PE nebo importní politika na přijímajícím PE a obvyklým viníkem bývají route targety.

Kontrolu route targetů čtěte odděleně od příjmu v BGP. Trasa může dorazit se správným next hopem a přesto neskončit ve VRF, protože importní target nesouhlasí. Na přijímajícím PE je show ip route vrf CUSTOMER 10.10.1.0 ten správný test; tabulka BGP jen dokazuje, že trasa prošla řídící rovinou.

Čtvrtý kontrolní bod: rozhraní je ve VRF

Definice VRF s rozlišovačem trasy a route targety nepřesune do ní žádné rozhraní. Rozhraní směrem k CE potřebuje přiřazení VRF a show ip vrf interfaces nebo show ip interface brief má uvést, že je u správné instance. To je kontrolní bod, kde se zkopírovaná konfigurace nejčastěji pokazí, protože blok VRF vypadá úplně, zatímco rozhraní stále sedí v globální tabulce.

Potom ověřte, že se PE naučil místní zákaznický prefix do oné VRF a že CE má cestu zpět přes připojení. Statická výchozí trasa na CE směrem k PE pro laboratoř stačí, pokud VRF na PE má trasu do sítě LAN na CE. Pokud chybí kterákoli polovina, ping selže dřív, než se vloží jakákoli značka.

Pátý kontrolní bod: odpověď najde cestu domů

Vystopujte dopředný paket a potom vratný paket, protože používají různé tabulky. Na vstupním PE se má zákaznický zdroj přeložit uvnitř VRF na vzdálený prefix se vzdálenou značkou. Na výstupním PE se má cíl přeložit uvnitř stejné VRF na rozhraní směrem k CE. Ping odeslaný z PE samotného není důkaz: může odejít přes globální tabulku nebo jinou zdrojovou adresu, a proto je ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 testem, který je třeba spustit.

Hostitelské firewally, filtrování reverzní cesty a přístupové seznamy na CE stále platí. Pokud dopředná cesta funguje a odpověď umírá, problém je v trase nebo filtru na straně návratu, ne v transportu MPLS.

U každého kontrolního bodu si veďte jednořádkový záznam, který pojmenuje první závislost, jež selhala. Ten záznam promění „zákazník nemůže pingnout“ ve konkrétní otázku o dosažitelnosti, stavu značek, importu tras, členství rozhraní nebo zpáteční cestě a zabrání tomu, aby příští ladění opakovalo stejných pět příkazů ve stejném pořadí.