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

    Резервные MikroTik и переопределение маршрутов подключения

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Резервные MikroTik и переопределение маршрутов подключения, RouterOS
     
    Tetrafluoroethane
    Guest
    #1
    0
    14.06.2012 19:59:00
    У меня возникла небольшая проблема с настройкой рабочей маршрутизации на паре MikroTik. Моя конфигурация состоит из двух роутеров RB750, каждый из которых подключён к отдельному сетевому свитчу через eth2 (порт 3). Свитчи соединены между собой одним портом. Роутеры подключены друг к другу через eth1 (порт 2). Каждый из роутеров имеет подключение к провайдеру через eth0 (порт 1). Интерфейсы eth0 у обоих роутеров имеют подсеть /30 для маршрутизации к провайдеру. На обоих роутерах установлен маршрут по умолчанию через этот интерфейс, а шлюз проверяется пингом. Это конфигурация с «ручным переключением» (manual fail-over). Интерфейсы eth0 на обоих роутерах имеют одинаковый IP-адрес, чтобы можно было просто переключить кабель, если один из роутеров выйдет из строя. Да, я знаю, не спрашивайте. Эта часть работает именно так, как задумано.

    Интерфейсы eth1 имеют адреса из сети 10.0.20.0/30. Это сделано так, чтобы независимо от того, что происходит на eth2, роутеры всегда могли между собой общаться. Этот интерфейс тоже настроен как маршрут по умолчанию, но с метрикой 2. Это гарантирует, что если на роутере не подключён кабель к eth0, он всё равно сможет отправлять пакеты во внешний мир через другой роутер. Эта часть работает неправильно из-за того, что происходит на eth2.

    На интерфейсах eth2 настроен VRRP. И у самих eth2, и у VRRP интерфейса адреса из сети 10.0.10.0/24. VRRP работает прекрасно, и остальные устройства, подключённые к свитчам, без проблем переключаются на разный шлюз. Проблема возникает, когда свитч, подключённый к роутеру с активным uplink (назовём его router1), выходит из строя. Или когда связь от этого роутера к свитчу пропадает — без разницы. В этом случае VRRP меняет шлюз на роутер без uplink (router2). Пакеты, предназначенные для внешних сетей, отправляются на router2, как и должно быть. Так как у router2 нет uplink, маршрут по умолчанию с метрикой 1 не активен, и router2 использует маршрут с метрикой 2, чтобы переслать пакеты на router1 через сеть 10.0.20.0/30 по eth1. Затем router1 отправляет пакеты дальше наружу. Тут вроде бы всё работает.

    Входящий трафик — совсем другая история. Пакеты приходят на router1 по uplink. Адрес сети назначения присутствует на одном из интерфейсов роутера, поэтому выбирается этот подключённый маршрут, даже когда линк сломан. В итоге эти пакеты так и не перенаправляются на router2, чтобы выйти дальше в сеть. При тестировании, если на router1 отключить адрес 10.0.10.x и тем самым убрать подключённый маршрут, всё начинает работать идеально.

    Вот в чём загвоздка. Мне нужно как-то заставить роутер не маршрутизировать пакеты, если интерфейс считается неработающим. Я понимаю словосочетание «неработающий» достаточно широко, потому что мне важно, чтобы другие хосты оставались доступны, даже если линк поднят. Думаю, можно использовать netwatch и скрипты, чтобы просто отключать адреса, как я делаю в тестах, но хотелось бы знать, нет ли какого-то более эффективного решения, которое я пропускаю.

    Что менять нельзя: один uplink. VRRP — я должен поддерживать клиентов, которые могут работать только с одним шлюзом. Если не существует другого способа переносить IP-адрес шлюза, то остаётся только VRRP.

    Буду благодарен за любые советы. Спасибо!
     
     
     
    bitshop
    Guest
    #2
    0
    06.07.2012 08:19:00
    Думаю, в VRRP есть какие-то баги — мне несколько раз пришлось сбрасывать прецедент (через изменение приоритета) при первоначальной настройке, чтобы заставить VRRP работать. Особого значения этому тогда не придавал, так как peer VRRP у меня — Mikrotik 3.x, и я вынужден был делать изменения, чтобы поддерживать старую версию VRRP.

    Вчера, примерно 24 часа назад, у нас упала сеть, и долго пришлось искать причину. Изнутри сети роутер пинговался для одних клиентов, для других — нет. Снаружи роутер пинговался, но форвардинг не работал. Мы перезагрузили роутер, заметили, что на какое-то время он заработал, а потом снова упал. Полагаем, что в период «работы» VRRP был на запасном роутере (мы перезагружали с кнопки сброса, думая, что что-то зависло).

    Дальше сделали interface vrrp set 0 priority=100, чтобы переключиться на другой Mikrotik, и всё заработало нормально. Сегодня вечером у нас запланировано окно обслуживания на случай неполадок, и мы сделали interface vrrp set 0 priority=225 (чтобы вернуться обратно) — всё работает.

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

    Steve Radich
     
     
     
    Tetrafluoroethane
    Guest
    #3
    0
    09.07.2012 15:29:00
    Хотя я не могу говорить за баги в такой старой версии RouterOS, могу сказать, что моя конфигурация работает нормально. У меня есть еще одна настройка VRRP с резервными uplink, и она тоже отлично справляется. Ты не указал, на каких интерфейсах у тебя запущен VRRP. Если ты запускаешь его только на внешнем интерфейсе, а для внутреннего используешь какой-то другой метод, у тебя фактически будет обратная моя проблема. Убедись, что у тебя не происходит «дрожание» интерфейсов. У меня есть скрипт, который следит за доступностью сетевых ресурсов с нормального мастер-устройства MikroTik. Если внутренний канал падает, скрипт отключает определенные IP-адреса на этом канале. Нужно быть осторожным с тем, какие адреса ты мониторишь, потому что если альтернативный маршрут становится активным и эти адреса становятся доступными с мастера, интерфейс снова поднимается, и адрес становится недоступным — возникает цикличность, или «дрожание» состояния. Еще одной проблемой могут быть твои сетевые коммутаторы. Некоторые простые или среднеуровневые коммутаторы долго обновляют таблицу MAC-адресов. Когда VRRP меняет адреса, таблица MAC должна понять, что MAC больше не на исходном порту. VRRP посылает запрос при переключении, но не все коммутаторы реагируют правильно. Если ты не можешь достучаться до MikroTik только с некоторых внутренних адресов, советую взглянуть на MAC-таблицу коммутаторов и проверить, на каких портах зарегистрирован VRRP MAC-адрес. Дай знать, что найдёшь.
     
     
     
    Paxy
    Guest
    #4
    0
    26.10.2012 20:26:00
    bitshop, у меня такая же проблема. По какой-то причине в какой-то момент основной маршрутизатор VRRP просто перестаёт пересылать данные. Он отвечает на ping с MT, но не отвечает на ping из внутренней сети и не пересылает никакие пакеты из внутренней сети. VRRP настроен на внутренний IP-адрес, поэтому к нему можно подключиться с WAN-ссылок. Я не смог найти причину, почему это происходит — ARP-таблица и на основном MT, и на следующем коммутаторе в порядке (виртуальный VRRP MAC). Поскольку пинг продолжает работать, резервный MT не переключается, и я просто теряю связь с внутренней сетью. Если я меняю приоритет, отключаю и включаю или перезагружаю MT, VRRP снова начинает работать. Я пытался сделать скрипт для обнаружения отказа VRRP, но пока безуспешно, так как связь с другим MT и остальной внутренней сетью сохраняется, даже без VRRP на виртуальном IP. Как вы решили эту проблему? P.S. версия MT 5.20
     
     
     
    MarcinB
    Guest
    #5
    0
    01.01.2013 23:25:00
    Привет, ты нашёл решение? У меня такая же проблема с двумя RB493 (5.22). Когда я отключаю vrrp, пересылка работает нормально. Я тоже использую OSPF, но проблема, похоже, связана именно с vrrp. С уважением, Марчин.
     
     
     
    Paxy
    Guest
    #6
    0
    02.01.2013 08:58:00
    Я написал скрипт, который пингует внутренний коммутатор используя VRRP IP-адрес с основного роутера. Если пинг не проходит, скрипт отключает и снова включает VRRP интерфейс. Этот скрипт запускается каждые 3 секунды. Таким образом, соединение не прервётся, даже если процесс VRRP остановится на секунду.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры