Hiërarchische DMVPN: één cloud per tunnelrelatie

Een filiaalknooppunt registreert zich met succes bij zijn regionale hub en kan toch geen dienst in een andere regio bereiken. De tunnel is actief, de NHS-status ziet er gezond uit, en de storing verschijnt alleen voor bestemmingen die een laaggrens overschrijden. Dat patroon betekent meestal dat het ontwerp nooit heeft vastgelegd welke apparaten aan welke DMVPN-cloud deelnemen, dus de lagen zijn op intuïtie gebouwd en komen nu niet meer overeen.

Het symptoom verschijnt bij de laaggrens

In een hiërarchisch ontwerp hebben een centrale hub, meerdere regionale hubs en veel filiaalknooppunten elk een positie. Een regionale hub kan meer dan één tunnelrelatie bezitten, en filialen hoeven zich niet bij elk centraal eindpunt te registreren. De paden die ertoe doen, zijn filiaal naar regionale dienst, filiaal naar een ander goedgekeurd regionaal knooppunt, en filiaal naar een centrale bestemming.

Wanneer een van die paden faalt terwijl de andere werken, is het probleem bijna altijd een ontbrekende of tegenstrijdige roldefinitie en niet een kapotte tunnel. Schrijf de bedoelde paden op en vergelijk ze met wat de apparaten werkelijk hebben gebouwd. Die vergelijking kost een uur en voorkomt een week gissen. Bewaar hem bij het ontwerpdossier.

Eén cloud, één interfacecontract

Noteer per cloud de tunnelinterface, de overlay-adressering, de lokale underlay-bron, de NHS- en NBMA-relaties, de multicast-levering en het beschermingsbeleid. Geef ook aan welke routes tussen de regionale en centrale context lopen, want juist die zin is het ontwerp.

Een regionale hub met twee tunnelinterfaces heeft twee contracten nodig, niet één met twee adressen. De underlay-bron, het NHRP-domein en de routes kunnen per interface verschillen, en een document dat ze samenvoegt, misleidt wie de tweede configureert.

ID's zijn lokale context, geen toegangscontrole

NHRP-netwerk-ID's en GRE-sleutels zijn de twee waarden die het vaakst ten onrechte voor globale instellingen worden aangezien. De IOS XE NHRP-gids beschrijft de netwerk-ID als lokaal betekenisvol, dus overeenkomende nummers op externe routers authenticeren niets en het wijzigen van het lokale nummer van één router creëert geen toegangsgrens.

Een GRE-sleutel, waar het ontwerp er een gebruikt, helpt de context van de ontvangende tunnel te identificeren, en hij wordt afgesproken tussen de eindpunten die die context delen. Het is geen wachtwoord en vervangt IKE-authenticatie noch routeringsbeleid niet. Behandel beide waarden als configuratiecontext die binnen een relatie moet overeenkomen, niet als beveiligingsmaatregelen die regio's scheiden.

Routeer bewust tussen de lagen

Bepaal welke prefixen de regionale hub omhoog adverteert en welke centrale bestemmingen hij aan zijn filialen biedt. Controleer daarna de werkelijke volgende hop en het fasespecifieke snelkoppelingsgedrag voor elk pad, want een samenvattingsroute en een snelkoppeling kunnen een heel andere doorsturing opleveren dan het diagram suggereert.

Gebruik routering en toegangsbeleid om regionale scheiding af te dwingen. Als een filiaal een andere regio niet rechtstreeks mag bereiken, moeten de route en het beleid dat zeggen, in plaats van te vertrouwen op een ID die nooit ontworpen is om dat af te dwingen. Schrijf het beleid naast de ID. Anders gaat de volgende ingenieur ervan uit dat het nummer het werk doet.

Diagnostiseer de onverwachte snelkoppeling

Wanneer een filiaal een directe relatie met een centraal eindpunt probeert te maken, onderzoek dan de route, de NHRP-mapping en de gekozen tunnelcontext voordat je ID's willekeurig wijzigt. Ontbrekende bereikbaarheid, een onbedoelde NHS-relatie en een legitieme maar niet-geautoriseerde snelkoppeling vragen drie verschillende correcties.

De DMVPN-configuratiegids toont de tunnel- en NHRP-instellingen samen, en daarom moeten de scopes eerst op papier worden gescheiden. Leg de cloudcontracten vast, houd de laagroutes expliciet, en de volgende grensfout heeft een plek om naar te wijzen.