Йерархичен DMVPN: един облак за всяка тунелна връзка

Филиален възел се регистрира успешно в регионалния си център и все още не може да достигне услуга в друг регион. Тунелът е активен, състоянието на NHS изглежда здраво, а отказът се появява само за дестинации, които пресичат граница на ниво. Този модел обикновено означава, че проектът никога не е посочвал кои устройства участват в кой DMVPN облак, затова нивата са изградени по интуиция и сега не съвпадат.

Симптомът се появява на границата на нивата

В йерархичен проект централен център, няколко регионални центъра и много филиални възли заемат всеки своя позиция. Регионалният център може да притежава повече от една тунелна връзка и филиалите не е нужно да се регистрират във всяка централна крайна точка. Пътищата, които имат значение, са от филиал до регионална услуга, от филиал до друг одобрен регионален възел и от филиал до централна дестинация.

Когато един от тези пътища се провали, докато останалите работят, проблемът почти винаги е липсващо или противоречиво определение на роля, а не счупен тунел. Запишете предвидените пътища и ги сравнете с това, което устройствата действително са изградили. Това сравнение отнема един час и предотвратява седмица на догадки. Пазете го заедно с проекта.

Един облак, един интерфейсен договор

За всеки облак запишете тунелния интерфейс, адресирането на горния слой, локалния източник на базовата мрежа, връзките NHS и NBMA, многоадресната доставка и политиката за защита. Посочете също кои маршрути пресичат между регионалния и централния контекст, защото точно това изречение е проектът.

Регионален център с два тунелни интерфейса се нуждае от два договора, а не от един с два адреса. Източникът на базовата мрежа, домейнът NHRP и маршрутите могат да се различават за всеки интерфейс и документ, който ги обединява, ще подведе този, който конфигурира втория.

Идентификаторите са локален контекст, а не контрол на достъпа

Мрежовите идентификатори на NHRP и GRE ключовете са двете стойности, най-често бъркани с глобални настройки. Ръководството за NHRP в IOS XE описва мрежовия идентификатор като локално значим, така че съвпадащите номера на отдалечени маршрутизатори не удостоверяват нищо и промяната на локалния номер на един маршрутизатор не създава граница за достъп.

GRE ключ, когато проектът използва такъв, помага да се идентифицира контекстът на приемащия тунел и се договаря между крайните точки, които споделят този контекст. Той не е парола и не замества удостоверяването с IKE или маршрутната политика. Третирайте двете стойности като конфигурационен контекст, който трябва да съвпада в рамките на връзката, а не като средства за сигурност, които разделят региони.

Маршрутизирайте между нивата умишлено

Решете кои префикси регионалният център обявява нагоре и кои централни дестинации предлага на своите филиали. След това проверете действителния следващ хоп и поведението на прекия път, специфично за фазата, за всеки път, защото обобщеният маршрут и прекият път могат да дадат много различно препращане от това, което подсказва диаграмата.

Използвайте маршрутизация и политика за достъп, за да наложите регионално разделяне. Ако филиал не трябва да достига директно до друг регион, маршрутът и политиката трябва да го казват, вместо да се разчита на идентификатор, който никога не е бил проектиран да го налага. Запишете политиката до идентификатора. Иначе следващият инженер ще предположи, че номерът върши работата.

Диагностицирайте неочаквания преки път

Когато филиал се опитва да създаде директна връзка с централна крайна точка, прегледайте неговия маршрут, неговото NHRP съпоставяне и избрания тунелен контекст, преди да променяте идентификаторите произволно. Липсваща достижимост, нежелана NHS връзка и законен, но неразрешен преки път изискват три различни корекции.

Ръководството за конфигуриране на DMVPN показва настройките на тунела и NHRP заедно и точно затова обхватите трябва първо да се разделят на хартия. Запишете договорите на облака, поддържайте маршрутите на нивата явни и следващият отказ на границата ще има къде да сочи.