Перейти к содержимому


- - - - -

Рекомендуемые значения величин Mtu/mru


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 10

#1 CTACb

CTACb

    Хранитель форума

  • Moderators
  • PipPipPipPipPipPipPipPip
  • 4 082 сообщений
  • Пол:Мужчина

Отправлено 03 Март 2007 - 22:46

Очень бы хотелось услышать авторитетное мнение господина slavon_net по этому поводу (но любые мысли на тему остальных форумчан также приветствуются). Суть вопроса заключается в следующем. У друга дома имеется два компьютера за *nix-like маршрутизатором. Естественно, на всех сетевых интерфейсах всех компьютеров, в том числе и роутера установлено значение mtu/mru по умолчанию, а именно 1500 байт. Соединение с Internet осуществляется через VPN посредством pppd. Естественно, что для ppp-пакета приходится устанавливать мЕньшее значение mtu для того, чтобы он мог быть успешно передан через ethernet. Так вот, вопрос первый - каким лучше устанавливать это значение? Вопрос второй - означает ли это, что при передаче больших файлов через VPN пакеты будут неизбежно фрагментированы, поскольку компьютеры за роутером ничего не знают о существовании VPN и формируют пакеты согласно их собственным настройкам mtu, т.е. 1500 байт? Вопрос третий - не приводит ли указанное обстоятельство к тому, что трафик, генерируемый таким пользователем будет больше, нежели пользователем непосредственно подключенным к VPN c Windows-компьютера? И если да, то насколько? Вопрос четвертый - что произойдёт, если не уменьшать значение mtu для pppd, а увеличить значение mtu для ethernet-интерфейса со стороны himki.net?

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

Сообщение отредактировал CTACb: 03 Март 2007 - 22:47


#2 sda00

sda00

    Завсегдатай

  • Members
  • PipPipPipPipPip
  • 591 сообщений

Отправлено 05 Март 2007 - 21:56

по большому счёту - хз, но imho (по очереди вопросов):
1. выставить на роутере mtu=1400 и то же на ppp0 (dsl0) интерфейсах машин за роутером наверное стоит (это типа дефолтное поведение M$ для pptp соединений)
3. уж как уважаемый Провайдер (и чем) считает трафф - сие есть тема для отдельного разговора
4. у тя палюбэ есть 2 интерфейса: dsl и eth, и они (imho) независимы (рулёж идёт на уровне kernel-a) - те ты сам себе можешь урезать eth хоть до нуля, при этом на dsl это ну никак не отразится. так каким образом изменение mtu на eth повлияет на dsl ? или я чушь порю? (по крайней мере как я экспериментировал - так и излагаю)
2. хз. бери роутер и смотри логи + логи на машинах за роутерами

#3 CTACb

CTACb

    Хранитель форума

  • Moderators
  • PipPipPipPipPipPipPipPip
  • 4 082 сообщений
  • Пол:Мужчина

Отправлено 05 Март 2007 - 22:18

Уважаемый sda00, по-моему мы друг друга не поняли.

Просмотр сообщенияsda00 (5.03.2007, 21:56) писал:

1. выставить на роутере mtu=1400 и то же на ppp0 (dsl0) интерфейсах машин за роутером
Стоп. На роутере имеется три интерфейса. eth0 смотрит домой (там к нему подключено два компа), eth1 смотрит в химки_нет, ppp0 смотрит на VPN-сервер. Домашние компы имеют ip вида 192.168.1.2 и 192.168.1.3, на них установлены форточки. Что именно и куда ты предлагаешь установить, поясни пожалуйста.

Цитата

3. уж как уважаемый Провайдер (и чем) считает трафф - сие есть тема для отдельного разговора
Мне это тоже интересно. Надо бы как-нибудь поднять соответствующую темку. Особенно интересно это на примере фрагментированных пакетов - как считаются они. Собственно поэтому я и заитересовался сабжем.

Цитата

так каким образом изменение mtu на eth повлияет на dsl ?
Дык TCP/IP-пакет с домашнего компа заворачивается в PPP, который в свою очередь заворачивается в GRE, который снова в свою очередь заворачивается в TCP, но с другими src/dst, который передается угадай через что? Правильно, через eth1. B если результирющий "будерброд" будет сильно больше, чем mtu для eth1, то он либо форагментируется, либо вообще не уйдёт.

Цитата

