Лечим проблему FHRP asymmetric routing

    Что такое “FHRP asymmetric routing”?


    Состояние маршрутизации, при котором трафик в пределах одной сессии уходит через один маршрутизатор FHRP(VRRP/HSRP) master, а возвращается — через второй.


    image


    Что в этом плохого?


    Если все маршрутизаторы находятся в пределах одной LAN — скорее всего, ничего.
    Проблемы начинаются, если сетевая топология выглядит так:


    image


    1. MTU discovery — if the smallest MTU of the two paths differ, end-point MTU path discovery could result in a largest of the two MTU, which in turn will result in dropping of maximum size packets. For example, if one path goes through a VPN tunnel and the other does not, the VPN tunnel will have a smaller MTU. ping will work fine, but transferring large files will fail consistently.
    2. Connectivity trouble shooting will be more difficult if one of the two path is broken but the other is not. Good old «traceroute» will be no help at all, as it will not be able to detect the reverse path intermediate points, unless it is exercised from both sides of the connection, which requires an out-of-band management channel.

    Источник


    Почему так получается?


    У вышестоящего маршрутизатора (core-r-1) отсутствует информация о ролях нижестоящих маршрутизаторов в FHRP.


    Решение о выборе маршрута принимается автономно, исходя из метрик протокола динамической маршрутизации или PBR.


    Как это исправить?


    С точки зрения прохождения трафика: трафик должен уходить и возвращаться через тот же маршрутизатор и VPN-туннель


    image


    С точки зрения маршрутизации:
    Вышестоящие маршрутизаторы должны получать информацию о состоянии FHRP.


    Например, маршрут к подсети с конечными устройствами при нормальном развитии событий должен анонсироваться только FHRP-мастером.


    Как это работает?


    image


    Тестовый стенд (GNS3, MikroTik, BGP, VRRP).


    image


    1. Ссылка для скачивания
    2. Router credentials:
      A. Login: admin
      B. Pass: нет

    Бонус для тех, кто дочитал до конца


    На самом деле, использовать 100500 выделенных подсетей /30 IPv4 не обязательно.
    Для решения задачи могут быть использованы динамические IPv6 link-local адреса, что сильно упрощает первичное развертывание.


    Решение (в реализации для MikroTik RouterOS) выглядит следующим образом:
    image


    © Идея — webfox, статья и сборка стенда — maniak

    • +13
    • 4.5k
    • 8
    Share post

    Similar posts

    Comments 8

      0
      Любопытно. А вот в мире серверов асимметричность наоборот много где нужна (см. Direct Server Return)…
        0
        %)
        в общем случае, в асимметричной маршрутизации нет ничего плохого.
        в качестве примера для чистого R&S — глобальная маршрутизация в интернете как раз асимметрична.

        но есть нюансы, зависящие от условий конкретного продакта, которые могут испортить всю малину )

        0
        Это черновик вашего RFC или реализация уже готового проверенного решения?
          0
          И то и другое.
          У коллеги webfox в продакте успешно поселилась реализация с использованием /30 IPv4 и OSPF.
          У нас запланирована к внедрению реализация с BGP и IPv6.

          0
          Описаная проблема выглядит высосанной из пальца.
          «Что в этом плохого?
          Если все маршрутизаторы находятся в пределах одной LAN — скорее всего, ничего.
          Проблемы начинаются, если сетевая топология выглядит так»

          Маршрутизаторы в вашей зоне ответственности должны поддерживать PMTU-Discovery. Для этого надо, как минимум, не запрещать «на всякий случай все icmp». Хотябы в пределах LAN+VPN. На крайний случай, mtu можно установить вручную и не забывать дополнительно корректировать tcp-mss.
          Пакеты отлично пройдут по ассиметричным маршрутам, лишь бы админ не наколхозил с SRC-NAT/DST-NAT. Много раз я видел «шедевры» типа "/ip firewall nat add chain=src-nat action=masquerade".

          В случае колхоза с nat и firewall, связь вполне закономерно развалится — в дефолтном перечне правил фаервола микротика есть правило в цепочке forward, «drop» для пакетов принадлежащих соединению со статусом «invalid». Оно и срабатывает при ассиметричном роутинге.
          Не надо изобретать велосипедов.
            0
            По поводу PMTU & clamp-mss в целом согласен.
            Собственно, у нас так и сделано.

            >в дефолтном перечне правил фаервола микротика есть правило в цепочке forward
            в какой версии ROS?
            На 6.42.9 под x86 не наблюдаю.
              0
              Написав «в дефолтном перечне правил фаервола микротика есть правило в цепочке forward», имел ввиду устройства маршрутизации «routerboard».
              На CHR/PC/cAP дефолтный фаервол иной. Т.к. на CHR/PC неизвестно заранее сколько каких будет интерфейсов и куда они будут подключены, а у cAP задачи иные.
              Для 90% случаев, две основные причины «загадочной проблемы» отсутствия связности: 1) нет маршрута 2) неправильная настройка фаервола.
                0
                Для 90% случаев, две основные причины «загадочной проблемы» отсутствия связности: 1) нет маршрута 2) неправильная настройка фаервола.

                Нет. Это следствие.
                Причиной является крайняя, гипертрофированная некомпетентность так называемого инженера, который настраивает сетевое оборудование.

          Only users with full accounts can post comments. Log in, please.