IPv6: использование ссылки mtu больше, чем mtu маршрута по умолчанию

При настройке локальной сети IPv6 может быть желательно использовать объявления маршрутизатора, чтобы объявить MTU канала со стандартными 1500 байтов или что-то большее, чтобы разрешить использование гигантских кадров, возможно, 9000. Это позволит связи между хостами в локальной сети использовать самый большой кадры возможны. Если маршрут по умолчанию к Интернету IPv6 должен проходить через туннель типа 6in4, MTU обычно составляет 1480 или 1472, если используется PPPoE.

Связь между узлами ЛВС должна быть непрерывной, но обычная цепочка событий в трафике по маршруту по умолчанию будет вести себя по-другому. Во время квитирования для большинства соединений первый пакет, содержащий значительный объем данных, почти всегда будет больше, чем MTU маршрута по умолчанию, побуждая маршрутизатор отбросить пакет и отправить пакету ICMPv6 слишком большое сообщение ( тип 2). Я предполагаю, что большинство операционных систем кэшируют результаты обнаружения MTU пути по адресу назначения, и поэтому это взаимодействие будет происходить почти со всеми соединениями по умолчанию. Этот обмен должен занимать не более десятков миллисекунд, поэтому я не ожидаю, что он вызовет значительные проблемы с производительностью.

Вопрос заключается в следующем: считается ли этот тип конфигурации наилучшей практикой? Является ли предпочтительным использование MTU канала, который равен (или меньше) MTU пути маршрута по умолчанию? Есть ли документация для этого?

                    LAN          WAN

hostA -----\                     v4 WAN Link / 6in4 tunnel
            \  MTU 9000            MTU 1500     MTU 1480
             |---------- router ------------------------  -  -  -
            /                    IPv4 Internet, 6in4 endpoint -->
hostB -----/

          <<< router adv
                  prefix
                   RDNSS
                MTU 9000
                     etc

Example TCP connection:

TCP(SYN, 94 bytes)-------------------------------------------->
<----------------------------------------TCP(SYN/ACK, 86 bytes)
TCP(ACK/PSH, 1635 bytes)---X
<--------ICMP(too big, MTU=1480)
TCP(ACK/PSH, 1480 bytes)-------------------------------------->
...
Источник

2 ответа

Я думаю, что такая установка имеет смысл. Между клиентами и шлюзом по умолчанию будет много сообщений Packet-Too-Big (PTB), но когда вы используете jumbo MTU в вашей локальной сети, вы, вероятно, делаете это, потому что в любом случае в локальной сети много трафика, который может извлечь из этого пользу., Несколько дополнительных пакетов даже не будут заметны.

Что я вижу, так это то, что некоторые потребительские CPE отправляют размер MTU 1480 (или 1472 и т. Д.) В объявлении маршрутизатора. Влияние на трафик в локальной сети будет не таким значительным (максимум, как 1,9%), и оно предотвратит сообщения PTB между шлюзом по умолчанию и клиентом, по крайней мере, хотя они могут все еще приходить по ссылкам в Интернете, которые еще меньше. Это зависит от ваших приоритетов.

Я лично всегда оптимизировал бы сеть и вообще не беспокоился о сообщениях PTB.

Источник

Я думаю, что MTU должен быть таким же, как у ссылки, и ничего больше.

Предполагать/оптимизировать более низкий MTU за пределами вашего локального канала - это преждевременная оптимизация, IMO. Фактически, вы наносите вред всем местным связям.

Любая ОС, будь то IPv4 или v6, будет правильно понимать уменьшенный MTU для конечной точки и не будет генерировать PTB (если это было для v6) для каждого отправляемого пакета, но только один раз при настройке нового соединения.

По понятным причинам - PMTUD в любом случае тоже должен работать.

Кроме того, для IPv6 MTU, объявленного через параметры объявления RA / Router, в RFC 4861 указано, что MTU — это MTU канала… а не следующего перехода или чего-то еще. Я думаю, это тоже очень ясно.

Если вы хотите оптимизировать, используйте ограничение MSS на маршрутизаторе, который я бы посоветовал.

Источник
Другие вопросы по тегам