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?"
Respuestas:
Edición 2 :
Como lo mencionaste...
Obliga a Brocade a proxy-arp para cada destino en 10.1.0.0/16 como si estuviera directamente conectado
iface0.No puedo responder sobre la implementación de caché ARP de Brocade, pero simplemente señalaría la solución fácil a su problema ... configure su ruta de manera diferente:
Al hacer esto, evita que Brocade ARP-ing para todo 10.1.0.0/16 (nota, es posible que deba renumerar el enlace entre R1 y R2 para estar fuera de 10.1.0.0/16, dependiendo de la implementación de las cosas de Brocade) .
Respuesta original :
Los enrutadores Cisco IOS CPU solo están limitados por la cantidad de DRAM en el enrutador, pero eso generalmente no será un factor limitante. Algunos conmutadores (como Catalyst 6500) tienen una limitación estricta en la tabla de adyacencia (que está correlacionada con la tabla ARP); Sup2T tiene 1 millón de adyacencias .
Los enrutadores Cisco IOS CPU no se quedan sin espacio en la tabla ARP, porque esos ARP se almacenan en DRAM. Supongamos que estás hablando de Sup2T. Piénselo de esta manera, suponga que tiene un Cat6500 + Sup2T y configuró todos los Vlans posibles, técnicamente eso es
Suponga que hace que cada Vlan sea un / 24 (es decir, 252 ARP posibles), y empaca cada Vlan completo ... eso es 1 millón de entradas ARP.
Cada uno de esos ARP consumiría una cierta cantidad de memoria en la propia tabla ARP, más la tabla de adyacencia IOS. No sé qué es, pero digamos que la sobrecarga total de ARP es de 10 bytes ...
Eso significa que ahora ha consumido 10 MB para gastos generales ARP; todavía no es mucho espacio ... si tuvieras tan poca memoria, verías algo así
%SYS-2-MALLOCFAIL.Con tantos ARP y un tiempo de espera de ARP de cuatro horas, tendría que dar servicio a casi 70 ARP por segundo en promedio; es más probable que el mantenimiento de 1 millón de entradas ARP agote la CPU del enrutador (posiblemente mensajes de CPUHOG).
En este punto, puede comenzar a rebotar las adyacencias del protocolo de enrutamiento y tener direcciones IP que son simplemente inalcanzables porque la CPU del enrutador estaba demasiado ocupada para ARP para la IP.
fuente
La única experiencia real que tuve con este hecho fue en los conmutadores C3550 (límite de MAC de 2-8k, dependiendo de la plantilla sdm) y allí se eliminó la entrada más antigua de la tabla.
fuente
Para IOS y JunOS y otras pilas comerciales que solo tienes que probar, por suerte no es muy difícil.
Pero para linux , freebsd, netbsd, openbsd, uIP, lwIP y probablemente muchas otras implementaciones, simplemente puede verificar su código fuente para el comportamiento.
En Linux, debe marcar 'net / core / neighbour.c' (comience con la línea 'if (entradas> = tbl-> gc_thresh3' || ') y' net / ipv4 / arp.c '.
En Linux parece que tener tres niveles completos
Cuando gc_thresh3 intenta exceder, intenta forzar la ejecución de la recolección de basura, a menos que ya se haya ejecutado recientemente. La recolección de basura parece eliminar las entradas a las que ya no se hace referencia, por lo que no significa más antiguo o más nuevo, sin embargo, gc_staletime exceder parece ser una forma de desreferenciar la entrada, que nuevamente se traduce en la entrada más antigua.
Si no se puede ejecutar la recolección de basura, simplemente no se agrega una nueva entrada. Todos estos intervalos de recolección de basura periódica y gc_threshN se pueden ajustar.
El código es independiente de la familia de direcciones (ipv4, ipv6), por lo que las tablas IPv6 ND e IPv4 ARP se manejan exactamente con la misma ruta de código, no ruta duplicada.
fuente
Arpiaría para la dirección IP almacenarlo en la tabla y, dependiendo de la implementación, debería eliminar la entrada más antigua. El impacto en el rendimiento depende, si esta es una ocurrencia infrecuente, no hay mucho impacto, pero este es un vector de ataque para que alguien pueda enviar muchas arps que afecten la utilización del procesador
fuente
El conmutador irá a ARP para que la IP de destino obtenga su dirección MAC (que también llenaría la tabla CAM con la respuesta). La solicitud ARP se transmite a todos los puertos. Esto requiere la CPU e implica el
ARP Inputproceso. Si las solicitudes ARP son para la misma IP, debido a que la tabla ARP se desborda con frecuencia, el conmutador debe limitar la velocidad del ARP a una vez cada dos segundos. Si las solicitudes son IP aleatorias con suficiente frecuencia, la CPU puede aumentar cuando esa CPU está involucrada tanto en las solicitudes ARP como en las respuestas.fuente
De los ataques que aprendí en los switches Cisco 3550, 3560, etc., puede convertirlos en hub gigante una vez que sobrecargue el límite de la dirección MAC. Los conmutadores tienen un límite establecido de dirección MAC (alrededor de 6000) que se puede almacenar, y una vez que se alcanza ese límite, inundará todos los datos de sus interfaces. No recuerdo si eso se aplica a los paquetes 802.1q porque no he tenido que hacerlo en mucho tiempo. Puede que tenga que encender mi laboratorio de red en casa para averiguarlo.
fuente