Зведення маршрутів DMVPN і карта зведення NHRP: різні таблиці
Зведення маршрутів змінює оголошений префікс і наступний хоп. Карта зведення NHRP змінює те, що повертає відповідь розв’язання. Те саме слово, інша таблиця.
Хтось просить вас звести spoke-вузли, і тікет закривається з меншою кількістю префіксів на hub. Через тиждень трафік між філіями, який раніше йшов напряму, знову проходить через hub, і ніхто не пов’язує ці дві зміни. Фраза звести spoke-вузли охоплює дві різні операції, що торкаються двох різних таблиць. Назвіть, який стан ви зменшуєте, перш ніж позичити команду з іншого прикладу DMVPN.
Симптом: прямий трафік spoke повернувся на hub
Ця відмінність найважливіша, коли обговорення Phase 2 застосовують до проєкту Phase 3. Ті самі слова з’являються в обох розмовах, а вплив на пересилання не однаковий.
Саме тому зміна виглядала правильною під час перегляду: перегляд перевірив таблицю маршрутизації, а це лише один із трьох задіяних станів.
Одне зведення, дві таблиці
Дві операції виглядають так:
| Operation | What it actually changes |
|---|---|
| Routing summary | Aggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs |
| NHRP summary map | Changes the network returned in a resolution reply, so a requesting spoke resolves to a different address |
| Protection path | IPsec state for the peer you actually resolved; neither aggregation changes it |
Зведення маршрутів — це твердження про те, що оголошує hub і що приймальний spoke встановлює як маршрут. Карта зведення NHRP — це твердження про відповідь, яку spoke надсилає, коли інший spoke питає, як дістатися до адреси. Це різні питання з різними режимами відмови, і проєкт може змінити одне, залишивши інше точно як було. Ставлення до них як до одного важеля — це шлях, яким зміна агрегації тихо стає зміною пересилання.
Жодна з операцій не є твердженням про шлях захисту, бо він узгоджується для того peer, який ви справді розв’язали.
Що насправді змінює зведення на hub
Посібник Cisco з карт зведення NHRP між spoke-вузлами описує схему Phase 3, у якій hub оголошує зведення і залишається наступним хопом маршрутизації. Потім переспрямування й подальше розв’язання NHRP дають пряміший шлях пересилання. Тому читання лише агрегованого маршруту не описує всього стану пересилання і не означає, що кожен пакет має вічно йти через hub. Зведення стосується досяжності, а не шляху.
Тому проєктний перегляд, який зупиняється на таблиці маршрутизації, може схвалити зміну, що змінює поведінку розв’язання. Перевіряйте вибраний маршрут, результат NHRP і шлях захисту як три окремі спостереження.
Якщо ви не можете сказати, який із трьох змінився, ви не завершили зміну.
Що змінює карта зведення NHRP
Візьміть spoke, якому належить 10.32.0.0/19 через кілька конкретніших LAN-маршрутів, а hub оголошує більшу агрегацію іншим spoke-вузлам. Запит на 10.32.12.10 інакше отримав би інформацію розв’язання для відповідної меншої мережі. Документована функція карти зведення NHRP дозволяє spoke повернути натомість свій налаштований покривний префікс, що може зменшити повторну роботу розв’язання для мереж, які належать цьому spoke. Це не робить зведення маршрутів hub і зведення розв’язання spoke одним і тим самим об’єктом.
Дайте цьому покривному префіксу продуману модель власності. Широка відповідь, що включає адреси, які належать інде, або прогалини, які недосяжні, може скерувати подальший трафік до невідповідного peer.
Перевірте фактичні маршрути й передбачувані випадки відмови до того, як збільшите префікс, а не після.
Порівняйте перший пункт призначення і один усередині зведення
Виберіть два пункти призначення: перший, який ви перевірили, і інший, що лежить усередині запропонованого зведення. Для кожного запишіть вибраний маршрут, стан NHRP, використаний для досягнення, і реальний шлях відповіді. Це порівняння скаже, чи змінили ви масштаб маршрутизації, масштаб розв’язання чи помилку пересилання, і це єдиний корисний висновок. Дисплей із меншою кількістю префіксів не є доказом жодного з цього.
Підтвердьте розгорнуту фазу й поведінку наступного хопу протоколу маршрутизації, перш ніж застосувати приклад Phase 3 до своєї мережі. Короткий приклад не доводить, що інший проєкт зберігає той самий прямий шлях spoke.
Тікет має сказати, яку таблицю ви зменшили і яку залишили недоторканою. Усе менше буде знову діагностовано з нуля через місяць.