2. хз. бери роутер и смотри логи + логи на машинах за роутерами
Мммм.... Кто бы подсказал методику эксперимента. Т.е. что делать и куда смотреть.

#4 sda00

sda00

    Завсегдатай

  • Members
  • PipPipPipPipPip
  • 591 сообщений

Отправлено 05 Март 2007 - 22:36

На ppp0, как минимум, 1400 (я же у себя 1400 вбил везде, ибо unlim и так сказать ленив настраивать...)
Далее - у меня роутер сам поднимает ppp0 соединение. Соответственно для ppp0 всё, что он получает, заворачивается в 1400 и если где и происходит фрагментация/потери - то это на ветке домашний комп - роутер, что imho меня вообще не парит, (кстати спасибо за тему, вспомнил, что щас без роутера и поменял настройки на 1500 - получил TX packets: dropped:7).
Опять же imho - Linux Advanced Routing & Traffic Control HOWTO - это MUST к прочтению
http://gazette.linux...articles/lartc/
и палюбэ 1460 байт - это максимальная полезная нагрузка на пакет...

а насчёт методик - кому как. я смотрю на ifconfig. есть dropped - лезу в сислог и начинаю рыть, а нету - и слава Богу...

Сообщение отредактировал sda00: 05 Март 2007 - 22:49


#5 slavon_net

slavon_net

    Живёт на форуме

  • Moderators
  • PipPipPipPipPipPipPip
  • 1 474 сообщений
  • Пол:Мужчина
  • Город:Молодёжная -> DeepTown :)
  • Интересы:Asm, c++, unix, linux, palmos, perl, php, design

Отправлено 05 Март 2007 - 22:51

не обидишься если я не буду читать вашу переписку с sda?

в общем...
во первый ничего выставлять не надо... мру/мту сам упадёт при потерях пакетов... машины сами договорятся... потеряешь пару пакетиков в начале сессии... механизм вычисления давно разработан и работает сам...

для правильной обработки между разными сетевушками с разными значениями давно есть такая фича

iptables -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu

это правило само всё как надо перефрагментирует

#6 sda00

sda00

    Завсегдатай

  • Members
  • PipPipPipPipPip
  • 591 сообщений

Отправлено 05 Март 2007 - 23:10

СТАСЬ
хех... лучше how-to почитай (в частности 15.6 и 15.7)

#7 slavon_net

slavon_net

    Живёт на форуме

  • Moderators
  • PipPipPipPipPipPipPip
  • 1 474 сообщений
  • Пол:Мужчина
  • Город:Молодёжная -> DeepTown :)
  • Интересы:Asm, c++, unix, linux, palmos, perl, php, design

Отправлено 05 Март 2007 - 23:25

Просмотр сообщенияCTACb (3.03.2007, 22:46) писал:

вопрос первый - каким лучше устанавливать это значение?

тут почитай
http://www.cisco.com...080093f1f.shtml

Просмотр сообщенияCTACb (3.03.2007, 22:46) писал:

Вопрос второй - означает ли это, что при передаче больших файлов через VPN пакеты будут неизбежно фрагментированы, поскольку компьютеры за роутером ничего не знают о существовании VPN и формируют пакеты согласно их собственным настройкам mtu, т.е. 1500 байт?

GRE это туннель точка-точка... пакует в туннель твоя машина... роутеры которые стоят дальше содержимым GRE не парятся...

Просмотр сообщенияCTACb (3.03.2007, 22:46) писал:

Вопрос третий - не приводит ли указанное обстоятельство к тому, что трафик, генерируемый таким пользователем будет больше, нежели пользователем непосредственно подключенным к VPN c Windows-компьютера? И если да, то насколько?

Хм... если пакетов получается больше (только за счёт того, что ты сгенерил больше пакетов при уменьшении окна) то трафик увеличится ровно на размер ЗАГОЛОВКОВ деленных пакетов...

Просмотр сообщенияCTACb (3.03.2007, 22:46) писал:

Вопрос четвертый - что произойдёт, если не уменьшать значение mtu для pppd, а увеличить значение mtu для ethernet-интерфейса со стороны himki.net?

Тут сложный вопрос.. теоретически сеть 100Base не должна пропускать больше  1500... но за счёт поддержки в сети вланов и прочих  протоколов возможна небольшая инкапсуляция... т.е. пакет ненамного больше 1500 сквозь свитчи и роутеры пройдёт...

