EIGRP-nágranni eða DMVPN-flutningur? Athugaðu hlutverkið fyrst

Nágrannatengingin vantar, og beinirinn í miðjunni virðist augljósasti grunurinn. Hann getur verið saklaus. Að senda ytri göngupakkana áfram og taka þátt í overlay-beiningarreglunni eru tvö ólík verk, og tæki getur gert það fyrra án þess að gera hið síðara. Farðu í gegnum fimm prófanirnar hér að neðan í réttri röð og stöðvaðu við þá fyrstu sem mistekst.

Skref 1: teiknaðu hlutverkin tvö

Teiknaðu fyrirhugaða EIGRP-nágrannatengingu sem rökrétta tengingu milli tveggja beinna og teiknaðu síðan underlay-beinana sem bera göngupakka hennar. Sama tækið þarf ekki að koma fram á báðum listunum, og að rugla listunum er algengasta ástæðan fyrir því að heilbrigður flutningsbeinir er sakaður um að brjóta nágrannatenginguna.

Flutningsbeinir sendir ytri pakkana áfram með venjulegri IP-beiningu og stefnu sinni. Hann þarf ekki að keyra regluna sem er flutt inni í varðaða göngunni, og þarf ekki EIGRP-ferli til að koma þessum pökkum áfram.

Skref 2: athugaðu hvað miðtækið lýkur

Ef beinirinn í miðjunni lýkur göngunni og á að mynda EIGRP-nágrannatengingar við spoke, breytist svarið algjörlega. Það tæki þarf studda overlay-beiningarhegðun, og að kalla það flutning eyðir ekki nágrannakröfunni. Lestu göngustillinguna á undan beiningarstillingunni. Það svar ræður hverri prófun sem á eftir kemur.

Fyrsta raunverulega spurningin er því ekki hvaða reglu eigi að stilla. Hún er hvort kassinn sé hub, spoke, hrein underlay-hopp eða Layer 2 þjónusta sem ber ramma milli endapunkta.

Skref 3: staðfestu stjórnplan nágrannans

Á hverju tæki sem á að vera nágranni skaltu staðfesta fjóra hluti: EIGRP-tilvikið og númer sjálfstæða kerfisins, auðkenningarbreyturnar, viðmótið sem tekur þátt í ferlinu og nettengdu fullyrðinguna sem nær yfir það viðmót. Misræmi í einhverju þeirra heldur nágrannatengingunni niðri á meðan viðmótið helst uppi og ping heldur áfram að virka.

RFC 7868 lýsir EIGRP sem IP-reglu með multicast-stjórnskiptum, og þess vegna er nágrannasamband ekki eitthvað sem millibeinir getur komið í staðinn fyrir með því að beina pökkum að áfangastað. Annaðhvort nær stjórnskiptin til jafningjans eða nágrannatengingin myndast ekki.

Skref 4: staðfestu að flutningurinn skili stjórnskiptunum

Athugaðu næst hvort overlayið beri stjórnunarumferðina á milli fyrirhuguðu endapunktanna. Skoðaðu NHRP-kortlagningu jafningjans og ytri leiðina sem nær til hans, og staðfestu síðan að gönguviðmótið sé uppi og hleypi umferð í gegn. Árangursríkt underlay-ping sannar að ytri leiðin sé til; það sannar ekki að búið sé að skila stjórnskiptum overlaysins.

Gegnsæ Layer 2 þjónusta, punkt-til-punkt göng og margpunkta DMVPN-ský skila multicast á ólíkan hátt. Fylgdu studdu viðmóts-, NHRP- og multicast-líkaninu fyrir það sem raunverulega er notað í stað þess að gera ráð fyrir að öll þrjú hagi sér eins.

Skref 5: hannaðu landamærin upp á nýtt ef þau geta ekki tekið þátt

Ef nauðsynlegt overlay-tæki getur ekki keyrt regluna skaltu breyta hönnuninni með skýrum hætti. Notaðu studda reglu eða skiptimódel við þau landamæri, eða útvegaðu viðeigandi göng frá enda til enda svo nágrannarnir séu endapunktarnir sem tala í raun hver við annan. Ekki gera ráð fyrir að stök leið breyti aðila sem ekki tekur þátt í endurvarpa fyrir hvern stjórnpakka.

Skráðu hlutverk hvers tækis á skýringarmyndinni og geymdu það með stillingunni. RFC 7868-skilgreiningin á reglunni er tilvísunin fyrir því hvers vegna ekki er hægt að herma nágrannasambandið með flutningsbeiningum.

Þegar nágrannatengingin mistekst enn eftir allar fimm prófanirnar eru eftirstöðvar grunsemdir eiginleikar vettvangsins eins og multicast-meðferð á gönguviðmótinu og stefna sem síar reglu 88. Það eru ákveðnar, prófanlegar orsakir, og þær eru meira virði en önnur umferð þar sem beinirnum í miðjunni er kennt um.