Почему протокол OSPF работает некорректно?

Question

Азамат

сетевое-администрирование , mpls , nokia , ospf , network-hardware

Почему протокол OSPF работает некорректно?

У меня есть OSPF сеть, построенная на сервисных маршрутизаторах Nokia: 7705 SAR-8 и 7750 SR-a4, где все маршрутизаторы находятся в 0 зоне. Между двумя маршрутизаторами (7705 и 7750) существует операторский канал, в котором ARP-запросы проходят только в одну сторону: от 7750 к 7705 проходит запрос, а ответ уходит обратно. Однако, в обратном направлении это не работает. В результате, если время жизни ARP-записи на 7705 истекло, 7705 не может определить, куда отправлять свои Ethernet-кадры, пока ARP не обновится на 7750. Это приводит к тому, что канал перестает работать. 

На интерфейсах этих маршрутизаторов настроен OSPF с типом интерфейсов point-to-point. Когда ARP-таблицы на обоих маршрутизаторах заполнены, система функционирует нормально. Но если ARP на 7705 истекает, то связь теряется, хотя OSPF-соседство на обеих маршрутизаторах остается в состоянии full. В результате маршрутизаторы продолжают отправлять трафик в этом канале, перенаправляя его только в случае падения линка на одном из маршрутизаторов. 

Я решаю проблему с ARP на уровне оператора. Также я изменил тип интерфейсов OSPF на broadcast, но в этом случае состояние OSPF Neighbor остается на этапе Exstart, хотя, по моему пониманию, оно должно быть в состоянии Init. 

Почему OSPF ведет себя таким образом? Почему он не распознает потерю канала? И как в случае point-to-point типа интерфейсов состояние соседства может достигать полного уровня даже при отсутствии связи? Я понимаю, что в случае неработающего канала пакет Hello от 7750 приходит, но как 7705 может отправить ответный Hello, если он должен инкапсулироваться в IP, а затем в Ethernet, и при этом маршрутизатор не знает, на какой MAC-адрес отправлять ответ?

4 ноября 2024 г. 14:13

Ответы на вопрос 2

Похожие вопросы

Answer 1

Ваше описание проблем с OSPF действительно указывает на сложные нюансы работы протокола в условиях ограничений ARP. Давайте разберёмся по порядку.

1. **Состояние OSPF-соседства**:
Когда у вас настроен тип интерфейса OSPF как point-to-point, OSPF-узлы должны обмениваться пакетами Hello для установки и поддержания соседства. Каждый роутер должен знать MAC-адрес соседа для успешной передачи этих пакетов. Если 7705 не знает, куда отправлять пакеты (из-за истечения ARP-записи), он не сможет ответить на Hello-пакет 7750, но если ARP-запись на 7750 всё ещё актуальна, он получит Hello от 7750 и сможет установить соседство. Надо учесть, что соседство может сохраняться даже при перегрузках или потерях связи на канале.

2. **Зачем OSPF остается в состоянии Full**:
OSPF поддерживает состояние Full, потому что оно зависит от получения Hello-пакетов, а не от возможности завести трафик через канал. Если каналы работают в «одностороннем» режиме, как в вашем случае, а сосед присылает Hello-пакеты, OSPF не может определить, что связь на самом деле нарушена, поскольку не получает никаких ошибок или неудач на уровне OSPF.

3. **Проблема с ARP**:
Учитывая, что ARP работает на уровне 2 (канальный уровень), а OSPF — на уровне 3 (сетевой уровень), когда ARP-запись истекает, 7705 не знает, куда отправлять пакеты, что приводит к потере связи, несмотря на установленные OSPF-соседства. Это классическая ситуация, когда проблемы канального уровня вызывают сбои на сетевом уровне.

4. **Изменение типа интерфейсов на Broadcast**:
Когда вы изменили тип интерфейсов на broadcast, OSPF ожидает от каждого соседа не только Hello-пакеты, но и DB-описания. Однако, если OSPF-сосед не может передавать свои Hello-пакеты в ответ из-за проблем с ARP, состояние OSPF-соседства останется в Init или Exstart, поскольку отправка и получение контрольных пакетов не произошло должным образом.

### Рекомендуемые действия:
1. **Решите проблемы с ARP**: Как вы уже планируете, оптимизируйте процесс ARP. Возможно, стоит настроить более долгие временные интервалы для ARP-записей или использовать статические ARP-записи, если это возможно.

2. **Убедитесь в корректной настройке OSPF**: Если OSPF тип интерфейса broadcast вызывает проблемы, вернитесь к типу point-to-point и попробуйте обеспечить, чтобы ARP работал корректно.

3. **Мониторинг состояния каналов**: Внедрите систему мониторинга состояния связей, чтобы выявлять и исправлять проблемы до того, как они повлияют на взаимодействие маршрутизаторов.

4. **Исследуйте другие механизмы**: Возможно, использование других протоколов или методов маршрутизации (например, статики в некоторых случаях) может решить проблемы в вашей ситуации.

Таким образом, основная проблема заключается в нарушении связи на уровне маршрутизации, вызванном неправильной работой ARP, что в конечном итоге влияет на возможность OSPF корректно работать.

Answer 2

Я понимаю, что при нерабочем канале от 7750 к 7705 Hello пакет приходит, но как 7705 отправляет ответный hello, если он должен инкапсулироваться в ip, а потом в ethernet, но маршрутизатор не знает на какой mac-адрес отправлять ответ?
 
 Насколько я помню OSPF использует свой протокол, которому не нужен ARP,  работает по дефолту он по мультикасту,  там не надо знать мак адреса участников,  пакет получать все кто будет слушать группу. 
 
 А при типах интерфейса broadcast маршрутизаторы по такой же схеме доходят до Exstart, а вот почему дальше ничего не происходит не понятно. 
 
 Во многих случаях на Exstart зависает,  когда MTU  на обоих концах разные. Можно попробовать убрать проверку MTU. В остальных случаях надо смотреть дебаг. 
 
 PS. Если платфора позволяет то настройте связку BFD + OSPF, она должна лучше отрабатывать переключение между линками во время проблем на одном из линков.