cisco и проблемный канал провайдера

[Erich]

Здравствуйте, уважаемые форумчане. Возникла на работе проблемная ситуация. Есть два маршрутизатора: Cisco 2911 и Cisco 3845, соединенные через арендованный канал провайдера и несколько наших коммутаторов. Привожу примерную схему. На конечных интерфейсах на роутерах настроена сеть с 30-й маской, через коммутаторы проброшен vlan.

Проблем с этим каналом провайдера две. Первая заключается в том, что, когда Сisco 2911 работает по каналу, предоставленному провайдером (Мегафон), у ospf периодически истекает dead timer и теряется соседство, хотя канал по-прежнему работает и пинги ходят в обе стороны. Вот кусок лога:

 

Apr 24 15:47:21: %OSPF-5-ADJCHG: Process 255, Nbr 172.20.120.4 on GigabitEthernet1/0.2 from FULL to DOWN, Neighbor Down: Dead timer expired
Apr 24 15:48:59: %OSPF-5-ADJCHG: Process 255, Nbr 172.20.120.4 on GigabitEthernet1/0.2 from LOADING to FULL, Loading Done

 

В течение нескольких минут это все восстанавливается, но потом повторяется по новой. И так за день может быть до 2-3 разрыва, а может и 15-20. Зоны, таймеры ospf проверял, все сделано одинаково. Нашел похожую тему на этом форуме, где советовали перевести hello пакеты ospf на данном интерфейсе в unicast, но это не помогло.

Вторая проблема заключается в том, что при работе по арендованному каналу, устройства локальной сети, подключенные к Сisco 2911, также периодически перестают пинговаться. При переключении на другой канал таких проблем не наблюдается. При этом ошибок в лог никаких не падает. Может быть кто сталкивался с подобным или есть какие-нибудь мысли как одолеть оказию

Буду очень признателен, если поможете разрешить хотя бы одну проблему!

P.S. Если не хватает информации, выложу выводы нужных команд.

Edited April 24, 2015 by Erich

[Sergeylo]

Провайдер подозревается в последнюю очередь?

[sol]

Внимательно проверьте MTU по всему маршруту.

[cant]

P.S. Если не хватает информации, выложу выводы нужных команд.

 

Начните с простого.

Визуализируйте в течении суток пинги с точностью до секунды во времени и пространстве по всем хопам.

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

 

Чем сейчас модно, типа mtr или pingplotter.

[russ1st]

Попробуйте проверить:

1) Графики загрузки портов участвующих в ПД по данному каналу, возможно где-то упирается в "полку"

2) Наличие полисера или какой-то защиты на них же

3) Ошибки на портах

Edited April 24, 2015 by russ1st

[applx]

как ворк ароунд можно повесить demand-circuit в OSPF на интерфэйсах.

[rmika]

Мультикаст проверьте...

tcpdump |grep ваш_ip |grep Hello

[vurd]

Мультикаст проверьте...

tcpdump |grep ваш_ip |grep Hello

 

Он же перевел на юникаст ospf-шные сессии. 2ТС, перевел же?

[uk2558]

Была похожая проблема - аренда vlan с нашим OSPF у стороннего оператора. Так же падал периодически OSPF по таймеру, IP доступно было. Решилась, не помню уже, давно было, вроде бы отключением на всем транзитном железе стороннего оператора igmp_snooping в данном vlan.

[myst]

засуньте все в туннель

например ipsec

[Erich]

Чего-то я недопонимаю. Чтобы перевести hello-пакеты в unicast вводил такие команды:

(config-if)# ip ospf network non-broadcast

и

(config-router)#neighbor 172.20.120.4

После ввода этих команд смотрел логи, там hello-пакеты вообще не отправляются. Так и должно быть?

MTU проверял, стоят 1500 на конечных маршрутизаторах. На D-Link'ах не нашел как посмотреть. Еще пробовал команду

(config-if)#ip ospf mtu-ignore

Проблема пока осталась.

 

Решилась, не помню уже, давно было, вроде бы отключением на всем транзитном железе стороннего оператора igmp_snooping в данном vlan.

Интересное замечание, проверим эту версию

Edited April 30, 2015 by Erich

[g3fox]

А графика нагрузки на CPU у вас нет?

Проблема может быть и на control plane. А не в сети вообще.

В логах что-то есть?

Ещё у оператора может быть что-то вроде storm (traffic) control, в котором ограничивается pps мультикаста.

А вы с обеих сторон перевели на non-broadcast?

[White_Alex]

ip ospf network point-to-point на интерфейсах есть у Вас?

 

ну и да, с MTU похоже где-то не так, как наиболее вероятный на мой взгляд сценарий.

Edited April 30, 2015 by White_Alex

[ShyLion]

А что означает "GE1/0.2(Физический FE24)" ???

 

Ну и как правильно заметили, через операторские каналы только тунели!

Лечить прохождение мультикаста через всю эту колбасу - пустая трата времени и нервов.

[Erich]

Если указывать non-broadcast в настройках интерфейсов, а в ospf указывать соседа, то эта сеть вообще перестает участвовать в процессе маршрутизации, циски просто не перестраиваются на работу через этот канал, хотя он продолжает работать. Стоимость прописана командой bandwidth.

Если указывать point-to-point, то ospf шлет multicast.

 

MTU поменял на 1472, посмотрим, что будет.

 

А графика нагрузки на CPU у вас нет?

Проблема может быть и на control plane. А не в сети вообще.

В логах что-то есть?

Ещё у оператора может быть что-то вроде storm (traffic) control, в котором ограничивается pps мультикаста.

А вы с обеих сторон перевели на non-broadcast?

Графика нагрузки нет. show proc cpu на С3845 показывает загрузку около 30%, на С2911 вообще 1%.

Переводил с обоих сторон.

 

А что означает "GE1/0.2(Физический FE24)" ???

Это значит, что патч-корд включен в 24 порт на свитч-плате SM-ES2-24, а для работы маршрутизации настроен субинтерфейс GE1/0.2

Edited May 5, 2015 by Erich