27.10.2018 10:57
maniak 7 2400 Источник

Что такое “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

Комментарии (7)


  1. Daleko
    28.10.2018 11:17
    #19293197

    Любопытно. А вот в мире серверов асимметричность наоборот много где нужна (см. Direct Server Return)…


    1. maniak Автор
      28.10.2018 11:28
      #19293251

      %)
      в общем случае, в асимметричной маршрутизации нет ничего плохого.
      в качестве примера для чистого R&S — глобальная маршрутизация в интернете как раз асимметрична.

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


  1. Henry7
    29.10.2018 03:20
    #19295509

    Это черновик вашего RFC или реализация уже готового проверенного решения?


    1. maniak Автор
      29.10.2018 08:34
      #19295731

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


  1. nkusnetsov
    29.10.2018 10:36
    #19296115

    Описаная проблема выглядит высосанной из пальца.

    «Что в этом плохого?
    Если все маршрутизаторы находятся в пределах одной 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». Оно и срабатывает при ассиметричном роутинге.
    Не надо изобретать велосипедов.


    1. maniak Автор
      29.10.2018 17:34
      #19298187

      По поводу PMTU & clamp-mss в целом согласен.
      Собственно, у нас так и сделано.

      >в дефолтном перечне правил фаервола микротика есть правило в цепочке forward
      в какой версии ROS?
      На 6.42.9 под x86 не наблюдаю.


      1. nkusnetsov
        30.10.2018 09:19
        #19300039

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