Обнаружение пути MTU - где ответы ICMP? - PullRequest
Новая
       32

Обнаружение пути MTU - где ответы ICMP?

4 голосов
/ 22 июля 2011

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

Я создал несколько виртуальных машин на своем компьютере и связал их следующим образом: 

VM1 (192.168.100.2)

R1  (192.168.100.1, 
     192.168.150.1)

R2  (192.168.150.2, 
     192.168.200.1)

VM2 (192.168.200.2)

Rx - это виртуальные машины с установленным Linux, у них есть два сетевых интерфейса сстатический маршрут.Пинг V2 с V1 и наоборот успешен. 

traceroute from 192.168.100.2 to 192.168.200.2 (192.168.200.2)
 1  192.168.100.1 (192.168.100.1)  0.437 ms  0.310 ms  0.312 ms
 2  192.168.150.2 (192.168.150.2)  2.351 ms  2.156 ms  1.989 ms
 3  192.168.200.2 (192.168.200.2)  43.649 ms  43.418 ms  43.244 ms

tracepath 192.168.200.2
 1:  ubuntu-VirtualBox.local                               0.211ms pmtu 1500
 1:  192.168.100.1                                         0.543ms 
 1:  192.168.100.1                                         0.546ms 
 2:  192.168.150.2                                         0.971ms 
 3:  192.168.150.2                                         1.143ms pmtu 750
 3:  192.168.200.2                                         1.059ms reached

Сегменты 100.x и 150.x имеют MTU 1500. Сегмент 200.x имеет MTU 750.

Я пытаюсьотправлять UDP-пакеты с включенным DF.Дело в том, что VM1 вообще не отправляет пакет в случае, если размер пакета больше 750 (я получаю ошибку EMSGSIZE для вызова send ()).

Однако я ожидаю такого поведения для пакетов, размер которых превышает 1500. И я ожидаю, что VM1 отправляет пакеты с размером от 750 до 1500 в R1, и R1 (или R2) отбрасывает такие пакеты ивозвращает ICMP-пакет на VM1.Но этого не происходит.

Есть два вопроса:

1) Почему?

2) Можно ли настроить мою виртуальную сеть для приема пакетов ICMP вСогласно RFC 1191?

Спасибо.

Ответы [ 2 ]

6 голосов
/ 27 июля 2011

Вполне возможно, что VM1 кэширует информацию PMTU. По умолчанию время ожидания для этих записей кэша составляет 10 минут. Вы можете изменить время ожидания, написав в / proc / sys / net / ipv4 / route / mtu_expires (секунды).

Для вашего эксперимента попробуйте очистить кэш (удалив кэш PMTU) перед отправкой 1500 байтовых пакетов: 

echo "0" > /proc/sys/net/ipv4/route/flush

Вы получите сообщение о необходимости фрагментации ICMP, которое снова заполнит запись PMTU для этого места назначения! Поэтому вам нужно будет очищать этот кэш, прежде чем пытаться повторить эксперимент.

0 голосов
/ 11 апреля 2018

столкнулся с той же проблемой при использовании ping6, потому что / proc / sys / net / ipv6 / conf / default / mtu равно 1280. И / proc / sys / net / ipv4 / route / min_pmtu по умолчанию равно 552.

Так что вы можете изменить значение внутри. И вы можете использовать -M вариант. вы не получите сообщение об ошибке EMSGSIZE. 

-M pmtudisc_opt
          Select  Path MTU Discovery strategy.  pmtudisc_option may be 
           either do (prohibit fragmentation, even local one), want (do 
           PMTU discovery, fragment locally when packet size
           is large), or dont (do not set DF flag).
...