Hiërargyske DMVPN: ien wolk per tunnelrelaasje

In filiaalknooppunt registrearret him mei sukses by syn regionale hub en kin dochs gjin tsjinst yn in oare regio berikke. De tunnel is oan, de NHS-steat liket sûn, en de flater ferskynt allinnich by bestimmingen dy't in laachgrins oerstekke. Dat patroan betsjut meastentiids dat it ûntwerp nea sei hokker apparaten oan hokker DMVPN-wolk meidogge, sadat de lagen op yntuysje boud binne en no net mear oerienkomme.

It symptoom ferskynt by de laachgrins

Yn in hiërargysk ûntwerp hawwe in sintrale hub, ferskate regionale hubs en in protte filiaalknooppunten elk in posysje. In regionale hub kin mear as ien tunnelrelaasje hawwe, en filialen hoege har net by elk sintraal einpunt te registrearjen. De paden dy't ta sizze binne, binne fan filiaal nei regionale tsjinst, fan filiaal nei in oar goedkard regionaal knooppunt, en fan filiaal nei in sintraal bestimming.

As ien fan dy paden mislearret wylst de oaren wurkje, is it probleem hast altyd in ûntbrekkende of tsjinstridige roldefinysje en net in brutsen tunnel. Skriuw de bedoelde paden op en fergelykje se mei wat de apparaten feitlik boud hawwe. Dy fergeliking duorret in oere en foarkomt in wike fan rieden. Bewarje se by it ûntwerpdokumint.

Ien wolk, ien ynterfacekontrakt

Registrearje foar elke wolk de tunnelinterface, de boppelizzende adressering, de lokale boarne fan it ûnderlizzende netwurk, de NHS- en NBMA-relaasjes, multicast-levering en it beskermingsbelied. Jou ek oan hokker rûtes tusken de regionale en sintrale konteksten oergean, want dy sin is it ûntwerp.

In regionale hub mei twa tunnelinterfaces hat twa kontrakten nedich, net ien mei twa adressen. De boarne fan it ûnderlizzende netwurk, it NHRP-domein en de rûtes kinne per interface ferskille, en in dokumint dat se gearfoeget sil dyjinge misliede dy't de twadde konfigurearret.

ID's binne lokale kontekst, gjin tagongsbehear

NHRP-netwurk-ID's en GRE-kaaien binne de twa wearden dy't it meast foar globale ynstellings oansjoen wurde. De IOS XE NHRP-gids beskriuwt de netwurk-ID as lokaal betsjuttingsfol, dus oerienkommende nûmers op fierte routers bewize neat en it feroarjen fan it lokale nûmer fan ien router skept gjin tagongsgrins.

In GRE-kaai, wêr't it ûntwerp ien brûkt, helpt by it identifisearjen fan 'e kontekst fan 'e ûntfangende tunnel, en der wurdt oerienkommen tusken de einpunten dy't dy kontekst diele. It is gjin wachtwurd en ferfangt gjin IKE-autentikaasje of routingbelied. Behannelje beide wearden as konfiguraasjekontekst dy't binnen in relaasje oerienkomme moat, net as feiligensmaatregels dy't regio's skiede.

Routearje mei opsetsin tusken lagen

Beslis hokker prefiksen de regionale hub omheech oankundiget en hokker sintrale bestimmingen er oan syn filialen biedt. Kontrolearje dan de wiere folgjende hop en it fasespesifike flugge paad foar elk paad, want in gearfettingsrûte en in fluch paad kinne hiel oare trochstjoering jouwe as it diagram suggerearret.

Brûk routing en tagongsbelied om regionale skieding te twingjen. As in filiaal in oare regio net direkt berikke mei, moatte de rûte en it belied dat sizze, ynstee fan te fertrouwen op in ID dat nea ûntwurpen is om dat te twingjen. Skriuw it belied njonken it ID. Oars sil de folgjende yngenieur oannimme dat it nûmer it wurk docht.

Diagnostisearje it ûnferwachte flugge paad

As in filiaal besiket in direkte relaasje mei in sintraal einpunt te meitsjen, ûndersykje dan syn rûte, syn NHRP-mapping en de keazen tunnelkontekst foardat jo ID's willekeurich feroarje. Ûntbrekkende berikberens, in ûnbedoelde NHS-relaasje en in legaal mar net autorisearre fluch paad freegje trije ferskillende korreksjes.

De DMVPN-konfiguraasjegids toant de tunnel- en NHRP-ynstellings byinoar, en krekt dêrom moatte de omfangen earst op papier skieden wurde. Registrearje de wolkekontrakten, hâld de laachrûtes eksplisyt, en de folgjende grinsflater sil in plak hawwe om nei te wizen.