Tunelul RSVP-TE este activ, dar L3VPN-ul clientului nu are cale

Două echipe pot avea dreptate în același timp când clientul raportează că VPN-ul este căzut, iar echipa de transport raportează că tunelul este în regulă. Un LSP cu inginerie de trafic și un MPLS L3VPN răspund la întrebări diferite: unul mută pachete etichetate prin nucleu, celălalt decide cărui context de rutare îi aparține un pachet. Când sunt confundate, discuția se învârte în cerc, pentru că fiecare parte măsoară un obiect diferit și ambele măsurători sunt valide.

Transportul activ și serviciul căzut este o stare normală

Un LSP poate fi stabilit, poate transporta trafic și poate fi vizibil în fiecare sistem de monitorizare, în timp ce serviciul clientului rămâne inutilizabil. Nimic din această combinație nu este contradictoriu, pentru că tunelul nu are o părere despre existența unui prefix îndepărtat, despre acceptarea lui de către o politică de import sau despre trecerea cadrelor prin circuitul de atașare.

Simptomul care dezvăluie de obicei confuzia este asimetric: pingurile din loopback-ul PE reușesc în timp ce un host din LAN-ul clientului nu primește nimic, sau invers. Notați ce adrese au funcționat înainte de a formula o teorie. Imediat ce observați că testați două obiecte diferite, pasul următor este să citiți stiva de etichete în loc să dezbateți care grafic este corect. Două adrese, doi proprietari și de obicei două persoane diferite care fiecare crede că cealaltă a stricat ceva.

Citiți stiva ca două responsabilități

Eticheta de jos aparține serviciului, iar eticheta de sus aparține căii. RFC 4364 descrie secvența simplu: mai întâi se impune eticheta rutei VPN, apoi acel pachet etichetat este tunelat către următorul salt BGP, unde un tunel de inginerie a traficului împinge propria etichetă deasupra.

La PE-ul îndepărtat, eticheta de serviciu selectează tratamentul, care poate fi o căutare în VRF sau o decizie de atașare. Acea etichetă nu poate fi înlocuită cu una care doar traversează nucleul, iar cele două nu sunt interschimbabile chiar și atunci când ambele apar în aceeași stivă pe aceeași interfață.

Ce demonstrează succesul RSVP și ce nu

RSVP-TE stabilește LSP cu rutare explicită, cu sau fără rezervări de resurse, ceea ce este o garanție concretă și utilă despre calea pe care un pachet o urmează prin nucleu. Nu este o afirmație despre rutele clientului, iar un nume de tunel configurat nu este deloc o rută.

Nici prezența RSVP nu oferă o promisiune de performanță de la un capăt la altul. Rezervarea de lățime de bandă pe un singur LSP nu spune nimic despre circuitul de atașare, linia de acces a clientului însuși sau comportamentul cozii la marginea îndepărtată. Tratarea ei ca garanție produce răspunsuri încrezătoare la întrebări pe care nimeni nu le-a pus. Dacă cerința este într-adevăr un angajament de lățime de bandă, el trebuie asamblat din piesele care îl impun cu adevărat, iar LSP-ul este doar mijlocul acelui lanț.

Verificați în ordine, apoi opriți-vă

Lucrați de la transport spre exterior și opriți-vă la primul pas care eșuează, pentru că fiecare pas ulterior presupune că cele anterioare au rezistat. Mai întâi confirmați că LSP-ul este stabilit și că intrarea de redirecționare pentru prefixul serviciului indică într-adevăr spre el. Apoi confirmați că ruta VPN există în tabela corectă, că legătura ei de etichetă este prezentă și că politica de import a acceptat-o. Apoi confirmați atașarea: interfața, încapsularea și, acolo unde se aplică, identificatorul VLAN care aparține acelui contract.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

Sintaxa comenzilor variază în funcție de platformă, așa că tratați cele patru linii ca cele patru întrebări și nu ca un script. Partea importantă este că fiecare dintre ele interoghează un obiect diferit, iar asta face ca o defecțiune să indice un proprietar anume.

Urmați o singură cerere permisă și păstrați dovezile bune

Încheiați cu o singură cerere reală a clientului, permisă de politică, și cu răspunsul ei. Un singur flux funcțional de la un capăt la altul rezolvă mai mult decât o pagină de citiri de contoare și exersează combinația, nu fiecare piesă izolat.

Când o etapă ulterioară eșuează, păstrați observația reușită a LSP-ului în loc să reconstruiți transportul. Reconstruirea unui tunel funcțional nu poate repara un prefix îndepărtat absent, o atașare VRF greșită sau o regulă de acces la destinație, și distruge dovada care vă spusese mai întâi că transportul era sănătos.