Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Как настроить MTU на UAP?, UniFi Network
 
Продолжение темы: http://community.ubnt.com/t5/UniFi/Cloud-server-Unifi-AP-quot-Disconnected-quot/m-p/850032#U850032. У меня UAP был в состоянии "отключено" на объекте клиента с PPPoe ADSL (MTU около 1400). Я вручную установил MTU на всех UAP в 1412, и всё, кажется, работает отлично. НО... настройки MTU на UAP после перезагрузки возвращаются к 1500... так как же сделать это изменение постоянным?
 
Прилагаю. Вариант 26 не запрашивается.
 
Было бы интересно посмотреть захват трафика, чтобы понять, почему wap не соблюдает mtu / mss роутера.
 
Эх, печально, что Unifi UAP не использует опцию DHCP interface-mtu постоянно.
 
Похоже, я тоже столкнулся с этой проблемой после того, как недавно перевели сайт на FTTH с PPPoE у Century Link. Я, честно говоря, не особо опытный в продуктах Ubiquiti, но после пары часов "что за черт происходит" понял, что дело в UAP-AC-Pro. Установка меньшего MTU на интерфейсе br0 решила проблему. Роутер, который обеспечивает WAN для этого сайта, — ERX, MTU на PPPoE — 1492, и я установил mss-clamping на 1412. (Кажется, "все остальное" работает нормально после перехода на PPPoE). Сейчас я использую bridging к модему, предоставленному CL, но планирую убрать его на этой неделе и перейти на конфигурацию VIF 201. Могу предоставить tcpdump'ы или любую другую сетевую информацию в "сломанном" или рабочем состоянии.

UAP-AC: 3.8.3.6587
ERX: 1.9.1

Кстати, этот сайт — отличный ресурс, и я ценю все время, которое пользователи и сотрудники UBNT тратят на ответы на вопросы.

Спасибо!
 
Точно мои мысли. Мы так и не смогли решить проблему с настройками MTU/MSS Clamping. Похоже, у нас еще какая-то странность с DNS на этих IPsec сайтах. Судя по всему, проблема только с обнаружением Unifi (насколько нам известно), так как зайти по SSH к устройствам все еще можно, если ввести IP-адрес контроллера для inform, то все работает нормально. Я пока что нашел временное решение для связи Unifi устройств с контроллером (так как на этих сайтах нет USG), пока не разберемся, что происходит. В общем, просто указал IP-адрес контроллера в качестве override для inform, вместо использования hostname. Продолжайте…
 
Для таких новичков, как я, вот что нужно сделать, чтобы создать файл. printf "ifconfig br0 mtu 1420" > profile
Сохранить.
 
Точно мои мысли.
 
Тот факт, что вы ещё не заметили проблему, не означает, что её уже не было. Ещё раз, оконечные устройства не должны нуждаться в обработке разных размеров MTU, кроме 1500, если они активно не используют протоколы, которые это меняют, например, VLAN, PPTP и так далее...
 
Ну да, похоже, уже появились вопросы о том, действительно ли MSS Clamping работает здесь. И стоит ли нам просто зафиксировать размер MTU на WAN-интерфейсе на 1400 или что-то вроде того. Раз у нас не было других проблем до этого, то UniFi оборудование стало первым признаком. У нас была бы возможность использовать DHCP Options для установки размера MTU у клиентов, но раз наши UniFi свитчи и APs имеют статические адреса, то это, конечно, не сработает.
 
Тогда лучше зафиксируйте MSS на роутере, чтобы он совпадал с MTU туннеля. В идеале, устройства внутри вашей сети вообще не должны сталкиваться с чем-то отличным от MTU 1500.
 
Видим то же самое, как и другие сказали, на всех наших сайтах после того, как перешли с управляемой MPLS-сети на управляемую IPSec-WAN. Перезагрузка временно решит проблему с устройством (AP/Switch), которое отображается как отключенное. При подключении по SSH к отключенному устройству видно, что оно не может разрешить Inform URL, хотя мы и можем пропинговать Inform URL с устройства. Всё это, вероятно, из-за накладных расходов IPSec и шифрования, поскольку начинает происходить фрагментация всего, что превышает 1408.
 
Я это уже делал, но после изменения некоторых настроек и активации всё сбросилось к заводским настройкам. Могу попробовать еще раз, но было бы здорово, если бы был официальный способ это сделать.
 
Посмотри мой пост выше...https://community.ui.com/questions/7c856157-12a6-42c4-baf8-f9c99022df6c#comment/9d606655-d6fb-4f41-b7aa-e6f3bec55385
 
У меня та же проблема, на всех наших DSL-соединениях у основного провайдера я могу получить соединение только при ручной установке MTU на 1412 или меньше. MSS Clamping на роутере вообще не работает. Было бы здорово иметь возможность настроить MTU, тогда я бы смог реально использовать контроллер в облаке.
 
Кто-нибудь уже подавал заявку на исправление бага? Кажется, логичнее в конечном итоге что-то подобное исправить, чем ковыряться с этим! Уверен, @UBNT-jeff или другие разработчики прошивки будут рады узнать об этом, чтобы, знаете, исправить! Обходные пути – отличные временные решения, но не останавливайтесь на этом – дайте им знать, чтобы в конечном итоге обходные пути не нужны были!
 
К сведению… Только что обновил один из своих APs с версии 3.4.18.3464 до 3.7.5.4969, и настройки MTU на br0 сохранились.
 
Работает, спасибо. Моя проблема была в том, что при сбое сети мы используем GRE через IPSEC туннели, у которых уменьшен MTU. В остальном все хорошо, но общение с контроллером не работало – информ не проходил. Вместо того, чтобы уменьшать MTU всего устройства, я уменьшил только Br0 – интерфейс, который устройство использует для общения с контроллером. Было бы неплохо, если бы Ubiquity предоставили нам эту возможность для центральной конфигурации, чтобы мне не приходилось возиться с каждым устройством в моих филиалах, у которых может быть эта сцена сбоя сети с GRE через IPSEC. BZ.v3.4.18# cat /etc/persistent/profile
ifconfig br0 mtu 1400
BZ.v3.4.18#
 
Можешь, пожалуйста, подробнее рассказать, как ты сделал файл и сохранил его навсегда?
 
@r4m3u5, ограничение TCP MSS мне не помогло. 😰
Страницы: 1 2 След.
Читают тему (гостей: 1)