Kvifor ein QFX-MAC viser seg i EVPN men ikkje i videresendingstabellen

Å finne ein MAC i EVPN-databasen provar at han vart annonsert eller motteken som ei rute, og ikkje noko meir. Videresendingstabellen er ein annan struktur, programmert seinare, så same MAC kan dukke opp i den eine og mangle i den andre medan kvar protokoll oppfører seg rett. Å handsame desse to utskriftene som kopiar av kvarandre sender ingeniørar etter ein BGP-feil medan den verkelege mangelen er ein importpolitikk eller eit uoppklart neste hopp. Spørsmålet som er verdt å stille, er ikkje om fabric kjenner MAC-en, men på kva trinn han slutta å bli send vidare.

To tabellar som svarar på ulike spørsmål

På Junos EVPN listar databasen MAC-adresser per instans saman med korleis kvar einskild kom inn: lært frå ein tilgangsport, motteken i ei Type 2-rute eller merkt som del av ei multihoming-gruppe. Junipers referanse til show evpn database dekkjer filtera per MAC og per instans som gjer visninga lesbar. Det er eit samandrag av kontrollplanet med nøkkel på instans og MAC, ikkje tabellen maskinvara svitsjar rammer med.

Svitsjetabellen er nettopp denne videresendingstilstanden. Begge utskriftene listar MAC-ar ved sida av VLAN- eller VNI-kontekst, og det er nettopp difor dei blir samanlikna linje for linje, og nettopp difor samanlikninga villeder. Ei oppføring i databasen seier at ruta finst og vart godteken i instansen; ho seier ingenting om plattforma installerte henne for videresending.

Ei Type 2-rute ber MAC-en, ein valfri IP, ein label eller VNI, ein rutedistinktør og eit neste hopp som namngjev den fjerne VTEP-en. Fire ting kan bryte mellom kabelen og den ruta: verten blir aldri lært, ruta blir aldri annonsert, ho blir avvist ved import, eller neste hopp let seg ikkje oppklare. Kvar feil etterlèt eit anna sett tabellar fylt, og det er grunnen til at sekvensen i det heile kan diagnostiserast.

Lokal læring skjer framleis først

Den vanlege antakinga er at EVPN tek over MAC-læringa, så ein tom database må tyde eit overlay-problem. Lokal læring går framleis på tilgangssida, akkurat som før VXLAN fanst: svitsjen lærer kjelde-MAC-en til ei tillaten ramme i rett VLAN og teneste, og genererer først deretter ein Type 2 for henne. Ein vert som ikkje har sendt noka relevant ramme, har ingenting å annonsere. Ein vert som rammene hans blir kasta av VLAN-medlemskap, eit filter eller eit inaktivt medlem av ein aggregering, ser identisk ut frå overlayet sitt synspunkt.

Start ved tilkoplinga og arbeid deg framover med skriveverna kommandoar. Målet er å prove at ei ramme frå verten kom gjennom i den tiltenkte tenesta, fordi ingenting lenger nede kompenserer for ei ramme som aldri kom fram.

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

Utvalde LACP-medlemmer betyr meir enn at buntinga er oppe, sidan ein aggregering kan vere oppe på eitt medlem medan trafikken til verten blir hasha til ei lenkje som er nede eller blokkert. Grensesnittteljarar skil ein stille vert frå ein som slepp, fordi ein vert som aldri sender og ein vert som rammene hans blir kasta av klassifisering, etterlèt den same tomme tabellen.

Kvar ein fjern MAC går tapt

Ein fjern MAC feilar i motsett retning, og det stille. Type 2-ruta kjem inn, men ho kjem berre inn i ein instans når rutedestinasjonen og VNI stemmer med den lokale konfigurasjonen, og ho blir berre brukbar når neste hopp blir oppklart til ein nåbar VTEP. Eit avvik i rutedestinasjonen etterlèt ei gyldig rute i BGP-tabellen som ingen instans nokosinne ber om.

Les dei tre visningane i rekkefølgje: tilstadeværet av ruta, databaseoppføringa, videresendingsoppføringa. Kommandoane nedanfor spør om same MAC på kvart trinn, og eksempeladressa held utskriftene samanliknbare.

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

Desse utskriftene svarar på tre separate spørsmål. Ei rute i bgp.evpn.0 utan databaseoppføring peikar på importpolitikk, rutedestinasjon eller instanskonfigurasjon. Ei databaseoppføring utan videresendingsoppføring peikar på programmeringa av plattforma, som høyrer til ein annan eskaleringsveg. Ei aktiv rute som neste hopp ikkje blir oppklart for, er eit transport- eller labelproblem, og inga mengd MAC-feilsøking reparerer det.

Ein omstart som fiksa det, provar svært lite

Når ein omstart får symptomet til å forsvinne, er den freistande konklusjonen at konfigurasjonen må vere sunn. Ein omstart programmerer kvar tabell på nytt frå botnen, så han skjuler òg tilfellet der ei utdatert oppføring skugga over ein politikkfeil; feilen kjem vanlegvis tilbake ved neste endring, link-flap eller ruteuttak.

Før eit kvart vedlikehaldsvindauge, fang opp det omstarten vil slette. Desse tre kommandoane er nok til å samanlikne før og etter, og dei endrar ingenting på eininga.

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

Arkiver desse utskriftene med dato og programvarebygg ved sida. Ein seinare rapport om at den same omstarten verka tidlegare, er eit spor snarare enn prov, og skilnaden blir berre synleg når nokon tok vare på den tidlegare utskrifta.

Fire observasjonar som avgjer dei fleste sakene

Fire observasjonar dekkjer nesten kvar sak: tilkoplinga og tenesta hennar, MAC-en som eksempelverdi, tilstanden til ruta og databasen, og bygget som blir brukt. Vel ein MAC som tydeleg er eit eksempel, slik at ingen forvekslar han med ei produksjonsadresse: ein første oktett på 02 markerer ei lokalt administrert unicast-adresse, dei resterande oktettane er frie, og 02:00:00:00:00:5c er difor ein trygg plasshaldar.

Lat så svara peike på trinnet som feila. Inga læring ved tilkoplinga betyr tilgangssida; ei rute utan databaseoppføring betyr import; ei databaseoppføring utan videresendingstilstand betyr programmering. Kva det enn viser seg å vere, overlever dei innsamla utskriftene saman med vert, grensesnitt, teneste og bygg, slik at den neste ingeniøren kan gjenskape vegen i staden for å gjenta spørjinga.