En al menos una implementación hay un límite estricto en la capacidad de la tabla ARP. ¿Qué sucede cuando el caché ARP está lleno y se ofrece un paquete con un destino (o siguiente salto) que no está en caché? ¿Qué sucede debajo del capó y cuál es el efecto en la calidad del servicio?
Por ejemplo, los enrutadores Brocade NetIron XMR y Brocade MLX tienen un sistema máximo configurableip-arp . El valor predeterminado en ese caso es 8192; El tamaño de una subred / 19. No está claro en la documentación si esto es por interfaz o para todo el enrutador, pero para el propósito de esta pregunta, podemos suponer que es por interfaz.
Pocos networkers configurarían una subred / 19 en una interfaz a propósito, pero eso no fue lo que sucedió. Estábamos migrando un enrutador central de un modelo de Cisco a un Brocade. Una de las muchas diferencias entre Cisco y Brocade es que Cisco acepta rutas estáticas que se definen con una interfaz de salida y una dirección de siguiente salto, pero Brocade insiste en una u otra. Dejamos caer la dirección del siguiente salto y conservamos la interfaz. Más tarde, aprendimos el error de nuestras formas y cambiamos de la interfaz a la dirección del siguiente salto, pero todo parecía estar funcionando inicialmente.
+----+ iface0 +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1 .2+----+
10.0.0.0/30
Antes de la migración, R1 era un Cisco y tenía la siguiente ruta.
ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2
Después de la migración, R1 era un Brocade y tenía la siguiente ruta.
ip route 10.1.0.0 255.255.0.0 iface0
R2 es un enrutador Cisco, y los enrutadores Cisco realizan ARP proxy de forma predeterminada. Esta es la configuración (incorrecta) en producción que preparó el escenario para lo que resultó ser un desbordamiento de caché ARP.
- R1 recibe un paquete destinado a la red 10.1.0.0/16.
- Sobre la base de la ruta de interfaz estática, R1 ARP para el destino en
iface0 - R2 reconoce que puede llegar al destino y responde al ARP con su propio MAC.
- R1 almacena en caché el resultado ARP que combina una IP en una red remota con el MAC de R2.
Esto sucede para cada destino distinto en 10.1.0.0/16. En consecuencia, a pesar de que el / 16 está correctamente dividido en subredes más allá de R2, y solo hay dos nodos en el enlace contiguo a R1 y R2, R1 sufre una sobrecarga de caché ARP porque induce a R2 a comportarse como si todas las direcciones de 65k estuvieran conectadas directamente.
La razón por la que hago esta pregunta es porque espero que me ayude a entender los informes de problemas del servicio de red (días después) que nos llevaron, eventualmente, al desbordamiento de caché ARP. En el espíritu del modelo StackExchange, traté de aclarar eso a lo que creo que es una pregunta clara y específica que puede responderse objetivamente.
EDITAR 1 Para ser claros, estoy preguntando acerca de parte de la capa de pegamento entre el enlace de datos (capa 2) y la red (capa 3), no la tabla de reenvío MAC dentro de la capa de enlace de datos. Un host o enrutador construye el primero para asignar direcciones IP a direcciones MAC, mientras que un conmutador construye el último para asignar direcciones MAC a puertos.
EDITAR 2 Aunque aprecio el esfuerzo realizado por los respondedores para explicar por qué algunas implementaciones no están sujetas al desbordamiento de caché ARP, creo que es importante que esta pregunta aborde las que sí lo están. La pregunta es "qué sucede cuando", no "es el proveedor X susceptible a". Ya hice mi parte al describir un ejemplo concreto.
EDITAR 3 Otra pregunta que no es esta es "¿cómo evito que el caché ARP se desborde?"