EIGRP-najbaro aŭ DMVPN-transito? Unue kontrolu la rolon

La najbareco mankas, kaj la enkursigilo en la mezo ŝajnas la evidenta suspektato. Ĝi povas esti senkulpa. Plusendi la eksterajn tunelajn pakaĵojn kaj partopreni en la overlay-enkursiga protokolo estas du malsamaj taskoj, kaj aparato povas fari la unuan sen fari la duan. Trapasu la kvin kontrolojn sube laŭorde kaj haltu ĉe la unua, kiu malsukcesas.

Paŝo 1: desegnu la du rolojn

Desegnu la celatan EIGRP-najbarecon kiel logikan ligon inter du enkursigiloj, poste desegnu la underlay-enkursigilojn, kiuj portas ĝiajn tunelajn pakaĵojn. La sama aparato ne devas aperi en ambaŭ listoj, kaj konfuzi la listojn estas la plej ofta kaŭzo, kial sana transit-enkursigilo estas akuzata pri rompo de la najbareco.

Transit-enkursigilo plusendas la eksterajn pakaĵojn per sia ordinara IP-enkursigado kaj politiko. Ĝi ne devas ruli la protokolon portatan ene de la protektita tunelo, kaj ĝi ne bezonas EIGRP-procezon por plusendi tiujn pakaĵojn.

Paŝo 2: kontrolu, kion finigas la meza aparato

Se la meza enkursigilo finigas la tunelon kaj devas formi EIGRP-najbarecojn kun spoke-aparatoj, la respondo tute ŝanĝiĝas. Tiu aparato bezonas la subtenatan overlay-enkursigan konduton, kaj nomi ĝin transito ne forigas la najbaran postulon. Legu la tunelan agordon antaŭ la enkursigan agordon. Tiu respondo decidas ĉiun sekvan kontrolon.

Do la unua reala demando ne estas, kiun protokolon agordi. Ĝi estas, ĉu la skatolo estas hub, spoke, pura underlay-hopo aŭ Layer 2-servo, kiu portas kadrojn inter finpunktoj.

Paŝo 3: kontrolu la regan ebenon de la najbaro

Sur ĉiu aparato, kiu devus esti najbaro, konfirmu kvar aferojn: la EIGRP-instancon kaj la numeron de la aŭtonoma sistemo, la aŭtentigajn parametrojn, la interfacon partoprenantan en la procezo, kaj la retan deklaron, kiu kovras tiun interfacon. Miskongruo en iu ajn el ili tenas la najbarecon mallevita, dum la interfaco restas levita kaj la ping daŭre funkcias.

RFC 7868 priskribas EIGRP kiel IP-protokolon kun multicast-kontrolinterŝanĝo, kaj tial najbara rilato ne estas io, kion intera enkursigilo povas prokuri per enkursigado de pakaĵoj al celo. Aŭ la kontrolinterŝanĝo atingas la samtavolanon, aŭ la najbareco ne formiĝas.

Paŝo 4: kontrolu, ĉu la transporto liveras la kontrolinterŝanĝon

Poste, kontrolu, ĉu la overlay efektive portas la kontroltrafikon inter la celataj finpunktoj. Ekzamenu la NHRP-mapadon por la samtavolano kaj la eksteran vojon, kiu atingas ĝin, poste konfirmu, ke la tunela interfaco estas levita kaj trapasas trafikon. Sukcesa underlay-ping pruvas, ke la ekstera vojo ekzistas; ĝi ne pruvas, ke la overlay-kontrolinterŝanĝo estis liverita.

Travidebla Layer 2-servo, punkto-al-punkta tunelo kaj plurpunkta DMVPN-nubo liveras multicast-on malsame. Sekvu la subtenatan interfacan, NHRP kaj multicast-modelon por tiu, kiu efektive estas deplojita, anstataŭ supozi, ke ĉiuj tri kondutas egale.

Paŝo 5: reprojektu la limon, se ĝi ne povas partopreni

Se bezonata overlay-aparato ne povas ruli la protokolon, ŝanĝu la dezajnon eksplice. Uzu subtenatan protokolon aŭ interŝanĝan modelon ĉe tiu limo, aŭ aranĝu taŭgan fin-al-finan tunelon, por ke la najbaroj estu la finpunktoj, kiuj efektive parolas unu al la alia. Ne supozu, ke statika vojo igas nepartoprenanton ripetilo por ĉiu kontrolpakaĵo.

Notu la rolon de ĉiu aparato en la diagramo kaj konservu ĝin kun la agordo. La RFC 7868-difino de la protokola interŝanĝo estas la referenco por kial la najbara rilato ne povas esti simulata per transit-enkursigado.

Kiam la najbareco ankoraŭ malsukcesas post ĉiuj kvin kontroloj, la restantaj suspektatoj estas platformaj trajtoj kiel multicast-traktado sur la tunela interfaco kaj politiko, kiu filtras protokolon 88. Tiuj estas konkretaj, testeblaj kaŭzoj, kaj ili valoras pli ol plia raŭndo da kulpigo de la meza enkursigilo.