BGP sesija veikia, kliento kelias sužlugdytas: MPLS per DMVPN

Peeringas veikia jau savaites, prefiksų skaičius atrodo teisingas, o vieno kliento srautas vis tiek renkasi ilgą kelią arba niekada neatvyksta. Tas pats rodiklis vertina du skirtingus dalykus. BGP sesija praneša, kad du peerai gali apsikeisti pranešimais TCP ryšiu; ji nieko nesako apie tai, ar perdanga gali perduoti pažymėtą paketą būtent tam klientui.

Šią spragą lengviausia pastebėti MPLS per DMVPN architektūroje, kur kelias per hub ir tiesioginis spoke kelias gali elgtis skirtingai dėl priežasčių, neturinčių nieko bendra su peeringu.

Ką sesija iš tikrųjų įrodo

BGP veikia per TCP, todėl kiekvienam peerui reikia maršruto į kito galo adresą, kol gali įvykti kas nors kita. Jei tokiu galu pasirenkate loopback, jūs sukūrėte pasiekiamumo reikalavimą, o ne perdavimo garantiją. Tada sesija gali likti aktyvi per sąsają, kurios kliento srautas niekada nenaudotų.

Prieš darydami išvadas užrašykite keturis faktus abiejuose galuose: sesijos šaltinio adresą, paskirties adresą, maršrutizavimo kontekstą, kuriame ji yra, ir kurią sąsają branduolys ar maršrutizatorius pasirinktų tai porai. Šie faktai aprašo valdymo plokštumą. Kliento paketai ant jų prideda VRF, žymų krūvą ir perdangos susiejimą.

Keturi mechanizmai, o ne vienas

Cisco dokumentacija apie MPLS per DMVPN aiškiai atskiria dalis. MP-BGP paskirsto kliento perdangos žymas tarp paslaugų teikėjo krašto įrenginių. MPLS naudoja tas žymas paketo perdavimo kontekstui parinkti. NHRP susieja perdangos adresą su transporto galu, kurio reikia dinaminiam tuneliui. IPsec apsaugo peer kelią ten, kur tai taikoma.

Bet kuris iš keturių gali būti teisingas, kai kitas neteisingas, ir būtent derinys perduoda srautą. Maršrutų mainai gali baigtis, kai vienos VRF žymos susiejimo trūksta, kai NHRP susiejimas rodo į pasenusį transporto adresą arba kai tunelis egzistuoja, bet jokia politika neleidžia vidinio paketo. Nė viena iš šių sąlygų nenumeta sesijos.

Palyginkite kelią per hub su trumpiniu, po vieną kintamąjį

Užfiksuokite šaltinio hostą, paskirties hostą ir VRF, tada du kartus atsekite tą patį srautą. Kelyje per hub užrašykite kitą šuolį, paslaugos žymą, identifikuojančią nuotolinį kliento kontekstą, ir naudojamą perdangos į transportą susiejimą. Numatytoje tiesioginėje kelyje užrašykite tuos pačius tris dalykus. Skirtumas tarp abiejų sąrašų ir yra gedimas, arba jo nebuvimas.

Palyginimo metu palaikykite srautą pastovų. Šaltinio hosto, VRF ar paskirties pakeitimas tarp stebėjimų sukuria dvi nesusijusias istorijas, ir tai yra dažniausias būdas, kaip šis pratimas nepavyksta.

Loopback testus laikykite atskiroje dalyje

Ping iš maršrutizatoriaus loopback yra naudingas testas, ir jis tikrina kitokį atvejį nei srautas iš hosto. Šaltinio adresas priklauso maršrutizatoriui, jo maršrutizavimo kontekstas gali būti globalus, o ne VRF, ir atsakymo kelias gali skirtis nuo to, kuriuo eitų kliento prefiksas. Todėl atsakantis loopback ir programa, veikianti per trumpinį, yra atskiri rezultatai, ir tik antrasis apibūdina klientą.

Išbandykite abu, tada pažymėkite juos atskirai savo užrašuose. Kai jie nesutampa, sužinojote ką nors konkretaus apie tai, kur architektūra nukrypsta, ir tai yra daugiau, nei kada nors pasakys viena žalia varnelė.

Versijos ir defekto teiginiams reikia savo įrodymų

Lauko ataskaitos kartais rekomenduoja pakeisti hosto kaukę arba BGP šaltinio adresą, ir tokias ataskaitas verta skaityti tik kartu su defektu, apie kurį jos parašytos, ir leidimais, kuriems jis turėjo įtakos. Vieno leidimo apėjimo būdas nėra teiginys, kad architektūra nepalaiko jokio /32 prefikso.

Naudokite dokumentaciją, atitinkančią jūsų DMVPN fazę, platformą ir leidimą, ir atminkite, kad vienas skyrius gali apimti kelias konfigūracijas, įskaitant FlexVPN. Vienos konfigūracijos pavyzdys tyliai nepersikelia į kitą. Pasirinkite sesijos galus pagal valdymo plokštumos architektūrą, kurios iš tikrųjų reikia, o tada atskirai patikrinkite kliento perdavimo kelią, nes kiekvienos loopback kaukės perrašymas nepakeičia išsiaiškinimo, kuri užduotis nepavyko.