Есть OSPF сеть построенная на сервисных маршрутизаторах Nokia: 7705 SAR-8 и 7750 SR-a4, все маршрутизаторы которой находятся в 0 зоне. Между двумя маршрутизаторами (7705 и 7750) имеется операторский канал в котором arp-запросы проходят только в одну сторону - от 7750 к 7705 приходит запрос и обратно уходит ответ. В обратную сторону это не работает. Соответственно если время жизни arp записи на 7705 истекло, то пока оно не истечет на 7750 (или arp на нем не будет очищен) 7705 не знает куда слать свои ethernet кадры и канал перестает работать.
На интерфейсах указанных маршрутизаторов поднят OSPF с типом интерфейсов point-to-point. Если arp-таблицы на обеих маршрутизаторах заполнены, то все работает отлично. Но вот если arp на 7705 истек, то канал соответственно пропадает, НО ospf-neighbor на обеих маршрутизаторах остается в full и соответственно маршрутизаторы вместо того, чтобы перенаправить трафик через другие узлы упорно шлют его в этот канал, перенаправляя трафик только в случае если на одном из маршрутизаторов упал линк.
Проблему с arp оператор решает.
Проблему с OSPF решил переводом OSPF-интерфейсов в тип broadcast, при этом даже в таком варианте OSPF Neighbor находятся в состоянии Exstart, хотя в моем понимании должны были остаться в Init.
Почему OSPF так странно отрабатывает? Почему не обнаруживает потерю канала? А при типах интерфейсов poin-to-point отношение соседства даже встает в состояние full?
Я понимаю, что при нерабочем канале от 7750 к 7705 Hello пакет приходит, но как 7705 отправляет ответный hello, если он должен инкапсулироваться в ip, а потом в ethernet, но маршрутизатор не знает на какой mac-адрес отправлять ответ?
Могу предположить, что маршрутизатор 7705 зная из конфига, что он к соседу подключен через L2 сеть, использует для ответа mac-адрес источника ethernet кадра который доставил hello пакет и по такому же принципу осуществляет весь обмен. А при типах интерфейса broadcast маршрутизаторы по такой же схеме доходят до Exstart, а вот почему дальше ничего не происходит не понятно. Да и в целом это предположение выглядит странно, просто пытаюсь хоть как-то себе это объяснить. Дамп не снимал, если проблема с arp не уйдет, то позже ради интереса сниму дамп и посмотрю что там происходит, если будет на это время.
Спасибо, что прочитали, если у Вас есть такая возможность, то прошу объяснить мне все максимально подробно.
Я понимаю, что при нерабочем канале от 7750 к 7705 Hello пакет приходит, но как 7705 отправляет ответный hello, если он должен инкапсулироваться в ip, а потом в ethernet, но маршрутизатор не знает на какой mac-адрес отправлять ответ?
Насколько я помню OSPF использует свой протокол, которому не нужен ARP, работает по дефолту он по мультикасту, там не надо знать мак адреса участников, пакет получать все кто будет слушать группу.
А при типах интерфейса broadcast маршрутизаторы по такой же схеме доходят до Exstart, а вот почему дальше ничего не происходит не понятно.
Во многих случаях на Exstart зависает, когда MTU на обоих концах разные. Можно попробовать убрать проверку MTU. В остальных случаях надо смотреть дебаг.
PS. Если платфора позволяет то настройте связку BFD + OSPF, она должна лучше отрабатывать переключение между линками во время проблем на одном из линков.
bfd настраивал, не помогло. Правда настроил его в момент когда 7705 не знал mac соседа. Bfd - сессия не поднималась, но ospf работал как и работал.
Возможно будет корректно работать когда устройства знали mac-адреса друг друга и на 7705 время жизни записи в arp-таблице истекло. В таком случае уже установившейся bfd сессия будет обрываться о чем bfd просигнализирует в ospf и ospf начнет перестраивать таблицу. Если будет такая возможность, то поэкспериментирую.
А по поводу ospf, он ведь действительно использует мультикаст, что-то я не подумал об этом.
Спасибо!
Strabbo, bfd падает, а ospf живой, если интерфейсы point -to-point, а если broadcast, то зависает в exchange. Трафик не ходит, да. Rsvp перестраивает lsp на резервные пути, а вот tldp пытается поднять сессию с встречным маршрутизатором, но безуспешно. Как следствие lsp подняты, а sdp падают.
LMM29, ну это уже совсем аномалия, скорее всего по каким то причинам OSPF не надеется на BFD... А у вас BFD на других сегментах сети тоже не работают? У некоторых вендоров можно BFD на LDP вешать, может ваш тоже может.
P.S. никогда не любил OSPF, только из-за перевел бы всё на is-is :)
Strabbo, да на других сегментах bfd работает хорошо, даже статика нормально переключается. В ldp bfd тоже прописал, но что-то безрезультатно. Сейчас пользуюсь тем, что все нормально работает когда ospf интерфейсы в режиме broadcast, в full не встаёт сосед, трафик идёт в обход, а если arp заполнился, начинает гнать трафик напрямую. Но в целом ситуация странная. Дополню комментарий, если разберусь в сути проблемы.
Простой
Простой
