Relace BGP běží, cesta zákazníka je přerušená: MPLS přes DMVPN

Peering je aktivní už týdny, počet prefixů vypadá správně, a přesto provoz jednoho zákazníka stále jde dlouhou cestou nebo vůbec nedorazí. Stejný indikátor posuzuje dvě různé věci. Relace BGP hlásí, že dva peery si mohou vyměňovat zprávy přes spojení TCP; už ale neříká nic o tom, zda overlay dokáže přenést označený paket právě pro tohoto zákazníka.

Tuto mezeru je nejlépe vidět v návrhu MPLS přes DMVPN, kde se cesta přes hub a přímá cesta přes spoke mohou chovat různě z důvodů, které s peeringem nemají nic společného.

Co relace skutečně dokazuje

BGP běží přes TCP, takže každý peer potřebuje trasu k adrese druhého konce, než se může stát cokoli dalšího. Zvolíte-li jako tento konec loopback, vytvořili jste požadavek na dosažitelnost, nikoli záruku forwardingu. Relace pak může zůstat aktivní přes rozhraní, které by zákaznický provoz nikdy nepoužil.

Před vyvozováním závěrů si na obou koncích poznamenejte čtyři skutečnosti: zdrojovou adresu relace, cílovou adresu, kontext směrování, ve kterém spočívá, a které rozhraní by jádro nebo router pro tuto dvojici zvolilo. Tyto skutečnosti popisují řídicí rovinu. Zákaznické pakety k nim přidávají VRF, zásobník štítků a mapování overlaye.

Čtyři mechanismy, ne jeden

Dokumentace Cisco k MPLS přes DMVPN díly jasně odděluje. MP-BGP distribuuje zákaznické overlay štítky mezi zařízeními na okraji poskytovatele. MPLS používá tyto štítky k výběru kontextu forwardingu paketu. NHRP mapuje overlay adresu na transportní konec, který dynamický tunel potřebuje. IPsec chrání cestu mezi peery tam, kde se uplatní.

Kterýkoli ze čtyř může být správně, zatímco jiný je špatně, a kombinace je to, co nese provoz. Výměna tras se může dokončit, zatímco vazba štítku pro jedno VRF chybí, zatímco mapování NHRP ukazuje na zastaralou transportní adresu, nebo zatímco tunel existuje, ale žádná politika vnitřní paket nepovoluje. Žádná z těchto podmínek relaci neshodí.

Porovnejte cestu přes hub se zkratkou, vždy jednu proměnnou

Zafixujte zdrojový host, cílový host a VRF a poté sledujte stejný tok dvakrát. Na cestě přes hub si všimněte dalšího hopu, servisního štítku, který identifikuje vzdálený zákaznický kontext, a používaného mapování overlaye na transport. Na zamýšlené přímé cestě si všimněte stejných tří věcí. Rozdíl mezi oběma seznamy je závada, nebo její nepřítomnost.

Udržujte tok během srovnávání konstantní. Změna zdrojového hostu, VRF nebo cíle mezi pozorováními vytváří dva nesouvisející příběhy, a to je nejčastější způsob, jak tento postup pokazit.

Nechte loopback testy ve vlastním oddělení

Ping odeslaný z loopbacku routeru je užitečný test a procvičuje jiný případ než tok z hostu. Zdrojová adresa patří routeru, jeho kontext směrování může být globální místo VRF a cesta odpovědi se může lišit od té, kterou by vzal zákaznický prefix. Proto jsou loopback, který odpovídá, a aplikace, která funguje přes zkratku, oddělené výsledky, a jen ten druhý popisuje zákazníka.

Otestujte obojí a poté je v poznámkách označte odděleně. Když se rozcházejí, dozvěděli jste se něco konkrétního o tom, kde se návrh odchyluje, což je více, než vám kdy řekne jediná zelená fajfka.

Tvrzení o verzi a o závadě potřebují vlastní důkazy

Terénní zprávy občas doporučují změnit masku hostu nebo zdrojovou adresu BGP a takové zprávy stojí za přečtení jen vedle závady, o níž byly napsány, a vydání, která zasáhla. Obchvat z jednoho vydání není tvrzením, že každý prefix /32 architektura nepodporuje.

Používejte dokumentaci odpovídající vaší fázi DMVPN, platformě a vydání a pamatujte, že jedna kapitola může pokrývat několik uspořádání včetně FlexVPN. Příklad z jednoho uspořádání se na jiné nepřenáší tiše. Zvolte konce relace pro návrh řídicí roviny, který skutečně potřebujete, a potom odděleně ověřte zákaznickou cestu forwardingu, protože přepisování každé loopback masky nenahrazuje zjištění, která úloha selhala.