Элтекс

Добрый день!
прошу помощи с настройкой OSPF между указанными железками

Описание схемы:
R1 и R2 в area 0.0.0.0. Остальные в AREA 6.0.0.0.
R1 и R2 - ABR.
R1, R2, R3 - 3108, R4,R5 - 3308

Изначально не было R3, зона не была замкнута. До этого экспериментировал с типами зон, данная зона была stub, попытался перевести в normal, между R1 и R5 ospf не поднимался, при возврате в stub всё снова работало. Добавился R3, зона замкнулась на R2, пока была stub, ospf работал.
Сейчас требуется зону перевести в normal. сначала бился с R3 и R4. состояние застревает на exchange с одной стороны и exchangeStart с другой.
После нескольких часов возни с конфигурацией, нескольких clear ip ospf process, состояние перешло в full.
Теперь нужно поднять ospf между R1 И R5, та же история, состояние выше Exchange не поднимается.

Версия 3108 - 2.5.42, 3308 - 4.0.10.

Здравствуйте.

Версия 3108 - 2.5.42, 3308 - 4.0.10.

Обновите 3108 до актуальной версии https://eltex-co.ru/catalog/aggregation/mes3108f/. Проблема уйдет?

Мой коллега тестировал ОСПФ на версии 2.5.46, была проблема с маршрутами
viewtopic.php?f=10&t=7261&p=34357&hilit=ospf#p34357
проблема решилась даунгрейдом до версии 2.5.42. Сейчас сеть запущена в эксплуатацию, а этот 3108 одна из центральных железок, не хотелось бы экспериментировать на живой сети. кроме того, между R3 И R4 на тех же версиях софта оспф поднялся.
Есть другие варианты?

Сейчас актуальная версия 2.5.48.2. Начиная с версии 2.5.47 было большое количество правок в работе OSPF. Прошу обновиться до 2.5.48.2 и перепроверить.

По вашей рекомендации решил потестить последний софт - 2.5.48.2
Собрал следующую схему:



R1 и R2 - действующие железки, 3108 2.5.42, в зоне 0.0.0.0, ABR
R3 и R4 - тестовые, в зоне 10.0.0.0

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

Затем на R4 я поменял софт на 2.5.48.2.
1. все маршруты, кроме directly connected и 10.129.204.84/30 в таблице маршрутизации были помечены как external. Тут, конечно, есть какая-то логика, для зоны 10.0.0.0 маршруты из других зон можно назвать External, но вроде как это всё же должны быть сети, введенные в оспф с помощью redistribute.
2. через несколько минут R4 выплюнул в консоль сообщение "FATAL ERROR", и ушел в ребут. Загрузился, в таблице маршрутизации ситуация, описанная выше. я подождал несколько минут, чтобы убедиться что он снова не перезагрузится.

Затем на R3 и поменял софт на 2.5.48.2.
1. Отправил R3 в перезагрузку для обновления софта, через несколько секунд в след за ним самостоятельно ушел в перезагрузку R4.
2. После загрузки оспф поднялся на всех узлах, на R3 и R4 таблицы маршрутизации выглядели аналогично - все маршруты, кроме connected и сетей в зоне 10.0.0.0, участвующих в оспф, были помечены как External.
3. Одновременная перезагрузка мне показалась совпадением, решил это проверить. на R3 откатил софт на 2.5.42. Когда R3 загрузился, на нём все соседи перешли в full, а на R4 состояние соседства с R3 было exchange. при этом с R4 10.129.204.82 пинговался, с HOST - нет. также с HOST не пинговался R2 и R3, хотя на R4 были маршруты до всех сетей. C HOST пинговались сети, которые находились за R1, но маршрут до которых НЕ проходил через R2.
4. через несколько минут пинг c HOST до интерфейса R4, на котором HOST терминируется, стал странный, через один пакет задержка была то 1 мс, то более 100-200. R4 перестал отвечать в консоль(COM-порт), пришлось рестартовать по питанию.
5. снова загрузил R3 c софтом 2.5.48.2. R3 и R4 самопроизвольно рестартовали каждые несколько минут.
6. погасил линки R2-R3 и R1-R4. R3 и R4 в течение минут 30 стояли без ребутов. далее тест был окончен.

для себя сделал вывод, что данные версии ПО не совместимы. Учитывая, что у меня в OSPF-домене сейчас порядка 30 узлов, одновременно на всех поменять софт не представляется возможным, следовательно, не исключить ситуацию, когда на узлах будут разные версии софта, и те, что с 2.5.48.2 будут рестартовать, пока софт не обновится на всех. В действующей сети такое допустить нельзя.

Есть ещё варианты?

Касательно ситуации в старте темы:
Такое ощущение, что между 3108 и 3308 не передаются определенные типы LSA.
Без проблем ОСПФ поднимается при виде зоны STUB и NSSA. При типе normal состояние соседства застревает на exchange вне зависимости от того, нулевая это зона или ненулевая.

Приветствую. Удалось настроить ?

Garri писал(а):Приветствую. Удалось настроить ?

Приветствую!
К сожалению, нет. Более того, применительно к первой схеме, непонятным образом поднявшийся ОСПФ между R3 и R4, в какой-то момент развалился и больше не поднялся. Больше тестов не проводил, можно было бы дампы какие-то пособирать, но 3308 на руках нет.

Последняя версия для 3108 это 2.5.48.5. Для 3308 - 4.0.10.1.
Если будите тестировать было бы интересно посмотреть на дампы.

на момент тестирования - 27 декабря - последняя версия для 3108 была 2.5.48.2.
Обновлять рабочие железки до 2.5.48.5 пока не планирую, т.к. тестирование 3108 с софтами 2.5.42 и 2.5.48.2 завершилось неудачей.
При обновлении у меня будет именно такая ситуация, на части 3108 в любом случае какое-то время будет старый софт, а завалить всю сеть я не могу себе позволить.
Если появятся 3308 для тестов, обязательно потестирую и отпишусь, но маловероятно, что это будет скоро

По поводу простоя.
Что мешает обновить прошивку на всех коммутаторах без последующей перезагрузки.
И когда все прошивки будут обновлены отправить все коммутаторы на перезагрузку?

Aleksey Shimanov писал(а):По поводу простоя.
Что мешает обновить прошивку на всех коммутаторах без последующей перезагрузки.
И когда все прошивки будут обновлены отправить все коммутаторы на перезагрузку?

мешает то, что это критичная инфраструктура, простои недопустимы, поэтому есть полное резервирование, но оно также организовано на элтексах и ОСПФ. кроме того, где гарантии, что после обновления на всех железках всё заработает? У меня нет уверенности в этом. А если что-то пойдёт не так, к примеру, на версии 2.5.47 были проблемы с маршрутами в ОСПФ, придется всё откатывать, это значительно увеличит время простоя.