Timeout ARP. Perché fisso periodico?

Question

Questo mi ha infastidito per anni.

domanda di base: C'è qualche motivo ARP deve da realizzare con intervalli di tempo fissi sulle voci di cache ARP?

Faccio un sacco di lavoro in circuiti in tempo reale. Attualmente effettuiamo la maggior parte delle nostre comunicazioni tra sistemi su collegamenti UDP/IP dedicati. Questo per la maggior parte funziona in modo affidabile in tempo reale, ma per un nit: timeout delle entrate ARP.

implementazioni

il tipico modo fanno ARP è la seguente:

• Quando cliente chiede di inviare un pacchetto IP a un indirizzo IP con un indirizzo MAC sconosciuta, invece di inviare quel pacchetto IP, lo stack invia un Richiesta ARP. Se un livello superiore (TCP) si reinvia, non c'è problema. Ma dal momento che usiamo UDP, il messaggio originale è perso. Al momento dell'avvio è OK, ma nel bel mezzo dell'operazione si tratta di una cosa brutta ™.
• (Dinamico) Le voci della tabella ARP vengono rimosse periodicamente dalla tabella ARP, anche se abbiamo ottenuto un pacchetto da quel sistema un millesimo di secondo. Ciò significa che il Bad Thing ™ si verifica regolarmente nel nostro sistema.

La soluzione ovvia (che usiamo religiosamente) è rendere statiche tutte le voci ARP. Tuttavia, questo è un PITA reale (in particolare su RTOS in cui trovare l'indirizzo MAC di un'interfaccia non è sempre questione di un paio di semplici clic della GUI).

Indietro quando scrivemmo il nostro stack IP, ho risolto questo problema senza mai (mai) il timeout delle voci della tabella ARP. Ciò ha ovvi inconvenienti. Una soluzione più robusta e perfettamente ragionevole potrebbe essere quella di aggiornare il timeout della voce ogni volta che viene visualizzato un pacchetto dalla stessa combinazione MAC/IP. In questo modo una voce sarebbe scaduta solo se non fosse stata comunicata con lo stack in quel lasso di tempo.

Ma ora stiamo usando lo stack IP del nostro fornitore e siamo tornati agli stupidi timeout ARP. Abbiamo abbastanza leva con questo fornitore che forse potrei farli usare uno schema meno sfavorevole. Tuttavia, l'universalità di questo algoritmo di timeout cerebrale mi porta a credere che potrebbe essere una parte necessaria dell'implementazione.

Questa è la domanda. Questo comportamento è in qualche modo richiesto?

Answer 1

RFC1122 Requirements for Internet Hosts discute questo.

 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. 

Le reti possono essere molto dinamiche; I server DHCP possono assegnare lo stesso indirizzo IP a diversi computer quando scadono i vecchi tempi di lease (rendendo non validi i dati ARP correnti), possono verificarsi conflitti IP che non verranno mai notificati a meno che non vengano eseguite periodicamente richieste ARP, ecc.

Fornisce inoltre un meccanismo per verificare se un host è ancora sulla rete. Immagina di trasmettere un video su UDP a un indirizzo IP 192.168.0.5. Se metti in cache per sempre l'indirizzo MAC di quel computer, continuerai a inviare spam ai pacchetti UDP anche se l'host non funziona. Fare una richiesta ARP ogni tanto interromperà il flusso con un errore di destinazione irraggiungibile perché nessuno ha risposto con un MAC per quell'IP.

Answer 2

Proviene dalla diffidenza dei protocolli di routing, specialmente nel mondo non Ethernet (in particolare le reti CHAOS del MIT). Chris Moon, uno dei primi "ARPAnauts" è stato citato specificamente su questo nel RFC ARP originale.

È possibile, naturalmente, impedire che le cache ARP degli altri ragazzi vengano interrotte in modo proattivo trasmettendo i propri annunci ARP. La maggior parte dei layer Ethernet accetterà risposte ARP gratuite nelle loro cache senza cercare di correlarle alle richieste ARP che hanno precedentemente inviato.