Но правильное решение -
iptables -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu
что сравняет размер окна...

#8 CTACb

CTACb

    Хранитель форума

  • Moderators
  • PipPipPipPipPipPipPipPip
  • 4 082 сообщений
  • Пол:Мужчина

Отправлено 06 Март 2007 - 09:49

slavon_net
Благодарю за небольшой экскурс в продвинутые сетевые технологии. Очень познавательно. Кое-что мне стало понятно. В частности, документ по той ссылке (http://www.cisco.com...080093f1f.shtml) многое прояснил. После прочтения текста я убедился в том, что правильно понимаю суть вопроса, и что такой вопрос действительно имеет место быть. Но возникли два новых сомнения (после прочтения сего документа).
Но прежде чем я изложу сомнения - просветите пожалуйста, в состав MTU/MRU уже входят заголовки пакетов, или нет? Другими словами, MTU=Payload+Headers или просто MTU=Payload ?
А теперь сомнения (речь далее пойдет о пакетах максимального размера, т.е. 1500 байт).
Сомнение №1.
Ситуация: пакет приходит от клиента на роутер R1. R1 понимает что не может его передать, потому что он на 24 байта больше чем можно протолкнуть через ethernet. Дальше два варианта. Либо флаг DF у этого пакета взведен, либо сброшен. Если он взведен, тогда пакет отбрасывается, передается icmp-сообщение пославшему этот пакет с требоваением "нарезать" их помельче, дальше всё идёт как надо. Рассмотрим второй вариант - DF сброшен. Тогда роутер R1 фрагментирует его и посылает двумя кусками на роутер R2. Собственно сомнение. Соберет ли роутер R2 эти два куска обратно в один пакет перед тем как передавать это все дальше, или так и отправит двумя кусками?

Сомнение №2.
Как считается трафик? По какому объему? По payload, по размерам пакетов вместе с заголовками, вместе с GRE, или до того как его "завернут" в GRE? Если пакеты фрагментированные и собираются/разбираются на роутере R2, то их считают до сборки или после? Если сформулировать вопрос кратко, то на каком этапе и по какому критерию происходит подсчет трафика из интернета к клиенту?

Теперь немного поцитирую тот самый документ.

Цитата

Solutions
One of these four solutions should solve the problem.
.....
Set the MTU on the Client's network interface to 1476 bytes, forcing the SMSS to be smaller, so packets won't have to be fragmented when they reach R2.
Собственно я сейчас именно так и поступаю. Правда, я их "зарезал" не по 1476, а по 1400 байт, но суть от этого не меняется. Однако читаем дальше:

Цитата

However, if you change the MTU for the Client, you should also change the MTU for all devices that share the network with this Client. On an Ethernet segment, this could be a large number of devices.
Вот этого-то я как раз и боялся. В этом случае, придётся менять MTU на всех домашних машинах. В-принципе, когда их две штуки - это не сложно. Но мне такой подход не очень нравится, ибо это некрасиво. А если этого не делать, то иногда появляются вот такие ошибки:

Цитата

read /dev/ppp: Value too large for defined data type
Ладно, читаем дальше:

Цитата

If the GRE tunnel runs over links that can have an MTU greater than 1500 bytes plus the tunnel header, then another solution is to increase the MTU to 1524 (1500 plus 24 for the GRE overhead) on all interfaces and links between the GRE endpoint routers.
Вот этот вариант мне уже больше нравится. Допустим, что slavon_net прав, и

Цитата

за счёт поддержки в сети вланов и прочих протоколов возможна небольшая инкапсуляция... т.е. пакет ненамного больше 1500 сквозь свитчи и роутеры пройдёт
Но у остальных-то пользователей стоит 1500 (по умолчанию). Т.е. если я даже установлю у себя MTU=1524, мне от этого сильно легче не станет. Пакеты в интернет перестанут фрагментироваться, но вот про DC, чувствуется, придется в этом случае забыть.

Вот так и получается - и так плохо, и так не лучше. Хотя с другой стороны, "работает - не трогай". Я не ставлю перед собой целью сэкономить эти несчастные 24 байта с одного пакета или сколько там получится. Мне интересно разобраться как сделать так, чтобы это всё работало оптимальным образом.

По поводу

Цитата

Но правильное решение -
iptables -A FORWARD -o ppp0 -j TCPMSS --clamp-mss-to-pmtu
что сравняет размер окна...
Это всё, конечно, хорошо. И, видимо, так я и поступлю. Но - это работает только для TCP. А есть еще UDP. Конечно, львиная доля трафика идет через HTTP, но ИМХО это решение нельзя называть правильным. Потому что оно всё же для распространяется только для частного случая, хотя и решает большинство проблем.

И еще. slavon_net, ты по-моему путаешь понятия окна протокола TCP (tcp window) и максимальный размер сегмента (Maximum Segment Size, MSS). Насколько я знаю, это вещи разные и друг с другом слАбо связаны. Я понял те мысли, которые ты хотел до меня донести (еще раз спасибо за ответ, кстати). Но всё-же было бы грамотнее выражаться точным техническим языком и называть вещи своими именами.

#9 slavon_net

slavon_net

    Живёт на форуме

  • Moderators
  • PipPipPipPipPipPipPip
  • 1 474 сообщений
  • Пол:Мужчина
  • Город:Молодёжная -> DeepTown :)
  • Интересы:Asm, c++, unix, linux, palmos, perl, php, design

