http://mikrotik.moscow Новое в теме Вопросы для сближения форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Wed, 05 Aug 2026 00:58:21 -0400 Вопросы для сближения RouterOS в форуме RouterOS.
Это не только про IP-адрес, интерфейсы, объединённые в бонд, вообще не должны иметь отдельной настройки. Это особенно важно при использовании LACP, потому что LACP PDUs не зависят от VLAN, так как предназначены для управления на канальном уровне. Поскольку вы не используете LACP, то можно нарушая все рекомендации добавить VLANы на интерфейсы-члены бонда, чтобы получить доступ к управлению радиостанциями. Насколько долго это будет работать — вопрос откровенно открытый, какой-то будущий апгрейд ROS может это сломать. Конечно, VLAN, используемый для управления, не должен пересекаться с «пользовательскими» VLANами, которые идут по бондированным каналам.

Чистое решение — использовать туннель EoIP через каждое соединение и объединять в бонд именно туннели EoIP, а не физические интерфейсы. Если вы сможете настроить MTU на радиостанциях и Ethernet-интерфейсах так, чтобы кадр с полезной нагрузкой в 1500 байт вместе со всеми заголовками EoIP ещё помещался в этот увеличенный MTU, потери пропускной способности на оверхед будут меньше, чем если EoIP придётся резать каждый кадр на две части, потому что MTU физического канала совпадает с размером полезной нагрузки.

Но, на мой взгляд, лучшее решение — забыть про бондирование и использовать mesh-сеть MikroTik. Мост с обычным протоколом spanning tree будет работать практически так же, если бы не то, что STP не умеет обнаруживать односторонние разрывы соединения — а с оптическими и микроволновыми линками это далеко не редкость. LACP это умеет, mesh-протокол тоже.

Mesh ищет лучший путь между узлами, но не блокирует никакие из них. Представьте кольцевое физическое соединение узлов A, B, C, D. Если все линксы в порядке, STP отключит один из них, чтобы избежать петли второго уровня, например, связь между A и B отключится, и трафик с A на B пойдёт по длинному пути. Mesh ничего не блокирует, поэтому пока все линксы живы, A будет общаться напрямую с B, а C — с D.

Можно настроить приоритеты через path-cost, чтобы трафик предпочитал 5 ГГц-соединение, пока оно доступно.
20.10.2020 08:11:00, sindy.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429775 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429775 Tue, 20 Oct 2020 08:11:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
sindy: Надеюсь, вы всё ещё следите за этой темой. У меня есть все необходимые элементы для настройки пробной конфигурации bonding, и я работаю над этим в свободное время. В вики в начале раздела о Bonding говорится: «Убедитесь, что на интерфейсах, которые вы собираетесь объединять в bonding, нет назначенных IP-адресов!»

Возможно, вы помните, что около года назад вы помогали мне настроить запись интерфейса, чтобы я мог получить доступ к устройствам на WAN-ссылке. Для этого потребовалось добавить настройку к интерфейсу ETH1. Текущая конфигурация /ip address такова:  
[admin@MikroTik] /ip address> print detail
Flags: X - отключён, I - неверный, D - динамический  
0   ;;; стандартная конфигурация  
address=192.168.0.1/24 network=192.168.0.0 interface=bridge1 actual-interface=bridge1  
1   ;;; доступ к устройствам на длинной сети 192.168.1.x  
address=192.168.1.1/24 network=192.168.1.0 interface=ether1-gateway actual-interface=ether1-gateway  

Очевидно, что ether1 подключён к моему WAN-соединению. Вот мой вопрос: как сохранить возможность доступа к WAN, соблюдая правило «без IP-адресов на bonded-интерфейсах»? И как (если возможно) получить доступ к WAN с любого из объединённых интерфейсов? Конечно, учитывая, что будет активен только один из них, как мы обсуждали ранее.

