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

    Случайные отключения соединения, часть 2

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Случайные отключения соединения, часть 2, RouterOS
     
    john231
    Guest
    #1
    0
    28.03.2020 11:27:00
    Привет, у меня всё еще проблемы с настройкой Mikrotik. Ранее писал тут: http://forum.mikrotik.com/t/mobile-devices-unusable/128011/1 и тут: http://forum.mikrotik.com/t/random-connection-dropping/134297/1.

    Проблема в том, что время от времени интернет пропадает, хотя устройство продолжает быть подключено к точке доступа. Особенно страдают мобильные устройства, но ПК и Mac тоже не в порядке. Сейчас проблема проявляется, например, при просмотре сайтов, видео и в тот момент вообще нельзя подключиться к основному роутеру (шлюзу) по адресу 192.168.88.1. Но само устройство остаётся связанным с точкой доступа.

    Последнее решение — выключение RSTP на коммутаторах — помогло значительно, но проблемы всё равно есть.

    Настройка очень простая, я приложил конфигурации каждого устройства (кроме коммутатора, его настройки есть в предыдущей теме и они не менялись). Коммутаторам назначены статические IP, на коммутаторе с адресом 192.168.88.4 поставил галочку «Long PoE в кабеле». Точки доступа сбрасывал до заводских настроек без конфигурации, а затем запускал export из файла, который приложил к этому сообщению. Также приложил схему сети:

    Каждая AC lite работает на 2.4 ГГц на разных каналах, чтобы не пересекаться.

    Кто-нибудь может подсказать, в чём я ошибаюсь? Я уже несколько месяцев ищу решение, а проблемы остались. Хотя это самая стабильная конфигурация, которую удалось сделать. Стандартная настройка с минимальными изменениями — например, перевод роутера в режим моста и установка статического IP — вообще не работает.

    SXT-LTE использую с настройками по умолчанию, с несколькими изменениями: автоматическое обновление включено, добавлен PIN сим-карты, назначены некоторые статические IP, время аренды DHCP — 1 день, отключены логирование и некоторые сервисы (telnet, api, ssh).

    Оru SXT-LTE (192.168.88.1).txt (4.49 KB)  
    OruAPMajaKatusTV (192.168.88.6).txt (2.4 KB)  
    OruAPMaja (192.168.88.2).txt (2.47 KB)  
    OruAPSaun (192.168.88.3).txt (2.41 KB)
     
     
     
    john231
    Guest
    #2
    0
    06.05.2020 07:48:00
    Хорошо, я провёл дополнительный анализ, и этот пропуск пакетов повторяется. Когда я пингуют 8.8.8.8 с ноутбука, подключённого к любой точке доступа, вижу потерю пакетов около 10%. А когда я пингуют с роутера sxt — потерь нет, среднее время отклика 23 мс. На ноутбуке уровень RSSI показывает -51 и ниже.
     
     
     
    SiB
    Guest
    #3
    0
    06.05.2020 08:09:00
    Следи за параметрами LTE — LteLogger должен показывать тебе смену между BTS Band/Cell и многое другое, например, такое поведение: после перезагрузки пинги нормальные, если немного подождать… потом само может исправиться. Я меняю положение устройства — и оно фиксится. Можно записывать, к какому cell id ты подключён, и когда всё работает стабильно, сделать cell lock, чтобы держать связь с одной полосой и её конкретной «антенной». Записывай смену cellid, и так можно понять, какая из них подходит именно тебе. Всё, что я написал, на 80% правда. Иногда, когда ты на CellLock и видишь проблемы, можно подумать, что разные сигналы — это параметры качества связи между тобой и базовой станцией. Тогда стоит подкорректировать позицию устройства и так далее…
     
     
     
    mutluit
    Guest
    #4
    0
    06.05.2020 13:56:00
    Как уже говорили другие участники: проанализируйте лог-файлы устройств. Судя по всему, устройство перезагружается из-за перегрева или внутренней ошибки, например, когда в коде или скрипте возникает бесконечный цикл. Проверьте, не связана ли проблема с перегревом. Если у ваших устройств есть активные вентиляторы охлаждения, возможно, какой-то из них неисправен. Если охлаждение пассивное, попробуйте подуть на устройство внешним вентилятором, например небольшим USB-вентилятором, и понаблюдайте, возникает ли ошибка снова.

    Еще один вариант — вы могли непреднамеренно использовать неподходящий блок питания, например, с слишком маленьким значением тока (Ампер). Проверьте и сверяйтесь с документацией и техническими характеристиками устройства.
     
     
     
    john231
    Guest
    #5
    0
    07.05.2020 05:01:00
    У меня включены все логи, даже отладочные, но журнал пустой. Есть ли инструкция, как его включить?
     
     
     
    john231
    Guest
    #6
    0
    07.05.2020 06:14:00
    Я сказал, что с LTE всё в порядке, проблем с пингом с SXT-LTE нет. Никаких проблем с перегревом — SXT стоит на улице при температуре около 15 градусов Цельсия. Похоже, это проблема уровня 2, и она совпадает с истечением срока аренды DHCP.
     
     
     
    john231
    Guest
    #7
    0
    07.05.2020 06:17:00
    Ещё одна вещь, которую заметил: может, это нормально, а может и нет, но когда смотрю список соседей SXT-LTE, вижу два MAC-адреса от одного устройства. Хотя на этом AP на eth1 и wlan1 у меня отключён ARP.
     
     
     
    john231
    Guest
    #8
    0
    07.05.2020 07:24:00
    Хорошо, проблема с MAC-адресом, похоже, решилась... пришлось задать административный MAC-адрес на мосту. Административный MAC-адрес на мосту установлен на eth1, который у меня является “WAN”-портом и подключён к свитчу. Также настроил логирование, и теперь оно работает.
     
     
     
    SiB
    Guest
    #9
    0
    07.05.2020 07:31:00
    Я говорю одно, а ты делаешь совсем другое.
     
     
     
    john231
    Guest
    #10
    0
    07.05.2020 08:35:00
    Как я и говорил, это проблема уровня 2. Она никак не связана с CellLock или чем-то подобным. SXT-LTE работает нормально. Проблема в внутренней сети, и когда я настраивал точку доступа, я добавил интерфейсы в бридж следующим образом:  
    /interface bridge port  
    add bridge=bridge1 interface=ether1  
    add bridge=bridge1 interface=ether2  
    add bridge=bridge1 interface=ether3  
    add bridge=bridge1 interface=ether4  
    add bridge=bridge1 interface=ether5  
    add bridge=bridge1 interface=wlan2  
    add bridge=bridge1 interface=wlan1  
    add bridge=bridge1 interface=ether1  

    В итоге функция auto-mac на интерфейсе бриджа взяла MAC-адрес wlan1 как собственный MAC-адрес самого бриджа. А должно было быть так:  
    /interface bridge port  
    add bridge=bridge1 interface=ether1  
    add bridge=bridge1 interface=ether2  
    add bridge=bridge1 interface=ether3  
    add bridge=bridge1 interface=ether4  
    add bridge=bridge1 interface=ether5  
    add bridge=bridge1 interface=wlan2  
    add bridge=bridge1 interface=wlan1  

    Или ещё лучше — у самого бриджа должен быть уникальный MAC-адрес, свой для сети.
     
     
     
    SiB
    Guest
    #11
    0
    08.05.2020 14:24:00
    john231 Верно, у всех моих мостовых интерфейсов уникальные административные MAC-адреса. Я генерирую MAC-адрес, добавляя новый интерфейс EoIP, который сам создаёт MAC-адрес — я не добавляю EoIP, а просто открываю окно нового туннеля, чтобы скопировать оттуда новый MAC-адрес, и затем нажимаю Отмена.
     
     
     
    john231
    Guest
    #12
    0
    15.05.2020 11:21:00
    Остался один вопрос... Сейчас, когда у меня все интерфейсы в бридже, и бриджу назначен IP, а обнаружение соседей по IP стоит по умолчанию как "!dynamic", при просмотре обнаруженных соседей я вижу MAC-адрес бриджа и MAC-адрес eth1 всех точек доступа. Разве я не должен видеть только MAC бриджа? /ip neighbor print  
    #  INTERFACE    ADDRESS        MAC-ADDRESS  
    0  ether1    192.168.88.1    B8:69:F4:01:35:55  
      bridge1  
    1  ether1    192.168.88.2    02:2A:F3:AA:A1:E2  
      bridge1  
    2  ether1    192.168.88.2    B8:69:F4:B1:FC:C0  
      bridge1  
    3  ether1    192.168.88.3    02:2F:19:EF:AF:37  
      bridge1  
    4  ether1    192.168.88.3    B8:69:F4:95:63:8E  
      bridge1  
    5  ether1    192.168.88.4    B8:69:F4:23:27:AE  
      bridge1  
    6  ether1    192.168.88.5    B8:69:F4:B4:1D:66  
      bridge1  

    Для чего вообще используется обнаружение соседей?
     
     
     
    SiB
    Guest
    #13
    0
    15.05.2020 14:14:00
    Это нормально, потому что это обнаружение происходит на уровне Layer2 и показывает реальный интерфейс, даже если он назначен на мост… смотри.
     
     
     
    john231
    Guest
    #14
    0
    17.05.2020 12:57:00
    Есть ли разница в порядке добавления портов в бридж? Это может вызвать проблемы...  
    /interface bridge port  
    add bridge=bridge1 interface=ether2  
    add bridge=bridge1 interface=ether3  
    add bridge=bridge1 interface=ether4  
    add bridge=bridge1 interface=ether5  
    add bridge=bridge1 interface=wlan2  
    add bridge=bridge1 interface=wlan1  

    а так нет проблем...  
    /interface bridge port  
    add bridge=bridge1 interface=ether1  
    add bridge=bridge1 interface=ether2  
    add bridge=bridge1 interface=ether3  
    add bridge=bridge1 interface=ether4  
    add bridge=bridge1 interface=ether5  
    add bridge=bridge1 interface=wlan2  
    add bridge=bridge1 interface=wlan1  

    Почему так?
     
     
     
    SiB
    Guest
    #15
    0
    17.05.2020 13:13:00
    никакой разницы
     
     
     
    mkx
    Guest
    #16
    0
    17.05.2020 14:35:00
    … если сначала вручную задать MAC-адрес на мосту. И даже в этом случае может случиться (временно) потеря связи, потому что управляющий MAC-адрес может измениться тем или иным способом. Если вы подключаетесь к RB по IP (и настройка IP-адреса сохраняется при изменениях в L2-конфигурации вашего RB), вам, возможно, придётся переподключиться. Если подключаетесь по MAC, придётся подключаться к новому MAC-адресу моста.
     
     
     
    john231
    Guest
    #17
    0
    20.05.2020 07:21:00
    Окей, небольшие обновления. Я настроил watchdog на все устройства, кроме watchdog между свитчами. Например, SXT → OruAPMaja и OruAPMaja → SXT с интервалом в 10 секунд. Это работает уже 5 дней, и проблем пока не было (я проверял несколько раз, отключая случайные точки доступа, и сразу же получал письма об этом). Также настроил watchdog с каждого устройства (кроме свитчей) к Google DNS (8.8.8.8). От watchdog никаких сообщений о проблемах не поступало.

    Однако сегодня утром, когда я переходил из одной комнаты в другую, на iPad пропало соединение, и я не мог пропинговать 192.168.88.1 (SXT — главный роутер) с iPad. Проблема длилась около полутора минут, потом пинг снова заработал. Возможно, проблема с переключением с одной точки доступа на другую? Я перемещался по дому, так что, скорее всего, это были AP 192.168.88.2 (OruAPMaja) или 192.168.88.6 (OruAPMajaKatusTV).
     
     
     
    SiB
    Guest
    #18
    0
    20.05.2020 09:18:00
    Это технический форум, здесь не занимаемся догадками… проверьте логи этого события. Попробуйте воспроизвести проблему.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры