Introducción
Este documento describe el uso de la inundación del Protocolo de resolución de direcciones (ARP) y la limpieza ARP en el fabric de Infraestructura centrada en aplicaciones (ACI).
Comprensión de la inundación ARP
En Cisco ACI, existe la opción de utilizar la inundación ARP o desactivarla cuando sea necesario. Es obligatorio conocer el comportamiento del fabric con respecto a la inundación ARP para poder resolver los problemas de Capa 2.
Si la inundación ARP está habilitada, el tráfico ARP se inunda dentro del entramado según el manejo ARP regular en las redes tradicionales. La inundación ARP es necesaria cuando se necesitan solicitudes Gratuitous ARP (GARP) para actualizar las memorias caché ARP del host o las memorias caché ARP del router. Esto sucede cuando una dirección IP puede tener una dirección MAC diferente (por ejemplo, con agrupación en clúster de conmutación por error de equilibradores de carga y firewalls).
Si se inhabilita la inundación ARP, el entramado intenta utilizar unicast para enviar el tráfico ARP al destino. Por lo tanto, se produce una búsqueda de Capa 3 para la dirección IP de destino del paquete ARP. ARP se comporta como un paquete de unidifusión de Capa 3 hasta que alcanza el switch de hoja de destino.
Nota: Tenga en cuenta que esta opción sólo se aplica si el ruteo unicast está habilitado en el dominio de bridge. Si el ruteo unicast está inhabilitado, la inundación ARP está habilitada implícitamente.
A continuación, verá algunos casos prácticos con respecto al uso de la inundación ARP.
Caso práctico 1. Los terminales se aprenden en ACI
Este caso práctico se aplica cuando el switch de hoja conoce ambos extremos.
No hay función de la inundación ARP en este escenario. El tráfico se conmuta localmente cuando el switch de hoja conoce su información de terminal. Este comportamiento es el mismo, cuando un punto final, como H1, envía una solicitud ARP hacia el otro (H2), y la inundación ARP está inhabilitada. Dado que el switch de hoja sabe dónde está conectado H2 y verifica la dirección IP de destino ARP (que es una dirección IP H2), no hay necesidad de inundar el tráfico o redirigirlo a la capa de columna. Por lo tanto, envía la solicitud ARP hacia H2.
Independientemente de la configuración del grupo de terminales (EPG), el dominio de puente o la configuración de acceso/encapsulación, si la hoja conoce los terminales, se tratan de la misma manera.
Ejemplo 1. Terminales conocidos por el fabric que funcionan en el mismo EPG, dominio de puente y acceso/encapsulación.
Ejemplo 2. Terminales conocidos por el fabric que funcionan en el mismo EPG, dominio de puente pero con diferente acceso/encapsulación.
Ejemplo 3. Terminales conocidos por el fabric que funcionan en diferentes EPG pero en el mismo dominio de puente.
Cuando se inhabilita la inundación ARP y los puntos finales son parte de los diferentes EPG en el mismo dominio de bridge, mientras están conectados al mismo switch de hoja, el tráfico ARP se rutea localmente si el switch de hoja conoce la dirección IP de destino ARP (el ruteo unicast está habilitado).
Caso práctico 2. Los terminales se aprenden en COOP
Este caso práctico se aplica cuando ambos extremos están conectados a switches de hoja diferentes; presentes en la base de datos de protocolo cooperativo (COOP) del switch de columna.
La solicitud ARP debe ser reenviada a través del entramado. El flujo de tráfico ARP de H1 a H3 es:
-
H1 envía una solicitud ARP para H3 mediante un MAC de destino de difusión.
-
La ACI intenta utilizar el reenvío de unidifusión para enviar la solicitud ARP, por lo que el switch de hoja local verifica la dirección IP de destino ARP, que es la dirección IP H3. Dado que el switch de hoja local no conoce la dirección IP del punto final H3, envía la solicitud ARP al switch de columna para el proxy de columna.
-
La columna tiene la información H3 en la base de datos COOP (el ruteo unicast está habilitado) y reenvía la solicitud ARP al switch de hoja de destino a través de la estructura, que la reenvía a H3. Una vez que H3 recibe el tráfico, responde a H1.
Nota: El mecanismo mencionado se aplica a los tres escenarios.
Ejemplo 1. Terminales conocidos por el fabric que funcionan en el mismo EPG, dominio de puente y acceso/encapsulación.
Ejemplo 2. Terminales conocidos por el fabric que funcionan en el mismo EPG, dominio de puente pero con diferente acceso/encapsulación.
Ejemplo 3. Terminales conocidos por el fabric que funcionan en diferentes EPG pero en el mismo dominio de puente.
Caso práctico 3. IP de destino desconocida, inundación ARP desactivada
Este caso práctico se aplica cuando Ingress Leaf no conoce la ubicación de la dirección IP de destino (inundación ARP deshabilitada, ruteo unicast habilitado).
En un escenario similar, cuando se inhabilita la inundación ARP y la hoja de ingreso no sabe dónde está ubicada la dirección IP de destino ARP, se envía una solicitud ARP al punto final del túnel del proxy de la columna de difusión por proximidad (TEP) en lugar de inundarse. El flujo de tráfico ARP de H1 a H2 es:
-
H1 envía una solicitud ARP para H2 mediante un MAC de destino de difusión.
-
La ACI intenta utilizar el reenvío de unidifusión para enviar la solicitud ARP. El switch de hoja local no conoce la dirección IP del terminal H2 (la IP de destino ARP es desconocida para la hoja de ingreso), por lo que envía la solicitud ARP al switch de columna para el proxy de columna.
-
Dado que falta información del punto final H2 de la base de datos COOP en el switch de columna, la columna descarta el paquete original, pero en lugar de ello, activa la captura ARP para detectar la IP de destino, de modo que las solicitudes ARP subsiguientes no se descartan.
Ejemplo 1. Independientemente de la configuración de EPG, dominio de puente o acceso/encapsulación, el flujo de solicitudes ARP sigue siendo el mismo que se mencionó anteriormente.
Caso práctico 4. IP de destino desconocida, inundación ARP habilitada
Este caso práctico se aplica cuando Ingress Leaf no conoce la ubicación de la dirección IP de destino (inundación ARP habilitada, routing unidifusión habilitado).
Si la inundación ARP está habilitada en el dominio de bridge, la solicitud ARP de H1 alcanza H2 a través de la inundación. El flujo de tráfico ARP de H1 a H2 es:
-
H1 envía una solicitud ARP para H2 mediante un MAC de destino de difusión.
-
La solicitud ARP se inunda a todas las interfaces en el dominio de bridge. H2 recibe la trama y responde, mientras que se aprende en el entramado.
Ejemplo 1.
Nota: la saturación de la encapsulación en Cisco ACI (dominio de puente o nivel EPG) se puede utilizar para limitar la saturación del tráfico dentro del dominio de puente a una sola encapsulación. Cuando dos EPG comparten el mismo dominio de bridge y se habilita la Inundación en encapsulación, el tráfico de inundación de EPG no llega al otro EPG.
Una de las ventajas de habilitar la inundación ARP es poder detectar una IP silenciosa que se movió de una ubicación a otra sin notificar una hoja de ACI. Debido a que la solicitud ARP se inunda dentro del dominio de bridge, incluso si la hoja de ACI todavía piensa que la IP está en la ubicación antigua, el host con la IP silenciosa responde apropiadamente para que la hoja de ACI pueda actualizar su entrada en consecuencia.
Si la inundación ARP está inhabilitada, la hoja ACI continúa reenviando la solicitud ARP solamente a la ubicación antigua hasta que el punto final IP caduca. Por otro lado, la ventaja de inhabilitar la inundación ARP es poder optimizar el flujo de tráfico enviando la solicitud ARP directamente a la ubicación de la IP de destino, asumiendo que ningún terminal se mueve sin notificar su movimiento a través de GARP y similares.
Caso práctico 5. Terminales en diferentes EPG y BD
Este caso práctico se aplica cuando los terminales están conectados en diferentes EPG y diferentes dominios de puente.
Cuando los terminales forman parte de los diferentes EPG y dominios de puente diferentes, el tráfico entre ellos debe enrutarse. La inundación no cruza los dominios de puente, incluida la inundación ARP. Por lo tanto, si H1 necesita comunicarse con H2, que está conectado en el mismo switch de hoja, el tráfico se envía hacia la dirección MAC del gateway predeterminado, por lo que la inundación ARP no es relevante en este ejemplo.
Comprensión de ARP Gleaning
Cisco ACI dispone de varios mecanismos para detectar hosts silenciosos, en los que una hoja de ACI no ha aprendido un terminal local. ACI dispone de algunos mecanismos para detectar estos hosts silenciosos. Para el tráfico conmutado de Capa 2 a un MAC desconocido, puede configurar la opción Unicast Desconocido de Capa 2 bajo el Dominio de Bridge (BD) para saturar, mientras que para las solicitudes ARP con un MAC de destino de broadcast, puede utilizar la opción de inundación ARP bajo el dominio de bridge para controlar el comportamiento de inundación. Además, Cisco ACI utiliza la limpieza ARP para enviar solicitudes ARP a fin de resolver la dirección IP de un terminal que aún no se ha detectado (detección de host silencioso).
Con la limpieza ARP, si la columna no tiene información sobre dónde está conectado el destino de la solicitud ARP (la IP de destino no está en la base de datos COOP), el entramado genera una solicitud ARP que se originó desde la dirección IP de la Interfaz Virtual de Switch (SVI) (gateway ubicuo) del dominio bridge. Esta solicitud ARP se envía a todas las interfaces de borde de los nodos de hoja que forman parte del dominio de bridge. Además, la limpieza ARP se activa para el tráfico ruteado (Capa 3) independientemente de la configuración, como la inundación ARP, siempre y cuando el tráfico se rutee a una IP desconocida.
La limpieza ARP tiene algunos requisitos:
-
La dirección IP se utiliza para el reenvío (solicitudes ARP con inundación ARP desactivada o tráfico a través de subredes con ACI BD SVI como gateway)
-
Routing unidifusión habilitado
-
Subred creada bajo el dominio de bridge
Caso práctico 1. IP de destino desconocida, inundación ARP desactivada
Este caso práctico se aplica cuando el fabric desconoce el terminal de destino (inundación ARP deshabilitada).
Cuando los terminales están en switches de hoja diferentes, mientras forman parte del mismo EPG y del mismo dominio de puente, y utilizan la misma asignación de acceso VLAN, la solicitud ARP (por ejemplo, de H1 a H3) debe reenviarse a través del fabric. Si falta información H3 de la base de datos COOP en el switch de columna (host silencioso) y la inundación ARP está inhabilitada, la limpieza ARP también se puede utilizar como se muestra en esta figura.
El flujo de tráfico ARP de H1 a H3 es:
-
H1 envía una solicitud ARP para H3 mediante un MAC de destino de difusión.
-
La ACI intenta utilizar el reenvío de unidifusión para enviar la solicitud ARP, por lo que el switch de hoja local verifica la dirección IP de destino ARP (IP H3). Dado que el switch de hoja local no conoce la dirección IP del punto final H3, envía la solicitud ARP al switch de columna para el proxy de columna.
-
Falta la información H3 de la base de datos COOP en el conmutador central y activa la limpieza ARP utilizando la dirección IP de gateway ubicua como origen. Esta solicitud ARP se inunda en el dominio.
-
H3 recibe la solicitud ARP y responde, mientras que se aprende en el entramado.
Independientemente de la configuración de EPG, dominio de puente o acceso/encapsulación, la función ARP glean funciona de la misma manera cuando dos terminales intentan comunicarse entre sí (independientemente de su conectividad con el mismo switch de hoja o con uno diferente dentro del fabric).
Caso práctico 2. Terminales en diferentes EPG y BD
Este caso práctico se aplica cuando los terminales están conectados en diferentes EPG y dominios de puente (inundación ARP habilitada).
Cuando los terminales forman parte de los diferentes EPG y dominios de puente diferentes, el tráfico entre ellos debe enrutarse. La inundación no cruza los dominios de puente, incluida la inundación ARP que puede ser generada por la limpieza ARP. Por lo tanto, si H1 necesita comunicarse con H2, que está conectado en el mismo switch de hoja, el tráfico se envía hacia la dirección MAC del gateway predeterminado, por lo que la limpieza ARP no es relevante en este ejemplo.