LINUX.ORG.RU
ФорумAdmin

MTU на ppp интерфейсах, я чего-то запутался

 , , ,


0

2

Во всяких инструкциях пишут, что «выравнивайте mtu для уменьшения фрагментации», но как выравнивать?

http://images.vfl.ru/ii/1548740672/747a33c5/25155649.png

Допустим есть у меня ПК который отправляет пакет в сеть, у него дефолтный MTU 1500.

На роутере, я выставляю MTU=1400 для ppp интерфейса и получается, что пакет будет биться на два.

Получается для нормальной работы мне необходимо на всех ПК уменьшать MTU заранее - звучит бредово. Bли я не понимаю чего то?

Deleted

Разбиранием/собиранием пакетов должен заниматься роутер, к которому подключены сети с разным MTU. Если ему от фрагментации пакетов плохеет ты конечно можешь навставлять костылей(выставив MTU на клиентах), попутно угробив простоту автонастройки клиентов по DHCP(MTU можно отдавать по DHCP, но мало кто из DHCP-клиентов не кладет на этот атрибут болт). Но лучше смени роутер на более производительный.

anonymous
()
Ответ на: комментарий от anonymous

Тогда зачем впринципе нужна возможность изменять MTU на ppp интерфейсе, если роутер всеравно режет-собирает пакеты?

Deleted
()
Ответ на: комментарий от Deleted

Тогда зачем впринципе нужна возможность изменять MTU на ppp интерфейсе, если роутер всеравно режет-собирает пакеты?

Потому что ppp может инкапсулироваться в другие протоколы и MTU соответсвенно будет разный

и откуда взялось mtu 1400?

najar
()
Ответ на: комментарий от Deleted

Где почитать про то какие резать можно, а какие нельзя? Желательно на русском.

Дело не в том, можно резать или нельзя. В зависимости от инкапсуляции у тебя получается разная величина пейлоада, для этого и нужен mtu - что бы сказать соседнему устройству какие пакеты пролезут а какие нет

najar
()
Ответ на: комментарий от najar

и откуда взялось mtu 1400?

Это для примера.

Deleted
()
Ответ на: комментарий от najar

Если берем L2TP без IPSec, получаем:

ip - 20bytes
udp - 8bytes
l2tp+ppp - 18 byte

1500-20-8-18=1454

Тогда мне надо нарезать пакеты уходящие в туннель по 1454bytes для наиболее оптимальной загрузки пакета? Правильно понял?

Deleted
()
Ответ на: комментарий от Deleted

Посчитал правильно, но рекомендую пощупать туннель пингом с DF-битом

najar
()

Если у Вас нигде не заблокирован icmp-протокол, то роутеры сами договорятся об оптимальном размере mtu, и руками данный параметр лучше не крутить. Подробнее можно посмотреть вот здесь, например.

Serge10 ★★★★★
()

Mtu туннеля по определению меньше mtu физического канала, если без потери производительности.

Не знаю кто и что там рекомендует, но лично могу рекомендовать только выравнивать пакеты целевого ПО по mtu целевого канала.

В общем либо приведи ссылку на сии рекомендации, что бы мы могли их дешифровать либо забей.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Более того, сиё практически не актуально в случае tcp, т.к. там подстройка размера окна и сегмента вшита в протокол.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

т.к. там подстройка размера окна и сегмента вшита в протокол.

Это все здорово, но работает только тогда, когда icmp-пакеты не заблокированы. Что, к сожалению, выполняется далеко не всегда :(.

Serge10 ★★★★★
()
Ответ на: комментарий от pon4ik

Причём тут icmp?

Посмотрите по ссылке, которую я выше привел, алгоритм согласования размера mtu. Вот цитата оттуда:

PMTU discovery – технология определения PMTU разработанная для уменьшения нагрузки на маршрутизаторы. 
Описана в RFC 1191 в 1988 году. Суть технологии заключается в том, что при соединении двух хостов 
устанавливается параметр DF (don’t fragment, не фрагментировать), который запрещает фрагментацию пакетов. 
Это приводит к тому, что узел, значение MTU которого меньше размера пакета, отклоняет передачу пакета и 
отправляет сообщение ICMP типа Destination is unreachable (Хост недоступен). К сообщению об ошибке 
прилагается значение MTU узла. Хост-отправитель уменьшает размер пакета и отсылает его заново. Такая 
операция происходит до тех пор, пока пакет не будет достаточно мал, чтобы дойти до хоста-получателя 
без фрагментации.
Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

MSS is sometimes mistaken for PMTU. MSS is a concept used by TCP in the Transport layer and it specifies the largest amount of data that a computer or communications device can receive in a single TCP segment. While PMTU is used by the IP layer and it specifies the largest packet size that can be sent over this path without suffering fragmentation.

pon4ik ★★★★★
()
Ответ на: комментарий от najar

С большой вероятностью - да. Разговор изначально был про то, что нужно выравнивать пакеты ПО на уровне его прикладного протокола, а не выравнивать значения mtu. И что в случае tcp на это можно забить, особенно если роутер умеет в QoS.

pon4ik ★★★★★
()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от pon4ik

но лично могу рекомендовать только выравнивать пакеты целевого ПО по mtu целевого канала.

Это не всегда возможно т.к. припредся очередной пользователь с аййфоном, подключится и что мне с ним делать?

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

Deleted
()
Ответ на: комментарий от pon4ik

Прошу прощения, не увидел, что Вы про MSS. Исходно в теме MTU обсуждали.

Serge10 ★★★★★
()

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

shashilx ★★
()
Ответ на: комментарий от Deleted

Издержки от фрагментации ещё не на каждый софт влияние дадут.

pon4ik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.