Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • 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
    Кратковременные, но периодические потери пакетов на канале 2xSXTSq AC

    Кратковременные, но периодические потери пакетов на канале 2xSXTSq AC

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Кратковременные, но периодические потери пакетов на канале 2xSXTSq AC, RouterOS
     
    joan10
    Guest
    #1
    0
    27.05.2021 10:15:00
    Всем привет! Мы настроили связь парой SXT Sq AC (RBSXTsqG-5acD) на расстоянии 330 метров для обслуживания клиентов. После настройки обеих устройств, выбора подходящих каналов и частот, мы запустили этот линк в работу с общим CCQ выше 90% (прикладываю график CCQ за последние 7 дней). Мощность передачи в обеих устройствах ниже максимума, рекомендуемого для AC на MCS9, а принимаемый сигнал – -58/-59 dBm. Мы проверили спектр, и, судя по всему, мы единственные на этом канале, так что проблем с линком не должно быть, всё должно работать идеально. Тест пропускной способности показывает около 200 Мбит/с. Мы особо не переживаем по этому поводу.

    Скрин графика CCQ:

    Однако через несколько дней эксплуатации мы заметили, что при умеренной нагрузке на трафик (около 30 Мбит/с вниз и 4–5 вверх) происходят потери пакетов. Эти потери случаются примерно каждые 2 минуты и длятся около 2–3 секунд. Если трафика нет, таких потерь не наблюдается. Что меня удивляет больше всего — теряются не только icmp-пакеты, а вообще все пакеты (даже те, которые и создают эту умеренную нагрузку), и при этом с подозрительно стабильной периодичностью и длительностью. Воспроизвести эту проблему сложно, но вчера мне удалось сделать скриншот такого поведения:



    Характеристики этого инцидента (периодичность и полная потеря пропускной способности линка), а также то, что все беспроводные метрики в норме, заставляют думать, что это, скорее всего, проблема с железом или ПО. Конечно, это не разрушит бизнес, но для реального времени — видеозвонков или онлайн-игр — это немного напрягает.

    Прикладываю /export полной конфигурации обеих антенн и вывод «print advanced» с обеих сторон.

    Некоторые детали:

    - Расстояние линка: 330 м
    - Устройство: RBSXTsqG-5acD
    - Протокол: 802.11
    - Частота: 5805
    - RX сигнал: -59/-59
    - Мощность TX: 16 дБм (в обеих)
    - Скорость передачи и приема: 400 Мбит/с – 40 МГц/2 поток/SGI (в обеих)
    - Версия ROS: 6.48.1 у обоих
    - SNR: 48 дБ
    - Загрузка CPU: около 10%

    Что мы пробовали — и это ничего не решило:

    - Использовать только 20 МГц каналы
    - Поменять каналы
    - Отключить station-roaming (решило другие проблемы, но не эту)*
    - Повысить мощность передачи
    - Понизить мощность передачи

    Station-roaming вызывал похожую проблему, но более постоянную и предсказуемую. Мы его отключили, стало стабильнее, но явно этого не хватило.

    Что мы не пробовали, потому что не считаем это полезным или смысленным (но, возможно, ошибаемся):

    - Обновление до 6.48.3 (нет улучшений в этом плане)
    - Отключение беспроводной безопасности
    - Пробовать другие протоколы
    - Менять антенны и радиомодули
    - Отключать SGI

    Итак, вопросы:

    - Это нормальное поведение, и мы слишком заостряем на этом внимание?
    - Считаете ли вы, как и мы, что это скорее проблема с железом или софтом, а не с настройкой линка?
    - Кто-нибудь сталкивался с подобным раньше?
    - Если да, есть ли советы, как это исправить (кроме замены оборудования)?

    Спасибо всем! Joan

    P.S. Проверили загрузку CPU — она в норме.

    station.rsc (1.8 KB)  
    ap_wirelessadvanced.txt (2.13 KB)  
    station_wirelessadvanced.txt (2.14 KB)  
    ap.rsc (1.91 KB)
     
     
     
    cdemers
    Guest
    #2
    0
    16.09.2021 17:43:00
    Я тоже это заметил, проблема возникает на многих устройствах, с которыми я работаю. Spanning tree постоянно создавал проблемы с потерей пакетов, в основном с OSPF на беспроводных PTP-связях. Сейчас я включаю spanning tree только на тех мостах, где это действительно нужно, и с тех пор особых проблем не было. Но если забыть и случайно замкнуть цикл, это обязательно вызовет трудности. У меня полностью маршрутизируемая сеть с резервными каналами, где spanning tree используется для быстрого переключения при отказе (в основном это 60GHz-связи с резервом на 5GHz).
     
     
     
    bpwl
    Guest
    #3
    0
    16.09.2021 20:23:00
    с избыточными связями, использующими spanning tree для быстрого переключения при отказе (в основном 60 ГГц с резервом на 5 ГГц). Хех... Cube60 работает с «объединёнными интерфейсами для 60 и 5 ГГц» для максимально быстрого переключения при отказе (http://forum.mikrotik.com/t/cubeg-5ac60ad/142666/1). Насколько я знаю, при использовании объединённых интерфейсов в чисто древовидной сети с bonded-связями spanning tree не нужен, но при этом сохраняется избыточность благодаря bonding. Spanning tree не требуется, если вы не создаёте избыточные циклы с bonded-связями. Bonding против избыточных циклов: самое интересное происходит со стековыми свитчами или виртуальными свитчами (один логический коммутатор поверх нескольких физических), когда физические каналы идут между разной аппаратурой для одного bonded-интерфейса. Если совмещать bonding, избыточные циклы и VLAN, используйте MSTP, а не ®STP. MSTP понимает, что при наличии цикла он локализован через настройки VLAN и не отключает линк в этом цикле.
     
     
     
    bpwl
    Guest
    #4
    0
    16.09.2021 20:36:00
    Если бы это касалось spanning tree или L2/L3, разве это не происходило бы даже без трафика по беспроводной ссылке? Я не знаю всех деталей этой настройки, но знаю, что WLAN-интерфейс на точке доступа считается НЕАКТИВНЫМ, если нет подключённого клиента. В нашей большой промышленной сети я обнаружил, что выбор корневого моста ®STP часто запускается из-за того, что какое-то устройство инженера начинает отправлять BPDU-сообщения при подключении. С тех пор все открытые порты настроены с «BPDU guard», и для их повторного включения теперь требуется вмешательство IT-отдела.
     
     
     
    AmirFarro
    Guest
    #5
    0
    12.07.2022 08:14:00
    Я уже полтора года мучаюсь с этой проблемой, и она решилась просто сменой RSTP на STP на моей точке доступа. Огромное спасибо! У меня ещё бывают странные и нелогичные скачки пинга, интересно, не подскажете, с чем это может быть связано?
     
     
     
    AmirFarro
    Guest
    #6
    0
    28.06.2021 08:35:00
    У меня такая же проблема, ты смог её решить?
     
     
     
    AmirFarro
    Guest
    #7
    0
    03.07.2021 17:47:00
    Поднимаю!
     
     
     
    joan10
    Guest
    #8
    0
    16.09.2021 12:42:00
    Всем привет, мне удалось это решить, пусть и с некоторым костылём. На самом деле я подтвердил, что у меня больше нет этой проблемы несколько часов назад. Как сказал bpwl, это было связано с протоколом spanning tree. Чтобы исправить, я просто отключил rstp на мостах обоих SXTSq: /interface bridge set protocol-mode=none br0

    Однако, коренной причины проблемы я так и не знаю. Думаю, она связана с некорректной настройкой L2 из-за неправильной конфигурации CRS112P, который подключён к одному из SXTs, но пока не уверен. Пытался воспроизвести проблему на других соединениях, но безуспешно, поэтому беспокоюсь о том, что такая же проблема может возникнуть в других частях моей сети. Похоже, придётся повспоминать учебные заметки по топологии L2.

    Топология L2 такая:  
    RB3011 — SXTSq 1 (- - - - -) SXTSq 2 — CRS112 — RB2011

    Связь между CRS112 и RB2011 настроена с VLAN-тегами (оба порта — trunk).  
    Прикладываю конфигурацию обоих устройств.  

    Спасибо,  
    Joan

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