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

    Bridge "Distance" против статического маршрута

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Bridge "Distance" против статического маршрута, RouterOS
     
    rules
    Guest
    #1
    0
    24.08.2021 13:48:00
    Всем привет! Наконец-то я дошёл до того момента, когда хочу сжечь все мосты и полностью перейти на маршрутизацию. Идея в том, чтобы заранее создать все привязки серверов и маршруты, а потом переключить удалённую сторону так, чтобы она больше не подключалась к мосту (чтобы сэкономить мне кучу поездок). Проблема в том, что у динамического маршрута моста параметр «Distance» равен 0, а у моего статического маршрута — 1, из-за чего статический маршрут становится недоступен, пока я не остановлю мост, что приводит к значительному простою. Нет ли какого-то способа изменить предпочтение маршрутов? Спасибо, R
     
     
     
    rules
    Guest
    #2
    0
    21.09.2021 07:33:00
    Привет, Sindy. Извини, никак не могу найти время, чтобы глубже разобраться в этом. Последние пару дней играюсь с идеей «в точности такого же», возможно, я немного преувеличил. У меня в поле три типа роутеров: wAP, wAP ac и LtAP, с разными версиями прошивок (ни у одного ниже 6.45.9, что для LtAP — максимум, иначе SIM-карта перестает работать). Пока что wAP и LtAP ведут себя как надо. Как только их SSTP-соединения установлены и настроена правильная маршрутизация, я могу пинговать и сам роутер, и вторичное устройство с любой точки сети (главный роутер, сервер 1, сервер 2 и мой ноутбук, который подключен к главному роутеру через VPN).

    Проблемой оказался wAP. Я могу пинговать этот роутер с любого устройства в сети, но только некоторые устройства главной сети могут пинговать вторичные устройства (например, роутер может, сервер 1 — нет, сервер 2 — может, и мой VPN-ноутбук тоже). Я уже перенастроил файрвол на всех проверенных устройствах, сейчас они полностью одинаковые. Единственное отличие — прошивка, но даже один из роутеров на самой свежей версии ведет себя так же, поэтому сомневаюсь, что дело в прошивке. Что касается SSTP-соединения, оно использует пул IP-адресов, который нигде больше в сети не задействован. Есть идеи?
     
     
     
    sindy
    Guest
    #3
    0
    21.09.2021 19:28:00
    Это уже странно само по себе. У меня стоит 6.47.10 в LtAP, и LTE работает нормально, так что, может, нужно подстроить at-chat под специфические требования вашего MNO? Или, возможно, сам LTE-модем нужно обновить, чтобы подружиться с новыми версиями RouterOS, начиная с версии новее 6.45.9. Ах да, и не пытайтесь обновлять LTE-модем на версиях старше 6.47 (или, может, на одной из последних 6.46.x, я точно не помню, где добавили последний фикс для процедуры обновления) — я так сломал свой LTE-модем прошлым летом и пришлось отправлять весь комплект LtAP-LTE на RMA. Единственный вариант — прослушать проблемные устройства, чтобы понять, как далеко уходит запрос (и доходит ли он вообще до удалённого роутера) и приходит ли вообще ответ с «вторичного устройства». Может, у server1 таблица маршрутизации отличается от server2? Или у вторичного устройства есть маршрут к адресу server1, который не использует соседний Mikrotik в качестве шлюза? Прослушивание покажет, какое устройство не передало пакет, и тогда мы сможем сосредоточиться на настройках именно этого устройства.
     
     
     
    rules
    Guest
    #4
    0
    22.09.2021 11:16:00
    Только что попытался перевести ещё один LtAP (учитывая, что все предыдущие работали), и теперь он ведёт себя так же странно, как и wAP. Я могу пинговать второе устройство с ноутбука через VPN, но ни сервер 1, ни сервер 2 пинговать его не могут. Запустил сниффер пакетов для обоих случаев (на удалённом LTE-роутере), и при тесте с ноутбуком вижу входящие ICMP-пакеты и ответы на них. Со стороны серверов пакеты доходят, но ответа с вторичного устройства нет (tracert подтверждает — он доходит до удалённого роутера, но дальше ответа нет). На серверах нет никаких статических маршрутов, которые могли бы мешать, у них просто стоит шлюз — мост на основном роутере.
     
     
     
    sindy
    Guest
    #5
    0
    22.09.2021 14:22:00
    Если я правильно тебя понял, предполагая, что вторичное устройство подключено к ether1 на LtAP, ты видишь пакеты с server1 или server2, которые приходят через sstp-out1 и уходят через ether1, но не видишь ответов, возвращающихся через ether1 от вторичного устройства? Или ты видишь, что пакеты пинга доходят только до удалённого маршрутизатора (то есть перехвачены на интерфейсе SSTP), но не появляются на ether1?
     
     
     
    rules
    Guest
    #6
    0
    27.09.2021 09:44:00
    Первый я видел, как они уходили с ether1. Поэтому я просто проверил ещё три сайта — все работают на 100%, и единственное, что я поменял, — добавил ether1 в список LAN-интерфейсов (исходя из предположения, что это связано с правилом drop all !LAN). А вот #4 ведёт себя ровно так же, как и исходная проблема, даже с этим изменением.
     
     
     
    sindy
    Guest
    #7
    0
    27.09.2021 10:28:00
    Добавление ether1 в список интерфейсов LAN изменит поведение только в том случае, если у вас не было стандартного правила «accept established» в файрволе. Но если бы это было причиной, вы всё равно увидели бы ответ на ether1, просто файрвол не позволил бы ему пройти дальше. Так что, если вы видите запрос на ether1, но не видите ответ, то либо проблемы с маршрутизацией у подключённого устройства — возможно, у него нет маршрута по умолчанию, и оно может отвечать только на запросы из своей подсети, либо что-то не так с ответом Mikrotik на ARP-запрос устройства. Если устройство получает IP-конфигурацию через DHCP от Mikrotik, проверьте в /ip dhcp-server network наличие (и правильность) пункта gateway.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры