Jump to content
Калькуляторы

Нужно ли делать adjust tcp mss на pppoe-брасе? без nat

Есть bras, который выдаёт клиентам реальные ip, он же является пограничным маршрутизатором. Нужно ли делать adjust tcp mss? Частенько вижу такое в примерах по конфигурированию pppoe на cisco/linux. Ведь клиенты знают свой mtu, следовательно знают правильный tcp mss и при инициировании tcp-соединения mss должен согласоваться.

Share this post


Link to post
Share on other sites

Не нужно, более того - это у нас вызывало проблемы в виде падения скорости.

Share this post


Link to post
Share on other sites

а не возникает проблем с soho роутерами? ведь в этом случае клиент будет выбирать tcp mss исходя из mtu=1500 ?

Share this post


Link to post
Share on other sites

bos9

Как я понимаю, в этом случае adjust должна делать cpe-шка

Share this post


Link to post
Share on other sites

нужно, еще как нужно, ато кто его знает что у клиента за говнокомп или роутер. Проблем будет намного меньше если включить мсс

Share this post


Link to post
Share on other sites

100% надо, а то проблемы возникнут с мыльницами. И скорость поднимитса у глюканых мыльниц.

Share this post


Link to post
Share on other sites

Если у вас вланы не используются (или уверены что везде пролезет), можно настроить чтобы внутри туннеля было 1500 честных байт.

Share this post


Link to post
Share on other sites

Если у вас вланы не используются (или уверены что везде пролезет), можно настроить чтобы внутри туннеля было 1500 честных байт.

 

Мсье теоретик? Размер фрейма всё равно будет больше обычного(за счёт ppp encap) и не всё абонентское железо нормальное к этому отнесётся.

 

100% надо, а то проблемы возникнут с мыльницами. И скорость поднимитса у глюканых мыльниц.

 

Можно конкретные примеры cpe, которые по умолчанию не делают tcp mss adjust?

Share this post


Link to post
Share on other sites
Мсье теоретик? Размер фрейма всё равно будет больше обычного(за счёт ppp encap) и не всё абонентское железо нормальное к этому отнесётся.

Большинство железа пропускает вплоть до 1536 фреймы эзернета, даже если об этом нигде не написано, кроме датащита от чипа.

Share this post


Link to post
Share on other sites

Это путь внезапных граблей)

Share this post


Link to post
Share on other sites

Ivan_83

Давайте соревноваться "кто круче сделает через жопу" в другом месте. Тема чисто практическая, а не академическая.

Share this post


Link to post
Share on other sites

srg555

Можно конкретные примеры cpe, которые по умолчанию не делают tcp mss adjust?

Давно это было. Но по моему dlink, edimax. WRT54gl с dd-wrt вообще как то неадекватно себя вёл. Любил просто не подключатся.

Share this post


Link to post
Share on other sites

господа, внезапно видел недавно прикольный, но известный в мире трабл, связанный с mtu и mss.

 

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

"специалисты" к нему ходили 100500 раз, делали стандартные пляски с бубном - нихрена не разобрались.

Чуть иички себе не откусили...

Даже переустановка венды не помогла!

При этом пинги и трассировочки до сайта ходили....

Пришлось САМОМУ мне поднимать свою геморойную задницу и ехать на местность.

И так, внезапно не открывался контрольный сайтег с блек-джеком (без шлюх).

На местности были обнаружены:

длинк вайфай роутер дир-300 и ноут с вендой 7.

Я сразу подключлся мимо роутера своим чистым ноутом с XPюшой - все ок. Контрольный сайт открывается. Далее проверил свой ноут через вайфай юзерский - все ок. Потом проверил ноут клиента без роутера - все ок. Потом проверил ноут юзера с роутером, но с проводами (а не вайфай) - тоже все ок.

Потом трассировочка, телнет на 80 порт того сайта, затем большой пинг с запретом фрагментации, и тут внезапно ясно стало - что трабл с MTU.

Погуглил - таки да - в семере иногда на беспроводном фейсе нихрена лыжи не едут с макс mtu - тупо жестко 1500 и писец, хоть убейся.

