EIGRP kaimynas ar DMVPN tranzitas? Pirmiausia patikrinkite vaidmenį

Kaimynystės nėra, o vidurinis maršrutizatorius atrodo akivaizdus įtariamasis. Jis gali būti nekaltas. Išorinių tunelio paketų persiuntimas ir dalyvavimas overlay maršrutizavimo protokole yra du skirtingi darbai, ir įrenginys gali atlikti pirmąjį neatlikdamas antrojo. Atlikite penkis patikrinimus žemiau iš eilės ir sustokite ties pirmuoju, kuris nepavyksta.

1 žingsnis: nubraižykite du vaidmenis

Nubraižykite numatomą EIGRP kaimynystę kaip loginį ryšį tarp dviejų maršrutizatorių, tada nubraižykite underlay maršrutizatorius, kurie perneša jos tunelio paketus. Tas pats įrenginys neturi būti abiejuose sąrašuose, o sąrašų painiojimas yra dažniausia priežastis, kodėl sveikas tranzitinis maršrutizatorius kaltinamas kaimynystės sugadinimu.

Tranzitinis maršrutizatorius persiunčia išorinius paketus įprastu IP maršrutizavimu ir politika. Jam nereikia vykdyti protokolo, pernešamo apsaugoto tunelio viduje, ir nereikia EIGRP proceso tiems paketams perduoti toliau.

2 žingsnis: patikrinkite, ką užbaigia vidurinis įrenginys

Jei vidurinis maršrutizatorius užbaigia tunelį ir turi sudaryti EIGRP kaimynystes su spoke, atsakymas visiškai pasikeičia. Tam įrenginiui reikia palaikomo overlay maršrutizavimo elgesio, o pavadinus jį tranzitu kaimyno reikalavimas nepradingsta. Skaitykite tunelio konfigūraciją prieš maršrutizavimo konfigūraciją. Tas atsakymas nulemia kiekvieną tolesnį patikrinimą.

Taigi pirmas tikras klausimas yra ne kurį protokolą derinti. Klausimas, ar dėžutė yra hub, spoke, grynas underlay šuolis ar Layer 2 paslauga, pernešanti kadrus tarp galinių taškų.

3 žingsnis: patikrinkite kaimyno valdymo plokštumą

Kiekviename įrenginyje, kuris turėtų būti kaimynas, patvirtinkite keturis dalykus: EIGRP egzempliorių ir autonominės sistemos numerį, autentifikavimo parametrus, sąsają, dalyvaujančią procese, ir tinklo teiginį, apimantį tą sąsają. Bet kurio iš jų neatitikimas palaiko kaimynystę išjungtą, kol sąsaja lieka įjungta ir ping veikia toliau.

RFC 7868 apibūdina EIGRP kaip IP protokolą su multicast valdymo mainais, todėl kaimyninis ryšys nėra tai, ką tarpinis maršrutizatorius galėtų pakeisti maršrutizuodamas paketus link paskirties. Arba valdymo mainai pasiekia partnerį, arba kaimynystė nesusidaro.

4 žingsnis: patikrinkite, ar transportas pristato valdymo mainus

Toliau patikrinkite, ar overlay tikrai perneša valdymo srautą tarp numatytų galinių taškų. Išnagrinėkite partnerio NHRP susiejimą ir išorinį maršrutą, vedantį link jo, tada patvirtinkite, kad tunelio sąsaja įjungta ir praleidžia srautą. Sėkmingas underlay ping įrodo, kad išorinis kelias egzistuoja; tai neįrodo, kad overlay valdymo mainai buvo pristatyti.

Skaidri Layer 2 paslauga, taškas-taškas tunelis ir kelių taškų DMVPN debesis multicast perduoda skirtingai. Vadovaukitės palaikomu sąsajos, NHRP ir multicast modeliu tam, kas iš tikrųjų įdiegta, o ne manykite, kad visi trys elgiasi vienodai.

5 žingsnis: perprojektuokite ribą, jei ji negali dalyvauti

Jei reikalingas overlay įrenginys negali vykdyti protokolo, pakeiskite projektą aiškiai. Toje riboje naudokite palaikomą protokolą arba mainų modelį, arba įrenkite tinkamą tunelį nuo galo iki galo, kad kaimynai būtų tie galiniai taškai, kurie tikrai kalba vieni su kitais. Nemanikite, kad statinis maršrutas ne dalyvį paverčia kiekvieno valdymo paketo retransliatoriumi.

Diagramoje užrašykite kiekvieno įrenginio vaidmenį ir saugokite jį kartu su konfigūracija. RFC 7868 apibrėžia protokolo mainus, ir ta apibrėžtis yra nuoroda, kodėl kaimyninio ryšio negalima imituoti tranzitiniu persiuntimu.

Kai kaimynystė vis dar nepavyksta po visų penkių patikrinimų, likę įtariamieji yra platformos funkcijos, pavyzdžiui, multicast tvarkymas tunelio sąsajoje ir politika, filtruojanti 88 protokolą. Tai konkretūs, patikrinami veiksniai, ir jie verti daugiau nei dar vienas ratas kaltinti vidurinį maršrutizatorių.