http://mikrotik.moscow Новое в теме EoIP и MTU форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Fri, 31 Jul 2026 04:09:57 -0400 EoIP и MTU RouterOS в форуме RouterOS.
Если я правильно помню... Думаю, между двумя удалёнными mikrotiks можно настроить защищённый ipsec, а внутри ipsec создать защищённый eoip-туннель. В итоге получится что-то с двойным шифрованием пакетов при передаче через публичный интернет и, возможно, с более широкими возможностями по MTU.
10.04.2025 01:12:00, TomjNorthIdaho.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423507 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423507 Thu, 10 Apr 2025 01:12:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Я подозреваю и предлагаю, что для затронутого TCP-трафика не работает PMTUD (Path MTU Discovery — определение максимального размера передачи пути). Нельзя это проверить, просто пингуя через ICMP. Если tcpdump на ESXi не показывает ICMP, запусти сниффер на Mikrotik, как я изначально советовал. Но если tcpdump на ESXi показывает, что TCP-пакеты размером 1500 байт или больше неоднократно отправляются роутеру для какого-то адреса за туннелем, это уже серьёзный признак такой проблемы.

TCP обычно ставит флаг do-not-fragment на все отправляемые пакеты, потому что эффективнее разбивать полезную нагрузку на несколько маленьких пакетов, чем фрагментировать каждый большой. Если роутер получает пакет с установленным флагом do-not-fragment, он подчиняется и просто отбрасывает такой пакет, вместо того чтобы пересылать его по частям, и уведомляет отправителя об этом.

Получив уведомление, отправитель уменьшает количество необработанных данных в буфере и посылает их снова, снова с тем же флагом do-not-fragment. Так размер сегмента (количество полезных байт, которое можно отправить в одном пакете) постепенно уменьшается до самого маленького MTU по пути к точке назначения. Этот процесс и называется PMTUD.

Если отправитель не получает это уведомление, или игнорирует его, он продолжает подряд бить пакетами такого же размера с флагом do-not-fragment, пока сессия не упадёт из-за таймаута повторной передачи.

Другой распространённый способ решить эту проблему — использовать правило mangle с action=change-mss в цепочке forward, чтобы изменить MSS (Maximum Segment Size) в SYN-пакетах, которыми TCP-клиент и сервер информируют друг друга о максимально возможном размере данных в пакете, который их буферы могут обработать. Однако некоторые TCP-стэки «считают себя умнее» и игнорируют полученное значение MSS, поэтому этот метод не решает проблему в 100% случаев.
09.04.2025 20:05:00, sindy.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423506 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423506 Wed, 09 Apr 2025 20:05:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Не знаю. Фрагментация и дефрагментация пакетов работают корректно. Если я выставляю MTU 1500 на vCenter и отправляю ping -s 1472 -4 -M на remote_esx_IP, приходит ответ. Правила фаервола очень простые: немного входящего трафика, немного форварда. Неправильное правило должно приводить к сбросу пакетов для всех видов связи, но всё работает.

ПРИМЕЧАНИЕ: Если я выставляю MTU 1500, всё работает, но, например, если включаю виртуальную машину, она запускается, а в vCenter вместо статуса «Завершено» отображается «Включение виртуальной машины» и 100%. Правильного отклика нет. Если бы у меня были неправильные правила фаервола, я бы вообще не смог ничего сделать с ESXi.

Если установить MTU 1300 на vCenter, всё работает без проблем. И это случилось после замены Mikrotiks.

ПРИМЕЧАНИЕ 2: Веб-консоль тоже не показывается. Это был хороший момент, чтобы подобрать максимально возможный MTU — и им оказался 1402. В любом случае я попытался залогировать ICMP-пакеты на Mikrotiks и ESXi (vCenter по неизвестной причине не показывает ICMP-пакеты в tcpdump), и ни одного упоминания о фрагментированных пакетах нигде не было.
09.04.2025 11:25:00, Alois7.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423505 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423505 Wed, 09 Apr 2025 11:25:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Можно прослушивать оба конечных устройства туннеля, и вы должны увидеть пакеты, поступающие на одно из них, которые больше, чем MTU IPIP-туннеля, из-за чего устройство не может их переслать и отправляет обратно отправителю ICMP-сообщение «фрагментация необходима, MTU xyz». Однако отправитель либо не получает эти ICMP-уведомления, либо игнорирует их. Корень проблемы может заключаться в неправильных правилах брандмауэра или сбоях в TCP-стеке. Wireshark поможет вам подробно проанализировать содержимое ICMP-пакетов, но обычно достаточно просто видеть их в прослушивании.
08.04.2025 18:08:00, sindy.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423504 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423504 Tue, 08 Apr 2025 18:08:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Пока не было времени разобраться. @tdw Трёхочковый бросок. vlan-filtering с BCP работает отлично. Только что проверил на v718. Не понимаю, как я мог пропустить это в списке изменений.
08.04.2025 11:18:00, nichky.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423503 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423503 Tue, 08 Apr 2025 11:18:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Итак, продолжим. Я перенастроил соединение. Сначала создаётся IPSec, поверх него — IPIP-туннель, и маршрутизируются сети. По сути, это та же конфигурация, что и раньше. Но vCenter не может установить стабильное соединение с ESXi. После снижения MTU всё работает. Вот в чём отличия: старые роутеры — 1100AHx4 и 4011, с более старой версией ROS — 7.6; поверх IPSec был EoIP-туннель. Новые роутеры — CCR2004 и CCR2116 с ROS 7.18.2 (та же проблема была с 7.16). vCenter — единственный, кто теряет соединения. Даже могу пинговать с MTU больше 1500, и фрагментация проходит нормально. HTTPS-сервисы работают без сбоев. Есть идеи, что ещё проверить или что может быть не так?
08.04.2025 08:04:00, Alois7.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423502 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423502 Tue, 08 Apr 2025 08:04:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Потому что с одной стороны это лучшее решение, а с другой — худшее. И нет универсального варианта для всех случаев из-за количества некомпетентных сетевых администраторов. TCP изначально создан для автоматической подстройки размера пакета под самый маленький MTU на пути между клиентом и сервером. Так он максимально эффективно использует пропускную способность и ресурсы маршрутизации, разбивая данные на оптимальные куски ещё у источника.

