Zakaj se MAC QFX pojavi v EVPN, a ne v tabeli posredovanja

Iskanje MAC v bazi EVPN dokazuje, da je bila oglašena ali prejeta kot pot, in nič več. Tabela posredovanja je druga struktura, programirana pozneje, zato se lahko ista MAC pojavi v eni in manjka v drugi, medtem ko se vsak protokol obnaša pravilno. Če ti dve izhodi obravnavamo kot kopiji drugega, pošljemo inženirje za napako BGP, medtem ko je resnična vrzel politika uvoza ali nerazrešen naslednji skok. Vprašanje, ki se ga splača vprašati, ni, ali fabric pozna MAC, ampak na kateri stopnji jo je prenehal posredovati.

Dve tabeli, ki odgovarjata na različni vprašanji

V Junos EVPN baza navaja naslove MAC po instanci skupaj s tem, kako je vsak prispel: naučen z dostopnega vrat, prejet v poti Type 2 ali označen kot del skupine multihoming. Referenca Juniper show evpn database pokriva filtre po MAC in po instanci, ki naredijo pogled berljiv. To je povzetek krmilne ravnine s ključem instance in MAC, ne tabela, s katero strojna oprema preklaplja okvire.

Preklopna tabela je prav to stanje posredovanja. Oba izhoda navajata MAC ob kontekstu VLAN ali VNI, in ravno zato ju primerjajo vrstico za vrstico, in ravno zato primerjava zavaja. Vnos v bazi pravi, da pot obstaja in je bila sprejeta v instanco; ne pravi nič o tem, ali jo je platforma namestila za posredovanje.

Pot Type 2 nosi MAC, izbirni IP, oznako ali VNI, razlikovalnik poti in naslednji skok, ki poimenuje oddaljeni VTEP. Med kablom in to potjo se lahko zlomijo štiri stvari: gostitelj se nikoli ne nauči, pot se nikoli ne oglašuje, zavrne se pri uvozu ali se njen naslednji skok ne razreši. Vsaka napaka pusti drugačen niz napolnjenih tabel, in zato je to zaporedje sploh mogoče diagnosticirati.

Lokalno učenje se še vedno zgodi prvo

Običajna predpostavka je, da EVPN prevzame učenje MAC, zato mora prazna baza pomeniti težavo z overlayem. Lokalno učenje še vedno teče na dostopni strani, natanko tako kot pred obstojem VXLAN: stikalo se nauči izvornega MAC dovoljenega okvira v pravilnem VLAN in storitvi in šele nato zanj ustvari Type 2. Gostitelj, ki ni poslal nobenega ustreznega okvira, nima česa oglaševati. Gostitelj, katerega okviri se zavržejo zaradi članstva v VLAN, filtra ali nedelujočega člana združitve, je z vidika overlaya videti enako.

Začnite pri priključku in nadaljujte s ukazi samo za branje. Cilj je dokazati, da je okvir z gostitelja šel skozi predvideno storitev, ker nič nižje ne nadomesti okvira, ki ni nikoli prispel.

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

Izbrani člani LACP so pomembnejši od tega, da je snop aktiven, saj je združitev lahko aktivna na enem članu, medtem ko se promet gostitelja zgošča na povezavo, ki je nedelujoča ali blokirana. Števci vmesnika ločijo tihega gostitelja od tistega, ki spušča, ker gostitelj, ki nikoli ne pošilja, in gostitelj, katerega okviri se zavržejo s klasifikacijo, pustita isto prazno tabelo.

Kje se izgubi oddaljeni MAC

Oddaljeni MAC odpove v nasprotni smeri, in to tiho. Pot Type 2 prispe, vendar v instanco vstopi le, ko se njen cilj poti in VNI ujemata z lokalno konfiguracijo, in postane uporabna le, ko se naslednji skok razreši v dosegljiv VTEP. Neujemanje cilja poti pusti v tabeli BGP veljavno pot, ki je nobena instanca nikoli ne zahteva.

Preberite tri poglede po vrsti: obstoj poti, vnos v bazi, vnos posredovanja. Spodnji ukazi sprašujejo isto MAC v vsaki stopnji, primerjalni naslov pa ohranja izhode primerljive.

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

Ti izhodi odgovarjajo na tri ločena vprašanja. Pot v bgp.evpn.0 brez vnosa v bazi kaže na politiko uvoza, cilj poti ali konfiguracijo instance. Vnos v bazi brez vnosa posredovanja kaže na programiranje platforme, kar spada na drugo pot stopnjevanja. Aktivna pot, katere naslednji skok se ne razreši, je težava prevoza ali oznake, in nobena količina razhroščevanja MAC je ne popravi.

Ponovni zagon, ki je to popravil, dokaže zelo malo

Ko ponovni zagon povzroči, da simptom izgine, je vabljiv sklep, da mora biti konfiguracija zdrava. Ponovni zagon preprogramira vsako tabelo od začetka, zato skrije tudi primer, ko je zastarel vnos zasenčil napako politike; napaka se običajno vrne ob naslednji spremembi, utripanju povezave ali umiku poti.

Pred katerim koli vzdrževalnim oknom zabeležite, kaj bo ponovni zagon izbrisal. Ti trije ukazi zadostujejo za primerjavo pred in po, in na napravi ne spremenijo ničesar.

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

Arhivirajte te izhode z datumom in različico programske opreme ob strani. Poznejše poročilo, da je isti ponovni zagon pomagal že prej, je sled in ne dokaz, razlika pa postane vidna le, ko je nekdo shranil prejšnji izhod.

Štiri opažanja, ki rešijo večino primerov

Štiri opažanja pokrijejo skoraj vsak primer: priključek in njegova storitev, MAC kot vzorčna vrednost, stanje poti in baze ter uporabljena različica. Izberite MAC, ki je očitno vzorec, da ga nihče ne zamenja s produkcijskim naslovom: prvi oktet 02 označuje lokalno upravljani unicast naslov, preostali okteti so prosti, zato je 02:00:00:00:00:5c varen nadomestni znak.

Nato pustite, da odgovori pokažejo na stopnjo, ki je spodletela. Brez učenja na priključku pomeni dostopno stran; pot brez vnosa v bazi pomeni uvoz; vnos v bazi brez stanja posredovanja pomeni programiranje. Karkoli je, predajte zbrane izhode skupaj z gostiteljem, vmesnikom, storitvijo in različico, da lahko naslednji inženir pot reproducira, namesto da bi ponavljal poizvedbo.