Ещё одна мысль: у меня на целевом устройстве запущен хотспот. Потребуется ли его перенастройка из-за bonding? Спасибо за внимание.
19.10.2020 15:18:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429774 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429774 Mon, 19 Oct 2020 15:18:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Синди, спасибо. Во время своего начального исследования по объединению каналов с помощью EoIP я наткнулся на некоторую информацию. Из-за отсутствия опыта я даже не рассматривал вариант с ячеистой конфигурацией, но твое описание преимуществ, которые можно получить, используя её, отправит меня обратно в «режим изучения». Думаю, в интернете полно материала для изучения. Наверняка я ещё вернусь на форум за советом. Ещё раз спасибо.
20.10.2020 15:49:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429773 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429773 Tue, 20 Oct 2020 15:49:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Подумав ещё над этим, пожалуй, стоит уточнить по поводу настройки. Ссылаясь на мою изначальную схему в текстовом режиме — исходный роутер RB 750 должен обеспечивать: подключение к провайдеру. У меня есть публичный статический IP через DHCP от провайдера. Хостинг начального конца связанного канала. Выполнять все необходимые транспортные и трансляционные операции, чтобы данные от провайдера попали на связанный канал. Целевой роутер RB 960 будет: хостить конечный конец связанного канала. Используя связанный канал как источник, выполнять традиционные функции роутера (DHCP, хотспот и т. д.). Другими словами, вести себя как обычный роутер, только с WAN, поступающим через связанный канал. Надеюсь, это описание не слишком избыточно.
25.10.2020 21:17:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429772 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429772 Sun, 25 Oct 2020 21:17:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Ладно, моя вина. Поскольку вся цепочка изначально не работала, я решил разбить всё на три части: сначала настроить подключение к Интернету на исходном устройстве (RB 750UP) без запущенного DHCP. Как только это будет сделано, заново настроить связку каналов и проверить, «просто работает» ли она. Если связка не заработает, сосредоточиться на этом. Я не видел смысла заниматься пунктами 2 и 3, пока пункт 1 не будет решён. Если только нет веской причины браться за всё сразу.
25.10.2020 21:09:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429771 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429771 Sun, 25 Oct 2020 21:09:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Если правило action=masquerade настроено на совпадение как с портом WAN, так и с перечнем портов LAN-моста одновременно, то оно вообще не будет работать. Но совпадение по порту моста возможно только если в настройках /interface bridge установлен use-ip-firewall в значение yes, так что правило может быть автоматически отключено. Тут слишком много догадок — выложи экспорт конфигурации, когда дойдёшь до этого. Именно так. DHCP используется для установки IP-адреса и сетевой маски как минимум, но обычно применяются и многие дополнительные параметры — шлюз по умолчанию, список DNS-серверов, список NTP-серверов, fqdn сервера конфигурации, имя сервера конфигурации… Я не совсем понимаю, зачем мы это делаем — ведь именно ты жаловался, что устройства за bond’ом не могут выйти в интернет после проделанных изменений. Первоначально я думал, что непонятна только настройка bonding’а, но теперь мне кажется, что вопросов гораздо больше. Поэтому сначала я и сосредоточился на переходе с одного кабельного подключения на bonded.
25.10.2020 20:07:00, sindy.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429770 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429770 Sun, 25 Oct 2020 20:07:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Хорошо, тут есть небольшой проблеск понимания… Единственное правило NAT на 750 — это дефолтное, которое очень похоже на это:  
0    ;;; defconf: masquerade chain=srcnat action=masquerade out-interface=ether1  
Обратите внимание, что я взял это с моего hEx дома, а 750 стоит у меня в мастерской, где я делаю тесты на стенде. Думаю, там было то же самое с добавлением записи в «Out Bridge Port List», которая, как мне кажется, была установлена на весь LAN. Это нужно будет проверить, когда я снова там буду.  
Вот это: «указать IP-адрес 750 в соответствующей подсети как дефолтный шлюз для клиентских устройств в 192.168.1.0/24 и/или 192.168.88.0/24, настроить их на использование DNS 8.8.8.8 и попробовать снова.»  
Так, это надо делать на конечных устройствах — ноутбуках, планшетах и т.п.? Или я что-то неправильно понял? Другими словами, вручную делать то, что DHCP-сервер делал бы автоматически?  
Мы делаем это только чтобы проверить, сможет ли устройство получить доступ в интернет через 750, когда всё настроено правильно?  
Полагаю, если доступ есть без запущенного DHCP, это уже один пункт можно вычеркнуть. Потом могу заново настроить bonding-интерфейс.
25.10.2020 19:54:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429769 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429769 Sun, 25 Oct 2020 19:54:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Часть про NAT очень важна. У 750 есть свой собственный WAN IP-адрес и маршрут по умолчанию, получаемые от “backhaul IP”, кем бы он ни был, но если этот “backhaul IP” не знает, что пакеты для 192.168.1.0/24 и/или 192.168.88.0/24 должны отправляться на WAN IP 750-го, то правило action=masquerade на 750 необходимо. Иначе пакеты с его LAN будут идти через WAN с исходным адресом, и в лучшем случае “backhaul IP” просто отбросит их по дороге к серверу в интернете, а в худшем эти пакеты дойдут до сервера, но ответ пойдет на 192.168.1.x (или 192.168.88.x) — устройство, которое никак не связано с серверной сетью.

