+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

OSPF — "Флаппинг" — ошибка?

OSPF — "Флаппинг" — ошибка?, RouterOS

samsung172

Guest

22.10.2014 23:39:00

Я использую OSPF для распределения MPLS по сети. Для этого я подключил кучу маршрутизаторов, используя подсети x.x.x.x/29, чтобы связать R1 с R2, и у всех маршрутизаторов есть loopback. На всех интерфейсах, связывающих маршрутизаторы, включен MPLS. Всё “ок”. OSPF используется для распространения MPLS-меток — тоже работает без проблем.

Сегодня заметил неизвестную ошибку, которая влияет на все устройства. Предположим, у меня 100 маршрутизаторов, подключённых тем или иным способом. Некоторые связаны так, что образуют “кольцо” с “шипами”. У ни одного маршрутизатора не должно быть статического дефолтного шлюза — всё настроено так, чтобы дефолтный маршрут назначался через OSPF, если он установлен. Вроде бы всё ок. Кажется...

Но сейчас у меня начались какие-то скачки в OSPF. По идее, OSPF всегда должен выбирать кратчайший путь... Но теперь он начал “прыгать” между основным (самым коротким) и резервным (не самым коротким) путём.

Почему возникают эти флуктуации? Это баг?

Пример: около 10 секунд у R1 в качестве шлюза стоит R2 — через интерфейс X, который их связывает. У R3 есть связь с ядром, но стоимость OSPF там около 1500. У R1-R2 стоимость — около 110. Теперь эти два канала начали “прыгать”: допустим, 0.0.0.0 через интерфейс 1 (стоимость 110) на несколько секунд, затем переключается на интерфейс 2 (стоимость 1000 с чем-то) на пару секунд, потом обратно на интерфейс 1.

Почему так происходит? Он же должен выбирать самый короткий путь и “держаться” за него. Почему возникают такие скачки?

ZeroByte

Guest

28.07.2015 14:59:00

Спасибо, что поделились своим решением. Это помогает тем, у кого похожие проблемы. Вы так и не выяснили, где у вас был цикл? RSTP не просто так сходит с ума и блокирует ссылки без причины. Согласен, что в топологии уровня 3 этого не должно быть, но если он всё же обнаружил цикл, это точно стоит проверить.

djmitch

Guest

27.07.2015 11:14:00

Итак, я замкнул кольцо в сети и переключил все беспроводные каналы обратно на NBMA, а ссылки через медный кабель оставил на мультикасте. Ошибок с флагом db master у меня нет, OSPF работает отлично уже 3 дня. Один из каналов прыгал (проблемы с питанием), но никаких негативных последствий не было. Для OSPF я использовал интерфейсы loopback в качестве router ID, к тому же у меня есть несколько областей в OSPF: основное ядро 0.0.0.0 и несколько споков с новым ID области. Также loopback применил для настроек MPLS LDP и транспорта. Loopback считается лучшей практикой для OSPF ID и для ссылок в настройках MPLS LDP/транспорта. Единственное, что добавил — это административный MAC-адрес на loopback. Это дало мне уверенность, что MAC у loopback всегда одинаковый (иначе он берет MAC с физического интерфейса, насколько я понимаю). При работе VPLS поверх MPLS переключение происходит очень быстро, и сессии не обрываются даже при сбое на одном из каналов. Всё это запущено на версии 6.28.

djmitch

Guest

23.07.2015 13:17:00

Удалось ли вам решить эту проблему? У меня похожая настройка — 14 роутеров, образующих 2 петли/кольца, которые выглядят как восьмерка, чтобы обеспечить резервные пути. На средней линии «восьмерки» находятся 2 роутера, которые соединяют верхнее и нижнее кольцо. Все работают на версии 6.28. Если я закрываю любое из колец, всё идёт наперекосяк, и в OSPF-дебагах появляется запись «wrong master flag». Сейчас сеть работает с OSPF/MPLS/VPLS. Всё стабильно, пока не закроешь одно из колец. Используется NBMA-режим, jumbo-фреймы и увеличенный MTU (по всей сети одинаковые). Кто-нибудь знает решение?

