Informações do Remetente Não Armazenadas em Cache no Receptor Durante uma Solicitação ARP

Question

Atualmente, estou tentando entender meus conceitos de rede mais avançados. A maneira como estou fazendo isso é indo em um dos servidores que eu cuido como um sysadmin e executando capturas de rede para ver e fazer sentido dos dados. (A máquina na qual estou executando esta captura é serveriamon.networkname.local com um IP de 172.16.2.7)

Isso me leva a essa troca na rede:

1127    11:46:55 12/10/2012 30.2960887      172.16.3.30
serveriamon.networkname.local   ARP ARP:Request, 172.16.3.30 asks for 172.16.2.7    

1128    11:46:55 12/10/2012 30.2961939      serveriamon.networkname.local   172.16.3.30 ARP ARP:Response, 172.16.2.7 at 78-2B-CB-23-8D-07   

Eu posso entender essa troca. A máquina em 172.16.3.30 quer descobrir onde e o que o MAC é para 172.16.2.7. O servidor nesse endereço (este servidor) responde com sua resposta ARP contendo o endereço Mac.

Imediatamente depois, esse quadro ocorre:

1129    11:46:55 12/10/2012 30.2964210      172.16.3.30 serveriamon.networkname.local   SNTP    SNTP:NTPv3 Request, Leap = 0, Mode = 3, RID = 5154  {SNTP:377, UDP:376, IPv4:375}

Isso eu entendo é um pedido para o tempo no servidor. Isso é bom. O próximo quadro é o que está me confundindo:

1130    11:46:55 12/10/2012 30.2972641      serveriamon.networkname.local   172.16.3.30 ARP ARP:Request, 172.16.2.7 asks for 172.16.3.30    

Incorporado no quadro 1129, a solicitação SNTP é o endereço de origem. Por que o servidor está imediatamente fazendo uma transmissão para descobrir onde está o endereço IP?

Eu suspeito que estou apenas entendendo mal como isso funciona, mas estou genuinamente intrigada. Parece "um desperdício" e "barulhento" lançar um ARP quando ele já deveria ter a informação?

    

Answer 1

Esta é uma observação interessante que eu nunca notei antes. Esse comportamento sugere que o servidor não está colocando o endereço de hardware em sua tabela arp quando ele recebe solicitações arp. Que tipo de sistema operacional é esse?

O ARP RFC 826 original fala sobre isso um pouco com relação a uma "bandeira de mesclagem":

"Notice that the triplet is merged into the table before the opcode is looked at. This is on the assumption that communcation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A."

Estou tendo problemas para encontrar mais informações sobre o sinalizador de mesclagem.

Um palpite sobre o motivo desse comportamento:
Uma razão que eu acho que você pode fazer isso é impedir que alguém transborde seu cache de arp. Em outras palavras, "Para ser seguro, só vou armazenar em cache isso se eu pedir por ele".

Caso contrário, as pessoas poderiam criar um monte de solicitações arp com muitos IPs diferentes e preencher a tabela (muitas outras maneiras de evitar isso, mas isso parece ser uma maneira simples de funcionar).