antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 20 Ноябрь , 2013

Хотелось бы обратить Ваше внимание на то, что начиная с 15го IOS, циска изменила поведение протокола NHRP. Изменения касаются 2ой фазы работы протокола.

Что же конкретно изменилось? Теперь когда споук инициирует трафик в сторону другого споука, то одновременно с высылкой NHRP Resolution Request, маршрутизатор ставит себе в nhrp-таблицу фейковый маппинг, в котором говорит, что удаленный споук доступен через хаб. Запись выставляется на 3 минуты и не может быть очищена вручную. Чем это грозит? Представим, что 1ый споук хочет послать пакет на 2ой, а 2ой в это время не доступен. Тогда, 1ый выставляет себе nhrp mapping, связывая споук 2 с хабом. Далее, при поднятии 2го споука (канал починили, ура!) трафик на него будет ходить через хаб в течение 3ех минут. И только после этого произойдет переключение.

Также могут возникнуть проблемы если у вас есть 2 DMVPN облака – может сложиться ситуация, что удаленный споук не доступен (в течение 3 минут), хотя 2ой канал в up’е.

Немного практики. Настройка вполне стандартна (для примера я решил не использовать ipsec, только чистый dmvpn)

———- R1(HUB) ———-

interface Tunnel10
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 100
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint

———- R3/R4(SPOKE) ———-

interface Tunnel10
ip address 10.0.0.3 255.255.255.0
ip nhrp map multicast 136.1.1.1
ip nhrp map 10.0.0.1 136.1.1.1
ip nhrp network-id 100
ip nhrp nhs 10.0.0.1
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint

Проверим связность между споуками:

R3#ping 10.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
!!!!.
Success rate is 80 percent (4/5), round-trip min/avg/max = 64/84/96 ms

И nhrp таблицу:

R3#show ip nhrp brief
Target             Via            NBMA           Mode   Intfc   Claimed
10.0.0.1/32          10.0.0.1        136.1.1.1       static   Tu10    <   >
10.0.0.3/32          10.0.0.3        136.1.1.3       dynamic  Tu10    <   >
10.0.0.4/32          10.0.0.4        136.1.1.4       dynamic  Tu10    <   >

Видим, что здесь всё как положено: туннельный интерфейс споука мапится в соответствующий ему физический NBMA-адрес.

Эмулируем падение WAN-канала:

R4(config)#int tu10
R4(config-if)#shutdown

NHRP-записи на R3 будут оставаться активными в течение какого-то интервала времени:

R3#show ip nhrp detail
10.0.0.4/32 via 10.0.0.4
Tunnel10 created 00:01:31, expire 00:02:29
Type: dynamic, Flags: router used
NBMA address: 136.1.1.4

По истечение этого времени проверим доступность канала:

R3#ping 10.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
Success rate is 0 percent (0/3)
R3#show ip nhrp brief
Target             Via            NBMA           Mode   Intfc   Claimed
10.0.0.1/32          10.0.0.1        136.1.1.1       static   Tu10    <   >
10.0.0.4/32          10.0.0.4        136.1.1.1       dynamic  Tu10    <   >

Восстановим работу канала:

R4(config)#interface Tunn10
R4(config-if)#no shut

Проверим связность:

R3#ping 10.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
!!!!!
R3#show ip nhrp
10.0.0.4/32 via 10.0.0.4
Tunnel10 created 00:01:30, expire 00:01:34
Type: dynamic, Flags: used temporary

NBMA address: 136.1.1.1

Всё вроде бы хорошо, но трафик ходит через хаб.

 

 

 

Метки:
Опубликовано: Безопасность cisco

 

3 комментария “Изменения в DMVPN, Phase2”

comment rss - Trackback

  1. SoHm:

    Никак не могу понять, зачем направлять трафик в первые 3 минуты после поднятия канала через хаб, есть только предположение:
    Централизованный обмен различными сообщениями типа маршрутной информации и следовательно более легкая(?) отладка в случае проблем?

  2. fantas1st0:

    IGP COntrol-Plane и так всегда ходит через Хаб…
    Я пока не догнал для чего это сделано..

  3. odmin:

    У нас бы такой опыт — как-то юзеры одного из споуков стали жаловаться на низкую скорость работы с нашим офисом (мы тоже споук). При диагностике проблемы выяснилось, что трафик от нас до них ходит через хаб.

    При детальном изучении проблемы оказалось, что из-за ошибки конфигурирования на их стороне не было возможности поднять ipsec до нашего споука и вот эта самая фича 15-го IOS позволила им вообще хоть как-то с нами взаимодействовать хотя бы через хаб. И жили они так не меньше недели!

    Т.е. пока не поднялся туннель споук-ту-споук трафик ходит через хаб, а тунель до хаба у всех поднят дефакто и первый пакет не думая отправляется именно туда, т.е. связность есть ещё до того как поднялся туннель между споуками, и даже если он вообще не поднялся.

» Оставить комментарий

Вы должны войти чтобы прокомментировать.