Состояние облака DMVPN
При выполнении ранее описанных пунктов настройки DMVPN Hub и DMVPN Spoke получим следующую схему коммуникации между центральным и дочерними офисами:
Рисунок 10. Схема коммуникации между центральным и дочерними офисами на момент завершения настройки
В данной схеме построены два облака DMVPN, участники которых описаны в таблицах 29 и 30:
Таблица 29. Описание участников облака DMVPN Cloud 1
| Имя хоста | Роль в облаке DMVPN | Туннельный IP-адрес | NBMA IP-адрес | NAT-OA IP-адрес | Локальные сети | Тестовые хосты в локальных сетях |
|---|---|---|---|---|---|---|
| RT-HUB-1 | Hub | 172.16.1.1/24 | 203.0.113.4 | 10.0.0.2 | 10.100.0.0/24 | 10.100.0.10 |
| RT-OFFICE-1 | Spoke | 172.16.1.11/24 | 203.0.114.2 | -- | 192.168.11.0/24 | 192.168.11.10 |
| RT-OFFICE-2 | Spoke | 172.16.1.12/24 | 203.0.114.130 | -- | 192.168.12.0/24 | 192.168.12.10 |
| RT-OFFICE-3 | Spoke | 172.16.1.13/24 | 203.0.115.2 | 10.0.0.19 | 192.168.13.0/24 | 192.168.13.10 |
| RT-OFFICE-4 | Spoke | 172.16.1.14/24 | 203.10.0.2 | -- | 192.168.14.0/24 | 192.168.14.10 |
| RT-OFFICE-5 | Spoke | 172.16.1.15/24 | 203.11.1.2 | -- | 192.168.15.0/24 | 192.168.15.10 |
Таблица 30. Описание участников облака DMVPN Cloud 2
| Имя хоста | Роль в облаке DMVPN | Туннельный IP-адрес | NBMA IP-адрес | NAT-OA IP-адрес | Локальные сети | Тестовые хосты в локальных сетях |
|---|---|---|---|---|---|---|
| RT-HUB-2 | Hub | 172.16.2.1/24 | 203.0.113.132 | 10.0.0.10 | 10.100.0.0/24 | 10.100.0.10 |
| RT-OFFICE-1 | Spoke | 172.16.2.11/24 | 203.0.114.2 | -- | 192.168.11.0/24 | 192.168.11.10 |
| RT-OFFICE-2 | Spoke | 172.16.2.12/24 | 203.0.114.130 | -- | 192.168.12.0/24 | 192.168.12.10 |
| RT-OFFICE-3 | Spoke | 172.16.2.13/24 | 203.0.115.2 | 10.0.0.19 | 192.168.13.0/24 | 192.168.13.10 |
| RT-OFFICE-4 | Spoke | 172.16.2.14/24 | 203.10.1.2 | -- | 192.168.14.0/24 | 192.168.14.10 |
| RT-OFFICE-5 | Spoke | 172.16.2.15/24 | 203.11.2.2 | -- | 192.168.15.0/24 | 192.168.15.10 |
За счет настройки протокола BGP прохождение трафика через членов облака Cloud 1 является наиболее приоритетным.
Проверка сетевой связности локальных сетей между центральным и дочерними офисами
Для проверки сетевой связности локальных сетей между центральным и дочерними офисами отправим трафик с тестовых хостов дочерних офисов в сторону тестового хоста локальной сети центрального офиса:
Во всех четырех трассировках можно заметить, что трафик через пограничный маршрутизатор дочерних офисов и облако DMVPN Cloud 1 попадает на DMVPN Hub RT-HUB-1, затем попадает на пограничный маршрутизатор центрального офиса RT-GW-1, после чего достигает тестового хоста в локальной сети центрального офиса.
Проверим корректность прохождения трафика в обратном направлении:
В обратную сторону трафик следует тем же путем. Задача обеспечения связности центрального и дочерних офисов выполнена.
Проверка возможности выхода хостов дочерних офисов в сеть Интернет через интернет-шлюз центрального офиса
Для проверки возможности выхода хостов дочерних офисов в сеть Интернет через интернет-шлюз центрального офиса отправим трафик с тестовых хостов дочерних офисов на публичный ресурс в сети Интернет. В качестве такого ресурса выберем адрес Google Public DNS, используемый как цель для SLA-теста на маршрутизаторе центрального офиса RT-GW-1:
Во всех четырех трассировках можно заметить, что трафик через пограничный маршрутизатор дочерних офисов и облако DMVPN Cloud 1 попадает на DMVPN Hub RT-HUB-1, затем попадает на пограничный маршрутизатор центрального офиса RT-GW-1, откуда уже достигает публичного ресурса в сети Интернет. В случае с RT-OFFICE-4 при переключении на резервный канал трафик пойдет через резервного провайдера на RT-HUB-2.
Задача организации доступа хостов в дочерних офисах в сеть Интернет через пограничный маршрутизатор центрального офиса выполнена.
Проверка сетевой связности локальных сетей между дочерними офисами
Для проверки сетевой связности локальных сетей между дочерними офисами отправим трафик между тестовыми хостами в локальных сетях дочерних офисов.
Начнем с проверки связности между дочерними офисами №1 и №2:
Обратим внимание, что первая трассировка проходит через DMVPN Hub RT-HUB-1, что логично, ведь без построенного Spoke-to-Spoke туннеля между дочерними офисами трафик между офисами проходит через DMVPN Hub:
А после построения Spoke-to-Spoke туннеля появляется короткий маршрут напрямую в сторону Spoke-соседа:
Увидеть построение Spoke-to-Spoke туннеля можно в соответствующих командах на обоих DMVPN Spoke:
Поскольку туннель GRE между DMVPN Spoke защищен технологией IPsec, в show-командах можно еще убедиться в корректном построении Spoke-to-Spoke IPsec-туннеля:
Таким образом, задача организации прямой сетевой связности локальных сетей между дочерними офисами выполнена.
