Этот капризный eigrp на DMVPN-тоннелях

в 21:21, , рубрики: Cisco, DMVPN, eigrp, Сетевое оборудование, Сетевые технологии, метки: , ,

Поделюсь проблемой и ее внезапным решением, с которыми мы столкнулись на прошлой неделе, и доставившей нам множество неприятностей.
Итак, ситуация достаточно стандартная, центральный офис компании соединен каналами связи с удаленными подразделениями. Связь (Интернет и VPN) дают два оператора. Для того, чтобы минимизировать простои удаленных подразделений на каждое подразделение построены по 2 тоннеля DMVPN. Маршрутизация внутри сети динамическая, eigrp. Соотвественно в центральном офисе используется 2 маршрутизатора Cisco.
Количество удаленных подразделений — около 70, соотвественно каждый маршрутизатор строит такое же количество тоннелей. Средняя нагрузка на канал — 40-60% от полосы пропускания, гарантированной операторами.
Настройка DMVPN использовалась достаточно стандартная, описанная в букваре:

hub:

interface Tunnel201
description -=DMVPN_201=-
ip address 10.10.201.1 255.255.255.0
no ip redirects
ip mtu 1416
ip hold-time eigrp 1 25
no ip next-hop-self eigrp 1
ip nhrp authentication 11111
ip nhrp map multicast dynamic
ip nhrp network-id 201
no ip split-horizon eigrp 1
delay 1000
cdp enable
tunnel source GigabitEthernet0/0.2
tunnel mode gre multipoint
tunnel key 11111
!
end

router eigrp 1
network 10.10.201.0 0.0.0.255
network 192.168.0.0 0.0.1.255

В общем-то классическая схема, прекрасно работающая несколько месяцев подряд.

www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008014bcd7.shtml — похожий пример от Cisco.

Пока в один прекрасный день мы не столкнулись с проблемой, что все внутренние маршруты по eigrp не начали отваливаться каждые 30-90 секунд. При этом тоннель прекрасно стоял и тоннельны интерфейс отлично пинговался. В логах сыпались ошибки типа:

*Apr 23 2013 15:19:47.759 GMT+11: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.10.202.9 (Tunnel202) is down: holding time expired
*Apr 23 2013 15:19:52.707 GMT+11: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.10.202.9 (Tunnel202) is up: new adjacency
*Apr 23 2013 15:23:56.298 GMT+11: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.10.202.57 (Tunnel202) is up: new adjacency
*Apr 23 2013 15:24:43.070 GMT+11: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.10.202.9 (Tunnel202) is down: holding time expired

Причем перегрузка проблема возникла внезапно и сразу на обоих маршрутизаторах. Начались танцы с бубном, курение cisco.com и т.д.
Перегрузка каждого из маршрутизаторов отдельно проблему не решило.
Перегрузка обоих маршрутизаторов, предпринятая как крайняя мера, оставила филиалы без связи на довольно большой (до 15-20 минут) промежуток, но с проблемой справиться помогло. Можно было выдохнуть и спокойно начать искать причину, надеясь что еще несколько месяцев все прекрасно проработает, как работало до этого.
Однако мы рано обрадовались, 3 дня спустя проблема повторилась абсолютно тем же способом. Все рекомендации с cisco.com по изменению mtu на тоннеле и физическом интерфейсе равно как прочие шаманские камлания результата не приносили. Спустя довольно продолжительный промежуток времени, на одном из совсем крошечных форумах нами был обнаружен топик с подобной проблемой, и в последнем сообщении было написано что-то типа:
«Всем спасибо, проблема пофиксена. Не знаю как и почему, но помогло включение ip bandwidth-percent eigrp».

Поскольку делать все равно было нечего, без особой веры в успех, прописываем указанную команду в свойствах тоннеля, указав в качестве параметра использования канала цмфру 100 (все равно терять нечего), и — ЧУДО, все заработало как часы.
А ведь перерывая кучу форумов мы неоднократно натыкались на данную проблему, возникшую у других коллег, и решения так и не было описано.
Естественно, в дальнейшем цифру мы уменьшили.
Может мы и изобрели очередной велосипед, но не нашли эту информацию больше нигде. Возможно понадобится еще кому-то. Пользуйтесь, пожалуйста.

Автор: NovgorodovNikolay

Источник

Поделиться

* - обязательные к заполнению поля