EVPN funcționează, dar serviciul nu: patru puncte de verificare

Atingerea adresei VTEP îndepărtate dovedește că rețeaua de bază transportă pachete, și asta este tot ce dovedește. Serviciul chiriașului are nevoie de o sesiune BGP EVPN cu familia de adrese corectă, un VNI local conectat și operațional, o rută originată și un import la capătul îndepărtat. Acestea sunt patru puncte de verificare separate, fiecare cu o altă reparație. A trata o rețea de bază verde drept pregătire a serviciului este cel mai frecvent mod în care o implementare EVPN se blochează.

Citiți-le în ordine și opriți-vă la primul care nu este ceea ce așteaptă proiectul. Punctele de verificare ulterioare nu pot compensa o defecțiune anterioară.

Punctul de verificare 1: transportul către VTEP

Începeți cu accesibilitatea între adresele loopback folosite ca surse VTEP. Ruta trebuie să existe în rețeaua de bază, calea trebuie să fie permisă, inclusiv orice cerință de încapsulare, iar calea de retur trebuie să funcționeze. O rută care există dar este filtrată într-o singură direcție produce o defecțiune asimetrică ce pare intermitentă. Confirmați ambele direcții înainte de a continua.

Notați adresele sursă și destinație pe care le-ați verificat. Un pas ulterior care rezolvă următorul salt printr-o altă adresă este un test diferit, iar tratarea lor ca unul singur este modul în care un următor salt rezolvat este învinovățit pentru o defecțiune de transport.

Punctul de verificare 2: familia EVPN, nu numărul de sesiuni

O sesiune BGP stabilită nu înseamnă că familia de adrese EVPN a fost negociată. Uitați-vă la starea specifică familiei pentru vecin: dacă familia este activată, dacă a fost negociată cu partenerul și dacă sesiunea o transportă deloc. O sesiune activă pentru IPv4 unicast care nu a negociat niciodată EVPN nu arată nimic greșit într-un rezumat general al vecinilor, iar specificația de suprapunere EVPN tratează procedurile de serviciu și control ca aspecte separate de transport.

Verificați și adresa sursă a sesiunii. Un peering construit pe o adresă care nu este sursa VTEP este o neconcordanță de proiectare care așteaptă să explice o defecțiune de redirecționare.

Punctul de verificare 3: serviciul local este conectat

VNI local trebuie să fie conectat la bridge-ul sau VRF-ul care reprezintă chiriașul, iar platforma trebuie să îl raporteze ca operațional. Starea de apartenență folosită de modelul de replicare poate conta înainte de a fi învățat orice MAC de gazdă, așa că un tabel de puncte terminale gol nu este dovada că serviciul este oprit.

Apoi confirmați ce originează de fapt dispozitivul: ruta locală pentru acel VNI cu route target-urile specificate de proiectare. Un VNI conectat dar neanunțat produce un serviciu care există local și nicăieri altundeva.

Punctul de verificare 4: importul la receptor

Pe dispozitivul receptor, comparați route target-urile exportate și importate în locul VNI-urilor numerice. Un număr de VNI identic nu dovedește că instanța receptoare importă anunțul, iar un route target nepotrivit este invizibil într-o listă de VNI. Rezolvați următorul salt anunțat prin rețeaua de bază înainte de a avea încredere în intrarea de redirecționare. Apoi citiți starea de redirecționare a suprapunerii pentru serviciu, nu pentru dispozitiv în ansamblu.

Un tabel de parteneri poate reflecta și date de plan de date sau învățare a apartenenței specifice implementării. Citiți originea și contextul serviciului împreună cu ruta EVPN, în loc să tratați numărul de rânduri drept dovadă.

O înregistrare care parcurge calea

Păstrați o înregistrare pe serviciu: starea locală a VNI, vecinul EVPN și familia, ruta originată și rezultatul primit și importat. Parcurgeți acea înregistrare de la origine la instalare. Când ceva eșuează, înregistrarea spune care dintre cele patru puncte de verificare trebuie reparat, nu ce comandă trebuie încercată.

Adăugați momente temporale în timp ce faceți asta. Un import care apare la câteva minute după anunț este o chestiune de politică sau de convergență, în timp ce unul care nu apare niciodată este o chestiune de configurare, iar diferența este vizibilă doar dacă ați notat când ați privit.

Când VXLAN static este răspunsul corect

O cale de date VXLAN configurată static poate funcționa cu parteneri furnizați manual în timp ce tabelul EVPN rămâne gol. Nu este o implementare EVPN defectă, este un alt model de control. Decideți pe care o intenționează proiectarea înainte de a diagnostica un tabel gol ca defecțiune.

Un vecin IGP din rețeaua de bază oferă transport și nimic mai mult. Starea serviciului suprapunerii este un lucru separat de construit și un lucru separat de verificat.