Если отключить DHCP-сервер, он не шлет клиентам сообщение про отзыв аренды, так что полученные через DHCP адреса и маршруты остаются в силе, пока не истечет время аренды. Если вручную назначать бывшим DHCP-клиентам только IP, но не маршрут по умолчанию, у них не будет маршрута, и они смогут обращаться только к устройствам в своей подсети. На Windows, если переключиться с “DHCP” на “ручное назначение IP”, аренда при этом аннулируется, даже если она ещё действительна.

Обработка NAT привязывается к каждому конкретному подключению при его старте (если первый пакет совпадает с правилом NAT). Если правило NAT отключить, текущие подключения продолжают NATиться, а новые — нет. Поэтому включите правило NAT на 750, укажите IP 750-го в соответствующей подсети как шлюз по умолчанию для устройств в 192.168.1.0/24 и/или 192.168.88.0/24, настройте там DNS 8.8.8.8 и попробуйте снова. Если интернет у устройств всё равно не работает, выложите экспорт конфигураций и 750, и 960.
25.10.2020 17:32:00, sindy.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429768 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429768 Sun, 25 Oct 2020 17:32:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
sindy — Позвольте добавить больше деталей, чтобы не тратить ваше время на пересказывание того, что я уже пробовал. Моя «тестовая» установка точно такая, как показано в оригинальном сообщении. Кабели там — полный беспорядок, как вы и можете представить. Два беспроводных соединения проверены и работают в режиме WDS. Поскольку 750 и 960 поддерживают только «ethernet», в QuickSet нет выбора различных режимов, как при наличии WLAN — только «router» и «bridge». (Кстати, спасибо за информацию про использование QS только один раз — возможно, это и была часть проблемы.)

Когда выбираю Bridge и назначаю статический IP, не могу зайти обратно — наверняка из-за того, что не понял, что произошло. Так что начинаю заново с Router... Подключаюсь к 750, не меняя вообще ничего, чтобы проверить, что он работает и имеет доступ в интернет. Оставляю IP по умолчанию (88.1). Выключаю DHCP и NAT через QS. Освобождаю два порта ETH (у меня это 4 и 5) через Webfig, чтобы их можно было использовать в bonding. Взял следующую инфу из другого вашего поста: «Чтобы полностью удалить интерфейс из моста, нужно отключить/удалить соответствующую строку в /interface bridge port; чтобы запретить коммутатору пересылать кадры на этот интерфейс, а не на CPU, в той же строке выставить hw=no». Потом применил команды из Wiki >> Quick Setup Guide (с соответствующими правками под разные ETH и подсеть 192.168.1.x): https://wiki.mikrotik.com/wiki/Manual:Interface/Bonding#Quick_Setup_Guide.

Всё прошло без ошибок в SSH сессии LXTerminal, и на 960, и на 750. Быстрая проверка нового интерфейса bond1 показала, что по нему идет небольшой служебный трафик, так что я (возможно, ошибочно) предполагаю, что он работает. Подключаюсь к 960, он раздает IP, но интернета нет. Проверяю дальше — оказывается, у «источника» 750 тоже нет интернета, если подключаться к ETH2 или ETH3. Немного поигрался с настройками, потом сбросил до заводских настроек, чтобы понять, на каком этапе теряется связь. После сброса всё хорошо. Повторяю шаги, описанные выше, и теряю интернет при отключении DHCP-сервера. DHCP-клиент видит ISP и может нормально обновлять настройки. Пинги с подключенного устройства не проходят (логично). Устройство всё ещё имеет IP, полученный при включенном DHCP, и настройки совпадают с Connection Information. Ручное назначение IP с теми же параметрами, но другим адресом из сети 88.x результата не дало.

Вот где я сейчас. Очевидно, пока у источника 750 нет интернета, на 960 его тоже не будет. Читал по теме в интернете, много сообщений говорят, что нужно настроить маршрутизацию. Но углубленное изучение этой темы завело меня в очень густые дебри, которые я пока не понимаю, даже если это и важно.

После моего последнего поста я вспомнил, что даже без IP после сброса «no factory config» можно подключиться по MAC через Winbox. Я давно этим не пользовался и забыл. С настройкой «no factory default» с нуля я пока не пробовал — кажется слишком радикальным, но если придется, попробую. Скорее всего, понадобится помощь с этим вариантом.

Вот так. Много текста, но надеюсь, теперь всё понятнее.
25.10.2020 16:40:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429767 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429767 Sun, 25 Oct 2020 16:40:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
«Factory defaults → home CPE» — хороший старт. «No defaults at all» можно управлять через Winbox, подключаясь по MAC-адресу, или через mac-telnet с другого Mikrotik, а также восстановить, сбросив настройки на заводские кнопкой при включении, но это уже не по теме. К тому же ты говоришь об одном устройстве, а для тестирования bonding нужны как минимум два.

