Теория

Что происходит в этот момент?
1) Отправляем пинг на адрес Loopback-интерфейса в Томске 2) Согласно таблице маршрутизации, следующий хоп
nsk-obsea-gw1#sh ip route 172.16.255.132 Routing entry for 172.16.255.132/32 Known via «ospf 1», distance 110, metric 11112, type intra area Last update from 172.16.254.3 on Tunnel0, 00:18:47 ago Routing Descriptor Blocks:
  • 172.16.254.3, from 172.16.255.132, 00:18:47 ago, via Tunnel0
    Route metric is 11112, traffic share count is 1
Это адрес из сети, непосредственно подключенной к интерфейсу Tunnel 0
nsk-obsea-gw1#sh ip route 172.16.254.3 Routing entry for 172.16.254.0/24 Known via «connected», distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks:
  • directly connected, via Tunnel0
    Route metric is 0, traffic share count is 1
3) Согласно настройкам интерфейса здесь используется NHRP. Смотрим таблицу соответствия, полученную от хаба
nsk-obsea-gw1#sh ip nhrp brief Target Via NBMA Mode Intfc Claimed 172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0 < >
Как видите, адрес 172.16.254.3 nhrp неизвестен. Поэтому пакет ICMP отправляется на статически настроенный хаб – 198.51.100.2:
msk-arbat-gw1, fa0/1:
А хаб сразу же перенаправляет запрос на нужный адрес:
msk-arbat-gw1, fa0/1:
4) Одновременно с этим маршрутизатор-клиент в Новосибирске отправляет NHRP-запрос, мол кто укрывает адрес 172.16.254.3:
msk-arbat-gw1, fa0/1:
5) Хаб обладает этим знанием:
msk-arbat-gw1#sh ip nhr br Target Via NBMA Mode Intfc Claimed 172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0 < > 172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0 < >
И отправляет эту информацию в NHRP-ответе:
msk-arbat-gw1, fa0/1:
Больше Хаб не встревает в разговор двух споков.
6) ICMP запрос пришёл в Томск:
tmsk-lenina-gw1, fa0/0:
Несмотря на то, что во внешнем заголовке IP адрес источника – это адрес хаба, внутри фигурирует изначальный адрес Новосибирского маршрутизатора:
7)Томск тоже пока не знает ничего об адресе 172.16.254.2, пославшем ICMP-запрос.
tmsk-lenina-gw1(config-if)#do sh ip nh br Target Via NBMA Mode Intfc Claimed 172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0 < >
Поэтому ICMP-ответ он отправляет тоже на хаб: tmsk-lenina-gw1, fa0/0:
8) Следом за ним он интересуется о публичном адресе отправителя:
tmsk-lenina-gw1, fa0/0:
9)Ну и хаб, естественно, отвечает:
tmsk-lenina-gw1, fa0/0:
10) Сейчас на всех узлах актуальная информация NHRP:
msk-arbat-gw1(config-if)#do sh ip nhr br Target Via NBMA Mode Intfc Claimed 172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0 < > 172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0 < >
nsk-obsea-gw1(config-if)#do sh ip nhr br Target Via NBMA Mode Intfc Claimed 172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0 < > 172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0 < >
tmsk-lenina-gw1(config-if)#do sh ip nh br Target Via NBMA Mode Intfc Claimed 172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0 < > 172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0 < >
Как видите, распространение происходит не автоматически, а по запросу, причём инициаторами являются только клиенты, потому что фактически, только они знают, куда обращаться (хаб изначально не знает о клиентах ничего)
11) Следующий ICMP-запрос он уже отправит по-новому:
nsk-obsea-gw1#sh ip route 172.16.255.132 Routing entry for 172.16.255.132/32 Known via «ospf 1», distance 110, metric 11112, type intra area Last update from 172.16.254.3 on Tunnel0, 00:20:24 ago Routing Descriptor Blocks:
  • 172.16.254.3, from 172.16.255.132, 00:20:24 ago, via Tunnel0
    Route metric is 11112, traffic share count is 1
Подсеть 172.16.254.0 подключена к интерфейсу Tunnel 0
nsk-obsea-gw1#sh ip route 172.16.254.3 Routing entry for 172.16.254.0/24 Known via «connected», distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks:
  • directly connected, via Tunnel0
    Route metric is 0, traffic share count is 1
12) Мы немного повторяемся, но… Интерфейс Tunnel 0 является mGRE и согласно таблицы NHRP весь трафик, для которого следующим хопом является 172.16.254.3 должен быть инкапсулирован в GRE и внешний IP-заголовок с адресом назначения 198.51.102.2 (В качестве адреса источника будет выбран адрес физического интерфейса – 198.51.101.2):
nsk-obsea-gw1(config-if)#do sh ip nhr br Target Via NBMA Mode Intfc Claimed 172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0 < > 172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0 < >
tmsk-lenina-gw1, fa0/0:
13) Ну и дальше пакет с адресом получателя 198.51.102.2 отправляется согласно таблице маршрутизации:
Gateway of last resort is 198.51.101.1 to network 0.0.0.0
Тут важно понимать, что несмотря на то, что общение между филиалами осуществляется в обход центрального узла, хаб однако несёт тут жизненно важную вспомогательную функцию и без него ничего работать не будет: он предоставляет клиентам таблицу NHRP, а также анонсирует все маршруты – филиалы распространяют маршрутную информацию не непосредственно друг другу, а через хаб.
Актуальная на данный момент конфигурация узлов:
msk-arbat-gw1
interface Tunnel0
ip address 172.16.254.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip ospf network broadcast
ip ospf priority 10
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint
nsk-obsea-gw1
interface Tunnel0
ip address 172.16.254.2 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tmsk-leneina-gw1
interface Tunnel0
ip address 172.16.254.3 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end
На данный момент решены следующие проблемы: 1) Связность. Филиалы подключены и доступны. 2) Маршрутизация. Через mGRE туннели успешно запущены IGP. 3) Масштабируемость. При добавлении нового spoke-маршрутизатора настраивается только он сам и нет необходимости лезть в конфигурацию уже существующих узлов. 4) Разгрузили хаб – через него передаётся только служебный трафик.
Осталось уладить вопрос с безопасностью.