CCR1036-8G-2S+ - Почему SFP+ порт перестал передавать данные?

Самое большое преимущество DHCP как для нас, так и для клиентов — это то, что они могут просто взять любой роутер прямо из коробки, подключить его, и хоп, сразу получить доступ в интернет, так как почти все роутеры по умолчанию настроены на DHCP. Даже если они сбросят его до заводских настроек, всё будет работать отлично. Поскольку роутеры MikroTik не обладают хорошим покрытием WiFi, это значительно облегчает нам жизнь: мы можем просто сказать им купить роутер с большими антеннами в магазине и подключить его, вопрос решен. Пока что каждый роутер, который я пробовал, не имел проблем с назначениями /32, что значит, что IP-адреса не теряются.

Следующее большое преимущество в том, что соединение не нужно «устанавливать». Кратковременное отключение или смена маршрута данных на соединении PPPoE могут привести к остановке передачи данных, и цепь должна истечь, а затем переподключиться, прежде чем сможет снова начать передачу. MikroTik справляется с этим быстрее всего, но даже в этом случае часто требуется несколько секунд, что достаточно долго, чтобы фактически прервать сессию VoIP, а у большинства других производителей время ожидания может превышать 30 секунд. Когда соединение PPPoE обрывается, оно сбрасывает соединения, что может привести к таймаутам на сайтах и прочему. Общие впечатления клиента становятся немного хуже.

В то время как в случае с DHCP/прямым IP это обрабатывается на уровне пакетов, нет необходимости восстанавливать соединение. Даже если маршрут данных меняется несколько раз, это не имеет значения, так как пакеты всё равно достигнут своей цели. Время восстановления после сбоя канала практически такое же, как и время, необходимое для восстановления канала — нет дополнительного ожидания.

Последнее преимущество — это управление трафиком. Вы не можете разделять трафик внутри туннеля PPPoE, он весь проходит одинаково. У нас есть достаточно много линков на 24 ГГц и 60 ГГц, которые отключаются во время дождя; они резервируются 5 ГГц, и текущее время переключения — всего около 200 мс, но теперь я могу выделить VoIP, чтобы всегда использовать 5 ГГц, когда он доступен, и я могу зарезервировать полосу пропускания для VoIP. Последние два пункта можно в основном реализовать просто переместив сессию PPPoE как можно ближе к клиенту, но всё равно это не так эффективно.

Я не нашел решения, и количество сбоев и проблем с клиентами, которые это вызвало, заставляет меня больше не пробовать это. Нам пришлось оставить эти основные маршрутизаторы полностью свободными от OSPF и MPLS. Поскольку PPPoE все еще завершается на этих маршрутизаторах, это означает, что мы теряем автоматическое переключение на резервный канал, если основной узел выходит из строя, и нам приходится вручную перемещать VPLS-каналы на другой основной узел, который связывается с ядром. Это совсем не идеальное решение, но сеть была достаточно стабильной, чтобы это не стало серьезной проблемой. Мы получаем оповещения сразу, когда сессия BGP с этими основными маршрутизаторами отключается, так что это занимает максимум 5 минут, чтобы переместить все каналы. План состоит в том, чтобы в конечном итоге перевести 90% наших клиентов на систему, основанную на DHCP Option 82. Проблема заключалась в инжекции маршрутов, чтобы разрешить назначение адресов /32 клиентам в любой точке сети, не прибегая к ручному вмешательству (фу). Мне удалось недавно написать скрипт, чтобы это решить. А для остальных клиентов — больше никаких VPLS-каналов. Их PPPoE будет завершаться на ближайшем маршрутизаторе, а не в централизованном месте. Таким образом, ядро сможет иметь только eBGP к интернету и iBGP к основным распределительным узлам. Весь клиентский трафик будет обычным IP-трафиком, что решает проблему переключения при сбое VPLS-каналов.

@wirelessDSL: Работает ли это стабильно на протяжении последней недели? Спасибо, glueck

Это случилось СНОВА в нашей сети на другом месте, но на портах ‘ethernet’ на этот раз. Кажется, этот баг не связывал ни с ethernet, ни с SFP модулями. Это произошло на CCR1009-7G-1C-1S+. На этом сайте были проблемы с внезапным отключением VPLS туннелей в течение последних нескольких месяцев. Я очень тщательно проверил MPLS метки на каждом маршрутизаторе в пути, проверил OSPF, проверил все, что мог. Проблем никакой нет, трассировки показывают, что MPLS работает нормально, но туннели просто не поднимаются. Как только перезагрузишь маршрутизатор, они работают… на короткое время, а затем начинают отключаться один за другим без всякой причины. Прошло несколько месяцев, и сегодня ether1 и ether3 просто полностью перестают передавать данные, та же ситуация, что и в оригинальном сообщении. Они нормально принимают, видят соседей, но не могут делать MAC ping или что-нибудь еще. TX байты остаются на 0 бесконечно. Эти порты не были объединены в мост и не имели ничего общего. Перезагрузка маршрутизатора делает порты полностью работоспособными на 1-10 минут, а затем они внезапно прекращают передачу. Я сузил проблему до MPLS или LDP, что-то одно из этого. Но поскольку вы не можете нормально использовать MPLS без LDP, мне просто придется отказать от MPLS полностью. Это ОГРОМНАЯ проблема, MikroTik, черт возьми. Я понимаю, что у вас нет некоторых корпоративных функций, но когда у вас есть такая ошибка, которая калечит сеть на якобы поддерживаемой функции, и вы не показываете абсолютно никакой реакции на это, это просто неприемлемо (да, мы отправили несколько supouts и сделали все необходимые проверки сами). Наше немедленное решение — полностью отключить MPLS на этом маршрутизаторе и использовать EoIP туннели ко всем сайтам и между всеми сайтами, которые проходят через этот маршрутизатор. Наш следующий шаг — полностью вырвать MPLS из всей сети, так как он медленно вызывает странное поведение без видимой причины. Все PPPoE сессии будут завершены как можно ближе к клиенту, чтобы убрать необходимость в VPLS туннелях. Но у нас есть проблемы с пропускной способностью на RB3011 (уже создал тему об этом). Поэтому наше долгосрочное решение может состоять в том, чтобы вовсе отказаться от MikroTik в нашей распределительной и основной сети и перейти к другому производителю. Похоже, на определенном уровне все просто ломается, и слишком много мелких проблем с огромными последствиями. Когда это произошло в последний раз, мы потеряли несколько клиентов, это просто не стоит того.

Это не идеальное решение. Но поможет ли просто увеличение L2MTU без снижения его обратно? В этом нет вреда, если установить L2MTU на максимум. На самом деле, я не понимаю, почему он не установлен на максимуме (это касается каждого устройства на рынке). Ничего не будет отправлять более крупные L2 кадры, если на это специально не указать, то есть если вы начинаете использовать множество тегов VLAN, MPLS/VPLS, PPPoE, увеличиваете L3MTU, используете упаковку IP и так далее. Даже такие L2 протоколы, как ARP, это маленькие пакеты, они не становятся вдруг огромными и не вызывают проблем, так как L2 пакеты просто тихо отбрасываются, нет механизма связи, поэтому все протоколы, в любом случае, построены с предположением о определенном универсально принятом размере L2 MTU.