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

    Избирательная маршрутизация с резервированием в MikroTik - Как?

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Избирательная маршрутизация с резервированием в MikroTik - Как?, RouterOS
     
    millenium7
    Guest
    #1
    0
    04.06.2020 03:18:00
    Итак, у меня есть 2 сценария, для которых мне нужно найти решение. Сценарий A: селективная маршрутизация с одним переходом. RouterA и RouterB работают между собой через OSPF, путь 60 ГГц установлен с типичной стоимостью 10 и работает через BFD, а путь 5 ГГц имеет стоимость 15. Это работает идеально для быстрого переключения в случае, если линк 60 ГГц выходит из строя. Трафик успешно переключается на 5 ГГц, в целом все хорошо. Однако он никогда не просто не отключается и остается отключенным, когда идет дождь или происходит частичное препятствие. На самом деле, что происходит, так это колебания линка или просто плохая работа, что очень заметно и весьма нарушает работу VoIP. Поэтому я бы предпочел, чтобы весь VoIP трафик постоянно проходил через ссылку 5 ГГц, чтобы не сталкиваться с ситуацией колеблющегося линка. Я могу добиться этого с помощью простого правила модуляции, которое переключается на, например, 'BackupRoutingTable', в которой всего 1 маршрут - стандартный маршрут к IP-адресу на 5 ГГц интерфейсе RouterA. Здорово... пока линк 5 ГГц не выйдет из строя. RouterB продолжит отправлять VoIP трафик через этот интерфейс, пока физический интерфейс не отключится, так как это локальный IP-адрес, а не петлевое соединение. Как мне решить эту проблему? Сценарий B: многопроходная селективная маршрутизация. Если мы сможем разобраться со Сценарием A, это может помочь решить и Сценарий B, но тут есть потенциальная проблема, особенно если мы используем правила модуляции. На RouterC это довольно просто, чтобы повлиять на путь. Если я хочу, чтобы весь трафик от клиента X шел через Internet1, он отправит на RouterB, который затем отправит на RouterA и дальше в интернет. А весь трафик от клиента Y отправится через Internet2, он пойдет на RouterD->RouterE. Это очень просто, потому что RouterB просто смотрит на свою таблицу маршрутизации и видит, что ближайший путь в интернет через RouterA, а то же самое касается RouterD к RouterE, легко. Но что насчет клиента Z? Если у меня есть правило на RouterE, что я хочу, чтобы весь его трафик шел через Internet1, он отправит на RouterD. Но RouterD увидит, что ближайший путь в интернет - через RouterE, так что просто отправит данные назад, а затем RouterE отправит трафик в Internet2 (или вызовет зацикливание, маршрутизируя его обратно к RouterD). Здесь не возможно использовать модуляцию, потому что данные соединения/пакетов не передаются, так что у RouterD нет способа точно узнать "о, этот трафик должен идти через Internet1", он просто будет смотреть на свою нормальную таблицу маршрутизации, он не будет использовать модуляцию. Какие возможности здесь?
     
     
     
    millenium7
    Guest
    #2
    0
    10.02.2021 07:38:00
    Я заставил это работать, но тут много команд и довольно запутано. Наверняка есть более чистый и простой способ… В данный момент я достигаю этого, создавая другой VLAN и IP-адреса на интерфейсах между роутерами в Route->VRF, добавляю эти VLAN с маркой маршрутизации типа “SendOverBackup”. Создаю еще один экземпляр OSPF, router-ID может быть тем же, устанавливаю распределение маршрута по умолчанию на всегда, таблица маршрутов остаётся как раньше, вручную отключаю DN (в противном случае маршруты не будут правильно рекламироваться). Добавляю еще одну область OSPF 0 под этот новый экземпляр. Добавляю IP-адреса этих VLAN в сети. Настраиваю параметры интерфейса OSPF (большая стоимость на 60 ГГц, чтобы он был менее предпочтительным). Создаю новый список интерфейсов и добавляю эти VLAN. Добавляю правило mangle, которое отмечает соединения, приходящие через эти VLAN: /ip firewall mangle add action=mark-connection chain=prerouting in-interface-list=BackupLinks new-connection-mark=fromSendOverBackup_c. Добавляю правило mangle для возврата трафика через тот же VRF, поскольку маршрутизация MikroTik по умолчанию этого не делает: /ip firewall mangle add action=mark-routing chain=prerouting connection-mark=fromSendOverBackup_c in-interface-list=!BackupLinks new-routing-mark=OtherWay. Теперь цель достигнута: все данные обычно проходят через 60 ГГц, с быстрой переключаемостью благодаря BFD. И наоборот, с другим экземпляром OSPF, работающим на 5 ГГц как основном, а 60 ГГц как резервном, с быстрой переключаемостью в другую сторону. Теперь трафик можно избирательно маркировать, чтобы всегда предпочитать резервный линк. Просто мне кажется, что это запутано и слишком сложно с множеством лишних шагов для достижения цели. Кто-нибудь знает лучший/простой метод? Помните, не может быть просто простого правила mangle, чтобы заставить весь трафик проходить через резервный линк. Цель состоит в том, чтобы иметь переключение на обоих направлениях. Если просто сделать простое правило mangle, то весь трафик всегда будет идти по резервному пути, даже если он не доступен и недостижим, потому что это радиорелеи. Физическое состояние интерфейса останется активным (ethernet к радио), но соединения не будет (радио к радио), поэтому это никогда не переключится правильно. Нужен OSPF или BGP.
     
     
     
    pe1chl
    Guest
    #3
    0
    18.03.2021 09:52:00
    Я думаю, что единственный реальный вариант маршрутизации по-разному в зависимости от меток пакетов (например, на основе DSCP или других типов SLA) — это иметь несколько разных таблиц маршрутизации, каждая из которых поддерживается отдельным экземпляром маршрутизирующего протокола (или разными маршрутизирующими протоколами), и использовать выборку из таблицы маршрутизации, которая одинаковая по всей сети. В вашем случае: вы поддерживаете отдельную таблицу маршрутизации для VoIP и выбираете ее на основе DSCP 46 или “верхние 3 бита DSCP равны 5”. Таблица маршрутизации (также называемая “маркером маршрутизации” в RouterOS) поддерживается экземпляром маршрутизирующего протокола, который настроен иначе и акцентирует внимание на надежных путях, а не на быстрых. Чтобы это работало нормально в более сложных сетях, чем вы себе представляете, важно, чтобы все узлы в сети были настроены одинаково и чтобы не было узлов, где, например, выбор таблицы маршрутизации на основе DSCP забыт или отличается. Потому что это может легко привести к петлям маршрутизации.
     
     
     
    sarah
    Guest
    #4
    0
    20.03.2021 13:28:00
    Просто интересно, добавишь ли ты второй маршрут по умолчанию к IP-адресу интерфейса 60 ГГц маршрутизатора RouterA с большим расстоянием и добавишь проверку шлюза для обоих маршрутов (5 ГГц и 60 ГГц). Это не будет «бесшовным» переключением, так как проверка шлюза требует около 30 секунд для вступления в силу. С другой стороны, это может не сработать, потому что обратный путь все равно будет предпочитать один путь другому.
     
     
     
    StubArea51
    Guest
    #5
    0
    20.03.2021 15:11:00
    Мы решили подобные задачи для клиентских WISP-сетей, используя этот дизайн… https://mum.mikrotik.com/presentations/US17/presentation_4519_1496062656.pdf
     
     
     
    millenium7
    Guest
    #6
    0
    20.03.2021 23:44:00
    Спасибо, я это прочитал. Если я правильно понял, вы манипулируете направлением трафика для подсети назначения. Это, похоже, может сработать, если клиенту дать 2 IP-адреса: один для обычных данных, другой для голосового трафика. Таким образом, вы можете заставить голос использовать менее предпочтительный путь, это так? То есть это никак не связано с классами трафика, это строго адрес назначения/подсеть. Это небольшой шаг в правильном направлении, но он не совсем оптимален. Похоже, что это добавляет довольно много административной нагрузки и требует дублирования IP-адресов для клиентов (мы в основном выдаем публичные адреса), а также требует больше настройки на маршрутизаторе клиента для разделения подсетей. MPLS также не использует маршруты BGP, так что не уверен, как это повлияет на ситуацию; вероятно, это сломает VPLS-туннели или MPLS VPN. Как насчет времени переключения при сбое? Нам важнее качество потока трафика, чем просто пропускная способность.
     
     
     
    pe1chl
    Guest
    #7
    0
    21.03.2021 08:54:00
    Да, я согласен, что было бы неплохо иметь маршрутизацию, зависящую от класса обслуживания. Я опубликовал свой ответ выше как копию того же ответа в другой теме, конечно, здесь он немного избыточен, потому что то, что я написал, в основном совпадает с тем, что вы уже сказали как нежелательное. Но я думаю, что когда вы принимаете решения по маршрутизации, основываясь только на классе обслуживания с локальной точки зрения, это приведет к неудаче, кроме самых тривиальных случаев (как вы изображали выше), когда между двумя конечными точками фактически всего два канала, и вам нужно только решить, какой из них использовать. Когда ваша сеть немного менее тривиальна, и, например, больше похожа на то, что показывает картинка IPANetEngineer, такие локальные решения о следующем хопе приведут к циклам маршрутизации! В этом случае неизбежно иметь отдельные таблицы маршрутизации для каждого класса обслуживания и строго придерживаться выбора правильной таблицы маршрутизации для каждого пакета. Но тогда вам действительно придется иметь дело с большой нагрузкой по поддержке двух различных конфигураций маршрутизации, и, возможно, вам даже придется использовать дополнительные вещи, такие как VLAN или другие формы туннелей, чтобы две конфигурации маршрутизации могли сосуществовать. В BGP можно иметь разные экземпляры, но я никогда не пробовал, что произойдет, если вы настроите 2 экземпляра, каждый с одним и тем же набором пиров. Будут ли 2 экземпляра хорошо сосуществовать и держать все отдельно, используя 2 набора AS-номеров, или будут ли пировые соединения жаловаться на неправильный AS-номер? Вероятно, второе. Так что это все равно потребует разных адресов на конечных точках для каждого пира. Это много работы, и одна маленькая ошибка вызовет большие проблемы.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры