Kāpēc QFX MAC parādās EVPN, bet ne pārsūtīšanas tabulā

MAC atrašana EVPN datubāzē pierāda, ka tas tika paziņots vai saņemts kā maršruts, un nekas vairāk. Pārsūtīšanas tabula ir cita struktūra, kas tiek ieprogrammēta vēlāk, tāpēc viens un tas pats MAC var parādīties vienā un trūkt otrā, kamēr katrs protokols darbojas pareizi. Šo divu izvadu uzskatīšana par viens otra kopijām sūta inženierus BGP kļūdas meklējumos, kamēr faktiskā plaisa ir importa politika vai neatrisināts nākamais lēciens. Jautājums, ko ir vērts uzdot, nav par to, vai fabric zina MAC, bet kurā posmā tas pārstāja to nodot tālāk.

Divas tabulas, kas atbild uz dažādiem jautājumiem

Junos EVPN datubāze uzskaita MAC adreses katrai instancei kopā ar to, kā katra ieradās: apgūta no piekļuves porta, saņemta Type 2 maršrutā vai atzīmēta kā multihoming grupas daļa. Juniper show evpn database atsauce aptver filtrus pēc MAC un instances, kas padara skatu lasāmu. Tas ir vadības plaknes kopsavilkums ar atslēgu pēc instances un MAC, nevis tabula, ar kuru aparatūra komutē kadrus.

Komutācijas tabula ir tieši šis pārsūtīšanas stāvoklis. Abi izvadi uzskaita MAC blakus VLAN vai VNI kontekstam, un tieši tāpēc tos salīdzina rindu pa rindai, un tieši tāpēc salīdzinājums maldina. Ieraksts datubāzē saka, ka maršruts pastāv un ir pieņemts instancē; tas neko nesaka par to, vai platforma to ir instalējusi pārsūtīšanai.

Type 2 maršruts pārnēsā MAC, neobligātu IP, etiķeti vai VNI, maršruta atšķirēju un nākamo lēcienu, kas nosauc attālo VTEP. Starp kabeli un šo maršrutu var salūzt četras lietas: resursdators nekad netiek apgūts, maršruts nekad netiek paziņots, tas tiek noraidīts importā vai tā nākamais lēciens netiek atrisināts. Katra kļūme atstāj citu tabulu kopumu piepildītu, un tāpēc šo secību vispār var diagnosticēt.

Vietējā apguve joprojām notiek vispirms

Parastais pieņēmums ir, ka EVPN pārņem MAC apguvi, tāpēc tukšai datubāzei jānozīmē overlay problēma. Vietējā apguve joprojām darbojas piekļuves pusē, tieši tāpat kā pirms VXLAN pastāvēšanas: komutators apgūst atļautā kadra avota MAC pareizajā VLAN un pakalpojumā, un tikai pēc tam izveido tam Type 2. Resursdatoram, kas nav nosūtījis nevienu attiecīgu kadru, nav ko paziņot. Resursdators, kura kadri tiek izmesti VLAN dalības, filtra vai agregāta neaktīva dalībnieka dēļ, no overlay skatpunkta izskatās identiski.

Sāciet pie pieslēguma un virzieties uz priekšu ar tikai lasīšanas komandām. Mērķis ir pierādīt, ka kadrs no resursdatora ir izgājis paredzētajā pakalpojumā, jo nekas lejup pa straumi nekompensē kadru, kas nekad nav ieradies.

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

Izvēlētie LACP dalībnieki ir svarīgāki par to, vai saišķis ir augšā, jo agregāts var būt augšā uz viena dalībnieka, kamēr resursdatora trafiks tiek hešēts uz saiti, kas ir izslēgta vai bloķēta. Interfeisa skaitītāji atšķir klusu resursdatoru no tāda, kas nomet kadrus, jo resursdators, kas nekad nesūta, un resursdators, kura kadri tiek izmesti klasifikācijā, atstāj to pašu tukšo tabulu.

Kur pazūd attālais MAC

Attālais MAC neizdodas pretējā virzienā, un klusi. Type 2 maršruts ierodas, bet instancei tas pievienojas tikai tad, kad tā maršruta mērķis un VNI atbilst vietējai konfigurācijai, un tas kļūst izmantojams tikai tad, kad nākamais lēciens tiek atrisināts uz sasniedzamu VTEP. Maršruta mērķa neatbilstība atstāj derīgu maršrutu BGP tabulā, kuru neviena instance nekad neprasa.

Lasiet trīs skatus secībā: maršruta esamība, datubāzes ieraksts, pārsūtīšanas ieraksts. Tālāk minētās komandas katrā posmā vaicā to pašu MAC, un parauga adrese saglabā izvadus salīdzināmus.

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

Šie izvadi atbild uz trim atsevišķiem jautājumiem. Maršruts bgp.evpn.0 bez datubāzes ieraksta norāda uz importa politiku, maršruta mērķi vai instances konfigurāciju. Datubāzes ieraksts bez pārsūtīšanas ieraksta norāda uz platformas programmēšanu, kas pieder citam eskalācijas ceļam. Aktīvs maršruts, kura nākamais lēciens netiek atrisināts, ir transporta vai etiķetes problēma, un nekāds MAC atkļūdošanas daudzums to nesalabo.

Restarts, kas to salaboja, pierāda ļoti maz

Kad restarts liek simptomam pazust, vilinošais secinājums ir tāds, ka konfigurācijai jābūt veselai. Restarts pārprogrammē katru tabulu no nulles, tāpēc tas arī paslēpj gadījumu, kad novecojis ieraksts aizsedza politikas kļūdu; kļūme parasti atgriežas nākamajā izmaiņā, saites mirgošanā vai maršruta atsaukšanā.

Pirms jebkura apkopes loga fiksējiet, ko restarts izdzēsīs. Šīs trīs komandas ir pietiekamas, lai salīdzinātu pirms un pēc, un tās neko nemaina ierīcē.

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

Arhivējiet šos izvadus kopā ar datumu un programmatūras versiju. Vēlāks ziņojums, ka tas pats restarts palīdzēja arī iepriekš, ir pavediens, nevis pierādījums, un atšķirība kļūst redzama tikai tad, kad kāds ir saglabājis agrāko izvadu.

Četri novērojumi, kas izšķir lielāko daļu gadījumu

Četri novērojumi aptver gandrīz katru gadījumu: pieslēgums un tā pakalpojums, MAC kā parauga vērtība, maršruta un datubāzes stāvoklis, un izmantotā versija. Izvēlieties MAC, kas acīmredzami ir paraugs, lai neviens to nesajauktu ar ražošanas adresi: pirmais oktets 02 apzīmē lokāli pārvaldītu unicast adresi, pārējie okteti ir brīvi, un tāpēc 02:00:00:00:00:5c ir drošs vietturis.

Tad ļaujiet atbildēm norādīt uz posmu, kas neizdevās. Apguves trūkums pieslēgumā nozīmē piekļuves pusi; maršruts bez datubāzes ieraksta nozīmē importu; datubāzes ieraksts bez pārsūtīšanas stāvokļa nozīmē programmēšanu. Lai kas tas būtu, nododiet savāktos izvadus kopā ar resursdatoru, interfeisu, pakalpojumu un versiju, lai nākamais inženieris varētu reproducēt ceļu, nevis atkārtot vaicājumu.