Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Вопрос, связанный с «Объяснением тайн мостов RouterOS»

    Вопрос, связанный с «Объяснением тайн мостов RouterOS»

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Вопрос, связанный с «Объяснением тайн мостов RouterOS», RouterOS
     
    HeptaZ
    Guest
    #1
    0
    23.12.2024 03:32:00
    @sindy, хотел бы задать пару вопросов, если можно. Если я правильно понял, существует два «объекта», способных переключать трафик — сам чип коммутатора и функциональный блок коммутации в процессоре?  
    И ещё: когда вы указываете мост с параметром tagged или untagged в /interface bridge vlan, это относится к порту, направленному на маршрутизатор, или к интерфейсу, направленному на коммутатор, или к обоим?  

    /interface bridge add name=bridge1  
    /interface bridge port add bridge=bridge1 interface=ether2  
    /interface bridge port add bridge=bridge1 interface=ether3  
    /interface bridge port add bridge=bridge1 interface=ether4  
    /interface vlan add vlan-id=10 interface=bridge1  

    После выполнения этих команд должно выглядеть именно так, как на картинке ниже? (исключая чип коммутатора, потому что я до сих пор не совсем понял этот момент). Я изобразил мост как отдельный «объект», работающий внутри функционального блока коммутатора, потому что, как мне кажется, функциональный блок коммутатора всегда активен и задействуется только при создании моста. Это так?  
     
     
     
    griswold
    Guest
    #2
    0
    21.02.2025 15:44:00
    Ссылка на мост в списке untagged или tagged в строке /interface bridge vlan управляет поведением только на порте, обращённом к роутеру. Привет. Извиняюсь, что оживляю старую тему, но разве не правда и обратное: указание самого bridge как tagged параметра в /interface bridge vlan тоже используется на РОУТЕРЕ (когда он выполняет маршрутизацию между VLAN), как в примере из поста pcunite (http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1)? Иными словами, вы добавляете сам мост как tagged участника для трафика, который взаимодействует с сервисами процессора роутера (то есть с трафиком, которому нужны L3-сервисы), как в настройке "router on a stick". P.S. Правильно ли я понимаю, что в случае коммутатора добавление интерфейса мостa как tagged участника в /interface bridge vlan используется, когда вы хотите получить доступ к коммутатору для управления (интерфейс vlan99), а также если сам коммутатор выполняет межвлановую маршрутизацию (например, как L3-коммутатор)? Заранее спасибо!
     
     
     
    sindy
    Guest
    #3
    0
    21.02.2025 16:22:00
    Весь исходный пост был сделан, чтобы объяснить, что на самом деле нет единого «моста», потому что термин «мост» на самом деле обозначает три разных функциональных сущности, которые тесно связаны между собой. Чёткое разделение этих сущностей в соответствующих контекстах критично для понимания того, как всё вместе работает. А то, что настройки, связанные со всеми этими сущностями, сгруппированы в одной строке конфигурации — это следствие (чрезмерно оптимистичного) предположения, что пользователи понимают базовую архитектуру.

    С точки зрения нужных настроек моста и VLAN существует всего два варианта: либо маршрутизатору нужно получить доступ к определённому VLAN, либо нет. То, что именно маршрутизатор потом делает с трафиком, полученным через конкретный VLAN, не меняет то, как должны быть настроены мост и VLAN'ы.

    Что изменилось со времени моего первоначального поста — теперь RouterOS автоматизирует гораздо больше задач, чем раньше, но архитектура при этом не изменилась. Раньше, если вы прикрепляли VLAN «сабинтерфейс» к «интерфейсу маршрутизатора, смотрящему в сторону свитча», надо было ещё добавить «порт моста, смотрящий в сторону маршрутизатора» в tagged-лист на строке /interface bridge vlan для этого VLAN. Начиная как минимум с ROS 7.16, ROS делает это автоматически.

    Итак, если вам нужно, чтобы маршрутизатор получил доступ к VLAN 234, достаточно выполнить /interface vlan add interface=bridge vlan-id=234 name=my234vlan, а если потом сделать /interface bridge vlan print, вы увидите примерно следующее:

    [me@myTik] > interface/bridge/vlan/print
    Flags: D - DYNAMIC  
    Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED  
    #   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED  
    ...  
    ;;; added by vlan on bridge  
    3 D bridge       234  bridge
     
     
     
    griswold
    Guest
    #4
    0
    21.02.2025 17:24:00
    «Что изменилось с тех пор, как я написал исходный пост по этой теме, так это то, что RouterOS теперь автоматизирует гораздо больше задач, чем раньше, но архитектура осталась прежней. Раньше, если вы привязывали VLAN “подинтерфейс” к “интерфейсу маршрутизатора, направленному на коммутатор”, нужно было также добавить “порт маршрутизатора моста” в список tagged в строке /interface bridge vlan для этого VLAN; начиная как минимум с ROS 7.16, ROS делает это автоматически.»

    А, ты имеешь в виду, что теперь это делать не нужно (из исходного поста)  
    /interface bridge vlan add bridge=bridge-row-name vlan-ids=10,… tagged=bridge-row-name,…

    P.S. Я только что понял, что сильно ошибался, всё время думая, что в исходном посте ты говорил про маршрутизатор и коммутатор как про отдельные устройства MikroTik (а не одно устройство с функциями и маршрутизации, и коммутации). Последние пару дней я просто запутался во всём этом, теперь собираюсь ещё пару дней разобраться, надеюсь, наконец пойму.

    Редактирование: Я только что попробовал твой пример с vlan234, но /interface/bridge/vlan/print показывает в колонке vlan-ids: 1 (vlan1). Хотя, может, у меня GNS3 с роутерос 7.8, и там всё работает по-другому...

    В любом случае спасибо за объяснения!
     
     
     
    mkx
    Guest
    #5
    0
    21.02.2025 18:22:00
    Нужно обращать внимание на детали: как уже писал @sindy, пример работает с версии ROS 7.16… в 7.8 такой функции нет.
     
     
     
    griswold
    Guest
    #6
    0
    24.02.2025 00:56:00
    Наконец-то понял, просто хочу поделиться своими наблюдениями по этому посту и провести параллели, скажем, с Cisco.

    Как только создаёшь мост и включаешь vlan-filter, порт свича, смотрящий на роутер, получает дефолтный pvid=1 (поведение при приёме), и этот порт не маркирует трафик для vlan1 (поведение при передаче). Интерфейс роутера, смотрящий на свич, может иметь собственный IP, прикреплённый напрямую к самому мосту (/ip address/add address=x.x.x.x interface=bridge), и принимает немаркированные кадры (по умолчанию из vlan1). Также можно создать vlan-субинтерфейс (как в Cisco) для конкретного VLAN, указав parent-интерфейс как сам мост (/interface vlan add interface=bridge vlan-id=...), который будет принимать трафик с тегом для этого VLAN.

    Я это понял, когда пытался сделать интерфейс для VLAN1 — его реально не нужно создавать, он уже там по умолчанию, достаточно просто добавить ему IP, добавив адрес непосредственно к мосту. Но…

    Если я создаю мост, включаю vlan-filter, назначаю IP адресу мосту (/ip address/add address=1.1.1.1/24 interface=bridge), привязываю порт eth1 к мосту в access-режиме для vlan1, то могу пинговать 1.1.1.1 с eth1.

    А теперь, если создать явно интерфейс vlan1 через /interface vlan add interface=bridge name=vl1 vlanid=1 и назначить на него IP (/ip address add address=1.1.1.2/24 interface=vl1), то пинг к 1.1.1.2 проходит, а к 1.1.1.1 — нет.

    Я думал, что для доступа к vl1 нужен tagged-порт на стороне свича для vlan1, но это работает и без тега, и с ним тоже (/interface bridge vlan/add tagged=bridge vlanid=1). В этом моменте не совсем понял.

    Невозможность пропинговать 1.1.1.1 теперь объяснилась тем, что я создавал vlan1 последним, и его маршрут стал первым в списке ip route. Если удалить IP с моста и добавить его снова, маршрут для моста будет первее в таблице, тогда пинги к 1.1.1.1 идут, а к 1.1.1.2 — нет.

    Роутер отвечает на пинг на любой из своих адресов, независимо от интерфейса, с которого пришёл пакет, при условии, что IP-стек видит пакет в немаркированном виде. То есть, если пакет для 192.168.1.254 приходит в виде кадра с тегом VID 10 через интерфейс X, и есть /interface vlan с vlan-id=10, привязанный к интерфейсу X, и на этом vlan-интерфейсе есть IP-адрес, то роутер принимает пакет, если адрес 192.168.1.254 есть на любом интерфейсе (не учитывая VRF).

    Но, по моему мнению, это не совсем так — роутер не примет пакет с тегом id10 для 192.168.1.254, если этот IP из другого подсета.

    Пример:

    MikroTik (с интерфейсами ether2 и subinterface ether2.10)  
    ether2 ----f0/0 Cisco (с subinterface f0/0.10 в vlan10)  
    ether2 IP = 192.168.1.254  
    ether2.10 IP = 10.10.10.254  
    f0/0.10 IP = 192.168.1.1

    Когда Cisco пингует 192.168.1.254, тегированный кадр с id10 приходит на ether2 MikroTik, но там нет vlan10-интерфейса с подсетью 192.168.1.0, поэтому MikroTik не примет кадр, и пинг не проходит.

    P.S. Все тестил в GNS3 с chr RouterOS 7.8.

    Правка: нашёл ответ на свой третий вопрос — сам мост (интерфейс роутера, смотрящий на свич) принимает немаркированные кадры, а если создашь vlan1 через /interface vlan, то ожидает кадры с тегом 1. Значит, нужно добавить /interface bridge vlan tagged=bridge vlan-id=1, но тогда уже не пингуется адрес моста 1.1.1.1.

    Причина, почему иногда мог пинговать vlan1, а иногда мост — в том, что ПК запомнил MAC адрес моста или vlan1 в ARP-таблице и сразу слал ICMP без ARP-запроса. Роутер тоже имел таблицу ip arp.

    Интересный факт: если ПК сразу шлёт ICMP на MAC-адрес vlan1 интерфейса (без ARP), запрос приходит на vlan1 и роутер отвечает, даже если я удалил /interface bridge vlan tagged=bridge vlan-ids=1. В таком случае ICMP приходит немаркированным на порт роутера, но, раз он на vlan1 MAC, subinterface vlan1 его обрабатывает.

    Так что забудьте об этом вопросе. Спасибо Sindy и всем остальным за прояснение темы.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры