Hvorfor en QFX-MAC vises i EVPN men ikke i videresendingstabellen

Å finne en MAC i EVPN-databasen beviser at den ble annonsert eller mottatt som en rute, og ikke noe mer. Videresendingstabellen er en annen struktur, programmert senere, så samme MAC kan dukke opp i den ene og mangle i den andre mens hver protokoll oppfører seg riktig. Å behandle disse to utskriftene som kopier av hverandre sender ingeniører etter en BGP-feil mens den virkelige mangelen er en importpolitikk eller et uoppklart neste hopp. Spørsmålet som er verdt å stille, er ikke om fabric kjenner MAC-en, men på hvilket trinn den sluttet å bli sendt videre.

To tabeller som svarer på forskjellige spørsmål

På Junos EVPN lister databasen MAC-adresser per instans sammen med hvordan hver enkelt kom inn: lært fra en tilgangsport, mottatt i en Type 2-rute eller merket som del av en multihoming-gruppe. Junipers referanse til show evpn database dekker filtrene per MAC og per instans som gjør visningen lesbar. Det er et sammendrag av kontrollplanet med nøkkel på instans og MAC, ikke tabellen maskinvaren svitsjer rammer med.

Svitsjetabellen er nettopp denne videresendingstilstanden. Begge utskriftene lister MAC-er ved siden av VLAN- eller VNI-kontekst, og det er nettopp derfor de sammenlignes linje for linje, og nettopp derfor sammenligningen villeder. En oppføring i databasen sier at ruten finnes og ble godtatt i instansen; den sier ingenting om hvorvidt plattformen installerte den for videresending.

En Type 2-rute bærer MAC-en, en valgfri IP, en label eller VNI, en rutedistinktør og et neste hopp som navngir den fjerne VTEP-en. Fire ting kan bryte mellom kabelen og den ruten: verten læres aldri, ruten annonseres aldri, den avvises ved import, eller neste hopp lar seg ikke oppklare. Hver feil etterlater et annet sett tabeller fylt, og det er grunnen til at sekvensen i det hele tatt kan diagnostiseres.

Lokal læring skjer fortsatt først

Den vanlige antakelsen er at EVPN overtar MAC-læringen, så en tom database må bety et overlay-problem. Lokal læring går fortsatt på tilgangssiden, akkurat som før VXLAN fantes: svitsjen lærer kilde-MAC-en til en tillatt ramme i riktig VLAN og tjeneste, og genererer først deretter en Type 2 for den. En vert som ikke har sendt noen relevant ramme, har ingenting å annonsere. En vert hvis rammer forkastes av VLAN-medlemskap, et filter eller et inaktivt medlem av en aggregasjon, ser identisk ut fra overlayets synspunkt.

Start ved tilkoblingen og arbeid deg fremover med skrivebeskyttede kommandoer. Målet er å bevise at en ramme fra verten kom gjennom i den tiltenkte tjenesten, fordi ingenting lenger ned kompenserer for en ramme som aldri kom frem.

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

Utvalgte LACP-medlemmer betyr mer enn at buntingen er oppe, siden en aggregasjon kan være oppe på ett medlem mens vertens trafikk hashes til en lenke som er nede eller blokkert. Grensesnitttellere skiller en stille vert fra en som slipper, fordi en vert som aldri sender og en vert hvis rammer forkastes av klassifisering, etterlater den samme tomme tabellen.

Hvor en fjern MAC går tapt

En fjern MAC feiler i motsatt retning, og det stille. Type 2-ruten ankommer, men den kommer bare inn i en instans når rutedestinasjonen og VNI stemmer med den lokale konfigurasjonen, og den blir bare brukbar når neste hopp oppklages til en nåbar VTEP. Et avvik i rutedestinasjonen etterlater en gyldig rute i BGP-tabellen som ingen instans noen gang ber om.

Les de tre visningene i rekkefølge: rutens tilstedeværelse, databaseoppføring, videresendingsoppføring. Kommandoene nedenfor spør om samme MAC på hvert trinn, og eksempeladressen holder utskriftene sammenlignbare.

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

Disse utskriftene svarer på tre separate spørsmål. En rute i bgp.evpn.0 uten databaseoppføring peker på importpolitikk, rutedestinasjon eller instanskonfigurasjon. En databaseoppføring uten videresendingsoppføring peker på plattformens programmering, som hører til en annen eskaleringsvei. En aktiv rute hvis neste hopp ikke oppklages, er et transport- eller labelproblem, og ingen mengde MAC-feilsøking reparerer det.

En omstart som fikset det, beviser svært lite

Når en omstart får symptomet til å forsvinne, er den fristende konklusjonen at konfigurasjonen må være sunn. En omstart programmerer hver tabell på nytt fra bunnen, så den skjuler også tilfellet der en utdatert oppføring skygget over en politikkfeil; feilen kommer vanligvis tilbake ved neste endring, link-flap eller ruteuttak.

Før ethvert vedlikeholdsvindu, fang opp det omstarten vil slette. Disse tre kommandoene er nok til å sammenligne før og etter, og de endrer ingenting på enheten.

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

Arkiver disse utskriftene med dato og programvarebygg ved siden av. En senere rapport om at den samme omstarten virket tidligere, er et spor snarere enn bevis, og forskjellen blir bare synlig når noen tok vare på den tidligere utskriften.

Fire observasjoner som avgjør de fleste sakene

Fire observasjoner dekker nesten enhver sak: tilkoblingen og dens tjeneste, MAC-en som eksempelverdi, tilstanden til ruten og databasen, og bygget som brukes. Velg en MAC som tydelig er et eksempel, slik at ingen forveksler den med en produksjonsadresse: en første oktett på 02 markerer en lokalt administrert unicast-adresse, de resterende oktettene er frie, og 02:00:00:00:00:5c er derfor en trygg plassholder.

La deretter svarene peke på trinnet som feilet. Ingen læring ved tilkoblingen betyr tilgangssiden; en rute uten databaseoppføring betyr import; en databaseoppføring uten videresendingstilstand betyr programmering. Hva det enn viser seg å være, overlever de innsamlede utskriftene sammen med vert, grensesnitt, tjeneste og bygg, slik at den neste ingeniøren kan gjenskape veien i stedet for å gjenta spørringen.