3

У меня ситуация, когда IP-адрес перемещается с одного устройства на другое, и никакое сообщение Gratuitous ARP (Address Resolution Protocol) не отправляется для обновления участников этой сети.

В этой сети есть устройство, которое, вероятно, нуждается в длительном тайм-ауте ARP до 20 минут для возобновления связи. Другое устройство отправляет свой запрос ARP сразу же после того, как оно распознает разорванное соединение, и поэтому оно довольно быстро снова доступно в сети.

Мне интересно, есть ли какое-то определение, что устройство должно повторно отправить запрос ARP, если его целевой MAC-адрес или IP-связь больше не доступны?

Этот вопрос как-то связан с вопросом « Как ARP обрабатывает перемещение IP-адреса на другое устройство?».

1 ответ1

2

Мне интересно, есть ли какое-то определение, что устройство должно повторно отправить запрос ARP, если его целевой MAC-адрес или IP-связь больше не доступны?

Нет там нет. Нет даже требования, чтобы у хостов были записи в таблице ARP.

RFC 826, Протокол разрешения адресов Ethernet или преобразование адресов сетевых протоколов в 48-битный адрес Ethernet для передачи по оборудованию Ethernet, обсуждает проблемы, связанные с этим:

Может быть желательно иметь таблицы старения и / или тайм-ауты. Их реализация выходит за рамки этого протокола. Вот более подробное описание (спасибо MOON @ SCRC @ MIT-MC).

Если хост перемещается, все соединения, инициированные этим хостом, будут работать, при условии, что его собственная таблица разрешения адресов очищается при перемещении. Тем не менее, соединения, инициированные к нему другими хостами, не будут иметь особой причины знать, чтобы отбросить их старый адрес. Однако 48-битные адреса Ethernet должны быть уникальными и фиксированными на все времена, поэтому они не должны меняться. Хост мог "переместиться", если имя хоста (и адрес в каком-то другом протоколе) было переназначено другому физическому элементу оборудования. Кроме того, как мы знаем из опыта, всегда существует опасность того, что неверная информация о маршрутизации будет случайно передана из-за аппаратной или программной ошибки; нельзя допустить, чтобы это продолжалось вечно. Возможно, сбой при установлении соединения должен сообщить модулю Address Resolution для удаления информации на том основании, что хост недоступен, возможно, из-за того, что он недоступен или старый перевод больше не действует. Или, возможно, получение пакета от хоста должно сбросить тайм-аут в записи разрешения адреса, используемой для передачи пакетов на этот хост; если от хоста не получено пакетов в течение подходящего промежутка времени, запись разрешения адреса будет забыта. Это может привести к дополнительным затратам на сканирование таблицы для каждого входящего пакета. Возможно, хеш или индекс могут сделать это быстрее.

Предложенный алгоритм получения пакетов с разрешением адресов пытается уменьшить время, необходимое для восстановления, если хост действительно перемещается. Напомним, что если он уже находится в таблице перевода, аппаратный адрес отправителя заменяет существующую запись. Следовательно, в идеальном Ethernet, где широковещательный запрос достигает всех станций на кабеле, каждая станция получит новый аппаратный адрес.

Другая альтернатива - заставить демона выполнить таймауты. По истечении подходящего времени демон рассматривает возможность удаления записи. Сначала он отправляет (с небольшим количеством повторных передач, если необходимо) пакет разрешения адреса с кодом операции REQUEST непосредственно на адрес Ethernet в таблице. Если в течение короткого промежутка времени ответ не отображается, запись удаляется. Запрос отправляется напрямую, чтобы не беспокоить каждую станцию в сети Ethernet. Простое забытие записей может привести к тому, что будет забыта полезная информация, которую необходимо восстановить.

Поскольку хосты не передают информацию ни о ком, кроме себя, перезагрузка хоста приведет к обновлению его таблицы сопоставления адресов. Плохая информация не может сохраняться вечно, передаваясь от машины к машине; единственная неверная информация, которая может существовать, находится на машине, которая не знает, что какая-то другая машина изменила свой 48.bit адрес Ethernet. Возможно, ручного сброса (или очистки) таблицы сопоставления адресов будет достаточно.

Этот вопрос явно нуждается в большем внимании, если считается важным. Это вызвано любым протоколом, похожим на разрешение адресов.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .