Потери PPPoE и OSPF

Извиняюсь за задержку. Да, возможно, дело в этом, но я сейчас в процессе загрузки этой конфигурации на другой роутер, а не на 1072, потому что нигде в сети больше такой проблемы нет, но при этом нигде больше мы не используем 1072 как BNG. Я также надеюсь на этот новый стабильный апдейт 6.47, но в списке изменений не вижу ничего, что могло бы касаться этой проблемы.

Привет! У нас проблемы с CCR (включая модель 1072), которые сбрасывают все или часть установленных PPPoE сессий. При этом CCR, кажется, перестаёт отвечать на API/SSH (WebFig остаётся доступен, но большинство разделов пусты). Мы связались с Mikrotik, отправили файлы поддержки и т.д., но в итоге получили ответ: «наш hardware не соответствует вашим требованиям». При том наши требования очень «лёгкие» — PPPoE, NAT/маршрутизация, ограничение скорости через simple queues (без OSPF и прочего).

У нас стоит 1072 в дата-центре, который обрабатывает 9,5 Гбит/с трафика с NAT/маршрутизацией из 20 подсетей, при загрузке CPU не выше 50%. Если не найдёте решения, советую искать альтернативного поставщика для функций PPPoE-концентратора, как мы сейчас и делаем. Проблема заявлена впервые ещё в 2009 году (уже 11 лет!!), но до сих пор не исправлена. Мы надёжно можем воспроизвести и вызвать эту проблему — если отключить любой downstream-сегмент сети, например, перезагрузить свитч или линк PtP — но решения нет: http://forum.mikrotik.com/t/rb1000-closing-tens-of-pppoe-connections-at-once/33500/1

Мы перепробовали все возможные варианты, в том числе увеличивали таймаут PPPoE, чтобы сессии могли «выдержать» временный разрыв downstream-ссылки (например, перезагрузку свитча, как говорилось выше), но без результата. Трафик сессии возвращается, но потом весь трафик останавливается, а сессии сбрасываются и восстанавливаются:



На скриншоте видно, что когда мы перезагружаем свитч, трафик примерно от 400 клиентов пропадает, затем появляется снова, как будто ничего не случилось (таймаут сессий 300 секунд на CCR и на клиентах), а примерно через 2 минуты происходит сброс.

Удачи!

Действительно, и служба поддержки Mikrotik, и другие коллеги на форуме указали на альтернативное оборудование как на решение, спасибо.

Есть часть, которая связана с нашей архитектурой и конфигурацией, но более глубокая и тревожная проблема в том, что в некоторых случаях практически невозможно понять, когда именно архитектура или конфигурация вызывает конкретную проблему. Если бы у нас были инструменты для этого (или если бы вики была полезнее в некоторых вопросах), шумиха на этом форуме из-за «архитектуры» или «конфигурации» значительно поутихла бы. Возьмём DNS в качестве следующей «головной боли-медузы» — я здесь замолкаю, а открою более общий топик «Отсутствие инструментов и видимости проблем с производительностью», но этот случай служит хорошим примером:



Что-то необычное заметили? Нет, правда? Tool->Profile тоже ничего не показал, DNS использует менее 1% CPU. Но у нас было сотни обращений от клиентов с жалобами «некоторые сайты не грузятся» и «DNS не резолвится», из-за чего страдал сервис. Мы долго пытались понять, где проблема. Проводили трассировку пакетов, которая показала, что DNS-ответы иногда вообще не приходят, иногда приходят с SERVFAIL, но ничего, что указывало бы на проблемы с производительностью на CCR или в топологии сети. Вот наша архитектура (в плане конфигурации — мы перепробовали всевозможные изменения DNS-настроек на всех задействованных узлах):



Стрелки показывают, кто является upstream-резолвером для каждого устройства. Клиентские hAP также работают как кеширующие DNS-серверы для устройств, подключённых к ним клиентами. Технически это достаточно эффективная схема: центральный CCR запрашивает DNS только один раз (в рамках TTL, естественно) и кеширует результат для всех CCR на уровне сети, а CCR на уровне сети делают то же самое для до 1500 CPE, подключённых к каждому из них.

Последним доказательством, устав от безрезультатных попыток, стало то, что мы подняли кеширующий bind9-сервер на DigitalOcean-дроплете в тестовом режиме. Мы сразу заметили рост трафика на 15-20% на двух CCR уровня сети, которые использовали этот DNS-сервер как свой upstream. Потом мы установили bind9 рядом с 1072 в дата-центре и направили все 20 CCR уровня сети к нему — и увидели скачок совокупного трафика с 8,3 Гбит/с на пике до чуть более 9,5 Гбит/с. Клиенты теперь говорят, что у них всё хорошо.

Возвращаясь к первому графику — отключение DNS с основного CCR не дало никакого положительного эффекта на загрузку CPU. Изменение сделали в пятницу днём.

Мой главный вопрос к вам теперь такой: можете ли вы предсказать, или, если не можете, хотя бы увидеть напрямую, когда CCR на уровне сети «сдадутся» по DNS так же, как они «сдаются» с PPPoE? Да, мы можем тогда направить клиентские hAP прямо на bind9-сервер, но разве нужно ждать, пока клиенты начнут кричать и поливать нас грязью в соцсетях, чтобы заметить это?

Какая же следующая функция CCR «сдастся»? Нам нужна куда более глубокая видимость проблем, прежде чем на нас станут сваливать вину за определённые «архитектурные» или «конфигурационные» косяки.

Думаю, если бы все эти хорошие качества действительно присутствовали, мы бы платили за Mikrotik цены уровня Cisco.