Sosed EIGRP ali tranzit DMVPN? Najprej preverite vlogo

Sosedstva ni, vmesni usmerjevalnik pa je videti očiten osumljenec. Morda je nedolžen. Posredovanje zunanjih paketov tunela in sodelovanje v protokolu usmerjanja overlay sta dve različni opravili, naprava pa lahko opravi prvo brez drugega. Izvedite pet spodnjih preverjanj po vrsti in ustavite se pri prvem, ki spodleti.

Korak 1: narišite dve vlogi

Narišite predvideno sosedstvo EIGRP kot logično povezavo med dvema usmerjevalnikoma, nato narišite usmerjevalnike underlay, ki prenašajo njegove pakete tunela. Ista naprava ni nujno na obeh seznamih, zamenjava seznamov pa je najpogostejši razlog, da je zdrav tranzitni usmerjevalnik obtožen, da je pokvaril sosedstvo.

Tranzitni usmerjevalnik posreduje zunanje pakete s svojim običajnim usmerjanjem IP in politiko. Ni mu treba poganjati protokola, ki se prenaša znotraj zaščitenega tunela, in ne potrebuje procesa EIGRP, da bi te pakete poslal naprej.

Korak 2: preverite, kaj končuje vmesna naprava

Če vmesni usmerjevalnik končuje tunel in naj bi tvoril sosedstva EIGRP s spoke, se odgovor popolnoma spremeni. Ta naprava potrebuje podprto vedenje usmerjanja overlay, in če jo imenujemo tranzit, to ne odpravi zahteve po sosedu. Preberite konfiguracijo tunela pred konfiguracijo usmerjanja. Ta odgovor določi vsako naslednje preverjanje.

Prvo resnično vprašanje torej ni, kateri protokol nastaviti. Je, ali je škatla hub, spoke, čist skok underlay ali storitev Layer 2, ki prenaša okvire med končnimi točkami.

Korak 3: preverite krmilno ravnino soseda

Na vsaki napravi, ki bi morala biti sosed, potrdite štiri stvari: instanco EIGRP in številko avtonomnega sistema, parametre overjanja, vmesnik, ki sodeluje v procesu, in omrežno izjavo, ki pokriva ta vmesnik. Neujemanje v kateri koli od njih drži sosedstvo spodaj, medtem ko vmesnik ostane zgoraj in ping še deluje.

RFC 7868 opisuje EIGRP kot protokol IP z multicast izmenjavo nadzora, zato sosedski odnos ni nekaj, kar bi vmesni usmerjevalnik lahko nadomestil z usmerjanjem paketov proti cilju. Bodisi izmenjava nadzora doseže partnerja bodisi sosedstvo ne nastane.

Korak 4: preverite, ali transport dostavi izmenjavo nadzora

Nato preverite, ali overlay resnično prenaša nadzorni promet med predvidenimi končnimi točkami. Preglejte preslikavo NHRP za partnerja in zunanjo pot, ki vodi do njega, nato potrdite, da je vmesnik tunela zgoraj in prepušča promet. Uspešen ping underlay dokazuje, da zunanja pot obstaja; ne dokazuje, da je bila izmenjava nadzora overlay dostavljena.

Pregledna storitev Layer 2, tunel od točke do točke in večtočkovni oblak DMVPN dostavljajo multicast različno. Sledite podprtemu modelu vmesnika, NHRP in multicasta za tisto, kar je dejansko nameščeno, namesto da predpostavljate, da se vsi trije vedejo enako.

Korak 5: preoblikujte mejo, če ne more sodelovati

Če zahtevana naprava overlay ne more poganjati protokola, spremenite zasnovo izrecno. Uporabite podprt protokol ali model izmenjave na tej meji ali uredite ustrezen tunel od konca do konca, da so sosedje končne točke, ki se resnično pogovarjajo med seboj. Ne predpostavljajte, da statična pot spremeni nesodelujočega v posredovalnik vsakega nadzornega paketa.

Zabeležite vlogo vsake naprave na diagramu in jo hranite s konfiguracijo. RFC 7868 določa izmenjavo protokola in ta opredelitev je referenca za to, zakaj sosedskega odnosa ni mogoče simulirati s tranzitnim posredovanjem.

Ko sosedstvo tudi po vseh petih preverjanjih spodleti, so preostali osumljenci funkcije platforme, kot sta obravnava multicasta na vmesniku tunela in politika, ki filtrira protokol 88. To so konkretni, preverljivi vzroki in so vredni več kot še en krog krivde na vmesni usmerjevalnik.