Sesiune BGP activă, calea clientului ruptă: MPLS peste DMVPN

Peeringul este activ de săptămâni, numărul de prefixe pare corect și, totuși, traficul unui client ia în continuare drumul lung sau nu ajunge niciodată. Două lucruri diferite sunt judecate de același indicator. O sesiune BGP raportează că doi peers pot schimba mesaje printr-o conexiune TCP; ea nu spune nimic despre capacitatea overlay-ului de a transporta un pachet etichetat pentru acel client anume.

Acel gol se vede cel mai ușor într-un proiect MPLS peste DMVPN, unde calea prin hub și calea directă prin spoke se pot comporta diferit din motive care nu au nicio legătură cu peeringul.

Ce dovedește de fapt sesiunea

BGP rulează peste TCP, deci fiecare peer are nevoie de o rută către adresa celuilalt capăt înainte să se întâmple orice altceva. Dacă alegeți un loopback ca acel capăt, ați creat o cerință de accesibilitate, nu o garanție de forwarding. Sesiunea poate apoi rămâne activă printr-o interfață pe care traficul clientului nu ar folosi-o niciodată.

Notați patru fapte la ambele capete înainte de a trage concluzii: adresa sursă a sesiunii, adresa de destinație, contextul de rutare în care se află și ce interfață ar alege kernelul sau routerul pentru acea pereche. Aceste fapte descriu planul de control. Pachetele clientului adaugă peste ele un VRF, o stivă de etichete și o mapare de overlay.

Patru mecanisme, nu unul

Documentația Cisco despre MPLS peste DMVPN separă clar componentele. MP-BGP distribuie etichetele de overlay ale clientului între echipamentele de la marginea furnizorului. MPLS folosește acele etichete pentru a selecta contextul de forwarding al unui pachet. NHRP mapează o adresă de overlay la capătul de transport de care are nevoie un tunel dinamic. IPsec protejează calea dintre peers acolo unde se aplică.

Oricare dintre cele patru poate fi corect în timp ce altul este greșit, iar combinația este cea care transportă traficul. Un schimb de rute se poate încheia în timp ce lipsește legarea etichetei pentru un VRF, în timp ce maparea NHRP indică o adresă de transport învechită sau în timp ce tunelul există, dar nicio politică nu permite pachetul interior. Niciuna dintre aceste condiții nu doboară sesiunea.

Comparați calea prin hub cu scurtătura, o variabilă pe rând

Fixați hostul sursă, hostul destinație și VRF-ul, apoi urmăriți același flux de două ori. Pe calea prin hub notați următorul hop, eticheta de serviciu care identifică contextul clientului îndepărtat și maparea overlay-la-transport folosită. Pe calea directă intenționată notați aceleași trei lucruri. Diferența dintre cele două liste este defecțiunea, sau absența ei.

Păstrați fluxul constant în timpul comparației. Schimbarea hostului sursă, a VRF-ului sau a destinației între observații produce două povești fără legătură, și acesta este cel mai obișnuit mod în care acest exercițiu eșuează.

Țineți testele de loopback în compartimentul lor

Un ping pornit din loopback-ul unui router este un test util și exersează un caz diferit de un flux de la un host. Adresa sursă aparține routerului, contextul său de rutare poate fi global în loc de VRF, iar calea de răspuns poate diferi de cea pe care ar lua-o un prefix de client. Așadar loopback-ul care răspunde și aplicația care funcționează pe scurtătură sunt rezultate separate, și doar al doilea descrie clientul.

Testați ambele, apoi etichetați-le separat în note. Când nu sunt de acord, ați învățat ceva concret despre unde diverge proiectul, și asta este mai mult decât vă va spune vreodată o singură bifă verde.

Afirmațiile despre versiune și despre defect au nevoie de propriile dovezi

Rapoartele de teren recomandă uneori schimbarea unei măști de host sau a unei adrese sursă BGP, iar astfel de rapoarte merită citite doar alături de defectul despre care au fost scrise și de versiunile afectate. O soluție de ocol dintr-o versiune nu este afirmația că arhitectura nu acceptă niciun prefix /32.

Folosiți documentație care corespunde fazei DMVPN, platformei și versiunii dumneavoastră, și amintiți-vă că un capitol poate acoperi mai multe aranjamente, inclusiv FlexVPN. Un exemplu dintr-un aranjament nu se transferă în tăcere la altul. Alegeți capetele sesiunii pentru proiectul planului de control de care aveți nevoie cu adevărat, apoi verificați separat calea de forwarding a clientului, pentru că rescrierea fiecărei măști de loopback nu înlocuiește aflarea sarcinii care a eșuat.