Ієрархічний DMVPN: одна хмара на кожне тунельне відношення

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

Симптом проявляється на межі рівнів

В ієрархічному проєкті центральний концентратор, кілька регіональних концентраторів і безліч філіальних вузлів займають кожен свою позицію. Регіональний концентратор може володіти більш ніж одним тунельним відношенням, а філіям не потрібно реєструватися на кожній центральній кінцевій точці. Важливі шляхи — від філії до регіонального сервісу, від філії до іншого схваленого регіонального вузла і від філії до центрального призначення.

Коли один із цих шляхів відмовляє, а інші працюють, проблема майже завжди в відсутньому або суперечливому визначенні ролі, а не в зламаному тунелі. Запишіть передбачувані шляхи й порівняйте їх із тим, що пристрої справді побудували. Це порівняння займає годину й запобігає тижню здогадок. Зберігайте його разом із проєктним документом.

Одна хмара, один контракт інтерфейсу

Для кожної хмари зафіксуйте інтерфейс тунелю, адресацію верхнього рівня, локальне джерело базової мережі, відносини NHS і NBMA, багатоадресну доставку та політику захисту. Укажіть також, які маршрути проходять між регіональним і центральним контекстами, бо саме це речення і є проєкт.

Регіональному концентратору з двома тунельними інтерфейсами потрібні два контракти, а не один із двома адресами. Джерело базової мережі, домен NHRP і маршрути можуть відрізнятися для кожного інтерфейсу, і документ, що їх об'єднує, введе в оману того, хто налаштовує другий.

Ідентифікатори — локальний контекст, а не контроль доступу

Ідентифікатори мережі NHRP і ключі GRE — це два значення, які найчастіше помилково вважають глобальними налаштуваннями. Посібник з NHRP в IOS XE описує ідентифікатор мережі як локально значущий, тому однакові номери на віддалених маршрутизаторах нічого не автентифікують, а зміна локального номера одного маршрутизатора не створює межі доступу.

Ключ GRE, якщо проєкт його використовує, допомагає визначити контекст приймального тунелю й узгоджується між кінцевими точками, які поділяють цей контекст. Це не пароль, і він не замінює автентифікацію IKE або політику маршрутизації. Розглядайте обидва значення як конфігураційний контекст, що має збігатися в межах відношення, а не як засоби захисту, що розділяють регіони.

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

Вирішіть, які префікси регіональний концентратор оголошує вгору і які центральні призначення пропонує своїм філіям. Потім перевірте фактичний наступний перехід і поведінку скорочення, специфічну для фази, для кожного шляху, бо сумарний маршрут і скорочення можуть дати зовсім іншу пересилку, ніж припускає схема.

Використовуйте маршрутизацію та політику доступу, щоб забезпечити регіональне розділення. Якщо філія не повинна напряму досягати іншого регіону, це мають казати маршрут і політика, а не розрахунок на ідентифікатор, який ніколи не призначався для цього. Запишіть політику поруч з ідентифікатором. Інакше наступний інженер припустить, що роботу виконує номер.

Діагностуйте неочікуване скорочення

Коли філія намагається створити пряме відношення з центральною кінцевою точкою, перевірте її маршрут, її зіставлення NHRP і вибраний контекст тунелю, перш ніж навмання змінювати ідентифікатори. Недоступність, ненавмисне відношення NHS і законне, але недозволене скорочення вимагають трьох різних виправлень.

Посібник з налаштування DMVPN показує параметри тунелю й NHRP разом, і саме тому області спершу треба розділити на папері. Зафіксуйте контракти хмари, тримайте маршрути рівнів явними, і наступному збою на межі буде на що вказати.