Отправлено 06 Март 2007 - 09:59

MTU=Payload+Headers

>Соберет ли роутер R2 эти два куска обратно в один пакет перед тем как передавать это все дальше, или так и отправит двумя кусками?
Если там размер "окна" больше и роутер об этом знает - то соберёт

>на каком этапе и по какому критерию происходит подсчет трафика из интернета к клиенту?
Трафик считается вместе с заголовками, но без GRE. К моменту подсчёта GRE инкапсуляция уже снимается.

>это работает только для TCP
Для ICMP момент фрагментации описан. Для UDP у тебя не гарантируется доставка пакета, поэтому и парится тебе не нужно (да и UDP обычно в связи с этим редко больше 150-200). Остаётся только TCP где доставка и фрагментация весит на роутере, поэтому только для него и делается -j TCPMSS --clamp-mss-to-pmtu

По поводу окна - я имел введу не tcp окно, а тупо окно - т.е. дырка в которую влезает опеределённый пакет, а больший не влезает =) извини, что запутал, сообщение писал после 5 минут как проснулся =)

#10 CTACb

CTACb

    Хранитель форума

  • Moderators
  • PipPipPipPipPipPipPipPip
  • 4 082 сообщений
  • Пол:Мужчина

Отправлено 06 Март 2007 - 10:20

Просмотр сообщенияslavon_net (6.03.2007, 09:59) писал:

>на каком этапе и по какому критерию происходит подсчет трафика из интернета к клиенту?
Трафик считается вместе с заголовками, но без GRE. К моменту подсчёта GRE инкапсуляция уже снимается.
Сейчас снова придерусь к ответу :lol:. Это наверное для ситуации когда пакет идет по пути клиент -> интернет. А я спрашивал когда наоборот :lol:. Но я тем не менее понял, можно дальше не разжевывать :lol:.

Просмотр сообщенияslavon_net (6.03.2007, 09:59) писал:

извини, что запутал, сообщение писал после 5 минут как проснулся =)
Да, в-общем, не особо запутал. Я так и понял :lol:. Админы спят в гнезде ? :P

Итак, подытоживая тему. Штоб всё работало как надо:
1. Используем правило TCPMSS (интересно, а что делать если аппаратная железка не понимает такого правила?).
2. Ставим MTU=1476 для PPP.

Правильно?

#11 slavon_net

slavon_net

    Живёт на форуме

  • Moderators
  • PipPipPipPipPipPipPip
  • 1 474 сообщений
  • Пол:Мужчина
  • Город:Молодёжная -> DeepTown :)
  • Интересы:Asm, c++, unix, linux, palmos, perl, php, design

Отправлено 06 Март 2007 - 10:35

Просмотр сообщенияCTACb (6.03.2007, 10:20) писал:

Итак, подытоживая тему. Штоб всё работало как надо:
1. Используем правило TCPMSS (интересно, а что делать если аппаратная железка не понимает такого правила?).
2. Ставим MTU=1476 для PPP.

1. Да. Циска сама это делает.
2. Ну можно конечно поставить, но вообще-то нада капнуть инет... по идее ppp должно само увидеть размер оптимальный... на винде клиент опередяет сам... да и у себя на линах я не выставлял явно mtu/mru




Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных