Hvorfor en QFX-MAC vises i EVPN men ikke i forwarding-tabellen

At finde en MAC i EVPN-databasen beviser, at den er annonceret eller modtaget som en rute, og intet ud over det. Forwarding-tabellen er en anden struktur, programmeret senere, så den samme MAC kan optræde i den ene og mangle i den anden, mens hver protokol opfører sig korrekt. Behandler man de to udgange som kopier af hinanden, sender det ingeniører efter en BGP-fejl, når det reelle hul er en importpolitik eller et uafklaret næste hop. Spørgsmålet, der er værd at stille, er ikke, om fabric kender MAC'en, men på hvilket trin den holdt op med at blive sendt videre.

To tabeller, der besvarer forskellige spørgsmål

På Junos EVPN lister databasen MAC-adresser pr. instans sammen med hvordan hver enkelt ankom: lært fra en adgangsport, modtaget i en Type 2-rute eller markeret som del af en multihoming-gruppe. Junipers reference til show evpn database dækker filtrene pr. MAC og pr. instans, som gør visningen læsbar. Det er et kontrolplansresumé med nøgle på instans og MAC, ikke den tabel, hardwaren switcher rammer med.

Switching-tabellen er netop den forwarding-tilstand. Begge udgange lister MAC'er ved siden af VLAN- eller VNI-kontekst, hvilket er præcis grunden til, at de sammenlignes linje for linje, og præcis grunden til, at sammenligningen vildleder. En post i databasen siger, at ruten findes og er accepteret i instansen; den siger intet om, hvorvidt platformen har installeret den til forwarding.

En Type 2-rute bærer MAC'en, en valgfri IP, en label eller VNI, en route distinguisher og et næste hop, der navngiver den fjerne VTEP. Fire ting kan bryde mellem kablet og den rute: værten læres aldrig, ruten annonceres aldrig, den afvises ved import, eller dens næste hop kan ikke opløses. Hver fejl efterlader et forskelligt sæt tabeller udfyldt, og det er grunden til, at sekvensen overhovedet kan diagnosticeres.

Lokal læring sker stadig først

Den gængse antagelse er, at EVPN overtager MAC-læring, så en tom database må betyde et overlay-problem. Lokal læring kører stadig på adgangssiden, præcis som før VXLAN fandtes: switchen lærer kilde-MAC'en for en tilladt ramme i det korrekte VLAN og den korrekte service og genererer først derefter en Type 2 for den. En vært, der ikke har sendt nogen relevant ramme, har intet at annoncere. En vært, hvis rammer kasseres af VLAN-medlemskab, et filter eller et nedlagt medlem af en aggregation, ser identisk ud set fra overlayet.

Begynd ved tilslutningen og arbejd fremad med skrivebeskyttede kommandoer. Målet er at bevise, at en ramme fra værten kom igennem i den tilsigtede service, fordi intet længere nede kompenserer for en ramme, der aldrig nåede frem.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Udvalgte LACP-medlemmer betyder mere end, at bundlen er oppe, da en aggregation kan være oppe på ét medlem, mens værtens trafik hashes til et link, der er nede eller blokeret. Interface-tællere adskiller en tavs vært fra en tabende, fordi en vært, der aldrig sender, og en vært, hvis rammer kasseres af klassificering, efterlader den samme tomme tabel.

Hvor en fjern MAC går tabt

En fjern MAC fejler i den modsatte retning, og det stille. Type 2-ruten ankommer, men den kommer kun ind i en instans, når dens route target og VNI matcher den lokale konfiguration, og den bliver kun brugbar, når næste hop opløses til en tilgængelig VTEP. En uoverensstemmelse i route target efterlader en gyldig rute i BGP-tabellen, som ingen instans nogensinde beder om.

Læs de tre visninger i rækkefølge: rutens tilstedeværelse, databasepost, forwarding-post. Kommandoerne nedenfor forespørger den samme MAC på hvert trin, og eksempeladressen holder udgangene sammenlignelige.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

De udgange besvarer tre separate spørgsmål. En rute i bgp.evpn.0 uden databasepost peger på importpolitik, route target eller instanskonfiguration. En databasepost uden forwarding-post peger på platformens programmering, som hører til en anden eskaleringsvej. En aktiv rute, hvis næste hop ikke kan opløses, er et transport- eller labelproblem, og ingen mængde MAC-fejlfinding reparerer det.

En genstart, der løste det, beviser meget lidt

Når en genstart får symptomet til at forsvinde, er den fristende konklusion, at konfigurationen må være sund. En genstart omprogrammerer hver tabel fra bunden, så den skjuler også det tilfælde, hvor en forældet post skyggede for en politikfejl; fejlen vender normalt tilbage ved næste ændring, link-flap eller rutetilbagetrækning.

Før ethvert vedligeholdelsesvindue skal du fange, hvad genstarten vil slette. Disse tre kommandoer er nok til at sammenligne før og efter, og de ændrer intet på enheden.

show evpn database instance blue
show route table bgp.evpn.0
show version

Arkivér de udgange med dato og softwarebuild ved siden af. En senere rapport om, at den samme genstart virkede tidligere, er et spor snarere end bevis, og forskellen bliver kun synlig, når nogen gemte den tidligere udgang.

Fire observationer, der afgør de fleste sager

Fire observationer dækker næsten enhver sag: tilslutningen og dens service, MAC'en som eksempelværdi, rutens og databasens tilstand og den anvendte build. Vælg en MAC, der tydeligt er et eksempel, så ingen forveksler den med en produktionsadresse: en første oktet på 02 markerer en lokalt administreret unicast-adresse, de resterende oktetter er frie, og 02:00:00:00:00:5c er derfor en sikker pladsholder.

Lad derefter svarene pege på det trin, der fejlede. Ingen læring ved tilslutningen betyder adgangssiden; en rute uden databasepost betyder import; en databasepost uden forwarding-tilstand betyder programmering. Hvad det end viser sig at være, så overdrag de indsamlede udgange sammen med vært, interface, service og build, så den næste ingeniør kan genskabe vejen i stedet for at gentage forespørgslen.