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

Некорректная таблица маршрутизации MPLS

Некорректная таблица маршрутизации MPLS, RouterOS

NickOlsen

Guest

23.11.2016 14:48:00

Приветствую. У меня полностью маршрутизируемая сеть на OSPF — более 65 «Core» сайтов. Кроме того, я внедрил MPLS для организации L2VPN-сервисов. С тех пор как мы начали использовать MPLS (~6.6ROS), появилась проблема: таблица MPLS-форвардинга выходит из синхронизации с локальной таблицей маршрутизации на основе OSPF. Из-за этого трафик неправильно маршрутизируется. Когда это случается, перезагрузка роутера решает проблему. Однако я могу также создать локальную binding label, применить её, а затем удалить (что заставляет таблицу форвардинга перезагрузиться), и проблема исчезает. Это гораздо быстрее, чем перезагружать весь роутер.

Я уже обращался с этой проблемой в Mikrotik, но их ответ всегда был примерно такой: «Пожалуйста, обновитесь до $LATESTROS и сообщите, если проблема сохранится». Проблема всегда повторяется. Но у меня никогда не получается зафиксировать момент, когда эта ошибка проявляется на роутере с последней версией ROS. Такая же ситуация случалась как на CCR, так и на RB2011, на всех версиях ROS от 6.6 и выше. При этом у меня пока нет ни одного Core-сайта на версии 6.37.2, но подозреваю, что там тоже будет такая же проблема.

Ниже — скриншоты с этой проблемой. Кто-нибудь сталкивался с этим? Или знает, как это исправить?

И ещё: после перезагрузки таблицы форвардинга путём временного применения локальной binding label всё нормально работает.

bbs2web

Guest

23.03.2017 19:18:00

Мы сталкиваемся с той же проблемой. Один из наших роутеров всегда получает сломанную таблицу переадресации после перезагрузки, если не отключить LDP перед выключением, а потом снова включить его после старта. Мы раздаём некоторые наши подсети через BGP и OSPF и думали, что маршруты на какое-то время «прыгают» из-за замены BGP-маршрутов OSPF. Но это не может быть причиной, потому что: роутеры не могут подключиться к BGP route reflectors без OSPF. У нас есть кор-роутер, который не работает на BGP (у нас распределённое ядро), и он сегодня тоже так себя повёл. В сегодняшнем случае кор-роутер перезагрузился, всё правильно переключилось на его резервного партнёра, но дальнейшая связь пропала, так как OSPF переключил трафик обратно на перезагруженный роутер, у которого оказались неверные метки. Отключение LDP на несколько секунд решило проблему. Похоже, придётся попробовать запускать скрипт при старте, который будет отключать LDP, ждать две минуты и включать его снова...

diegotormes Guest	#3 0 28.03.2017 03:46:00 Обновляйтесь до версии 6.38.x на всех роутерах!

nz_monkey Guest	#4 0 28.03.2017 07:58:00 Есть ли в версии 6.38 конкретное исправление для этой проблемы?

bbs2web Guest	#5 0 29.03.2017 22:58:00 У нас уже установлена версия 6.38.5…

diegotormes Guest	#6 0 30.03.2017 18:18:00 http://forum.mikrotik.com/t/mpls-te-broken-since-v6-35-fixed-6-38-1/104738/1 У нас были очень похожие проблемы с MPLS+TE… но возможно, это другая ошибка…

NickOlsen

Guest

31.03.2017 19:14:00

Придётся выкатывать 6.38.x и проверить, изменится ли что-то. Могу точно сказать, что дело связано с нестабильностью маршрутов. Похоже, что это только усугубляет проблему. На одном конкретном объекте эта проблема была почти каждый день в сезон дождей. Там стоял AF24 с резервом на 5 ГГц. У нас были короткие таймеры на OSPF, так что переключение происходило быстро, и никто этого даже не замечал. Сейчас сезон дождей закончился, и AF24 не теряет связь. За всё это время не было ни одного сбоя. Думаю, как только сезон дождей вернётся, ситуация изменится.

bbs2web

Guest

06.04.2017 21:38:00

Примерно две недели назад мы внесли следующие изменения и теперь нам больше не нужно отключать LDP после перезагрузки конкретно проблемного роутера. Ранее его нельзя было достичь, если только не подключиться через mac telnet, отключить LDP, подождать пару секунд и снова включить его:

/mpls set dynamic-label-range=53248-57343
/mpls ldp set enabled=yes lsr-id=10.17.245.3 transport-address=10.17.245.3
/mpls ldp interface add hello-interval=1s hold-time=10s interface=XXX

