Назад | Перейти на главную страницу

Почему виртуальная машина с загрузкой PXE агрессивно ищет обратный ARP?

Обратный ARP ... ну, почти мертв, насколько я знаю? Одна из великих историй успеха Интернета в уничтожении протокола? Он устарел в пользу BOOTP (а позже и DHCP) почти три десятилетия.

Итак, я был немного удивлен, когда заметил, что виртуальная машина безжалостно запрашивает IP-адрес через RARP во время загрузки PXE - даже после получения совершенно хорошего IP-адреса через DHCP.


В начале загрузки первым отправляемым широковещательным пакетом является пакет обратного ARP, за которым сразу следует широковещательная рассылка DHCP.

20:31:19.408086 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:19.441857 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:20:fd:ce, length 548
20:31:19.443536 IP 192.168.100.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

По-видимому, ему не нравится этот первый ответ DHCP, поскольку он ждет другого (обратите внимание, что я только захватываю широковещательные пакеты, поэтому tcpdump не видит остальную часть разговора DHCP), но не раньше, чем отправит еще пару запросов RARP:

20:31:19.935341 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:20.935426 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:21.500371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:20:fd:ce, length 548
20:31:21.501288 IP 192.168.100.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
20:31:21.504278 ARP, Request who-has 192.168.100.40 tell 192.168.100.6, length 46
20:31:22.935467 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

Ок, отлично; он получил IP-адрес, а затем ARP-адрес для PXE-сервера, чтобы он мог запустить TFTP. В конце он прятал еще один RARP, хорошо. Теперь это все в среде pxelinux:

А потом? Еще один запрос RARP, ровно через 1 секунду после последнего.

20:31:23.935340 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

И еще один, ровно через 2 секунды.

20:31:25.935384 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

А потом еще немного. 3 секунды спустя, 5 секунд после этого, 8 секунд, 13 секунд, 21 секунда ... и в этот момент он наконец утихает.

20:31:28.935548 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:33.935518 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:41.935633 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:54.935970 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:32:15.936232 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

Все это время в среде pxelinux с уже привязанным к этому сетевому адаптеру рабочим IP-адресом.


Итак, кто-нибудь знает, о чем думает эта виртуальная машина (точнее, каждая виртуальная машина ESX (i), по крайней мере, на 4.1 и 5.0)?

Я убедился, что это происходит как на эмулируемом E1000, так и на устройстве vmxnet3; это немного «особенное» поведение кода VMware PXE, или это типичное поведение любого старого кода PXE?

Имеет ли смысл вообще искать RARP, поскольку как протокол он не может предоставить какую-либо информацию о сервере PXE (насколько мне известно)?

Мне нужно укусить пулю и настроить rarpd посмотреть, как на это отреагирует PXE-устройство?

Я могу ошибаться, но это похоже на RARP-пакеты, отправленные vkernel, если vswitch имеет конфигурацию 'Notify Switches', которая включена по умолчанию.