krik_krak Опубликовано 11 ноября, 2019 · Жалоба Столкнулся с этой же проблемой на hAP ac2 ROS v6.45.7 Поднял EoIP туннель между двумя железками - добавил EoIP интерфейс и включил его в бридж, после чего стали отваливать сайты по ERR_TIMED_OUT Помогло это обсуждение. Как выяснилось, при настройках по-умолчанию MTU интерфейса EoIP-tunnel1 было установлено в 1458. Установил в 1500 и всё заработало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
n-k Опубликовано 7 февраля, 2020 · Жалоба On 11/11/2019 at 3:17 PM, krik_krak said: Столкнулся с этой же проблемой на hAP ac2 ROS v6.45.7 Поднял EoIP туннель между двумя железками - добавил EoIP интерфейс и включил его в бридж, после чего стали отваливать сайты по ERR_TIMED_OUT Помогло это обсуждение. Как выяснилось, при настройках по-умолчанию MTU интерфейса EoIP-tunnel1 было установлено в 1458. Установил в 1500 и всё заработало. Это не верное решение! При добавлении EoIP туннеля в Bridge туннель какого-то черта меняет mtu самому Bridge на mtu EoIP туннеля, который он тоже походу придумывает сам на лету при создании EoIP интерфейса, из этого и начинаются перекосы в работе! Нужно вернуть mtu 1500 бриджу руками (Жестко прописать), а дальше уже играться с mtu EoIP подбирая его под свои каналы, у меня к примеру с двух сторон 1458 шикарно работает и протаскивает 500+ мегабит на Hap ac2 с обеих сторон. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XGate Опубликовано 21 февраля, 2020 · Жалоба В 07.02.2020 в 05:08, n-k сказал: Это не верное решение! При добавлении EoIP туннеля в Bridge туннель какого-то черта меняет mtu самому Bridge на mtu EoIP туннеля, который он тоже походу придумывает сам на лету при создании EoIP интерфейса, из этого и начинаются перекосы в работе! Нужно вернуть mtu 1500 бриджу руками (Жестко прописать), а дальше уже играться с mtu EoIP подбирая его под свои каналы, у меня к примеру с двух сторон 1458 шикарно работает и протаскивает 500+ мегабит на Hap ac2 с обеих сторон. На самом деле все просто - MTU на bridge автоматически выставляется по наименьшему MTU из всех интерфейсов, объединенных этим самым bridge. Иначе говоря, поменяв MTU на eoip-тоннеле у вас автоматически изменится MTU и на бридже в целом (если, конечно, в этот бридж не входят другие интерфейсы с маленьким MTU). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 21 февраля, 2020 · Жалоба МТУ на бридже имеет смысл когда на него IP адрес вешаете для работы, если бридж только для объединения интерфейсов, например проброс ether порта через eoip туннель, это значение ни на что не влияет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
plastilin Опубликовано 22 августа, 2020 · Жалоба Здравствуйте. И все таки подскажите как правильно и какие побочки. Если имеем EoIP воткнутый в bridge, то MTU bridge становится таким же как MTU EoIP, в моем случае 1408. Выхватил проблему отваливающихся сайтов. Варианта решения проблемы нашел 2 и оба работают: 1. Повышение MTU bridge до 1500 2. Настройка изменения TCP MSS в цепочке Forward mangle Какой из этих вариантов правильней и какой предпочтительней? Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...