http://mikrotik.moscow Новое в теме Потери PPPoE и OSPF форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Wed, 15 Jul 2026 00:33:11 -0400 Потери PPPoE и OSPF RouterOS в форуме RouterOS.
По моему мнению, это правильный ответ от CZ. На этом обсуждение должно закончиться или перейти в зону пожеланий…
19.09.2020 14:36:00, aacable.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409521 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409521 Sat, 19 Sep 2020 14:36:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Хммм, не согласен с этим — Cisco выставляет сумасшедшие цены, потому что у них монополия на рынке и, конечно, решения для огромных объемов данных. Если предположить, что DNS-резолвер в RouterOS — это Bind под капотом, то нет никаких оправданий не предоставить уровень логирования, который есть в Bind, а он, между прочим, просто невероятно подробный (причём именно от него и взялись графики, которые я выкладывал раньше). То же самое касается отслеживания соединений и других подобных функций. Нет необходимости тратить такие же деньги, как требует Cisco, чтобы показать больше информации.

С другой стороны, Mikrotik чётко нацелен на рынок провайдеров среднего размера — а именно туда мы только начинаем заходить (модули на 40 Гбит/с, CWDM-решения, устройства, способные обрабатывать терабиты трафика и т.п.), но без «взрослых» инструментов туда не войти.

Что я ожидал в ответ клиенту, который развернул 15 000 hAP Lite и десятки CCR, — это «Вот конкретные вещи, которые вы можете проверить» или хотя бы «Давайте свяжем вас с платным консультантом, который это решит». Я бы даже согласился на «Вы тут новичок и не совсем правильно делаете, вот как это надо...» (я, кстати, новичок!). А вот такое пожимание плечами и «Наших коробок вам недостаточно» — это не конструктивно и только вредит делу...
17.08.2020 20:14:00, flameproof.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409520 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409520 Mon, 17 Aug 2020 20:14:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Думаю, если бы все эти хорошие качества действительно присутствовали, мы бы платили за Mikrotik цены уровня Cisco.
17.08.2020 19:57:00, CZFan.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409519 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409519 Mon, 17 Aug 2020 19:57:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Так почему же эта информация не включена в данные о производительности от Mikrotik, вместе с возможностями DNS-резидера? Почему так сложно проанализировать проблемы с отслеживанием соединений? Ты приближаешься к ответу, но не к тому пути, который ведёт к решению проблемы. Посмотри, пожалуйста, мой «философский» тред на эту тему, где я рассматриваю более широкую проблему: http://forum.mikrotik.com/t/architecture-and-growth-how-to-know-when-to-change/142238/1 В любом случае спасибо за твоё мнение — оно важно и ценится!
17.08.2020 17:11:00, flameproof.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409518 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409518 Mon, 17 Aug 2020 17:11:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Есть часть, которая связана с нашей архитектурой и конфигурацией, но более глубокая и тревожная проблема в том, что в некоторых случаях практически невозможно понять, когда именно архитектура или конфигурация вызывает конкретную проблему. Если бы у нас были инструменты для этого (или если бы вики была полезнее в некоторых вопросах), шумиха на этом форуме из-за «архитектуры» или «конфигурации» значительно поутихла бы. Возьмём 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 «сдастся»? Нам нужна куда более глубокая видимость проблем, прежде чем на нас станут сваливать вину за определённые «архитектурные» или «конфигурационные» косяки.
17.08.2020 06:24:00, flameproof.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409517 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409517 Mon, 17 Aug 2020 06:24:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Хмм, я бы скорее сказал, что проблема в вашей архитектуре или конфигурации, но в любом случае…
15.08.2020 10:36:00, CZFan.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409516 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409516 Sat, 15 Aug 2020 10:36:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Действительно, и служба поддержки Mikrotik, и другие коллеги на форуме указали на альтернативное оборудование как на решение, спасибо.
15.08.2020 09:43:00, flameproof.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409515 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409515 Sat, 15 Aug 2020 09:43:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Ответы для решения вашей проблемы были даны как службой поддержки MT, так и в теме, которую вы указали.
14.08.2020 21:53:00, CZFan.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409514 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409514 Fri, 14 Aug 2020 21:53:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Привет! У нас проблемы с 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 минуты происходит сброс.

Удачи!
14.08.2020 06:13:00, flameproof.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409513 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409513 Fri, 14 Aug 2020 06:13:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Можно ли посмотреть OSPF /area/, сеть /интерфейсы/ и IP-адреса?
04.06.2020 21:48:00, nichky.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409512 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409512 Thu, 04 Jun 2020 21:48:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Извиняюсь за задержку. Да, возможно, дело в этом, но я сейчас в процессе загрузки этой конфигурации на другой роутер, а не на 1072, потому что нигде в сети больше такой проблемы нет, но при этом нигде больше мы не используем 1072 как BNG. Я также надеюсь на этот новый стабильный апдейт 6.47, но в списке изменений не вижу ничего, что могло бы касаться этой проблемы.
04.06.2020 19:41:00, jefferyf.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409511 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409511 Thu, 04 Jun 2020 19:41:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Решение вам предлагает один из участников форума Mikrotik, из темы, которую вы цитировали ранее: Connection Tracking сильно напрягает роутер.
17.08.2020 16:44:00, CZFan.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409510 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409510 Mon, 17 Aug 2020 16:44:00 -0400 RouterOS Потери PPPoE и OSPF RouterOS в форуме RouterOS.
Привет! У меня странная проблема с одним из наших роутеров. Это CCR1072-1G-8S+, на котором сейчас обслуживается около 250 PPPoE-сессий. Проблема в том, что когда одновременно отключается 5 или больше PPPoE-соединений, логи начинают заполняться сообщениями типа «already active closing previous one» многократно, снова и снова. После этого через некоторое время падает OSPF, а затем заново устанавливается. Роутер не перезагружается и сохраняет время работы, но к нему невозможно подключиться, похоже, он зависает. Во вложении — скриншот подобных записей в логе. Используем текущую версию прошивки 6.46.6.
15.05.2020 17:56:00, jefferyf.]]> http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409509 http://mikrotik.moscow/forum/forum57/86705-poteri-pppoe-i-ospf/message409509 Fri, 15 May 2020 17:56:00 -0400 RouterOS