Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • 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
    Направленный 18 Мбит/с против соединенного 13 Мбит/с.

    Направленный 18 Мбит/с против соединенного 13 Мбит/с.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Направленный 18 Мбит/с против соединенного 13 Мбит/с., RouterOS
     
    jober
    Guest
    #1
    0
    23.05.2006 20:51:00
    Я тестировал новую систему, и скорости от RB532s меня совсем не радуют. Мне правда нужно объединить эту сеть, но когда устройства настроены в режиме бриджа, я получаю всего 13 мбит/с TCP. Переключил на маршрутизацию — теперь 18–19 мбит/с. Хотелось бы было установить быструю сеть для этой школы, но теперь я не уверен, что это вообще получится. У кого-нибудь еще наблюдается такое падение скорости при использовании бриджа вместо маршрутизации?
     
     
     
    Zorker
    Guest
    #2
    0
    24.05.2006 01:21:00
    У меня та же проблема. Я использую Nstreme2 между двумя RB532 на частоте 400 МГц. Работало отлично, пока я не стал связывать эти устройства. Поскольку Nstreme2 не поддерживает связывание, мне пришлось использовать EOIP на RB532, и это фактически снизило скорость до 20 Мбит/с (можно было бы просто отключить вторую радиостанцию). Можно, конечно, подключить стандартный ПК с каждой стороны и там делать EOIP, а связывать их какими-нибудь старыми компьютерами, которые валяются без дела…
     
     
     
    dsovereen
    Guest
    #3
    0
    24.05.2006 13:51:00
    Мы соединяем backhaul-ы, использующие протокол Nstreme2, устанавливая один конец в режим mode=bridge, а другой – в mode=station-wds, и настраивая интерфейс wds на стороне mode=bridge (можно было бы настроить динамический wds, но мы используем статический). Затем помещаем интерфейс wds в bridge на стороне mode=bridge, а беспроводной интерфейс — в bridge на стороне mode=station-wds. У нас десятки таких соединений, и они отлично работают. Дэйв.
     
     
     
    jober
    Guest
    #4
    0
    24.05.2006 14:20:00
    У меня нет проблем с настройкой или конфигурацией. У меня проблема со скоростью. Мне интересно, почему скорость такая медленная при бриджинге?
     
     
     
    dsovereen
    Guest
    #5
    0
    24.05.2006 14:35:00
    Я скорее отвечал тому мужчине, который жаловался, что не может заставить работать бриджинг, а вместо этого использует EoIP. EoIP будет медленнее, чем WDS бриджинг. Я недостаточно тестировал, чтобы знать, насколько бриджинг значительно медленнее маршрутизации. Но поскольку мы используем бриджинг, мне очень интересно, чтобы он работал как можно быстрее. Предлагаю написать в службу поддержки support@mikrotik.com с вашими конфигурациями и результатами тестов, чтобы получить ответ. Они не всегда обращают внимание на форумы. Дэйв.
     
     
     
    tully
    Guest
    #6
    0
    24.05.2006 14:44:00
    Убедитесь, что используете более новую версию — новее чем .20. Мы оптимизировали некоторые мосты после этого. John
     
     
     
    jober
    Guest
    #7
    0
    24.05.2006 15:45:00
    Я использую версию 2.9.24.
     
     
     
    sten
    Guest
    #8
    0
    24.05.2006 23:02:00
    Пожалуйста, выложите вашу конфигурацию моста и параметры тестирования… Скорости выше этих вполне достижимы. Работа моста будет медленнее с каждым новым хостом в вашей таблице “обучения”. Подключение более двух интерфейсов к мосту легко приведёт к неэффективности. Рассматривайте мосты как хабы, которые иногда могут оптимизировать, пересылая пакет только на один (или несколько) интерфейсов. Дублирование пакетов – не дешёвая операция! Работа моста ставит интерфейсы в режим прослушивания, что приводит к увеличению нагрузки на входной путь. Мост использует алгоритм 802.1d (насколько я знаю) и жертвует эффективностью обработки пакетов ради корректности (что, безусловно, очень хорошо!). При работе с IP-пакетами мост имеет дополнительный брандмауэр, который нужно обойти (это не большая потеря, но каждая инструкция процессора – это инструкция процессора).  Поиск маршрутов требует не более 32 шага, тогда как работа моста потребует гораздо больше шагов. Ему придётся сравнивать исходный адрес с каждым хостом, изученным на входящем интерфейсе, а затем сравнивать целевой адрес со всеми хостами, изученными на всех остальных интерфейсах. Сравнение 48-битных адресов не очень “естественно” для 32-битных архитектур. Роутеры пересылают только пакеты, предназначенные для MAC-адреса роутера (без многоадресной рассылки или плохо настроенных мостов, расходующих ресурсы пересылки).
     
     
     
    dsovereen
    Guest
    #9
    0
    24.05.2006 23:38:00
    Не знаю, работаете ли вы на Mikrotik или нет, но похоже, вы отлично разбираетесь в этой теме. Я обнаружил одно поведение bridge, которое кажется не совсем оптимальным. У меня в bridge есть правило DST-NAT, которое меняет MAC-адрес назначения пакетов с адресом назначения FF:FF:FF:FF:FF:FF (broadcast) на определенный MAC-адрес. Единственные broadcast'ы в нашей сети - это от DHCP-клиентов, которым нужен IP-адрес. Это правило разработано для того, чтобы DHCP-запрос направлялся непосредственно к DHCP-серверу и не распространялся на всех остальных. Но с этим правилом DST-NAT bridge все равно пересылает пакет по всем интерфейсам, а не только по интерфейсу, на котором находится NATed MAC-адрес назначения. Вот моя полная конфигурация bridge:
    / interface bridge add name="ap" mtu=1500 arp=reply-only protocol-mode=rstp priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m comment="bridge to ap-# sectors" disabled=no
    / interface bridge port add interface=ap-1 bridge=ap priority=0x80 path-cost=10 edge=auto point-to-point=auto external-fdb=auto comment="" disabled=no
    add interface=ap-2 bridge=ap priority=0x80 path-cost=10 edge=auto point-to-point=auto external-fdb=auto comment="" disabled=no
    add interface=ap-3 bridge=ap priority=0x80 path-cost=10 edge=auto point-to-point=auto external-fdb=auto comment="" disabled=no
    add interface=ether1 bridge=ap priority=0x80 path-cost=10 edge=auto point-to-point=auto external-fdb=auto comment="" disabled=no
    / interface bridge filter add chain=forward mac-protocol=arp action=accept comment="" disabled=no
    add chain=forward mac-protocol=ip action=accept comment="" disabled=no
    add chain=forward mac-protocol=0x8863 action=accept comment="" disabled=no
    add chain=forward mac-protocol=0x8864 action=accept comment="" disabled=no
    add chain=forward action=drop comment="" disabled=no
    / interface bridge nat add chain=dstnat src-mac-address=!00:30:48:27:65:D8/FF:FF:FF:FF:FF:FF dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF action=dst-nat to-dst-mac-address=00:30:48:27:65:D8 comment="" disabled=no
    Чтобы помочь, я добавил IP-правило, которое позволяет IP-broadcast'ам (IP-адрес назначения 255.255.255.255) выходить только по интерфейсу, где находится DHCP-сервер. Это предотвращает выход пакета через другие интерфейсы роутера. Но кажется, что правило DST-NAT bridge должно делать то же самое. Если у вас есть какие-либо советы по оптимизации моей конфигурации bridge, я буду рад их услышать. Спасибо, Дэйв.
     
     
     
    sten
    Guest
    #10
    0
    25.05.2006 01:01:00
    Я не работаю на Mikrotik. Модуль RSTP bridge экспериментальный. Скорее всего, он пока не совсем оптимизирован по скорости. Этот вариант, вероятно, будет настоящим убийцей производительности. Если вы используете DHCP, возможно, стоит попробовать DHCP-релей. Вы не указали входящий интерфейс. Связаться со мной можно по адресу: lists@arcticwireless.no
     
     
     
    jober
    Guest
    #11
    0
    25.05.2006 04:24:00
    Стен, я изменил тестовую конфигурацию на OSPF для проверки скорости маршрутизации, поэтому пока не могу выложить конфиг. Придется всё вернуть в bridge mode, потому что сеть должна быть бриджовой для всей этой университетской системы. Выложу конфиги, когда верну обратно в bridge mode. Есть ли более удобный способ бриджинга, чем AP-Bridge/WDS к Station-wds? Нам нужно, чтобы система выглядела как подключенная к главному коммутатору, как остальные рабочие станции и серверы. Я буду запускать ПК с 4 радиомодулями в главном здании, а в небольших 4 зданиях будут rb532 для небольших сетей. Связь будет точкой-точка (ptp), чтобы не перегружать одно радио, как в ptmp-схеме. Беспроводная сеть и текущая проводная сеть будут объединены в одну большую сеть /24. В целом, мы справимся, если сможем пропустить 25 мбит/с по каждой ptp-связи.
     
     
     
    jober
    Guest
    #12
    0
    25.05.2006 16:38:00
    Отслеживание соединений отключено. RB532 #1 [admin@MikroTik] > interface wireless print
    Flags: X - отключен, R - работает
    0 X name=“wlan1” mtu=1500 mac-address=00:15:6D:50:0A:88 arp=enabled disable-running-check=no interface-type=Atheros AR5213 radio-name=“00156D500A88” mode=station ssid=“MikroTik” area=“” frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=2412 band=2.4ghz-b scan-list=default rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps, 54Mbps basic-rates-b=1Mbps basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no
    1 R name=“wlan2” mtu=1500 mac-address=00:15:6D:51:09:B2 arp=enabled disable-running-check=no interface-type=Atheros AR5213 radio-name=“00156D5109B2” mode=station-wds ssid=“MikroTik” area=“” frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=5180 band=5ghz scan-list=default rate-set=configured supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps, 54Mbps basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no
    [admin@MikroTik] > interface bridge print
    Flags: X - отключен, R - работает
    0 R name=“bridge1” mtu=1500 arp=enabled mac-address=00:0C:42:04:EB:06 stp=no priority=32768 ageing-time=5m forward-delay=15s garbage-collection-interval=5s hello-time=2s max-message-age=20s
    RB532 #2 [admin@MikroTik] > interface wireless print
    Flags: X - отключен, R - работает
    0 X name=“wlan1” mtu=1500 mac-address=00:15:6D:50:0A:8D arp=enabled disable-running-check=no interface-type=Atheros AR5213 radio-name=“00156D500A8D” mode=station ssid=“MikroTik” area=“” frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=2412 band=2.4ghz-b scan-list=default rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps, 54Mbps basic-rates-b=1Mbps basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no
    1 R name=“wlan2” mtu=1500 mac-address=00:15:6D:51:09:AA arp=enabled disable-running-check=no interface-type=Atheros AR5213 radio-name=“00156D5109AA” mode=ap-bridge ssid=“MikroTik” area=“” frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=5180 band=5ghz scan-list=default rate-set=configured supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps, 54Mbps basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=dynamic wds-default-bridge=bridge1 wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no
    [admin@MikroTik] > interface bridge print
    Flags: X - отключен, R - работает
    0 R name=“bridge1” mtu=1500 arp=enabled mac-address=00:0C:42:04:EA:FD stp=no priority=32768 ageing-time=5m forward-delay=15s garbage-collection-interval=5s hello-time=2s max-message-age=20s
    Только 14 Мбит/с по TCP в одном направлении и 7,7 Мбит/с в обоих направлениях.
     
     
     
    wildbill442
    Guest
    #13
    0
    25.05.2006 20:34:00
    И как же тогда эффективно связать несколько интерфейсов? Настроить несколько мостовых интерфейсов, определив только два порта моста для каждого интерфейса? Но тогда разве не будет дублирования пакетов, учитывая, что один из портов войдет в состав нескольких мостовых интерфейсов…
     
     
     
    sten
    Guest
    #14
    0
    25.05.2006 21:20:00
    Зависит от того, что ты подразумеваешь под "эффективно". В любом случае, останется проблема с неизвестным местом назначения, что приведет к какой-то неэффективности. На мой взгляд, лучше всего будет настроить vlan для каждого ap отдельно. А следующая по эффективности вещь — формировать/направлять поток данных в конкретный поток от точки A к точке B.
     
     
     
    sten
    Guest
    #15
    0
    25.05.2006 21:52:00
    Получаю всего 14 Мбит/с TCP в одну сторону и 7,7 Мбит/с в обе. Можно и лучше… Здесь слишком много переменных, чтобы я мог вам как-то помочь по переписке. Если хотите, чтобы я посмотрел, напишите мне на электронную почту, указанную выше. Удачи в этом черном искусстве оптимизации. #networktroubleshooting #internetproblems
     
     
     
    kalviz
    Guest
    #16
    0
    29.05.2006 08:20:00
    Стен, а ты как думаешь, если три интерфейса объединены в бридж, то входящий фрейм (который приходит через интерфейс A и предназначен для хоста, доступного через интерфейс B) тоже переводится на интерфейс C? Руководство по Mikrotik говорит, что интерфейс бриджа работает как коммутатор, а не как концентратор.
     
     
     
    sten
    Guest
    #17
    0
    29.05.2006 08:42:00
    Если устройство приходит по каналу A и мост знает, что пункт назначения находится по каналу B, то трафик не будет дублироваться на канал C. Как у (совместимого с 802.1D) коммутатора, но любой коммутатор может вести себя как концентратор в определенных повседневных условиях. И это хорошо. Многие сетевые администраторы не знают, как работает мост, и поэтому соединяют целые сети. Многие сетевые администраторы думают, что если это делается по DSL или на дешевых внутренних точках доступа, то это стоит делать и в беспроводной сети. Однако это подчеркивает сильные стороны одной технологии и одновременно указывает на слабости другой.
     
     
     
    stealth
    Guest
    #18
    0
    12.08.2006 10:45:00
    Привет, ты правда имеешь в виду nstream2 (dual)? Ведь для nstream dual нужно изменить wlan1 и wlan2 в режим mode=nstream-dual-slave, так что bridge или station-wds использовать нельзя. В отличие от обычной конфигурации nstream, где bridge и station-wds - обычное дело. Сейчас я особо не вижу, как использовать прозрачный ptp bridge с nstream dual, может, arp-proxy поможет?
     
     
     
    dsovereen
    Guest
    #19
    0
    12.08.2006 15:48:00
    Это была ошибка. Мы используем Nstreme, а не Nstreme2. Надо бы начать лучше проверять свои ответы. Извини. Дэйв
     
     
     
    aviper
    Guest
    #20
    0
    13.08.2006 14:01:00
    Как сигнал? Попробуй без nstream… Ты включил опросы? Есть ли ещё какие-то устройства на той же частоте? Закрыть частоту? SNR? Шумы? И больше информации будет полезно…
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры