Laboratorul MPLS L3VPN nu răspunde la ping? Verificați aceste cinci salturi

Două routere ale clientului, o pereche de echipamente provider edge și un ping care moare fără mesaj de eroare. Într-un laborator MPLS L3VPN mic, defectul se află aproape întotdeauna la unul dintre cele cinci puncte de control, iar fiecare are o comandă care arată fie că dependența funcționează, fie că lipsește. Greșeala este să repornești BGP de fiecare dată când pingul eșuează, în loc să testezi dependențele în ordine. Dacă sari direct la configurația VRF, poți petrece o oră pe o problemă care a început cu un next hop nerezolvat cu două echipamente mai departe.

Parcurgeți lista de jos în sus. Un punct de control care trece rămâne trecut, iar primul eșec este cel care merită depanat.

Punctul de control unu: PE-urile se ating între ele

Fiecare PE are nevoie de o rută către loopback-ul celuilalt PE, iar acea rută trebuie să se rezolve prin ceva real. Un interior gateway protocol este calea obișnuită, dar o rută statică funcționează la fel de bine atât timp cât căutarea recursivă ajunge pe o adjacency activă. Pe echipamentele de stil IOS, show ip route 10.0.0.2 urmat de show ip cef 10.0.0.2 arată dacă prefixul există și dacă în spatele lui se află o adjacency rezolvată. O rută în tabelă fără adjacency în spate nu este accesibilitate.

Verificați ambele direcții. Costurile IGP asimetrice, o passive interface pe partea greșită sau o distribute list care filtrează loopback-ul strică fiecare doar o direcție, iar o singură direcție este suficientă pentru a ucide sesiunea. Dacă loopback-urile răspund la ping dar sesiunea BGP stă în Active, uitați-vă la update source înainte de a atinge altceva.

Punctul de control doi: există o cale de etichete

O rută IP către loopback-ul îndepărtat nu dovedește că transportul va pune o etichetă. Într-un proiect LDP, confirmați că loopback-ul îndepărtat are o legătură locală și una îndepărtată, și că eticheta de ieșire apare în forwarding table. show mpls ldp bindings 10.0.0.2 32 arată perechile de etichete, iar show mpls forwarding-table 10.0.0.2 arată ce va pune de fapt line card-ul. Când a doua comandă nu arată nicio etichetă sau cade înapoi pe IP, transportul nu duce traficul VPN așa cum presupune proiectul.

Distincția vine din felul în care MPLS separă forwarding state de prefixele de destinație, modelul descris în RFC 3031. Dacă laboratorul folosește RSVP-TE sau etichete adiacente BGP în loc de LDP, verificați starea proprie a acelui mecanism; a presupune că LDP distribuie fiecare etichetă de sub-strat este o modalitate obișnuită de a urmări un bug fantomă. O cale de etichete ruptă apare de obicei mai târziu ca o rută VPN prezentă dar inutilizabilă.

Punctul de control trei: ruta VPN a sosit intactă

Uitați-vă la ruta VPNv4 sau VPNv6 pentru prefixul exact al clientului, nu la rezumatul sesiunii. show bgp vpnv4 unicast all 10.10.1.0/24 ar trebui să arate route distinguisher-ul, next hop-ul setat pe loopback-ul PE-ului îndepărtat și o etichetă. Dacă prefixul lipsește, politica de export de pe PE-ul de origine sau politica de import de pe PE-ul receptor este primul suspect, iar route target-urile sunt vinovatul obișnuit.

Citiți verificarea route target separat de recepția BGP. O rută poate sosi cu next hop-ul corect și totuși să nu ajungă în VRF pentru că import target-ul nu se potrivește. Pe PE-ul receptor, show ip route vrf CUSTOMER 10.10.1.0 este testul care contează; tabela BGP dovedește doar că ruta a traversat planul de control.

Punctul de control patru: interfața este în VRF

O definiție VRF cu route distinguisher și route target-uri nu mută nicio interfață în ea. Interfața către CE are nevoie de alocarea VRF, iar show ip vrf interfaces sau show ip interface brief ar trebui să o listeze sub instanța corectă. Acesta este punctul de control la care o configurație copiată greșește cel mai des, pentru că blocul VRF pare complet în timp ce interfața stă încă în tabela globală.

Apoi confirmați că PE-ul a învățat prefixul local al clientului în acea VRF și că CE-ul are o rută de întoarcere prin legătură. Un default static pe CE care indică PE-ul este suficient pentru un laborator, cu condiția ca VRF-ul PE-ului să aibă o rută către LAN-ul CE-ului. Dacă lipsește oricare dintre cele două jumătăți, pingul eșuează înainte ca vreo etichetă să fie pusă.

Punctul de control cinci: răspunsul își găsește drumul acasă

Urmăriți pachetul dus și apoi pachetul întors, pentru că folosesc tabele diferite. Pe PE-ul de intrare, sursa clientului trebuie să se rezolve în interiorul VRF-ului către prefixul îndepărtat cu eticheta îndepărtată. Pe PE-ul de ieșire, destinația trebuie să se rezolve în același VRF către interfața dinspre CE. Un ping pornit de pe PE-ul însuși nu este o dovadă: poate ieși prin tabela globală sau printr-o altă adresă sursă, și de aceea ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 este testul de rulat.

Firewall-urile gazdelor, reverse-path filtering și listele de acces de pe CE se aplică în continuare. Dacă drumul dus funcționează și răspunsul moare, problema este o rută sau un filtru pe partea de întoarcere, nu transportul MPLS.

Țineți o linie pe punct de control care numește prima dependență care a eșuat. Acea linie transformă plângerea că clientul nu poate face ping într-o întrebare concretă despre accesibilitate, starea etichetelor, importul de rute, apartenența interfeței sau drumul de întoarcere și împiedică următoarea sesiune de depanare să repete aceleași cinci comenzi în aceeași ordine.