Чтение сайта майкрософт по поводу сабжа выдержал секунд 40 - далее затошнило - ибо разрыв шаблонов и взаимоисключающие параграфы...

Вычислил макс размер пакета - постепенно уменьшая длину пинга. Вручную в семере вбил - лыжи поехали.

(почувствовал себя мегаодмином венды - CLI почти как Like a Cisco, только наоборот - нихера не похоже : )

 

**********

В теории хосты нормально снюхиваются и вычисляют узкое горлышко - тобишь одна из сторон отвечает особым icmp Ответом, шо мол - дятел, уменьши мту. Но, я погуглил и нашел заметки об "упоротых" админах - которые блокируют чуть менее чем полностью все типы icmp, кроме пингов - что вызывает кучу граблей в разных ситуациях...

Ну и еще эта венда - которая иногда - нипонятно почему - на безпроводном фейсе не хочет определять автоматом макс мту до хоста...

 

И тут я задумался - а сколько реально таких страдальцев клиентов может быть....

Погуглил и нашел правило для Тика:

 

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn

out-interface=ic action=change-mss new-mss=clamp-to-pmtu

 

(да - вы таки будете смеяться, но я юзаю Mikrotik RouterOS (5.13) + тазики на матерях интел, на процах iCore7 и винрарных сетевухах i82576 - ибо Тик и тазики стоят копейки - настраиваются за 5 минут и лопатят месяцами моих 12тыс физиков (останавливаются по причине 220, пылесосить, обновить на новые плюшки), пакеты не дропает, задержки 1ms - и я бы рад ваши цыски жуниперы редбэки поюзать и стать мегаодмином - но мне не дадут стока бабла, к тому же - "работает -не трогай!!!)

**********

Таки может вы еще будете смеяться, что юзаю биллинг Ideco АСР?

Кому-то он не нравиться, что "сам в себе" идет как монолитный дистр и ничего самому нельзя делать. А мне это нравится - устанавливается моментально из каропки сам со всеми нужными модулями как единое целое. И настраивается мышкой за 15 минут.

Я не хочу знать ни про какие ядра линагза, тюнинг sysctl, прерывания, зависимости, явы, питоны, перлы и прочие php.

И версия 3.4.4 шуршит и в ус не дует.

Могет я просто привык и не пробовал больше ничего - но "Работает - не трогай!!!" : )

(до 15 000 юзеров (условно) - рабочий проверенный биллинг (на большем к-ве не проверял))

Итого - если меня завтра переедет комбайн - любой студент 4-го курса факультета ИТ асилит MikroTik + ideco - есть доки, саппорт, сообщество. Нет никаких собственных хитрых костылей и "тюнинга"...

**************************************************

P.S. ответ на вопрос топик стартера - "да" : )

Edited by white_crow

Share this post


Link to post
Share on other sites

Если ТС не возражает, задам сопутствующий вопрос.

 

PC под Linux, для tcp mss adjust используется:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

 

В логи переодически падает куча сообщений вида:

 

xt_TCPMSS: bad length (41 bytes)
xt_TCPMSS: bad length (41 bytes)
xt_TCPMSS: bad length (41 bytes)
xt_TCPMSS: bad length (41 bytes)
xt_TCPMSS: bad length (41 bytes)
xt_TCPMSS: bad length (41 bytes)
xt_TCPMSS: bad length (41 bytes)
xt_TCPMSS: bad length (41 bytes)

 

Наколько я понимаю это связано с получением tcp с взведенным флагом SYN и длиной пейлоада отличной от нуля (в данном случае 1 байт данных).

Что делать? Забить? Фильтровать на входе или искать корни зла в собственной криворукости?

Share this post


Link to post
Share on other sites
Тема чисто практическая, а не академическая.

Чисто практически нужно было изначально включить TCPMSSFix и забыть.

 

 

В логи переодически падает куча сообщений вида:

Это вроде в старых ядрах линукса. Обновитесь или закоментируйте строку и пересоберите ядро.

Share this post


Link to post
Share on other sites

ведь в этом случае клиент будет выбирать tcp mss исходя из mtu=1500 ?

