Время ожидания ARP. Почему фиксированные периодические?

Question

Этот год меня раздражал.

Основной вопрос: Есть ли какая-то причина, по которой ARP имеет, с фиксированными таймаутами в записи ARP-кеша?

Я занимаюсь большой работой в кривых в реальном времени. В наши дни мы выполняем большую часть наших межсистемных коммуникаций на выделенных линиях UDP/IP. Это по большей части работает надежно в режиме реального времени, но за один тайм-аут ARP.

Путь типичных реализаций сделать ARP заключается в следующем:

• Когда клиент просит отправить пакет IP на IP-адрес с UNKOWN MAC-адрес, вместо отправки этого пакета IP, стек отсылает ARP-запрос. Если верхний уровень (TCP) повторно отправляется, это не проблема. Но поскольку мы используем UDP, исходное сообщение теряется. Во время запуска это нормально, но в середине операции это Bad Thing ™.
• (динамический) Записи таблицы ARP периодически удаляются из таблицы ARP, даже если мы только что получили пакет из этой системы миллисекунд назад. Это означает, что Bad Thing ™ происходит с нашей системой регулярно.

Очевидное решение (которое мы используем религиозно) состоит в том, чтобы сделать все записи ARP статическими. Тем не менее, это королевская PITA (особенно в RTOS, где поиск MAC-адреса интерфейса не всегда зависит от нескольких простых графических кликов).

Назад, когда мы написали наш собственный стек IP, я решил эту проблему, никогда (никогда) не выбирая записи таблицы ARP. Это имеет очевидные недостатки. Более надежным и вполне разумным решением может быть обновление тайм-аута ввода, когда будет просматриваться пакет из той же комбинации MAC/IP. Таким образом, запись будет только время ожидания, если она не сообщила со стеком за это время.

Но теперь мы используем стек IP нашего поставщика, и мы вернулись к глупым таймаутам ARP. У нас достаточно рычагов с этим продавцом, чтобы я мог заставить их использовать менее неудобную схему. Тем не менее, универсальность этого алгоритма «мозгового мертвого таймаута» заставляет меня думать, что это может быть неотъемлемой частью реализации.

Так вот в чем вопрос. Это как-то требуется?

Answer 1

RFC1122 Requirements for Internet Hosts обсуждает это.

 2.3.2.1 ARP Cache Validation 

     An implementation of the Address Resolution Protocol (ARP) 
     [LINK:2] MUST provide a mechanism to flush out-of-date cache 
     entries. If this mechanism involves a timeout, it SHOULD be 
     possible to configure the timeout value. 

     ... 

     DISCUSSION: 
      The ARP specification [LINK:2] suggests but does not 
      require a timeout mechanism to invalidate cache entries 
      when hosts change their Ethernet addresses. The 
      prevalence of proxy ARP (see Section 2.4 of [INTRO:2]) 
      has significantly increased the likelihood that cache 
      entries in hosts will become invalid, and therefore 
      some ARP-cache invalidation mechanism is now required 
      for hosts. Even in the absence of proxy ARP, a long- 
      period cache timeout is useful in order to 
      automatically correct any bad ARP data that might have 
      been cached. 

Сети могут быть очень динамичными; DHCP-серверы могут назначать один и тот же IP-адрес на разных компьютерах, когда истечет срок аренды (что делает текущие данные ARP недействительными), могут быть конфликты IP, которые никогда не будут замечены, если ARP-запросы не будут периодически выполняться и т. Д.

Он также предоставляет механизм для проверки того, находится ли хост в сети. Представьте, что вы передаете видео через UDP на какой-то IP-адрес 192.168.0.5. Если вы будете кэшировать MAC-адрес этой машины навсегда, вы просто будете рассылать пакеты UDP, даже если хост не работает. Выполнение ARP-запроса время от времени останавливает поток с недостижимой ошибкой адресата, потому что никто не ответил MAC для этого IP-адреса.

Answer 2

Он возник из-за недоверия к протоколам маршрутизации, особенно в мире не-Ethernet (особенно в сетях CHAOS MIT). Крис Мун, один из ранних «ARPAnauts», был конкретно указан в оригинальной ARP RFC.

Вы можете, конечно, сохранить тайники ARP других ребят из-за упреждающего вещания ваших собственных объявлений ARP. Большинство слоев Ethernet будут принимать безвозмездные ответы ARP в свои кеши, не пытаясь сопоставить их с запросами ARP, которые они ранее отправили.