Hvers vegna QFX-MAC birtist í EVPN en ekki í framsendingartöflunni
MAC í EVPN-gagnagrunninum er staðreynd stjórnflatar, ekki sönnun þess að framsendingartaflan hafi verið forrituð. Lestu fjögur stigin í röð áður en þú kennir BGP um.
Að finna MAC í EVPN-gagnagrunninum sannar að hann var tilkynntur eða móttekinn sem leið, og ekkert frekar. Framsendingartaflan er önnur uppbygging, forrituð síðar, svo sami MAC getur birst í annarri og vantað í hinni á meðan hvert samskiptareglur hegðar sér rétt. Að meðhöndla þessi tvö úttök sem afrit hvors annars sendir verkfræðinga á eftir BGP-galla þegar raunverulega bilið er innflutningsstefna eða óleyst næsta hopp. Spurningin sem er þess virði að spyrja er ekki hvort fabric þekkir MAC-ið, heldur á hvaða stigi það hætti að senda það áfram.
Tvær töflur sem svara ólíkum spurningum
Á Junos EVPN telur gagnagrunnurinn upp MAC-vistföng fyrir hvert tilvik ásamt því hvernig hvert kom: lært af aðgangstengi, móttekið í Type 2 leið eða merkt sem hluti af multihoming hópi. Tilvísun Juniper show evpn database nær yfir síurnar fyrir hvert MAC og hvert tilvik sem gera yfirlitið læsilegt. Þetta er samantekt stjórnflatar með lykli á tilvik og MAC, ekki taflan sem vélbúnaðurinn skiptir rammum með.
Skiptitaflan er þetta framsendingarástand. Bæði úttökin telja upp MAC við hlið VLAN- eða VNI-samhengis, sem er einmitt ástæðan fyrir því að þau eru borin saman línu fyrir línu, og einmitt ástæðan fyrir því að samanburðurinn villir. Færsla í gagnagrunninum segir að leiðin sé til og hafi verið samþykkt í tilvikið; hún segir ekkert um hvort kerfið hafi sett hana upp fyrir framsendingu.
Type 2 leið ber MAC-ið, valfrjálst IP, merki eða VNI, leiðaraðgreini og næsta hopp sem nefnir fjarlæga VTEP. Fjórir hlutir geta brotnað milli snúrunnar og þeirrar leiðar: hýsillinn er aldrei lærður, leiðin er aldrei tilkynnt, henni er hafnað við innflutning eða næsta hopp hennar leysist ekki. Hver bilun skilur eftir annað sett af töflum fylltum, og þess vegna er hægt að greina röðina yfirhöfuð.
Staðbundið nám á sér enn stað fyrst
Algengt er að ætla að EVPN taki yfir MAC-nám, svo tómur gagnagrunnur hlýtur að þýða overlay-vandamál. Staðbundið nám gengur enn á aðgangshliðinni, nákvæmlega eins og áður en VXLAN var til: rofinn lærir upprunalega MAC-ið á leyfðum ramma í réttu VLAN og þjónustu og býr aðeins þá til Type 2 fyrir hann. Hýsill sem hefur ekki sent neinn viðeigandi ramma hefur ekkert að tilkynna. Hýsill sem rammum hans er hent vegna VLAN-aðildar, síu eða niðri stæðs meðlims í samtengingu lítur eins út frá sjónarhóli overlaysins.
Byrjaðu á tengingunni og farðu áfram með skipanir sem eru aðeins til lestrar. Markmiðið er að sanna að rammi frá hýslinum hafi farið í gegnum fyrirhugaða þjónustu, því ekkert neðar bætir upp ramma sem kom aldrei.
show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0
Valdir LACP-meðlimir skipta meira máli en að búntið sé uppi, því samtenging getur verið uppi á einum meðlim á meðan umferð hýsilsins hasast á tengil sem er niðri eða lokaður. Viðmótsteljarar greina hljóðlátan hýsil frá þeim sem sleppir, því hýsill sem sendir aldrei og hýsill sem rammum hans er hent með flokkun skilja eftir sömu tómu töfluna.
Hvar fjarlægt MAC týnist
Fjarlægt MAC bregst í gagnstæða átt, og hljóðlega. Type 2 leiðin berst, en hún fer aðeins inn í tilvik þegar leiðarmarkmið hennar og VNI passa við staðbundna stillingu, og verður aðeins nothæf þegar næsta hopp leysist í aðgengilegt VTEP. Ósamræmi í leiðarmarkmiði skilur eftir gilda leið í BGP-töflunni sem ekkert tilvik biður um.
Lestu þrjú yfirlitin í röð: tilvist leiðar, færsla í gagnagrunni, framsendingarfærsla. Skipanirnar hér að neðan spyrja um sama MAC á hverju stigi, og sýnidæmið heldur úttökunum samanburðarhæfum.
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
Þessi úttök svara þremur aðskildum spurningum. Leið í bgp.evpn.0 án færslu í gagnagrunni bendir á innflutningsstefnu, leiðarmarkmið eða stillingu tilviks. Færsla í gagnagrunni án framsendingarfærslu bendir á forritun kerfisins, sem tilheyrir annarri stigmögnunarleið. Virk leið sem næsta hopp hennar leysist ekki er flutnings- eða merkisvandamál, og engin magn MAC-kembileitni lagar það.
Endurræsing sem lagaði það sannar mjög lítið
Þegar endurræsing lætur einkennin hverfa er freistandi niðurstaðan að stillingin hljóti að vera heilbrigð. Endurræsing forritar hverja töflu frá grunni, svo hún felur líka tilfellið þar sem gömul færsla skyggndi stefnuvillu; gallinn kemur venjulega aftur við næstu breytingu, tengilslökk eða leiðardrátt.
Fyrir hvaða viðhaldsglugga sem er skaltu fanga það sem endurræsingin mun eyða. Þessar þrjár skipanir duga til að bera saman fyrir og eftir, og þær breyta engu á tækinu.
show evpn database instance blue
show route table bgp.evpn.0
show version
Geymdu þessi úttök með dagsetningunni og hugbúnaðarútgáfunni við hliðina. Seinna skýrsla um að sama endurræsing hafi virkað áður er vísbending frekar en sönnun, og munurinn verður aðeins sýnilegur þegar einhver geymdi fyrra úttakið.
Fjórar athuganir sem ráða flestum tilfellum
Fjórar athuganir ná yfir nær hvert tilfelli: tengingin og þjónusta hennar, MAC sem sýnigildi, staða leiðar og gagnagrunns og útgáfan sem er í notkun. Veldu MAC sem er augljóslega sýnidæmi svo enginn ruglist á því við framleiðsluvistfang: fyrsti oktett 02 merkir staðbundið stýrt unicast-vistfang, hinir oktettarnir eru lausir, og því er 02:00:00:00:00:5c öruggur staðgengill.
Láttu þá svörin vísa á stigið sem brást. Ekkert nám við tenginguna þýðir aðgangshliðina; leið án færslu í gagnagrunni þýðir innflutning; færsla í gagnagrunni án framsendingarástands þýðir forritun. Hvað sem það reynist vera, afhentu söfnuðu úttökin ásamt hýslinum, viðmótinu, þjónustunni og útgáfunni, svo næsti verkfræðingur geti endurskapað leiðina í stað þess að endurtaka fyrirspurnina.