Так что я бы сделал так: настроил одно устройство как роутер с WAN и LAN (вначале заводские настройки, потом «home CPE» в QuickSet), а другое — как мост (сначала заводские, затем «bridge» в QuickSet). После любых дополнительных изменений QuickSet лучше не использовать. Если хочешь начать сначала — сбрасываешь на заводские, потом настраиваешь QuickSet.

Если у QuickSet «bridge» задан статический IP для управления (не знаю, я этого не использовал), придётся убрать конфликт IP, заменив адрес только что созданного моста с 192.168.88.1/24 на 192.168.88.2/24. На этом этапе я бы подключил один из Ethernet-портов моста к одному из LAN-портов роутера и проверил, что устройство с DHCP-клиентом, подключённое к мосту, получает IP от роутера и может выходить в интернет (если, конечно, WAN роутера подключён к интернету).

Дальше можно приступать к экспериментам с bonding. На обоих устройствах убираем из моста два неиспользуемых Ethernet-порта, добавляем их в созданный bonding, а новый bonding уже добавляем в мост как порт. Потом кабель, соединяющий два устройства, меняем с текущих Ethernet-портов на порты в bonding.

Если всё настроено правильно, устройство с мостом по-прежнему будет выходить в интернет. После этого можно добавить второй кабель, убрать первый и так далее.
25.10.2020 09:24:00, sindy.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429766 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429766 Sun, 25 Oct 2020 09:24:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Я сбросил RB 750 до заводских настроек, чтобы начать процесс обучения. Сначала попробую bonding просто как эксперимент. Похоже, сделать это работает не так просто, как просто ввести команды из примера в Wiki. Наверное, гораздо сложнее.

После отключения DHCP и NAT (этим будет заниматься «принимающая» сторона) и того, как убрать два ETH-интерфейса, которые я хотел использовать для bond, из моста на плате с каждой стороны, я настроил обе стороны согласно инструкции из Wiki, немного поменяв номера интерфейсов. Видно, что объединённый канал пропускает служебный трафик, но интернета на удалённой стороне нет. Проверив путь обратно, оказалось, что и на «исходной» стороне интернета тоже нет. DHCP-клиент на 750 показывает корректные данные от Verizon.

Вопросы:

С чего вообще лучше начинать?
Заводские настройки роутера?
Заводские настройки моста?
Или вообще никаких настроек? (Я так не пробовал из-за множества страшилок о том, как люди восстанавливали устройство с помощью serial-кабеля.)

Мне кажется, bonded-ссылка сработает, если на исходной стороне будет интернет без DHCP. Просто у меня пока не хватает знаний, чтобы понять, что не так.

Если кто-то знает пошаговую инструкцию по настройке bonded link, где не предполагается, что у вас уже всё изначально настроено правильно, было бы здорово. Все примеры, что я нашёл, вообще ничего не говорят о начальной настройке устройств перед конфигурацией портов для bond.
25.10.2020 00:12:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429765 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429765 Sun, 25 Oct 2020 00:12:00 -0400 RouterOS Вопросы для сближения RouterOS в форуме RouterOS.
Всем привет! Рассматриваю вариант реализации bonding, чтобы получить резервное соединение на беспроводной линии длиной 26 миль. Вот небольшой рисунок предлагаемой схемы:  

Причина в том, что иногда у нас бывают сильные дождь или снег, которые могут повлиять на 5G-связь. Если она полностью упадёт, хотелось бы остаться «в эфире» с помощью 2G-соединения, которое, скорее всего, пройдёт там, где 5G не справится.  

Я прочитал документацию по bonding — вроде бы всё относительно просто настраивается. Но у меня есть несколько вопросов, на которые пока не нашёл ответ:  

2G-линия при нормальных условиях будет значительно медленнее 5G. В идеале хотелось бы, чтобы система вообще не использовала 2G, если 5G работает стабильно. По описанию bonding кажется, что обе линии будут всегда активны и передавать трафик. Как это скажется на скорости сети при нормальной работе, когда 2G на самом деле не нужен?  

Что будет, если разница в пропускной способности между двумя линиями будет очень большой? Можно ли настроить bonding так, чтобы он мониторил состояние обеих линий и при ухудшении (например, пинги слишком высокие, и появляются потери) переключался на запасную линию? А при улучшении — снова возвращался на основную?  

В документации вижу, что что-то подобное поддерживается разными опциями Failover, но так как у меня на исходном конце нет двух IP-адресов, мне кажется, что Failover не подойдёт, или я неправильно это понимаю.  

Заранее спасибо за любые советы!
25.09.2020 17:36:00, VanceG.]]> http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429764 http://mikrotik.moscow/forum/forum57/88728-voprosy-dlya-sblizheniya/message429764 Fri, 25 Sep 2020 17:36:00 -0400 RouterOS