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

Информация об отправителе не кэшируется на получателе во время запроса ARP

В настоящее время я пытаюсь разобраться в более сложных сетевых концепциях. Я делаю это, заходя на один из серверов, за которыми я наблюдаю как системный администратор, и выполняю сетевые записи, чтобы увидеть и понять данные. (Машина, на которой я выполняю этот захват, - serveriamon.networkname.local с IP-адресом 172.16.2.7)

Это привело меня к этому обмену в сети:

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   

Я могу понять этот обмен. Машина по адресу 172.16.3.30 хочет узнать, где и какой MAC для 172.16.2.7. Сервер по этому адресу (этот сервер) отвечает своим ARP-ответом, содержащим Mac-адрес.

Сразу после этого появляется этот кадр:

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}

Насколько я понимаю, это запрос времени на сервере. Это хорошо. Меня смущает следующий кадр:

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    

В кадр 1129 запроса SNTP встроен адрес источника. Почему тогда сервер немедленно выполняет широковещательную рассылку, чтобы узнать, где находится IP-адрес?

Я подозреваю, что просто неправильно понимаю, как это работает, но я искренне заинтригован. Кажется «расточительным» и «шумным» выпускать ARP, когда он уже должен иметь информацию?

Это интересное наблюдение, которого я раньше не замечал. Такое поведение предполагает, что сервер не помещает Аппаратный адрес в свою таблицу arp, когда получает запросы arp. Что это за операционная система?

Оригинал ARP RFC 826 говорит об этом немного в отношении «флага слияния»:

«Обратите внимание, что триплет объединяется в таблицу до того, как будет рассмотрен код операции. Это сделано при условии, что связь является двунаправленной; если у A есть какая-то причина разговаривать с B, тогда у B, вероятно, будет какая-то причина поговорить с A.»

Однако мне не удается найти дополнительную информацию о флаге слияния.

Предположение о причине такого поведения:
Одна причина, по которой я угадать вы можете сделать это, чтобы предотвратить переполнение вашего кеша arp. Другими словами, «На всякий случай я буду кэшировать это, только если я спросил для этого".

В противном случае люди могли бы создать кучу arp-запросов с множеством разных IP-адресов и заполнить таблицу (вы можете предотвратить это множеством других способов, но это кажется простым способом, который будет работать).