Comments 8
Любопытно. А вот в мире серверов асимметричность наоборот много где нужна (см. Direct Server Return)…
Это черновик вашего RFC или реализация уже готового проверенного решения?
И то и другое.
У коллеги webfox в продакте успешно поселилась реализация с использованием /30 IPv4 и OSPF.
У нас запланирована к внедрению реализация с BGP и IPv6.
У коллеги webfox в продакте успешно поселилась реализация с использованием /30 IPv4 и OSPF.
У нас запланирована к внедрению реализация с BGP и IPv6.
Описаная проблема выглядит высосанной из пальца.
Маршрутизаторы в вашей зоне ответственности должны поддерживать 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». Оно и срабатывает при ассиметричном роутинге.
Не надо изобретать велосипедов.
«Что в этом плохого?
Если все маршрутизаторы находятся в пределах одной 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». Оно и срабатывает при ассиметричном роутинге.
Не надо изобретать велосипедов.
По поводу PMTU & clamp-mss в целом согласен.
Собственно, у нас так и сделано.
>в дефолтном перечне правил фаервола микротика есть правило в цепочке forward
в какой версии ROS?
На 6.42.9 под x86 не наблюдаю.
Собственно, у нас так и сделано.
>в дефолтном перечне правил фаервола микротика есть правило в цепочке forward
в какой версии ROS?
На 6.42.9 под x86 не наблюдаю.
Написав «в дефолтном перечне правил фаервола микротика есть правило в цепочке forward», имел ввиду устройства маршрутизации «routerboard».
На CHR/PC/cAP дефолтный фаервол иной. Т.к. на CHR/PC неизвестно заранее сколько каких будет интерфейсов и куда они будут подключены, а у cAP задачи иные.
Для 90% случаев, две основные причины «загадочной проблемы» отсутствия связности: 1) нет маршрута 2) неправильная настройка фаервола.
На CHR/PC/cAP дефолтный фаервол иной. Т.к. на CHR/PC неизвестно заранее сколько каких будет интерфейсов и куда они будут подключены, а у cAP задачи иные.
Для 90% случаев, две основные причины «загадочной проблемы» отсутствия связности: 1) нет маршрута 2) неправильная настройка фаервола.
Sign up to leave a comment.
Лечим проблему FHRP asymmetric routing