По сути мы:
- Согласовали таймеры hello и hold LDP с нашими настройками OSPF
- Назначили каждому роутеру свой собственный диапазон LDP (начинается с 4096 до <base+4095>)

Эта проблема в основном проявлялась при перезапуске роутеров или при проблемах с подключением. У меня нет официального обучения по этой теме, так что, возможно, нормально, что соседние роутеры не должны иметь пересекающиеся диапазоны назначаемых меток?

Проблема впервые появилась, когда мы начали делать всю сеть действительно отказоустойчивой, особенно с равнозначными связями между роутерами…

NickOlsen

Guest

13.04.2017 19:45:00

Отлично! Мне обязательно нужно это попробовать. Ты сделал это на каждом маршрутизаторе, участвующем в LDP/MPLS? А ты также расширял это на оборудование CPE, которое работает с LDP? Может быть, для клиента, которому ты предоставляешь Metro-E? Никогда не слышал о необходимости жёстко задавать диапазон меток. Но это отвечает на многие вопросы, по крайней мере на мой главный. Могу предположить, что маршрутизатор имеет локальную метку для определённого назначения, а потом получает ту же метку, но с другим назначением или что-то в этом духе. Из-за дублирующей информации он, наверное, не может правильно вставить это в таблицу переадресации.

bbs2web

Guest

#10

13.04.2017 20:20:00

MPLS-метки должны быть важны только для роутера, который их получает, поэтому пересечение меток для разных назначений не должно создавать проблем в таблице пересылки роутера. В таблице может быть так: Чтобы отправить на x.x.x.x/y — добавь метку 20 и отправь через интерфейс A. Чтобы отправить на w.w.w.w/z — добавь метку 20 и отправь через интерфейс B. Однако скриншоты из твоего первого сообщения точно показывают, что для маршрута была назначена неправильная исходящая интерфейсная запись. Принимающий роутер может даже иметь подходящую запись в таблице пересылки по полученной метке и затем неправильно переслать пакет дальше, на второй или следующий хоп. Обычно мы не запускаем MPLS до самого устройства пользователя (CPE) — мы полагаемся на операторов, которые обеспечивают «последнюю милю», и просто «подключаем» оборудование в дата-центрах, а наше CPE находится на другом конце канала оператора. В итоге нам пришлось настраивать это примерно на 40 инфраструктурных роутерах. К сожалению, мне так и не удалось воспроизвести эту проблему в лаборатории, а таймеры не объясняют, почему конкретный роутер после перезагрузки может быть недоступен, а потом — доступен. PS: Мне нужно будет прочитать RFC или другую документацию, чтобы понять, переносятся ли метки постоянно или только при изменениях. Думаю, что использование LDP через UDP или TCP тоже может прояснить ситуацию...

sajibnandi

Guest

#11

13.06.2020 21:10:00

У меня такая же проблема: как только один маршрут OSPF исчезает, таблица пересылки MPLS не обновляется другим маршрутом IGP. Таблица MPLS начинает работать только после ручной перезагрузки LDP. Кто-нибудь знает, как решить эту проблему?

telcouk Guest	#12 0 15.06.2020 11:02:00 Мы тоже так думаем, решение предложено выше, но логически я не вижу, как это могло бы сработать. Может, я что-то упускаю?

bbs2web

Guest

#13

17.06.2020 05:23:00

У нас не было этой проблемы уже 3 года после того, как мы сделали следующее: согласовали времена LDP с OSPF, заменили маршрутизаторы MikroTik с route reflector на VyOS (FRR). VyOS использует FRR и теперь может работать с MPLS, он отражает значения по умолчанию, и я отправил патчи, чтобы добиться паритета по функциям фильтрации маршрутов в VyOS (установка distance, preferred source, сопоставление по local preference, настройка route map при программировании маршрутов BGP в FIB). Поддерживается работа с peer group, чтобы расчёты не выполнялись отдельно для каждого пира. В результате конвергенция сильно улучшилась (в 20 раз быстрее при запуске CHR с теми же ресурсами), и больше нет каскадных сбоев маршрутизации, когда пиры отключаются при отзыве наших black hole маршрутов (в среднем около 20 тысяч префиксов /32). У нас есть кластер из резервных route reflector в каждом дата-центре, к которым подключается каждый маршрутизатор этого центра, а route reflector между собой обмениваются информацией для корректировки local preference, чтобы получить следующий порядок предпочтений: местный клиент, удалённый клиент, местный пир, удалённый пир, местный транзит, удалённый транзит.

telcouk Guest	#14 0 22.06.2020 08:53:00 Большое спасибо, я попробую.

Читают тему

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