Хотелось бы обратить Ваше внимание на то, что начиная с 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)#shutdownNHRP-записи на 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 temporaryNBMA address: 136.1.1.1
Всё вроде бы хорошо, но трафик ходит через хаб.
Метки: DMVPN
Опубликовано: Безопасность cisco
Никак не могу понять, зачем направлять трафик в первые 3 минуты после поднятия канала через хаб, есть только предположение:
Централизованный обмен различными сообщениями типа маршрутной информации и следовательно более легкая(?) отладка в случае проблем?
IGP COntrol-Plane и так всегда ходит через Хаб…
Я пока не догнал для чего это сделано..
У нас бы такой опыт — как-то юзеры одного из споуков стали жаловаться на низкую скорость работы с нашим офисом (мы тоже споук). При диагностике проблемы выяснилось, что трафик от нас до них ходит через хаб.
При детальном изучении проблемы оказалось, что из-за ошибки конфигурирования на их стороне не было возможности поднять ipsec до нашего споука и вот эта самая фича 15-го IOS позволила им вообще хоть как-то с нами взаимодействовать хотя бы через хаб. И жили они так не меньше недели!
Т.е. пока не поднялся туннель споук-ту-споук трафик ходит через хаб, а тунель до хаба у всех поднят дефакто и первый пакет не думая отправляется именно туда, т.е. связность есть ещё до того как поднялся туннель между споуками, и даже если он вообще не поднялся.