Erich Опубликовано 24 апреля, 2015 (изменено) · Жалоба Здравствуйте, уважаемые форумчане. Возникла на работе проблемная ситуация. Есть два маршрутизатора: 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. Если не хватает информации, выложу выводы нужных команд. Изменено 24 апреля, 2015 пользователем Erich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergeylo Опубликовано 24 апреля, 2015 · Жалоба Провайдер подозревается в последнюю очередь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 24 апреля, 2015 · Жалоба Внимательно проверьте MTU по всему маршруту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cant Опубликовано 24 апреля, 2015 · Жалоба P.S. Если не хватает информации, выложу выводы нужных команд. Начните с простого. Визуализируйте в течении суток пинги с точностью до секунды во времени и пространстве по всем хопам. Бывает что это сразу и быстро помогает локализовать проблему даже уже постфактум и по характеру дропа,задержек понять её природу. Чем сейчас модно, типа mtr или pingplotter. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
russ1st Опубликовано 24 апреля, 2015 (изменено) · Жалоба Попробуйте проверить: 1) Графики загрузки портов участвующих в ПД по данному каналу, возможно где-то упирается в "полку" 2) Наличие полисера или какой-то защиты на них же 3) Ошибки на портах Изменено 24 апреля, 2015 пользователем russ1st Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 24 апреля, 2015 · Жалоба как ворк ароунд можно повесить demand-circuit в OSPF на интерфэйсах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rmika Опубликовано 25 апреля, 2015 · Жалоба Мультикаст проверьте... tcpdump |grep ваш_ip |grep Hello Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 25 апреля, 2015 · Жалоба Мультикаст проверьте... tcpdump |grep ваш_ip |grep Hello Он же перевел на юникаст ospf-шные сессии. 2ТС, перевел же? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 27 апреля, 2015 · Жалоба Была похожая проблема - аренда vlan с нашим OSPF у стороннего оператора. Так же падал периодически OSPF по таймеру, IP доступно было. Решилась, не помню уже, давно было, вроде бы отключением на всем транзитном железе стороннего оператора igmp_snooping в данном vlan. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 27 апреля, 2015 · Жалоба засуньте все в туннель например ipsec Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Erich Опубликовано 30 апреля, 2015 (изменено) · Жалоба Чего-то я недопонимаю. Чтобы перевести 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. Интересное замечание, проверим эту версию Изменено 30 апреля, 2015 пользователем Erich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 30 апреля, 2015 · Жалоба А графика нагрузки на CPU у вас нет? Проблема может быть и на control plane. А не в сети вообще. В логах что-то есть? Ещё у оператора может быть что-то вроде storm (traffic) control, в котором ограничивается pps мультикаста. А вы с обеих сторон перевели на non-broadcast? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
White_Alex Опубликовано 30 апреля, 2015 (изменено) · Жалоба ip ospf network point-to-point на интерфейсах есть у Вас? ну и да, с MTU похоже где-то не так, как наиболее вероятный на мой взгляд сценарий. Изменено 30 апреля, 2015 пользователем White_Alex Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 30 апреля, 2015 · Жалоба А что означает "GE1/0.2(Физический FE24)" ??? Ну и как правильно заметили, через операторские каналы только тунели! Лечить прохождение мультикаста через всю эту колбасу - пустая трата времени и нервов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Erich Опубликовано 5 мая, 2015 (изменено) · Жалоба Если указывать 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 Изменено 5 мая, 2015 пользователем Erich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...