Por que uma VM de inicialização de PXE procura agressivamente o ARP reverso?

Question

O ARP reverso é ... bem, praticamente morto, tanto quanto sei? Uma das grandes histórias de sucesso na Internet para matar um protocolo? Está obsoleto em favor do BOOTP (e mais tarde, DHCP) por quase três décadas.

Então, fiquei um pouco surpreso ao notar uma VM implacavelmente pedindo um endereço IP via RARP durante uma inicialização PXE - mesmo depois de obter um endereço IP perfeitamente bom via DHCP.

No início da inicialização, o primeiro pacote de transmissão enviado é um pacote ARP reverso, seguido imediatamente por uma transmissão 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

Aparentemente, ele não gosta da primeira resposta DHCP, pois aguarda por outra (note que estou capturando apenas pacotes de broadcast, então tcpdump não vê o resto da conversação DHCP), mas não antes de enviar outro par de pedidos de 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

Ok, ótimo; ele recebeu um IP e, em seguida, ARP para o servidor PXE, de modo que ele pudesse acionar o TFTP. Ele pegou outro RARP lá no final, tudo bem. Agora é todo o caminho para o ambiente pxelinux:

Edepois?OutropedidodeRARP,exatamente1segundoapósoúltimo.

20:31:23.935340ARP,ReverseRequestwho-is00:0c:29:20:fd:cetell00:0c:29:20:fd:ce,length46

Eoutro,exatamente2segundosdepois.

20:31:25.935384ARP,ReverseRequestwho-is00:0c:29:20:fd:cetell00:0c:29:20:fd:ce,length46

Eentãoalguns.3segundosdepois,5segundosdepoisdisso,8segundos,13segundos,21segundos...enessepontoelefinalmentedesaparece.

20:31:28.935548ARP,ReverseRequestwho-is00:0c:29:20:fd:cetell00:0c:29:20:fd:ce,length4620:31:33.935518ARP,ReverseRequestwho-is00:0c:29:20:fd:cetell00:0c:29:20:fd:ce,length4620:31:41.935633ARP,ReverseRequestwho-is00:0c:29:20:fd:cetell00:0c:29:20:fd:ce,length4620:31:54.935970ARP,ReverseRequestwho-is00:0c:29:20:fd:cetell00:0c:29:20:fd:ce,length4620:32:15.936232ARP,ReverseRequestwho-is00:0c:29:20:fd:cetell00:0c:29:20:fd:ce,length46

Tudoenquantonoambientepxelinux,comumendereçoIPdetrabalhojávinculadoaessaNIC.

Então,alguémtemalgumaidéiadoqueestaVM(oumelhor,cadaVMESX(i),pelomenosem4.1e5.0)estápensando?

EuverifiqueiqueissoocorretantonoemuladoE1000quantonodispositivovmxnet3;issoéumpoucodecomportamento"especial" do código VMware PXE, ou esse é um comportamento típico de qualquer código PXE antigo?

Faz algum sentido que ele esteja procurando pelo RARP, já que, como protocolo, ele não é capaz de fornecer qualquer informação do servidor PXE (até onde eu sei)?

Eu preciso morder o marcador e configurar rarpd para ver como o dispositivo PXE reagirá a ele?

    

Answer 1

Eu posso estar errado, mas isso parece ser pacotes RARP enviados pelo vkernel se o vswitch tiver a configuração 'Notify Switches', que está ativada por padrão.