Пример "беспричинного" ARP.

Рисунок 4.7 Пример "беспричинного" ARP.

(Мы использовали флаг -n программы tcpdump, чтобы напечатать адреса в цифровом десятичном виде вместо имен хостов.) В терминах полей ARP запроса, адрес протокола отправителя и адрес протокола назначения идентичны: 140.252.13.35 (что соответствует хосту bsdi). Адрес источника в заголовке Ethernet, 0:0:c0:6f:2d:40 как показано программой tcpdump, эквивалентен аппаратному адресу отправителя (из рисунка 4.4).

"Беспричинный" ARP предоставляет две характеристики.

Он позволяет хосту определить, существует ли другой хост с тем же самым IP адресом. Хост bsdi не ожидает отклика на свой запрос, однако если отклик принят, на консоли возникает сообщение об ошибке "обнаружен дублирующий IP адрес с Ethernet адресом: a:b:c:d:e:f". Это предупреждение системному администратору о том, что одна из систем неправильно сконфигурирована.
Если хост, посылающий "беспричинный" ARP, только что изменил свой аппаратный адрес (может быть потому, что хост был выключен, удалена интерфейсная плата и затем хост был перезагружен), этот пакет заставляет другой хост на кабеле, который имеет запись в своем кэше для старого аппаратного адреса, обновить ARP кэш соответствующим образом. Малоизвестный факт о протоколе ARP [Plummer 1982] заключается в том, что если хост получает ARP запрос для IP адреса, который он уже имеет в кэше, содержимое кэша обновляется аппаратным адресом отправителя (Ethernet адресом) из запроса ARP. Это делается для любого запроса ARP, полученного хостом. (Повторим, что ARP запросы широковещательные, поэтому такие действия осуществляются всеми хостами в сети каждый раз при появлении ARP запроса.) [Bhide, Elnozahy, and Morgan 1991] описывает приложения, которые используют эту характеристику ARP. Она позволяет запасному (backup) файл-серверу занять место вышедшего из строя сервера с использованием "беспричинного" ARP запроса с запасным аппаратным адресом, однако с тем же IP адресом, который имел вышедший из строя хост. При этом все пакеты, направляемые серверу, вышедшему из строя, будут посланы на запасной сервер, а пользовательские приложения не будут знать о том, что основной сервер вышел из строя.

К сожалению, авторы затем отказались от этого подхода, так как он зависит от корректности реализации ARP на всех типах клиентов. Существуют различные типы ARP, которые не поддерживают эту спецификацию.

Наблюдения за всеми системами в подсети, используемой в этой книге, показывает, что SunOS 4.1.3 и 4.4BSD используют "беспричинный" ARP при загрузке, а SVR4 не поддерживает эту характеристику.

Содержание раздела