Точно, когда выполняется PMTUD? (Обнаружение пути MTU)

В дискуссиях, которые вызвали другие вопросы на этом сайте , я понял, что у меня нет четкого понимания того, когда выполняется Path MTU Discovery (PMTUD).

Я знаю, что он делает - обнаруживает самый низкий MTU на пути от клиента к серверу).
Я знаю, как это происходит - отправляйте постепенно увеличивающиеся пакеты с установленным битом «Не фрагментировать» и смотрите, какой большой пакет вы можете получить, не получив ошибку «Необходимость фрагментирования ICMP».

Мой вопрос, конкретно, тогда, когда хозяин будет выполнять PMTUD?

Я ищу конкретные случаи. Не просто что-то общее, например, «когда хост хочет обнаружить MTU пути». Бонусные баллы, если вы можете предоставить захват пакета хостом, выполняющим это, или предоставить инструкции для генерации такого захвата пакета.

Также я конкретно имею в виду IPv4. Я знаю, что в IPv6 временные маршрутизаторы не несут ответственности за фрагментацию и могут представить, что PMTUD происходит гораздо чаще. Но сейчас я ищу конкретные примеры PMTUD в IPv4. (хотя, если единственное средство захвата пакетов, которое вы можете собрать из PMTUD, находится в IPv6, я все равно хотел бы увидеть его)

Ответ прост: когда хозяин желает. В самом деле. Это так просто.

В приведенном ниже объяснении предполагается среда только для IPv4, поскольку IPv6 устраняет фрагментацию в маршрутизаторах (заставляя хост всегда иметь дело с фрагментацией и обнаружением MTU).

Не существует строгого правила, определяющего, когда (или даже если) хост выполняет Path MTU Discovery. Причина появления PMTUD заключается в том, что фрагментация считается вредной по разным причинам. Чтобы избежать фрагментации пакетов, концепция PMTUD была воплощена в жизнь. Конечно, хорошая операционная система должна использовать PMTUD для минимизации фрагментации.

Поэтому, естественно, точная семантика использования PMTUD зависит от операционной системы отправителя, в частности, от реализации сокета. Я могу говорить только о конкретном случае Linux, но другие варианты UNIX, вероятно, не очень отличаются.

В Linux PMTUD контролируется IP_MTU_DISCOVERопцией сокета. Вы можете получить его текущий статус getsockopt(2), указав уровень IPPROTO_IPи IP_MTU_DISCOVERпараметр. Эта опция действительна SOCK_STREAMтолько для сокетов ( SOCK_STREAMсокет является двухсторонним, ориентированным на соединение, надежным сокетом; на практике это сокет TCP, хотя возможны и другие протоколы), и когда он установлен, Linux будет выполнять PMTUD точно так, как определено в RFC 1191.

Обратите внимание, что на практике PMTUD является непрерывным процессом; пакеты отправляются с установленным битом DF - включая пакеты трехстороннего рукопожатия - вы можете рассматривать его как свойство соединения (хотя в какой-то момент реализация может пожелать принять определенную степень фрагментации и прекратить отправку пакетов с DF) бит установлен). Таким образом, PMTUD является лишь следствием того факта, что все в этом соединении отправляется с DF.

Что делать, если вы не установите IP_MTU_DISCOVER?

Там есть значение по умолчанию. По умолчанию IP_MTU_DISCOVERвключен на SOCK_STREAMсокетах. Это можно прочитать или изменить, прочитав /proc/sys/net/ipv4/ip_no_pmtu_disc. Нулевое значение означает, что IP_MTU_DISCOVERпо умолчанию включено в новых сокетах; ненулевой означает обратное.

А как насчет сокетов без соединения?

Это сложно, потому что ненадежные сокеты без установления соединения не ретранслируют потерянные сегменты. Пользователь несет ответственность за упаковку данных в куски размера MTU. Кроме того, ожидается, что пользователь сделает необходимые повторные передачи в случае слишком большой ошибки в сообщении . Таким образом, по сути пользовательский код должен переопределить PMTUD. Тем не менее, если вы готовы принять вызов, вы можете включить бит DF, передав IP_PMTUDISC_DOфлаг setsockopt(2).

Суть

