Relácia BGP beží, cesta zákazníka je prerušená: MPLS cez DMVPN

Peering je aktívny už týždne, počet prefixov vyzerá správne, a predsa prevádzka jedného zákazníka stále ide dlhou cestou alebo vôbec nedorazí. Rovnaký indikátor posudzuje dve rôzne veci. Relácia BGP hlási, že dvaja peery si môžu vymieňať správy cez spojenie TCP; už ale nehovorí nič o tom, či overlay dokáže preniesť označený paket práve pre tohto zákazníka.

Túto medzeru je najlepšie vidieť v návrhu MPLS cez DMVPN, kde sa cesta cez hub a priama cesta cez spoke môžu správať rôzne z dôvodov, ktoré s peeringom nemajú nič spoločné.

Čo relácia skutočne dokazuje

BGP beží cez TCP, takže každý peer potrebuje trasu k adrese druhého konca, kým sa môže stať čokoľvek ďalšie. Ak ako tento koniec zvolíte loopback, vytvorili ste požiadavku na dosiahnuteľnosť, nie záruku forwardovania. Relácia potom môže zostať aktívna cez rozhranie, ktoré by zákaznícka prevádzka nikdy nepoužila.

Pred vyvodzovaním záverov si na oboch koncoch poznamenajte štyri skutočnosti: zdrojovú adresu relácie, cieľovú adresu, kontext smerovania, v ktorom spočíva, a ktoré rozhranie by jadro alebo smerovač pre túto dvojicu zvolilo. Tieto skutočnosti opisujú riadiacu rovinu. Zákaznícke pakety k nim pridávajú VRF, zásobník štítkov a mapovanie overlaya.

Štyri mechanizmy, nie jeden

Dokumentácia Cisco k MPLS cez DMVPN jasne oddeľuje časti. MP-BGP distribuuje zákaznícke overlay štítky medzi zariadeniami na okraji poskytovateľa. MPLS používa tieto štítky na výber kontextu forwardovania paketu. NHRP mapuje overlay adresu na transportný koniec, ktorý dynamický tunel potrebuje. IPsec chráni cestu medzi peermi tam, kde sa uplatní.

Ktorýkoľvek zo štyroch môže byť správny, zatiaľ čo iný je nesprávny, a kombinácia je to, čo nesie prevádzku. Výmena trás sa môže dokončiť, zatiaľ čo väzba štítku pre jedno VRF chýba, zatiaľ čo mapovanie NHRP ukazuje na zastaranú transportnú adresu, alebo zatiaľ čo tunel existuje, ale žiadna politika vnútorný paket nepovoľuje. Žiadna z týchto podmienok reláciu nezhodí.

Porovnajte cestu cez hub so skratkou, vždy jednu premennú

Zafixujte zdrojový host, cieľový host a VRF a potom sledujte ten istý tok dvakrát. Na ceste cez hub si všimnite ďalší hop, servisný štítok, ktorý identifikuje vzdialený zákaznícky kontext, a používané mapovanie overlaya na transport. Na zamýšľanej priamej ceste si všimnite tie isté tri veci. Rozdiel medzi oboma zoznamami je porucha, alebo jej neprítomnosť.

Udržiavajte tok počas porovnávania konštantný. Zmena zdrojového hosta, VRF alebo cieľa medzi pozorovaniami vytvára dva nesúvisiace príbehy, a to je najčastejší spôsob, akým tento postup zlyhá.

Nechajte loopback testy vo vlastnom oddelení

Ping odoslaný z loopbacku smerovača je užitočný test a precvičuje iný prípad než tok z hosta. Zdrojová adresa patrí smerovaču, jeho kontext smerovania môže byť globálny namiesto VRF a cesta odpovede sa môže líšiť od tej, ktorou by šiel zákaznícky prefix. Preto sú loopback, ktorý odpovedá, a aplikácia, ktorá funguje cez skratku, oddelené výsledky, a iba ten druhý opisuje zákazníka.

Otestujte oboje a potom ich v poznámkach označte oddelene. Keď sa rozchádzajú, dozvedeli ste sa niečo konkrétne o tom, kde sa návrh odkláňa, čo je viac, než vám kedy povie jediná zelená fajka.

Tvrdenia o verzii a o poruche potrebujú vlastné dôkazy

Terénne správy niekedy odporúčajú zmeniť masku hosta alebo zdrojovú adresu BGP a takéto správy stoja za prečítanie len vedľa poruchy, o ktorej boli napísané, a vydaní, ktoré zasiahla. Obchádzka z jedného vydania nie je tvrdením, že architektúra nepodporuje žiadny prefix /32.

Používajte dokumentáciu zodpovedajúcu vašej fáze DMVPN, platforme a vydaniu a pamätajte, že jedna kapitola môže pokrývať viacero usporiadaní vrátane FlexVPN. Príklad z jedného usporiadania sa na iné neprenáša ticho. Zvoľte konce relácie pre návrh riadiacej roviny, ktorý skutočne potrebujete, a potom oddelene overte zákaznícku cestu forwardovania, pretože prepisovanie každej loopback masky nenahrádza zistenie, ktorá úloha zlyhala.