Varför en QFX-MAC visas i EVPN men inte i vidarebefordranstabellen

Att hitta en MAC i EVPN-databasen bevisar att den annonserades eller togs emot som en rutt, och inget mer. Vidarebefordranstabellen är en annan struktur, programmerad senare, så samma MAC kan visas i den ena och saknas i den andra medan varje protokoll beter sig korrekt. Att behandla dessa två utdata som kopior av varandra skickar ingenjörer efter ett BGP-fel när den verkliga luckan är en importpolicy eller ett ouppklarat nästa hopp. Frågan som är värd att ställa är inte om fabric känner till MAC-adressen, utan i vilket steg den slutade skickas vidare.

Två tabeller som svarar på olika frågor

På Junos EVPN listar databasen MAC-adresser per instans tillsammans med hur var och en kom in: inlärd från en accessport, mottagen i en Type 2-rutt eller markerad som del av en multihoming-grupp. Junipers referens till show evpn database täcker filtren per MAC och per instans som gör vyn läsbar. Det är en sammanfattning av kontrollplanet med nyckel på instans och MAC, inte tabellen som hårdvaran växlar ramar med.

Växlingstabellen är just detta vidarebefordringstillstånd. Båda utdata listar MAC-adresser bredvid VLAN- eller VNI-kontext, och det är just därför de jämförs rad för rad, och just därför jämförelsen vilseleder. En post i databasen säger att rutten finns och accepterades i instansen; den säger ingenting om huruvida plattformen installerade den för vidarebefordran.

En Type 2-rutt bär MAC-adressen, en valfri IP, en label eller VNI, en ruttavskiljare och ett nästa hopp som namnger den avlägsna VTEP:n. Fyra saker kan gå sönder mellan kabeln och den rutten: värden lärs aldrig in, rutten annonseras aldrig, den avvisas vid import, eller dess nästa hopp går inte att lösa upp. Varje fel lämnar en annan uppsättning tabeller fyllda, och det är därför sekvensen överhuvudtaget kan diagnostiseras.

Lokalt lärande sker fortfarande först

Det vanliga antagandet är att EVPN tar över MAC-inlärningen, så en tom databas måste betyda ett overlay-problem. Lokalt lärande körs fortfarande på accesssidan, precis som innan VXLAN fanns: switchen lär sig käll-MAC-adressen för en tillåten ram i rätt VLAN och tjänst, och genererar först därefter en Type 2 för den. En värd som inte skickat någon relevant ram har ingenting att annonsera. En värd vars ramar kastas av VLAN-medlemskap, ett filter eller en nedkopplad medlem av en aggregering ser identisk ut ur overlayns perspektiv.

Börja vid anslutningen och arbeta dig framåt med skrivskyddade kommandon. Målet är att bevisa att en ram från värden kom igenom i den avsedda tjänsten, eftersom ingenting längre ned kompenserar för en ram som aldrig kom fram.

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

Utvalda LACP-medlemmar betyder mer än att buntningen är uppe, eftersom en aggregering kan vara uppe på en medlem medan värdens trafik hashas till en länk som är nere eller blockerad. Gränssnittsräknare skiljer en tyst värd från en som tappar, eftersom en värd som aldrig sänder och en värd vars ramar kastas av klassificering lämnar samma tomma tabell.

Var en fjärr-MAC går förlorad

En fjärr-MAC misslyckas i motsatt riktning, och det tyst. Type 2-rutten anländer, men den kommer bara in i en instans när dess ruttmål och VNI matchar den lokala konfigurationen, och den blir bara användbar när nästa hopp löses upp till en nåbar VTEP. En avvikelse i ruttmålet lämnar en giltig rutt i BGP-tabellen som ingen instans någonsin begär.

Läs de tre vyerna i ordning: ruttens närvaro, databaspost, vidarebefordringspost. Kommandona nedan frågar efter samma MAC i varje steg, och exempeladressen håller utdata jämförbara.

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

Dessa utdata svarar på tre separata frågor. En rutt i bgp.evpn.0 utan databaspost pekar på importpolicy, ruttmål eller instanskonfiguration. En databaspost utan vidarebefordringspost pekar på plattformens programmering, vilket hör till en annan eskaleringsväg. En aktiv rutt vars nästa hopp inte löses upp är ett transport- eller labelproblem, och ingen mängd MAC-felsökning reparerar det.

En omstart som fixade det bevisar mycket lite

När en omstart får symptomet att försvinna är den frestande slutsatsen att konfigurationen måste vara sund. En omstart programmerar om varje tabell från grunden, så den döljer också fallet där en inaktuell post skuggade ett policyfel; felet återkommer vanligtvis vid nästa ändring, länkflapp eller ruttåterdragning.

Fånga före varje underhållsfönster vad omstarten kommer att radera. Dessa tre kommandon räcker för att jämföra före och efter, och de ändrar ingenting på enheten.

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

Arkivera dessa utdata med datum och programvarubyggnad bredvid. En senare rapport om att samma omstart fungerade tidigare är ett spår snarare än bevis, och skillnaden blir bara synlig när någon behöll den tidigare utdata.

Fyra observationer som avgör de flesta fall

Fyra observationer täcker nästan varje fall: anslutningen och dess tjänst, MAC-adressen som exempelvärde, tillståndet för rutten och databasen, och byggnaden som används. Välj en MAC som uppenbart är ett exempel så att ingen förväxlar den med en produktionsadress: en första oktett på 02 markerar en lokalt administrerad unicast-adress, de återstående oktetterna är fria, och 02:00:00:00:00:5c är därför en säker platshållare.

Låt sedan svaren peka på steget som misslyckades. Ingen inlärning vid anslutningen betyder accesssidan; en rutt utan databaspost betyder import; en databaspost utan vidarebefordringstillstånd betyder programmering. Vad det än visar sig vara, överlämna de insamlade utdata tillsammans med värd, gränssnitt, tjänst och byggnad, så att nästa ingenjör kan återskapa vägen istället för att upprepa frågan.