• Хост решает, когда (и если) использовать PMTUD
• Когда он использует PMTUD, это похоже на атрибут соединения, это происходит постоянно (но в любой момент реализация может прекратить это делать)
• Различные операционные системы используют разные подходы, но обычно надежные сокеты, ориентированные на соединение, по умолчанию выполняют PMTUD, тогда как ненадежные сокеты без установления соединения не

Как правило, обнаружение максимальной единицы передачи в тракте (PMTUD) происходит всякий раз, когда хост считает, что пакет был отброшен из-за его слишком большого размера.

Это может быть ответом на запрос требуемой фрагментации ICMP (тип 3, код 4), явно указывающий, что пакет был отброшен. В обычной практике все пакеты IPv4 устанавливаются с установленным флагом «не фрагментировать» (DF), поэтому любой пакет, превышающий MTU, вызовет такой ответ. IPv6 вообще не поддерживает фрагментацию.

Некоторые маршрутизаторы или межсетевые экраны хоста часто сбрасывают все ICMP, потому что наивный администратор считает ICMP угрозой безопасности . Или, некоторые схемы агрегации ссылок могут нарушить доставку ICMP . Был превышен альтернативный механизм обнаружения MTU, который не зависит от ICMP, предложенный в RFC4821 .

tracepathмой любимый инструмент Linux для исследования MTU. Вот пример с хоста с 9001 MTU в локальной сети, но который должен пройти через IPsec VPN, чтобы достичь 10.33.32.157:

$ tracepath -n 10.33.32.157
 1?: [LOCALHOST]                                         pmtu 9001
 1:  10.1.22.1                                             0.122ms pmtu 1500
 1:  169.254.3.1                                           1.343ms pmtu 1422
 1:  10.255.254.61                                        23.790ms 
 2:  no reply
^C [this host won't return an ICMP port unreachable, so tracepath won't terminate]

Ошибки ICMP можно наблюдать при tcpdump:

$ sudo tcpdump -p -ni eth0 'icmp and icmp[0] == 3 and icmp[1] == 4'
14:46:57.313690 IP 10.1.22.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1500), length 36
14:46:57.315080 IP 169.254.3.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1422), length 556

Открытия MTU кэшируются. В Linux это можно наблюдать и очищать ip(остерегайтесь изменений после Linux 3.6 ):

$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache  expires 591sec mtu 1422
$ sudo ip route flush cache
$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache

Для TCP превышение MTU можно избежать как часть настройки соединения. В SYN, отправляемый каждым концом, включен максимальный размер сегмента (MSS). Заголовок TCP (20 байтов без учета опций ) и заголовок IP (20 байтов) означают MSS и MTU, связанные разницей в 40 байтов.

Вот пример настройки соединения между этими двумя хостами при передаче большого файла с помощью scp:

$ sudo tcpdump -p -ni eth0 'host 10.33.32.157 and tcp[13]&2 == 2'
IP 10.1.22.194.45853 > 10.33.32.157.22: Flags [S], seq 634040018, win 26883, options [mss 8961,sackOK,TS val 10952240 ecr 0,nop,wscale 7], length 0
IP 10.33.32.157.22 > 10.1.22.194.45853: Flags [S.], seq 1371736848, ack 634040019, win 26847, options [mss 1379,sackOK,TS val 10824267 ecr 10952240,nop,wscale 7], length 0

В первом пакете локальный хост предлагает MSS 8961. Это настроенный MTU 9001, меньше 40 байтов. Возвращенный SYN / ACK имеет MSS 1379, что означает MTU 1419. Я знаю, что в этой сети удаленный хост также отправил 8961, но значение было изменено маршрутизатором, так как он знает, что путь включает в себя интернет-путь ( MTU 1500) служебная информация из туннеля IPsec. Этот маршрутизатор также изменил нашу отправленную MSS 8961, чтобы появиться как 1419 на другом хосте. Это называется зажимом MSS .

Таким образом, в некотором смысле, PMTUD происходит все время. На практике это может фактически никогда не случиться, если ограничение MSS на месте и весь трафик происходит по TCP, или если ни один из маршрутизаторов не имеет MTU меньше, чем настроено на конечных точках. Даже без ограничения MSS это может происходить очень редко, когда срок действия кэша истекает.

PMTUD используется для расчета лучшего MSS для сеансов TCP. Одним из примеров является реализация BGP на маршрутизаторах Cisco или Juniper.

http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/routing-configuring-mtu-discovery-for-bgp-sessions.html

Благодарю.