Unele rute L2VPN dispar după ce adăugați reflectoare de rută

Sesiunile rămân active, IGP este stabil și totuși câteva rute L2VPN nu apar niciodată pe două din cele patru margini ale furnizorului. Acest tipar aparține unei probleme de reflexie, nu uneia de transport, pentru că o sesiune ruptă eșuează complet, în timp ce o graniță de reflexie reutilizată eșuează selectiv. Inelul fizic nu are nicio legătură; graful logic de distribuție este locul unde s-au oprit acele rute. Găsirea acelui punct nu cere reconstruirea planului de control.

Pierderea este selectivă, ceea ce îngustează căutarea

Patru margini de furnizor pe un inel fizic au nevoie de șase sesiuni logice pentru o plasă completă, fiindcă fiecare router se împerechează cu ceilalți trei. Acele sesiuni merg pe transportul rutat, așa că cablarea nu spune nimic despre câte adiacențe există sau care dintre ele reflectă. Când două margini pierd un anumit set de prefixe în timp ce tot restul converge, cablul nu este suspectul.

Pierderea selectivă indică prevenirea buclelor, politica sau direcția relației, unde unele rute trec o graniță, iar altele sunt aruncate pe drum. Pierderea totală indică sesiunea sau familia de adrese. Să decizi pe care dintre cele două o vezi este primul pas util și costă o singură comandă.

Ce schimbă de fapt reflexia

Reflexia rutelor relaxează regula că un vorbitor iBGP nu poate reanunța o rută învățată de la alt vorbitor iBGP. RFC 4456 exprimă excepția prin relația dintre vorbitor și sursa rutei, iar direcția acelei relații contează mai mult decât sugerează majoritatea rezumatelor. O rută învățată de la un client poate fi reflectată către alți clienți și către neclienți, în timp ce o rută învățată de la un neclient poate fi reflectată doar către clienți. Citiți asimetria de două ori, pentru că explică modul în care adăugarea unei relații de client poate ascunde o eroare de proiectare: deschide o cale pe care topologia nu a intenționat-o niciodată.

Atributul CLUSTER_LIST înregistrează istoricul reflexiei, iar un reflector care își găsește propriul ID de cluster în acea listă trebuie să ignore anunțul. Aceasta este prevenirea buclelor și este și mecanismul care șterge rute atunci când identificatorii sunt reutilizați din greșeală. ORIGINATOR_ID joacă un rol înrudit, numind routerul care a anunțat ruta prima dată.

ID-urile de cluster reutilizate sunt modul în care rutele dispar

O rețea mică invită la o scurtătură: dați fiecărui router un ID de cluster egal cu loopback-ul său, adăugați mai târziu încă un reflector și reutilizați un loopback existent pentru că este la îndemână. Dacă acel identificator apare acum în două etape de reflexie independente, a doua etapă își vede propriul ID în CLUSTER_LIST și aruncă ruta. Nimic nu înregistrează o eroare, pentru că aruncarea este răspunsul corect la o buclă.

Reflectoarele redundante care deservesc un singur cluster sunt excepția legitimă: împart un ID intenționat, astfel încât oricare dintre ele să poată deservi aceiași clienți. Identificatorul trebuie să corespundă proiectării reflexiei și nu să distingă numele șasiurilor.

Desenați graful dorit înainte de a atinge orice configurație: cine originează prefixul, ce relație de client permite prima reflexie, care reflector îl duce la etapa următoare și unde se află ultimul client. Fiecare salt din acel graf este un loc unde un identificator reutilizat, o relație de client lipsă sau un filtru de politică pot opri ruta. Cu graful desenat, o rută lipsă are o locație în loc de un mister.

Rezistați tentației de a face client fiecare vecin

Reparația rapidă pentru o rută lipsă este să faceți fiecare vecin client al fiecărui reflector. Propagarea revine, iar proiectarea nu vă mai spune nimic: multiplică rutele pe care le poartă fiecare vorbitor și, în același timp, ascunde care relație ar fi trebuit să facă treaba.

O rețea mică are de obicei nevoie de una din două forme. O plasă iBGP completă înseamnă șase sesiuni pentru patru routere, fără nicio reflexie, iar o pereche desemnată de reflectoare care deservește marginile rămase este cealaltă. Ambele sunt mai ușor de gândit decât o plasă parțială în care fiecare router reflectă puțin. Alegeți forma după scară și comportamentul la defect, nu după diagrama de cablare.

Verificați familia de adrese înainte de a da vina pe reflexie

O sesiune TCP pe portul 179 dovedește că cei doi vorbitori pot vorbi, și nimic despre dacă familia de adrese VPN a schimbat măcar o rută. Stabiliți starea sesiunii, apoi familia, apoi prefixul individual.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Cele trei ieșiri separă o problemă de adiacență de una de schimb și de una de prefix lipsă. Dacă familia nu arată niciun prefix, inspectați starea de activare și politica de export a vecinului înainte de a privi reflexia. Dacă prefixele apar pe o margine dar nu pe alta, comparați lista de clustere și originatorul pe partea receptoare, apoi parcurgeți graful din secțiunea anterioară.

Țineți accesibilitatea următorului salt și starea de forwarding în afara acelei verificări. O rută reflectată cu un următor salt inaccesibil este prezentă și inutilizabilă, ceea ce arată ca o defecțiune a reflexiei până când priviți coloana următorului salt. Rezolvați următorul salt, confirmați intrarea de forwarding și abia apoi decideți dacă graful de distribuție are nevoie de încă un reflector.