# Теория

Что происходит в этот момент?

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:**\
![](http://img-fotki.yandex.ru/get/5641/83739833.23/0_abbff_9b09cdd_XXXL.jpg)

А хаб сразу же перенаправляет запрос на нужный адрес:

**msk-arbat-gw1, fa0/1:**\
![](http://img-fotki.yandex.ru/get/6428/83739833.23/0_abc00_a4d66506_XXXL.jpg)

4\) Одновременно с этим маршрутизатор-клиент в Новосибирске отправляет NHRP-запрос, мол кто укрывает адрес 172.16.254.3:

**msk-arbat-gw1, fa0/1:**\
![](http://img-fotki.yandex.ru/get/6440/83739833.23/0_abdb7_e6d9b593_XXXL.jpg)

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:**\
![](http://img-fotki.yandex.ru/get/5629/83739833.23/0_abdb8_1fce29ad_XXXL.jpg)

Больше Хаб не встревает в разговор двух споков.

6\) ICMP запрос пришёл в Томск:

**tmsk-lenina-gw1, fa0/0:**\
![](http://img-fotki.yandex.ru/get/5624/83739833.23/0_abdb6_928b7641_XXXL.jpg)

Несмотря на то, что во внешнем заголовке 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:**\
![](http://img-fotki.yandex.ru/get/6446/83739833.23/0_abdb9_e99cac81_XXXL.jpg)

8\) Следом за ним он интересуется о публичном адресе отправителя:

**tmsk-lenina-gw1, fa0/0:**\
![](http://img-fotki.yandex.ru/get/4138/83739833.23/0_abdc6_33f6cc63_XXXL.jpg)

9\)Ну и хаб, естественно, отвечает:

**tmsk-lenina-gw1, fa0/0:**\
![](http://img-fotki.yandex.ru/get/5634/83739833.23/0_abdbc_e0284054_XXXL.jpg)

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:**\
![](http://img-fotki.yandex.ru/get/6437/83739833.23/0_abdbd_56822ef5_XXXL.jpg)

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\) Разгрузили хаб – через него передаётся только служебный трафик.

Осталось уладить вопрос с безопасностью.


---

# Agent Instructions: 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://linkmeup.gitbook.io/sdsm/7.-vpn/5.-dmvpn/1.-ospf/1.-teoriya.md?ask=<question>
```

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.