Если же принудительно задать MTU равным 1500, а реальный минимальный MTU на пути меньше этого значения, каждый пакет, превышающий минимальный MTU, придётся фрагментировать. Это влечёт за собой две неприятные проблемы:

1. Дальше по пути пакет уже считается как два отдельных, из-за чего нагрузка по количеству пакетов на маршрутизаторы удваивается, а соотношение полезной нагрузки к накладным расходам ухудшается, поскольку у каждого фрагмента свой IP-заголовок (а иногда и Ethernet-заголовок).
2. Если какой-то маршрутизатор на пути сбрасывает не первые фрагменты (что случается удивительно часто, частично из-за неправильной настройки правил файрвола), полный пакет не собирается на приёмной стороне и фактически теряется целиком.

Так что если вы выставляете MTU 1500 на туннельном интерфейсе, вы удваиваете количество пакетов и добавляете лишние накладные расходы уже у себя на маршрутизаторе (потому что пакет с полезной нагрузкой 1500 вместе с накладными туннеля превышает 1500 интерфейса отправки и его придётся там же фрагментировать), но при этом соединение всё равно работает, даже если на пути между клиентом и сервером сломан Path MTU Detection (чаще всего из-за непрофессиональных админов, полностью блокирующих ICMP ради «безопасности из-за секретности»).

Однако это работает, только если не сбрасываются не первые фрагменты. То есть, если вам «повезёт», вы почините соединение к тем серверам, где PMTUD не работает, но при этом сломаете связь с теми, у кого на пути сбрасывают не первые фрагменты.
15.03.2025 16:05:00, sindy.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423501 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423501 Sat, 15 Mar 2025 16:05:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Спасибо. Каждый раз, когда я спрашивал про MTU в туннеле, всегда советовали ставить MTU на 1500. Так почему бы это не сделать настройкой по умолчанию с возможностью менять её по необходимости?
15.03.2025 15:48:00, Alois7.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423500 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423500 Sat, 15 Mar 2025 15:48:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Просто установи свойство mtu для туннеля IPIP на 1500... он сможет отлично справиться с необходимой фрагментацией и дефрагментацией (с тороны приёма).
14.03.2025 15:55:00, mkx.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423499 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423499 Fri, 14 Mar 2025 15:55:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
У меня еще один вопрос. Я настроил туннель IPIP поверх IPsec. Фактический MTU — 1402. Нужно ли вручную ставить 1500 или оставить как есть? Сейчас я не переключал трафик с EoIP, чтобы успеть подготовиться. Спасибо за ответ.
14.03.2025 15:45:00, Alois7.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423498 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423498 Fri, 14 Mar 2025 15:45:00 -0400 RouterOS EoIP и MTU RouterOS в форуме RouterOS.
Привет, у меня проблемы с филиалом. Я заменил 1100AHx4 на CCR2116 (7.17.2) и перенастроил VPN, теперь там EoIP с IPSec. И столкнулся с проблемами подключения vCenter к ESXi в филиале (два сервера). Постоянно таймауты и разрывы соединения. Я пытался поместить их в ту же VLAN, что и vCenter (добавил эту VLAN в мост), чтобы исключить проблемы с фаерволом, но безуспешно. На сайте Broadcom видел, что у кого-то была похожая проблема, и помогло снижение MTU на VPN (https://community.broadcom.com/vmware-cloud-foundation/discussion/not-able-to-add-remote-esxi-host-to-vcenter), поэтому я пробовал 1200, 1300 и 1500, и похоже, что на одном ESXi стало лучше с MTU 1200, но другой так и не подключается. Старая и полностью рабочая конфигурация была IPsec поверх EoIP с маршрутизируемыми сетями. Новая конфигурация — прямой EoIP с включённым IPsec, а интерфейс EoIP добавлен в мост вместе с VLAN. Сети по-прежнему маршрутизируемые, но теперь при желании можно напрямую мостить некоторые VLAN. Что ещё стоит попробовать? Заранее спасибо за помощь!
23.02.2025 10:01:00, Alois7.]]> http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423497 http://mikrotik.moscow/forum/forum57/88105-eoip-i-mtu/message423497 Sun, 23 Feb 2025 10:01:00 -0500 RouterOS