C какой такой радости-то?

Хотя да, если ручки не стоят задать на брасе MTU/MRU, в настройках демона, то клиент может и максимальный MTU получить...

 

Проблем будет намного меньше если включить мсс

Как показывает практика - проблем будет намного больше.

Share this post


Link to post
Share on other sites

C какой такой радости-то?

Хотя да, если ручки не стоят задать на брасе MTU/MRU, в настройках демона, то клиент может и максимальный MTU получить...

 

Клиент, поключенный напрямую, конечно получит правильный MTU. А вот если он подключен ч\з роутер (pppoe/pptp настроено на роутере), то ваш MTU получит только внешний интерфейс роутера, а сам клиент, подключенный к LAN, будет искользовать MTU 1500.

 

Это вроде в старых ядрах линукса. Обновитесь или закоментируйте строку и пересоберите ядро.

 

т.е. в новых версиях эти сообщения просто игнорируются или там нечто другое? Закоментировать и пересобрать - это вы имеете ввиду конкретную опцию ядра?

Edited by bos9

Share this post


Link to post
Share on other sites
т.е. в новых версиях эти сообщения просто игнорируются или там нечто другое? Закоментировать и пересобрать - это вы имеете ввиду конкретную опцию ядра?

Видимо да. Поищите по форуму, здесь уже это всплывало.

 

PS: я в потрохах линукса оч редко бываю :)

Share this post


Link to post
Share on other sites

Это вроде в старых ядрах линукса.

 

Да. Вы были правы. В свежих версиях проверка соответствия длины SYN пакета и длины tcp header'а осталась, а вот вывод в лог убрали. Видимо задолбал =)

http://forum.nag.ru/forum/index.php?showtopic=72265&view=findpost&p=672335

Share this post


Link to post
Share on other sites

Клиент, поключенный напрямую, конечно получит правильный MTU. А вот если он подключен ч\з роутер (pppoe/pptp настроено на роутере), то ваш MTU получит только внешний интерфейс роутера, а сам клиент, подключенный к LAN, будет искользовать MTU 1500.

И что? При попытке передать пакет больше, чем MTU ифейса роутера, роутер отправит клиенту ICMP сообщение о необходимости фрагментировать пакет.

Костыль-то нужен только в том случае, если где-то есть криво сконфигуреный файрвол, режущий ICMP ответы. Почитайте это к примеру.

Share this post


Link to post
Share on other sites

И что? При попытке передать пакет больше, чем MTU ифейса роутера, роутер отправит клиенту ICMP сообщение о необходимости фрагментировать пакет.

Костыль-то нужен только в том случае, если где-то есть криво сконфигуреный файрвол, режущий ICMP ответы. Почитайте это к примеру.

 

Cогласен! А что будет при попытке удаленной стороны отправить клиенту пакет превышающий MTU роутера? Дойдет ли до нее ICMP? А ситуация возможна, т.к. клиент шлет tcp mss 1460.

Share this post


Link to post
Share on other sites

А что будет при попытке удаленной стороны отправить клиенту пакет превышающий MTU роутера?

При входящем соединении что будет - неведомо, да и в 99% случаев это пользователя не волнует. При исходящем - такая ситуация невозможна, ибо снюхиваются обе стороны и устанавливают MSS исходя из того, сколько по сети пролезет без необходимости фрагментации.

Повторюсь, у нас на брасах нигде не стоит автоопределение MSS, и ни у одного из тысяч абонентов не было никаких проблем с этим. А когда пытались в свое время "улучшить" то, что и так работало - наткнулись на грабли в виде падения скорости.

Share this post


Link to post
Share on other sites

Повторюсь, у нас на брасах нигде не стоит автоопределение MSS, и ни у одного из тысяч абонентов не было никаких проблем с этим

А какие скорости даёте юзерам?

Share this post


Link to post
Share on other sites
и ни у одного из тысяч абонентов не было никаких проблем с этим

Интереснее происходит, когда внезапно отключаешь ajust mss.

Сразу всплывают клиенты с недонастроенными софтовыми шлюзами.

Напоролся на неделе на грабли (

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this