Теория
Что происходит в этот момент?
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:
А хаб сразу же перенаправляет запрос на нужный адрес:
4) Одновременно с этим маршрутизатор-клиент в Новосибирске отправляет NHRP-запрос, мол кто укрывает адрес 172.16.254.3:
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-ответе:
Больше Хаб не встревает в разговор двух споков.
6) ICMP запрос пришёл в Томск:
Несмотря на то, что во внешнем заголовке 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 < >
8) Следом за ним он интересуется о публичном адресе отправителя:
9)Ну и хаб, естественно, отвечает:
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 < >
13) Ну и дальше пакет с адресом получателя 198.51.102.2 отправляется согласно таблице маршрутизации:
Gateway of last resort is 198.51.101.1 to network 0.0.0.0
Тут важно понимать, что несмотря на то, что общение между филиалами осуществляется в обход центрального узла, хаб однако несёт тут жизненно важную вспомогательную функцию и без него ничего работать не будет: он предоставляет клиентам таблицу NHRP, а также анонсирует все маршруты – филиалы распространяют маршрутную информацию не непосредственно друг другу, а через хаб.
Актуальная на данный момент конфигурация узлов:
На данный момент решены следующие проблемы: 1) Связность. Филиалы подключены и доступны. 2) Маршрутизация. Через mGRE туннели успешно запущены IGP. 3) Масштабируемость. При добавлении нового spoke-маршрутизатора настраивается только он сам и нет необходимости лезть в конфигурацию уже существующих узлов. 4) Разгрузили хаб – через него передаётся только служебный трафик.
Осталось уладить вопрос с безопасностью.
Last updated
