> For the complete documentation index, see [llms.txt](https://adavyshin.gitbook.io/networks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://adavyshin.gitbook.io/networks/network/laboratornaya-rabota-dmvpn.md). # Лабораторная работа: DMVPN ## Ч1. Введение Для отработки практике по настройке технологий `Dynamic Multipoint VPN` мы будем отрабатывать на лабораторном полигоне, где у нас будет 6 географически распределённых точек присутствия. Две площадки у нас - это `Data Center`-ы (DC), где мы установим Hub-устройства, на которых у нас будет строиться сеть. Для более детальной проработки, я решил усложнить топологию, во второй половине нашей лабораторной работы мы активируем второго провайдера, и у каждого роутера будет по два канала связи. Для peering-а с первым провайдером используются сети `203.X.113.0/24`, где `X` - это порядковый номер площадки. Для peering-а со вторым провайдером мы будем использовать сеть `192.0.X.0/24`, где опять же `X` - это порядковый номер площадки. ## Ч2. Основы и DMVPN Phase 1 В технологии DMVPN существует 3 модели взаимодействия Hub and Spoke, их еще в терминологии Cisco называют Phase (фазами). `Phase 1` предполагает архитектуру, где любое общение между `Spoke` происходит только через `Hub` устройства. Концепция `Phase 2` заключается в том, что каждый `Spoke` получает полную таблицу маршрутизации из топологии DMVPN, с указанием на какой другой `Spoke` нужно целенаправленно отправить траффик, минуя `Hub` на всём протяжении времени. Концепция `Phase 3` заключается в первоначальной суммаризации всех маршрутов на себя со стороны `Hub`, но как только один из филиалов начнёт взаимодействовать с другим через `Hub`, то `Hub` отправит Redirect-cообщение и предложит им взаимодействовать напрямую, минуя `Hub`. В нашем лабораторном полигоне предполагается два `Next-hop server` сервера (HUB1 и HUB2) для отказоустойчивости. 🔧Настройка маршрутизатора HUB1: ``` configure terminal ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.1 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ``` Параметр `ip nhrp network-id 1111` используется как идентификатор DMVPN-тенанта, если на одном устройстве у вас запушено сразу несколько независимых DMVPN-процесса со своими туннелями. 🔧Настройка маршрутизатора SPOKE3: ``` configure terminal ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.3 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 ip nhrp nhs 172.21.0.1 ip nhrp map 172.21.0.1 203.1.113.10 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ``` Параметр `ip nhrp nhs 172.21.0.1` отвечает за указание, какой туннельный адрес являет Next-Hop Server. Параметр `ip nhrp map 172.21.0.1 203.1.113.10` указывает за каким публичным IP-адресом находится адрес 172.21.0.1, то есть мы делаем статическую NHRP-запись. По аналогии, настраиваем все оставшиеся SPOKE-устройства... 🔧Настройка маршрутизатора SPOKE4: ``` configure terminal ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.4 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 ip nhrp nhs 172.21.0.1 ip nhrp map 172.21.0.1 203.1.113.10 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ``` 🔧 Настройка маршрутизатора SPOKE5: ``` configure terminal ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.5 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 ip nhrp nhs 172.21.0.1 ip nhrp map 172.21.0.1 203.1.113.10 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ``` 🔧 Настройка маршрутизатора SPOKE6: ``` configure terminal ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.6 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 ip nhrp nhs 172.21.0.1 ip nhrp map 172.21.0.1 203.1.113.10 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ``` 🔦 На маршрутизаторе HUB1 можем увидеть все филиалы, которые зарегистрировались по NHRP с помощью команды `show dmvpn`
Туннели готовы, но просто туннели хорошо, но что же мы будем туннелировать? А туннелировать мы будем трафик между филиалами, и между филиал-хаб. Туннелируем трафик на основе маршрутов, давайте пропишем статические маршруты, на HUB1 у нас будут маршруты до каждой сети по отдельности, а на филиалах мы можем использовать один широкий маршрут указывающий на HUB. 🔧 Настройка маршрутов на HUB1: ``` configure terminal ! ip route 10.30.0.0 255.255.255.0 172.21.0.3 name {Spoke3-Backend} ip route 10.40.0.0 255.255.255.0 172.21.0.4 name {Spoke4-Backend} ip route 10.50.0.0 255.255.255.0 172.21.0.5 name {Spoke5-Backend} ip route 10.60.0.0 255.255.255.0 172.21.0.6 name {Spoke6-Backend} ``` 🔧 Настройка маршрутов на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! ip route 10.0.0.0 255.192.0.0 172.21.0.1 name {To_Networks_Behind_Hub} ``` Пробуем от адреса Lo10 маршрутизатора SPOKE3 допустим пропинговать адрес Lo10 маршрутизатора SPOKE4.
Теперь у нас территориально распределённая сеть филиалов можем взаимодействовать между собой, но что же произойдёт, когда наш HUB1 выйдет из строя? Да, настало время ввести в эксплуатацию маршрутизатор HUB2. На данном роутере пока делаем идентичный HUB1 конфигурацию, только изменяем IP-адрес интерфейса. 🔧 Настройка маршрутизатора HUB2: ``` configure terminal ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.2 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ``` 🔧 Настройка маршрутов на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! interface Tunnel1 ip nhrp nhs 172.21.0.2 ip nhrp map 172.21.0.2 203.2.113.10 ``` Для проверки того, что запасной туннель поднялся между филиалами и вторичным хабом используем команду `show dmvpn`:
Конечно, мы можем прописать статические маршруты по аналогии, как мы делали ранее, но поверьте, ECMP на статических маршрутах нам может выйти боком, давайте оставим эту идею... Чтобы не усложнять себе жизнь давайте внедрим динамическую маршрутизацию в нашу топологию. ## Ч3 Применение OSPF в DMVPN ### Ч3.1 DMVPN Phase 1 на базе OSPF До этого момента мы рассматривали технологию DMVPN на основе статической маршрутизации, а мы здесь собрались ради другого же... Да, давайте попробуем внедрить динамическую маршрутизацию в нашу топологию для автоматического схождения сетей без ручного участия. Вначале рассмотрим OSPF... Особенность DMVPN в том, что внутри него multicast-трафик не сможет полноценно работать, так как нам явно придётся в NHRP-записи указывать куда отправлять multicast-трафик, а все эти настройки на 50 и более устройств, сведут администрирование к настоящему "геморрою". Сейчас в примерах конфигурации вы увидите, что multicast-траффику нужно явно сказать "куда". Также перед настройкой OSPF хочу обратить внимание на параметр `network-type`, который может принимать следующие значения * `Non-broadcast` * `Broadcast` * `Point-to-point` * `Point-to-multipoint` В топологии, которую мы получаем в DMVPN, тип network type `point-to-point` не применим, так как никаким боком соединения двух устройств не будет, мы наоборот стремимся получить обратную картину. `Non-boadcast` топологию тоже не целесообразно использовать, так как нам до каждого филиала на HUB придётся писать статических ospf-соседей, при количестве филиалов более 20-30, то такой подход уже плохо будет масштабироваться. В DMVPN образуется топология `NBMA` (Non-Broadacst Multiple Access), то есть в пространстве множество устройств, но каждый до каждого связаться не может (нет broadcast). Топологию NMBA очень часто приводят у прощённому виду, другой топологии Hub-and-Spoke или топология звезда, где среди всех устройств должен быть маршрутизатор, который имеет канал связи со всеми. Это можно достичь с помощью типом топологии интерфейса `point-to-multipoint`. На основе этого `network type` можно построить `Phase 1` и `Phase 3` архитектуры. Broadcast превращает нашу топологию DMVPN в один большой коммутатор, напомню что в такой топологии выбирается DR (диспетчер) и BDR (резервный диспетчер). Для корректной работоспособности выборы будут только из двух кандидатов, концентраторов HUB, так как если один из Spoke выберется диспетчером, то для него важно multicast-сообщение на `224.0.0.6` отправлять сообщения на всех остальных участниках. 🔧 Настройка маршрутов на HUB1: ``` configure terminal ! interface Tunnel1 ip ospf network point-to-multipoint ip ospf 1 area 0 ip nhrp map multicast dynamic ! router ospf 1 router-id 172.21.0.1 log-adjacency-changes detail network 172.21.0.0 0.0.0.255 area 0 network 10.12.0.0 0.0.0.255 area 0 ``` 🔧 Настройка маршрутов на HUB2: ``` configure terminal ! interface Tunnel1 ip ospf network point-to-multipoint ip ospf 1 area 0 ip nhrp map multicast dynamic ! router ospf 1 router-id 172.21.0.2 log-adjacency-changes detail network 172.21.0.0 0.0.0.255 area 0 network 10.12.0.0 0.0.0.255 area 0 ``` 🔧 Настройка маршрутов на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: 
configure terminal
!
interface Tunnel1
  ip ospf network point-to-multipoint
  ip ospf 1 area 0
  ip nhrp map multicast 203.1.113.10
  ip nhrp map multicast 203.2.113.10
!
router ospf 1
 router-id 172.21.0.X
 log-adjacency-changes detail
 network 172.21.0.0 0.0.0.255 area 0
 network 10.0.0.0 0.255.255.255 area 0
И последний штрих это избавиться от статических маршрутов, которые создавали в [#ch2.-osnovy-i-dmvpn-phase-1](#ch2.-osnovy-i-dmvpn-phase-1 "mention"). 🔧 Удаление маршрутов на HUB1: ``` configure terminal ! no ip route 10.30.0.0 255.255.255.0 172.21.0.3 name {Spoke3-Backend} no ip route 10.40.0.0 255.255.255.0 172.21.0.4 name {Spoke4-Backend} no ip route 10.50.0.0 255.255.255.0 172.21.0.5 name {Spoke5-Backend} no ip route 10.60.0.0 255.255.255.0 172.21.0.6 name {Spoke6-Backend} ``` 🔧 Удаление маршрутов на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! no ip route 10.0.0.0 255.192.0.0 172.21.0.1 name {To_Networks_Behind_Hub} ``` При тестовых генерациях трафика с маршрутизатора SPOKE3 с `Loopback10` на адрес `Loopback10` маршрутизатора SPOKE4 мы видим, что `traceroute` показывает 2 прыжка, и на первом хопе у нас происходит ротация адреса, она связна с ECMP.
Таблица маршрутизации на маршрутизаторе SPOKE3 явно подтверждает такое поведение, т.к. у маршрута 10.40.0.1/32 два next-hop на оба HUB-маршрутизатора.
Но, постойте, почему у `10.40.0.1` маска `/32` , а не целевая `/24` . Этот момент возникает у Loopback-адресов, давай глянем на вывод команды `show ip ospf interface Loopback10`. Обратите внимание, что Network Type - LOOPBACK, это и вносит свои коррективы, для того, чтобы скорректировать нашу топологию, необходимо поправить ospf type.
🔧 Правим тип Loopback-интерфейса на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! interface Loopback10 ip ospf network point-to-point ``` Проверяем еще раз таблицу маршрутизации на роутере SPOKE3:
🎉 Подытоживая, мы видим в трассировке, что трафик от одного SPOKE до другого SPOKE проходит всегда через HUB-маршрутизаторы, что и предполагает `Phase 1`. ### Ч3.2. DMVPN Phase 2 на базе OSPF Для построения архитектуры `Phase 2` на основе OSPF нам необходимо перевести network type в `Broadcast`, это позволит сделать взаимодействие всех SPOKE-устройств между собой напрямую, минуя HUB-маршрутизаторы. Для концентраторов HUB1 и HUB2 выставим приоритеты OSPF 10 и 5 соответственно, а для остальных выставляем - 0. 🔧 Настройка маршрутов и HUB1: ``` configure terminal ! interface Tunnel1 ip ospf network broadcast ip ospf priority 10 ``` 🔧 Настройка маршрутов и HUB2: ``` configure terminal ! interface Tunnel1 ip ospf network broadcast ip ospf priority 5 ``` 🔧 Настройка маршрутов на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! interface Tunnel1 ip ospf network broadcast ip ospf priority 0 ``` После того, как примените конфигурацию на всех маршрутизаторах, то заметите странную вещь, у вас будут то появляться, то пропадать соседства. И тут возникает вопрос, а где на HUB1 в соседях числится маршрутизатор HUB2, его нет... Так как мы выбрали топологию broadcast, то у нас по идеи все участники должны общаться друг с другом, то это не так.. Нет связи между HUB1 и HUB2, что в свою очередь не даёт общаться между собой DR и BDR, а это чревато некорректной LSDB.
Также со стороны `Spoke`-устройств мы видим, что HUB2 завис в `2WAY` состоянии.
Для того, чтобы наша топология ожила, на маршрутизаторе HUB2 пропишем статический nhs и multicast-получателя в лице HUB1. 🔧 Добавляем конфиг на HUB2: ``` configure terminal ! interface Tunnel1 ip nhrp nhs 172.21.0.1 ip nhrp map 172.21.0.1 203.1.113.10 ip nhrp map multicast 203.1.113.10 ``` Всё должно полегчать и мы должны увидеть следующую картину ( в частности на SPOKE3), где теперь оба HUB-а находятся в полной синхронизации, с приоритетами 10 и 5 как ранее и указывали.
🔦 Проверяем маршруты на роутере SPOKE3:
Обратите внимание, что маршруты до сетей филиалов `10.X.0.0/24` указывают на Tunnel-адреса интерфейсов маршрутизаторов в соответствующем филиале. Если мы запустим трассировку, то увидим что первая проходка была через HUB-маршрутизатор, последующая трассировка покажет нам, что путь идёт на прямую. Вроде по описанию похоже на `Phase 3`, но всё не совсем так.
Первоначально два hop было в связи с тем, что SPOKE3 просто не знал, какой публичный адрес кроется за сетью филиала №4, но судя по таблице маршрутизации выше еще раз повторюсь, все маршрутизаторы знают на какой нужный туннельный адрес необходимо отправить пакет, но не знают где находится сам филиал. И после NHRP Resolution Request и последующего NHRP Resolution Reply трафик маршрутизируется согласно канонам DMVPN Phase 2. ### Ч3.3. DMVPN Phase 3 на базе OSPF А принцип DMVPN Phase 3 заключается в том, что изначально таблица маршрутизации должна указывать на туннельный адрес HUB-устройства, но как только первый пакет придёт на HUB, он своим сообщением `NHRP Redirect` должен изменить `FIB` на филиальном маршрутизаторе. В основе Phase 3 на OSPF лежит `point-to-multopoint` тип интерфейса, поэтому откатываемся обратно на него. Также нет необходимости держать записи `nhs` на HUB2, указывающие на HUB2. Для реализации Phase 3 нам необходимо включить OSPF-суммаризацию на `Hub`-устройствах. А также добавить "магические" строки конфигурации, на Hub-устройствах это сразу две команды `ip nhrp shortcut` и `ip nhrp redirect`, первая по включает обработку `NHRP Redirect` сообщений, а вторая включает генерацию этих сообщений. Схема работает следующим образом, траффик изначально идёт на `Hub`, т.к. у вас агрегация маршрутов на них указывает, как только на него приходит сообщение от одного из `Spoke`, адресованное другому `Spoke`, `Hub`-отправляет специальное сообщение, чтобы два `Spoke` общались напрямую, а не через `Hub`. 🔧 Настройка маршрутов на HUB1: ``` configure terminal ! router ospf 1 area 1 nssa no-summary ! interface Tunnel1 no ip ospf priority ip ospf network point-to-multipoint ip nhrp shortcut ip nhrp redirect ip ospf 1 area 1 ! interface GigabitEthernet0/0 ip ospf 1 area 0 ``` 🔧 Настройка маршрутов на HUB2: ``` configure terminal ! router ospf 1 area 1 nssa no-summary ! interface Tunnel1 no ip ospf priority ip ospf network point-to-multipoint no ip nhrp nhs 172.21.0.1 no ip nhrp map 172.21.0.1 203.1.113.10 no ip nhrp map multicast 203.1.113.10 ip nhrp shortcut ip nhrp redirect ip ospf 1 area 1 ! interface GigabitEthernet0/0 ip ospf 1 area 0 ``` 🔧 Настройка маршрутов на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! router ospf 1 area 1 nssa ! interface Tunnel1 no ip ospf priority ip ospf network point-to-multipoint ip nhrp shortcut ip ospf 1 area 1 ! interface Loopback10 ip ospf 1 area 1 ```
Если смотреть на количество 1 LSA, то можно сделать вывод, что в DMVPN архитектуре с большим количеством филиалом, SPF будет задыхаться в вычислениях и нужно это взаимодействие упростить. Предлагаю использовать "костыль" до которого додуматься не сразу - отключить анонсирование LSA на туннельных интерфейсах HUB-устройств. В результате у нас обрабатывать LSA будут только HUB, но как же будут действовать филиалы? а мы пропишем статический маршрут до HUB, как только трафик инициируется его перебьёт маршрут полученный по NHRP Redirect. 🔧 Настройка на HUB1: ``` configure terminal ! interface Tunnel1 ip ospf database-filter all out ! ``` 🔧 Настройка на HUB2: ``` configure terminal ! interface Tunnel1 ip ospf database-filter all out ! ``` После выполнения данной команд можно подождать 1800 секунд пока LSA протухнут, или можно ускорить процесс командой clear ip ospf process, которая рестартанёт процессы. По итогу на SPOKE-устройствах будет LSA только от самих себя, а на
А вот на HUB-устройстве вполне удачный улов LSA:
Отсутствие LSA на филиалах ведёт к тому, что на них не будет никаких маршрутов до сетей филиалов. Чиним этот момент созданием статических маршрута, унифицированного на всех ранее.
🔧 Настройка статических маршрутов на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! ip route 10.0.0.0 255.192.0.0 172.21.0.1 name {To_Networks_Behind_Hub} ```
Проверяем работоспособность нашего тунеля, здесь к примеру со SPOKE6 пингум адрес SPOKE3, и возвращаемся в таблицу маршрутизации. Здесь мы видим, что у нас добавились NHRP маршруты с административным расстоянием 250. Тот самый NHRP Redirect.
🎉 Поздравляю, ты построил `Phase 3` на OSPF, правда не без костылей, но построил. ## Ч4. Применение EIGRP в DMVPN С EIGRP будет проще во всех стадия DMVPN так как эта технология затачивалась именно под этот протокол динамической маршрутизации. Нам необходимо очистить конфигурацию от предыдуших изысканий с OSPF: 🔧 Переконфигурация на HUB1: ``` configure terminal ! no interface Tunnel1 ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.1 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ! no router ospf 1 ! interface GigabitEthernet 0/0 no ip ospf 1 area 0 ``` 🔧 Переконфигурация на HUB2: ``` configure terminal ! no interface Tunnel1 ! interface Tunnel1 description {DMVPN-through-WAN1} ip address 172.21.0.2 255.255.255.0 ip mtu 1400 ip tcp adj 1360 ip nhrp network-id 1111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 1111 ! no router ospf 1 ! interface GigabitEthernet 0/0 no ip ospf 1 area 0 ``` 🔧 Переконфигурация на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: 
configure terminal
!
no ip route 10.0.0.0 255.192.0.0 172.21.0.1 name {To_Networks_Behind_Hub}
!
no interface Tunnel1
!
interface Tunnel1
 description {DMVPN-through-WAN1}
 ip address 172.21.0.X 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map 172.21.0.1 203.1.113.10
 ip nhrp map 172.21.0.2 203.2.113.10
 ip nhrp map multicast 203.1.113.10
 ip nhrp map multicast 203.2.113.10
 ip nhrp network-id 1111
 ip nhrp nhs 172.21.0.1
 ip nhrp nhs 172.21.0.2
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 tunnel key 1111
 !
 interface Loopback10
   no ip ospf 1 area 1
!
no router ospf 1
### Ч4.1 DMVPN Phase 1 на базе EIGRP 🔧 Конфигурация EIGRP на HUB1: ``` configure terminal ! router eigrp 1 eigrp router-id 172.21.0.1 network 172.21.0.0 0.0.0.255 network 10.12.0.0 0.0.0.255 ``` 🔧 Конфигурация EIGRP на HUB2: ``` configure terminal ! router eigrp 1 eigrp router-id 172.21.0.2 network 172.21.0.0 0.0.0.255 network 10.12.0.0 0.0.0.255 ``` 🔧 Конфигурация EIGRP на SPOKE3: ``` configure terminal ! router eigrp 1 eigrp router-id 172.21.0.3 network 172.21.0.0 0.0.0.255 network 10.30.0.0 0.0.0.255 ``` 🔧 Конфигурация EIGRP на SPOKE4: ``` configure terminal ! router eigrp 1 eigrp router-id 172.21.0.4 network 172.21.0.0 0.0.0.255 network 10.40.0.0 0.0.0.255 ``` 🔧 Конфигурация EIGRP на SPOKE5: ``` configure terminal ! router eigrp 1 eigrp router-id 172.21.0.5 network 172.21.0.0 0.0.0.255 network 10.50.0.0 0.0.0.255 ``` 🔧 Конфигурация EIGRP на SPOKE6: ``` configure terminal ! router eigrp 1 eigrp router-id 172.21.0.6 network 172.21.0.0 0.0.0.255 network 10.60.0.0 0.0.0.255 ``` Давайте посмотрим на таблицу маршрутизации одного из филиалов, в частности SPOKE3:
А мы не видим маршрутов до подсетей в филиалах, а это связано с основным правилом Distance Vector протоколов, которое называется `split-horizon`, которое гласит, что мы не анонсируем сети из того же интерфейса из которого получили вектор маршрутов. Для исправления этого нюанса, нам необходимо отключить split-horizon на HUB-маршрутизаторах. 🔧 Отключение split-horizon на HUB1: ``` configure terminal ! interface Tunnel1 no ip split-horizon eigrp 1 ``` 🔧 Отключение split-horizon на HUB2: ``` configure terminal ! interface Tunnel1 no ip split-horizon eigrp 1 ``` После отключения split-horizon на HUB-маршрутизаторах, давайте снова проверим таблицу маршрутизации SPOKE3 и там мы должны увидеть анонсы от других филиалов.
Проверим трассировку из под клиентской сети SPOKE3 до клиентской сети SPOKE5
🎉 Трафик ходит через посредников в виде маршрутизаторов HUB1 и HUB2, что предполагает Phase 1. Но у нас это WAN-соединения через сеть Интернет, а в таких случаях ECMP не очень применительно, так как разный провайдер может с разной скоростью пропускать трафик. Предлагаю приоритизировать наши HUB-ы, с помощью функции `offser-list`, смысл которой добавить `EIGRP Delay` ко всем исходящим маршрутам из указанного интерфейса, в нашем случае это будет Tunnel1 на маршрутизаторе HUB2: 🔧 Добавляем offset-list для всех исходящих маршрутов на HUB2: ``` configure terminal ! ip access-list standard ANY permit any ! router eigrp 1 offset-list ANY out 100 Tunnel1 ``` После применения offset-list давайте проверим заново таблицу маршрутизации на SPOKE3, и мы увидим, что в FIB теперь у нас только один next-hop, так как метрика получаемая с HUB2 будет на \ 100 ед. больше, чем у HUB1.
### Ч4.2 DMVPN Phase 2 на базе EIGRP Переход на Phase 2 очень плавный и заключается в том, что на HUB-маршрутизаторах нам необходимо отключить подставление своего IP-адреса в атрибуте Next-hop. 🔧 Отключаем next-hop-self на HUB1: ``` configure terminal ! interface Tunnel1 no ip next-hop-self eigrp 1 ``` 🔧 Отключаем next-hop-self на HUB2: ``` configure terminal ! interface Tunnel1 no ip next-hop-self eigrp 1 ``` Проанализируем полученный результат с таблицы маршрутизации SPOKE3
🎉 Из скриншота выше видно, что маршруты указывают напрямую на адреса туннельных интерфейсов SPOKE-маршрутизаторов. Значит, мы добились необходимого результата. ### Ч4.3 DMVPN Phase 3 на базе EIGRP Повторюсь, основная идея Phase 3 заключается в том, что изначально таблица маршрутизации указывает на HUB-маршрутизатор, но после первого пакета, который летит в сторону HUB-а, HUB-маршрутизатор отправляет NHRP Redirect и добавляет NHRP-прямой маршрут до того филиала, куда направлялся пакет. 🔧 Включаем Phase 3 на HUB1: ``` configure terminal ! interface Tunnel1 ip next-hop-self eigrp 1 ip nhrp shortcut ip nhrp redirect ``` 🔧 Включаем Phase 3 на HUB2: ``` configure terminal ! interface Tunnel1 ip next-hop-self eigrp 1 ip nhrp shortcut ip nhrp redirect ``` 🔧 Конфигурация EIGRP на SPOKE3, SPOKE4, SPOKE5 и SPOKE6: ``` configure terminal ! interface Tunnel1 ip nhrp shortcut ``` Теперь анализируем таблицу маршрутов на SPOKE3, обратите внимание, что после инициации трафика у нас изменился Code напротив маршрута 10.50.0.0/24.
Знак `%` - означает `next hop override`, то есть у нас маршрут форсированно перекрывается NHRP shortcut записью, которую мы можем увидеть с помощью команды show ip nhrp shortcut
Также вишенкой на торте, будет использование суммаризации на HUB-маршрутизаторах, для облегчения таблицы маршрутизации, т.к. если количество филиалов будет в порядках тысяч, то это будет нагрузка на ресурсы роутеров в филиалах, а в филиалах теоретически могут устанавливаться маршрутизаторы младших моделей, у которых ресурсы ограничены. 🔧 Включаем суммаризацию на HUB1: ``` configure terminal ! interface Tunnel1 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 ``` 🔧 Включаем суммаризацию на HUB2: ``` configure terminal ! interface Tunnel1 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 ```
🎉 Мои поздравления, у вас функционирует архитектура на EIGRP Phase 3 в DMVPN Phase 3. ## Ч5. Применение BGP в DMVPN Для BGP предлагаю откатиться с помощью snapshot до первоначальной версии и заново пройти пункт [#ch2.-osnovy-i-dmvpn-phase-1](#ch2.-osnovy-i-dmvpn-phase-1 "mention")для базовой настройки туннелей, только без добавления статических маршрутов, т.к. маршрутизация буден на базе BGP. ### Ч5.1 DMVPN Phase 1 на базе BGP Давайте начнём с HUB-маршрутизаторов, тут мы создаем peer-group SPOKES, и для этой peer-group указываем диапазон адресов, с которых могут подключаться динамические neighbor-ы. Обратите внимание, что используется `neighbor SPOKES next-hop-self all`, так как без слова `all`, это работает только при передаче маршрутов, полученных от **eBGP** соседей. А у нас все устройства находятся в одной AS, и получается, что **HUB**-ы пересылают маршруты от iBGP соседа к iBGP-соседу. 🔧 Настройка BGP на маршрутизаторе HUB1: ``` configure terminal ! router bgp 65000 bgp router-id 172.21.0.1 bgp log-neighbor-changes neighbor SPOKES peer-group neighbor SPOKES route-reflector-client neighbor SPOKES timers 10 30 neighbor SPOKES update-source Tunnel1 neighbor SPOKES remote-as 65000 neighbor SPOKES next-hop-self all neighbor SPOKES soft-reconfiguration inbound bgp listen limit 50 bgp listen range 172.21.0.0/24 peer-group SPOKES network 10.12.0.0 mask 255.255.255.0 ``` 🔧 Настройка BGP на маршрутизаторе HUB2: ``` configure terminal ! router bgp 65000 bgp router-id 172.21.0.2 bgp log-neighbor-changes neighbor SPOKES peer-group neighbor SPOKES route-reflector-client neighbor SPOKES timers 10 30 neighbor SPOKES update-source Tunnel1 neighbor SPOKES remote-as 65000 neighbor SPOKES next-hop-self all neighbor SPOKES soft-reconfiguration inbound bgp listen limit 50 bgp listen range 172.21.0.0/24 peer-group SPOKES network 10.12.0.0 mask 255.255.255.0 ``` 🔧 Настройка BGP на маршрутизаторе SPOKE3: ``` configure terminal ! router bgp 65000 bgp router-id 172.21.0.3 bgp log-neighbor-changes neighbor HUBS peer-group neighbor HUBS remote-as 65000 neighbor HUBS timers 10 30 neighbor HUBS update-source Tunnel1 neighbor HUBS soft-reconfiguration inbound neighbor 172.21.0.1 peer-group HUBS neighbor 172.21.0.2 peer-group HUBS network 10.30.0.0 mask 255.255.255.0 ``` 🔧 Настройка BGP на маршрутизаторе SPOKE4: ``` configure terminal ! router bgp 65000 bgp router-id 172.21.0.4 bgp log-neighbor-changes neighbor HUBS peer-group neighbor HUBS remote-as 65000 neighbor HUBS timers 10 30 neighbor HUBS update-source Tunnel1 neighbor HUBS soft-reconfiguration inbound neighbor 172.21.0.1 peer-group HUBS neighbor 172.21.0.2 peer-group HUBS network 10.40.0.0 mask 255.255.255.0 ``` 🔧 Настройка BGP на маршрутизаторе SPOKE5: ``` configure terminal ! router bgp 65000 bgp router-id 172.21.0.5 bgp log-neighbor-changes neighbor HUBS peer-group neighbor HUBS remote-as 65000 neighbor HUBS timers 10 30 neighbor HUBS update-source Tunnel1 neighbor HUBS soft-reconfiguration inbound neighbor 172.21.0.1 peer-group HUBS neighbor 172.21.0.2 peer-group HUBS network 10.50.0.0 mask 255.255.255.0 ``` 🔧 Настройка BGP на маршрутизаторе SPOKE6: ``` configure terminal ! router bgp 65000 bgp router-id 172.21.0.6 bgp log-neighbor-changes neighbor HUBS peer-group neighbor HUBS remote-as 65000 neighbor HUBS timers 10 30 neighbor HUBS update-source Tunnel1 neighbor HUBS soft-reconfiguration inbound neighbor 172.21.0.1 peer-group HUBS neighbor 172.21.0.2 peer-group HUBS network 10.60.0.0 mask 255.255.255.0 ``` В качестве проверки, что Phase 1 работает корректно, смотрим RIB и FIB на маршрутизаторе SPOKE3. И next-hop для всех сетей должен быть IP-адрес туннеля на HUB1 - 172.21.0.1.
### Ч5.2 DMVPN Phase 2 на базе BGP Для того, чтобы мигрировать с Phase 1 на Phase 2, нам необходимо на HUB-маршрутизаторах убрать строку с next-hop-self, для того чтобы в BGP префиксах RR оставляли исходный адрес next-hop, согласно канону internal-BGP, тем самым указывая напрямую в филиал. 🔧 Конфигурация на HUB1: ``` configure terminal ! router bgp 65000 no neighbor SPOKES next-hop-self all ``` 🔧 Конфигурация на HUB2: ``` configure terminal ! router bgp 65000 no neighbor SPOKES next-hop-self all ``` Проверяем также FIB и RIB на маршрутизаторе SPOKE3, и видим, что next-hopы для маршрутов указывают на туннельные адреса других SPOKE-маршрутизаторов.
### Ч5.3 DMVPN Phase 3 на базе BGP 💡 Напоминаю, что Phase 3 работает за счёт **NHRP redirect + shortcut.** Hub “учит” spoke-устройства строить прямые туннели, когда он видит, что трафик между ними проходит через него.\ Чтобы это работало: 1. Hub должен быть **next-hop** для маршрутов; 2. Hub должен иметь **агрегированный маршрут** в сторону Spokes. 3. Spoke не знает о точных сетях других spoke и идёт трафик через hub; 4. Hub видит трафик между spokes и отправляет **redirect**; 5. Spokes создают прямой туннель В конфигурацию bgp добавляем `aggregate-address 10.0.0.0 255.0.0.0 summary-only`, где `summary-only` опция для того что все дочерние маршруты скрывались за агрегированным. 🔧 Конфигурация для **phase 3** на устройстве HUB1: ``` configure terminal ! router bgp 65000 aggregate-address 10.0.0.0 255.0.0.0 summary-only ! interface Tunnel1 ip nhrp redirect ``` 🔧 Конфигурация для **phase 3** на устройстве HUB2: ``` configure terminal ! router bgp 65000 aggregate-address 10.0.0.0 255.0.0.0 summary-only ! interface Tunnel1 ip nhrp redirect ``` Видим, что согласно п.1 hub-устройства являются **next-hop** в агрегированных маршрутах.
Инициируем трафик от внутреннего интерфейса в филиале 3 до адреса из филиала 4.
А теперь видим NHRP-маршрут точечно ведущий на маршрутизатор SPOKE3.
[^1]: Номер вашего SPOKE-маршрутизатора [^2]: Номер филиала --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://adavyshin.gitbook.io/networks/network/laboratornaya-rabota-dmvpn.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.