djmitch

Guest

24.07.2015 05:28:00

Ладно, кажется, сегодня я наконец-то разобрался с этим. Переключил свои линки в режим PTP — это убрало проблему с мастер-флагом, но сетевая петля всё равно не держалась стабильной. Я решил проверить, почему не могу пропинговать между линками (а они должны работать, даже если кольцо «летает»). Обратил внимание, что на коммутаторе, к которому подключён Mikrotik, запущен RSTP, который блокировал форвардинг. Выключил RSTP — и линк поднялся. Проверил остальные коммутаторы, сделал то же самое, и теперь обе петли, похоже, работают нормально. Моя догадка: я замкнул петлю, какие-то пакеты появились на интерфейсе, которого коммутатор не ожидал, и он «задёргался» — заблокировал форвардинг. Это может объяснить, почему между разными линками были перебои. Планирую так оставить на пару часов, посмотреть, что будет дальше. Хочу потом переключить линки обратно на NBMA (вместо PTP), поскольку PTP всё же использует мультикаст. Надеюсь, что с исчезновением OSPF проблема с DB master flag тоже пройдет. Обновлю, когда верну всё обратно. Поскольку я работаю с MPLS/VPLS и split horizon, сетевые петли не должны вызывать проблем. Буду держать пальцы скрещенными…

djmitch Guest	#6 0 28.07.2015 17:55:00 Привет, ZeroByte! Итак, на каждом объекте у нас есть Ubiquiti ToughSwitch (8 портов) и Mikrotik RB2011. Как правило, порт 8 на ToughSwitch подключен к порту 8 на Mikrotik и настроен как транковый порт. Порт 8 на ToughSwitch настроен с VLAN 50 и 51 как Tagged, и на Ether 8 добавлены VLAN 50 и 51. VLAN 50 — это управление, 51 — для клиентов. Также мы метим трафик на точках доступа и CPE, чтобы иметь и управленческое соединение, и PPPoE/клиентское соединение ко всем устройствам. Всё стандартно. Предположим, что на каждом объекте есть 2 PtP-ссылки, тогда порты 1 и 2 на ToughSwitch будут VLAN 12, и эти порты настроены как access/untagged. Порты 3 и 4 — VLAN 34, тоже access/untagged. Эти VLANы не идут в транковый порт. Нечётные порты питают, например, беспроводной мост, а чётные идут на Mikrotik. В данном случае, скажем, Ether 2 и Ether 4 идут на toughswitch порты 2 и 4. IP-адреса назначены на Ether 2 и 4, и это формирует PtP /29 линк. Такая настройка коммутатора может отличаться от других, но работает и позволяет обойтись только двумя устройствами на каждом холме. Думаю, проблемы появились, когда VPLS-трафик приходил в локальный VLAN (50 или 51) с другого объекта (после «замыкания» петли), и коммутатор обнаруживал петлю и отключал порт, с которого шел трафик — в этом случае один из беспроводных юнитов. Это происходило между разными ссылками, то есть RSTP закрывал порты на разных коммутаторах в зависимости от того, как сеть обучалась маршрутам. По сути, во время начального переобучения маршрутов трафик шел с неожиданного для RSTP места, и он отключал порт. Каждый раз, когда сеть пыталась изучить маршруты, какой-то порт отключался или блокировался. Я отключил RSTP на всех коммутаторах, так как вероятность локальной петли на такой конфигурации мала. Я мог бы включить RSTP только на нужном VLAN — возможно, VLAN 51 (клиентском), поскольку он проброшен (для PPPoE) через VPLS-сеть. Но я использую split horizon, так что RSTP не нужен. Кажется, я правильно понимаю... Надеюсь, это кому-то пригодится. Я взял много заметок из других проблем с OSPF и улучшил свою конфигурацию, но это может заставить думать, что проблема в OSPF, тогда как на самом деле всё из-за слишком «рьяного» коммутатора — вот в чём настоящая проблема...

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры