EIGRP naaber või DMVPN transiit? Kontrollige kõigepealt rolli

Naabrus puudub ja keskel olev ruuter tundub ilmselge kahtlusalune. See võib olla süütu. Väliste tunnelipakettide edasisaatmine ja overlay-marsruutimisprotokollis osalemine on kaks eri tööd ning seade võib teha esimest tegemata teist. Käige allolevad viis kontrolli järjekorras läbi ja peatuge esimesel, mis ebaõnnestub.

Samm 1: joonistage kaks rolli

Joonistage kavandatud EIGRP naabrus kahe ruuteri vahelise loogilise ühendusena, seejärel joonistage underlay-ruuterid, mis kannavad selle tunnelipakette. Sama seade ei pea esinema mõlemas loendis ja loendite segiajamine on kõige tavalisem põhjus, miks tervet transiitruuterit süüdistatakse naabruse rikkumises.

Transiitruuter saadab väliseid pakette edasi oma tavalise IP-marsruutimise ja poliitikaga. Tal ei ole vaja käivitada kaitstud tunneli sees kantavat protokolli ja nende pakettide edasisaatmiseks ei ole vaja ka EIGRP protsessi.

Samm 2: kontrollige, mida keskmine seade lõpetab

Kui keskmine ruuter lõpetab tunneli ja peaks looma EIGRP naabrusi spoke-seadmetega, muutub vastus täielikult. See seade vajab toetatud overlay-marsruutimiskäitumist ja transiidiks nimetamine ei kõrvalda naabrinõuet. Lugege tunneli konfiguratsiooni enne marsruutimise konfiguratsiooni. See vastus määrab iga järgneva kontrolli.

Esimene tõeline küsimus ei ole seega, millist protokolli häälestada. Küsimus on, kas seade on jaotur, spoke, puhas underlay-hüpe või Layer 2 teenus, mis kannab kaadreid lõpp-punktide vahel.

Samm 3: kontrollige naabri juhtimistasandit

Igas seadmes, mis peaks olema naaber, kinnitage neli asja: EIGRP instants ja autonoomse süsteemi number, autentimise parameetrid, protsessis osalev liides ja seda liidest kattev võrgukäsk. Erinevus ükskõik millises neist hoiab naabruse maas, samal ajal kui liides jääb üles ja ping töötab edasi.

RFC 7868 kirjeldab EIGRP-d kui IP-protokolli multicast-juhtimisvahetusega, mistõttu naabersuhe ei ole midagi, mida vahepealne ruuter saaks pakette sihtkohta marsruutides asendada. Kas juhtimisvahetus jõuab partnerini või naabrust ei teki.

Samm 4: kontrollige, kas transport toimetab juhtimisvahetuse kohale

Järgmisena kontrollige, kas overlay kannab juhtimisliiklust tõesti kavandatud lõpp-punktide vahel. Uurige partneri NHRP-vastendust ja välismarsruuti, mis selleni viib, seejärel kinnitage, et tunneliliides on üles ja laseb liiklust läbi. Õnnestunud underlay-ping tõestab, et väline tee on olemas; see ei tõesta, et overlay juhtimisvahetus kohale toimetati.

Läbipaistev Layer 2 teenus, punkt-punkt-tunnel ja mitmepunktiline DMVPN pilv toimetavad multicast’i erinevalt. Järgige tegelikult juurutatud lahenduse puhul toetatud liidese-, NHRP- ja multicast-mudelit, selle asemel et eeldada, et kõik kolm käituvad ühtemoodi.

Samm 5: kujundage piir ümber, kui see ei saa osaleda

Kui vajalik overlay-seade ei saa protokolli käivitada, muutke projekti selgesõnaliselt. Kasutage sellel piiril toetatud protokolli või vahetusmudelit või korraldage sobiv otsast-otsani tunnel, et naabriteks oleksid lõpp-punktid, mis tegelikult omavahel räägivad. Ärge eeldage, et staatiline marsruut muudab mitteosaleja iga juhtimispaketi releeks.

Märkige diagrammil iga seadme roll ja hoidke seda koos konfiguratsiooniga. RFC 7868 protokollivahetuse määratlus on viide sellele, miks naabersuhet ei saa transiitmarsruutimisega simuleerida.

Kui naabrus ei teki ka pärast kõiki viit kontrolli, on allesjäänud kahtlusalused platvormi funktsioonid, nagu multicast’i käsitlemine tunneliliidesel ja poliitika, mis filtreerib protokolli 88. Need on konkreetsed ja testitavad põhjused ning need on väärt rohkem kui veel üks voor keskmise ruuteri süüdistamist.