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

[Daleko]

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

[pmb_it]

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

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

[Henry7]

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

[pmb_it]

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

[nkusnetsov]

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

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

[pmb_it]

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

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

[nkusnetsov]

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

[Henry7]

Для 90% случаев, две основные причины «загадочной проблемы» отсутствия связности: 1) нет маршрута 2) неправильная настройка фаервола.

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