Kial QFX-MAC aperas en EVPN sed ne en la plusenda tabelo

Trovi MAC en la EVPN-datumbazo pruvas ke ĝi estis anoncita aŭ ricevita kiel vojo, kaj nenion pli. La plusenda tabelo estas alia strukturo, programita poste, do la sama MAC povas aperi en unu kaj manki en la alia dum ĉiu protokolo kondutas ĝuste. Trakti tiujn du elirojn kiel kopiojn unu de la alia sendas inĝenierojn post BGP-difekton, kiam la reala breĉo estas importa politiko aŭ nesolvita sekva salto. La demando inda je starigo ne estas ĉu la fabric konas la MAC, sed en kiu etapo ĝi ĉesis transdoni ĝin.

Du tabeloj, kiuj respondas al diversaj demandoj

En Junos EVPN la datumbazo listigas MAC-adresojn laŭ kazo kune kun tio, kiel ĉiu alvenis: lernita el alirhaveno, ricevita en Type 2-vojo aŭ markita kiel parto de multhejma grupo. La referenco de Juniper show evpn database kovras la filtrilojn laŭ MAC kaj laŭ kazo, kiuj faras la vidon legebla. Ĝi estas resumo de la rega ebeno ŝlosita laŭ kazo kaj MAC, ne la tabelo per kiu la aparataro komutas kadrojn.

La komuta tabelo estas ĝuste tiu plusenda stato. Ambaŭ eliroj listigas MAC-ojn apud VLAN- aŭ VNI-kunteksto, kio estas ĝuste la kialo, ke ili estas komparataj linion post linio, kaj ĝuste la kialo, ke la komparo trompas. Rikordo en la datumbazo diras, ke la vojo ekzistas kaj estis akceptita en la kazon; ĝi diras nenion pri tio, ĉu la platformo instalis ĝin por plusendo.

Type 2-vojo portas la MAC, laŭvolan IP, etikedon aŭ VNI, voj-distingilon kaj sekvan salton nomantan la foran VTEP. Kvar aferoj povas rompiĝi inter la kablo kaj tiu vojo: la gastiganto neniam estas lernita, la vojo neniam estas anoncita, ĝi estas malakceptita ĉe importo, aŭ ĝia sekva salto ne solviĝas. Ĉiu malsukceso lasas malsaman aron da tabeloj plenigitaj, kaj pro tio la sinsekvo entute estas diagnozebla.

Loka lernado ankoraŭ okazas unue

La ordinara supozo estas, ke EVPN transprenas MAC-lernadon, do malplena datumbazo devas signifi tavolan problemon. Loka lernado ankoraŭ funkcias ĉe la alirflanko, same kiel antaŭ ol ekzistis VXLAN: la komutilo lernas la fontan MAC de permesita kadro en la ĝusta VLAN kaj servo, kaj nur poste originas Type 2 por ĝi. Gastiganto, kiu sendis neniun rilatan kadron, havas nenion anonci. Gastiganto, kies kadroj estas forĵetitaj de VLAN-membreco, filtrilo aŭ malaktiva membro de agregado, aspektas idente el la vidpunkto de la tavolo.

Komencu ĉe la alkroĉo kaj antaŭeniru per nurlegaj komandoj. La celo estas pruvi, ke kadro de la gastiganto trapasis en la celita servo, ĉar nenio malsupre kompensas kadron, kiu neniam alvenis.

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

Elektitaj LACP-membroj gravas pli ol tio, ke la fasko estas aktiva, ĉar agregado povas esti aktiva sur unu membro dum la trafiko de la gastiganto haŝiĝas al ligilo, kiu estas malaktiva aŭ blokita. Interfacaj nombriloj apartigas silentan gastiganton de perdanta, ĉar gastiganto, kiu neniam elsendas, kaj gastiganto, kies kadroj estas forĵetitaj de klasifiko, lasas la saman malplenan tabelon.

Kie fora MAC perdiĝas

Fora MAC malsukcesas en la kontraŭa direkto, kaj silente. La Type 2-vojo alvenas, sed ĝi eniras kazon nur kiam ĝia voj-celo kaj VNI kongruas kun la loka agordo, kaj ĝi fariĝas uzebla nur kiam la sekva salto solviĝas al atingebla VTEP. Miskongruo de voj-celo lasas validan vojon en la BGP-tabelo, kiun neniu kazo iam petas.

Legu la tri vidojn laŭorde: ekzisto de vojo, datumbaza rikordo, plusenda rikordo. La subaj komandoj demandas la saman MAC ĉe ĉiu etapo, kaj la ekzempla adreso tenas la elirojn kompareblaj.

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

Tiuj eliroj respondas al tri apartaj demandoj. Vojo en bgp.evpn.0 sen datumbaza rikordo montras al importa politiko, voj-celo aŭ kaza agordo. Datumbaza rikordo sen plusenda rikordo montras al platforma programado, kiu apartenas al alia eskala vojo. Aktiva vojo, kies sekva salto ne solviĝas, estas transporta aŭ etikeda problemo, kaj neniu kvanto da erarserĉado pri MAC riparas ĝin.

Restarto, kiu ĝin riparis, pruvas tre malmulte

Kiam restarto igas la simptomon malaperi, la alloga konkludo estas, ke la agordo devas esti sana. Restarto reprogramas ĉiun tabelon de nulo, do ĝi ankaŭ kaŝas la kazon, kiam eksdata rikordo ombris politikan eraron; la difekto kutime revenas ĉe la sekva ŝanĝo, ligila flapo aŭ voja retiriĝo.

Antaŭ ajna prizorga fenestro registru, kion la restarto forviŝos. Tiuj tri komandoj sufiĉas por kompari antaŭe kaj poste, kaj ili ŝanĝas nenion sur la aparato.

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

Konservu tiujn elirojn kun la dato kaj la programara versio apude. Pli posta raporto, ke la sama restarto antaŭe helpis, estas spuro prefere ol pruvo, kaj la diferenco videblas nur kiam iu konservis la pli fruan eliron.

Kvar observoj, kiuj decidas la plej multajn kazojn

Kvar observoj kovras preskaŭ ĉiun kazon: la alkroĉo kaj ĝia servo, la MAC kiel ekzempla valoro, la stato de la vojo kaj datumbazo, kaj la uzata versio. Elektu MAC, kiu evidente estas ekzemplo, por ke neniu konfuzu ĝin kun produktada adreso: unua okto de 02 markas loke administritan unicast-adreson, la ceteraj oktoj estas liberaj, kaj 02:00:00:00:00:5c do estas sekura anstataŭilo.

Poste lasu la respondojn montri al la etapo, kiu malsukcesis. Neniu lernado ĉe la alkroĉo signifas la alirflankon; vojo sen datumbaza rikordo signifas importon; datumbaza rikordo sen plusenda stato signifas programadon. Kio ajn ĝi montriĝos, transdonu la kolektitajn elirojn kune kun la gastiganto, interfaco, servo kaj versio, por ke la sekva inĝeniero povu reprodukti la vojon anstataŭ ripeti la demandon.