Cisco ACI Bridge Domain, L2 Unknown Unicast: Hardware Proxy vs Flooding Mode
Antes de empezar, vamos a asegurarnos una vez más de que entendemos bien qué es el dominio puente en ACI. El dominio del puente puede compararse con un interruptor gigante. Cisco ACI conserva la semántica de enrutamiento de capa 2, incluso si el tráfico se enruta en Fabric. El TTL no se reduce para el tráfico de capa 2, y las direcciones MAC de los puntos finales de origen y destino se conservan.
Enrutamiento Unicast, permite que el Dominio Puente enrute el tráfico y aprenda las direcciones IP de los puntos finales (endpoints).
La mejor práctica es no habilitar esta opción cuando la puerta de enlace predeterminada para los endpoints no sea
Cuando la puerta de enlace predeterminada para los endpoints no sea la interfaz virtual de conmutación (SVI), el
Cuando se configura el bridge domain en ACI, hay que decidir qué se quiere hacer con los paquetes ARP y qué se quiere hacer con L2 Unknown Unicast. Básicamente uds, pueden:
* Habilitar o no el ARP Flooding.
* Elija entre los dos modos L2 Unknown Unicast: Flood y Hardware Proxy.
La mejor práctica es establecer esta opción en Activado cuando hay servidores agrupados, cortafuegos o Balenceadores de carga para que GARP sea inundada.
En ACI BD, a diferencia de las redes tradicionales, se puede optimizar Unknown Unicast con la tecnología Hardware-proxy, pero se suele utilizar como Flood porque muchas vezes ACI se suele implementar como una red L2 pura.
Puede habilitar el flooding mode: si no se conoce la dirección MAC de destino, inunda el bridge domain. Por defecto, el tráfico ARP no se inunda, sino que se envía al endpoint de destino. Al activar el modo de inundación ARP, el tráfico ARP también se inunda.
Este modo de funcionamiento es equivalente al de un conmutador de capa 2 regular, salvo que en Cisco ACI este tráfico se transporta en el fabric como una estructura de capa 3 con todas las ventajas del multipathing de capa 2, la convergencia rápida, etc.
El Hardware proxy unknown unicast y ARP flooding, son dos modos de funcionamiento opuestos. Con el Hardware proxy
desactivado y sin inundación de unicast y ARP, la conmutación de capa 2 no funcionaría. La ventaja de deshabilitar el hardware-based proxy y utilizar la inundación para hosts desconocidos y ARP es que el fabric no necesita aprender millones de direcciones IP de origen procedentes de un puerto determinado.
Un buen caso de uso para habilitar la ARP flooding sería cuando la puerta de enlace predeterminada reside fuera del ACI Fabric. Esta configuración no ideal requerirá la activación del ARP Flooding en la BD. Si no activas el enrutamiento ip porque quieres usar la BD como un dominio L2 puro, entonces mantenga activada la unicast flooding
2 Proxy de hardware
Si no se conoce el destino en el leaf, se envía al proxy Spine. Si Spine tampoco conoce la dirección, descarta el paquete. La ventaja del modo de Hardware Proxy es que no se producen inundaciones en el fabric. La desventaja potencial es que el fabric tiene que aprender todas las direcciones de los endpoints (puntos finales).
La ventaja del modo HardwareProxy es que no se producen inundaciones en el tejido. La desventaja potencial es que el tejido tiene que aprender todas las direcciones de los puntos finales.
Sin embargo, con Cisco ACI, esto no es una preocupación con los servidores virtuales y físicos que forman parte del tejido: la base de datos está construida para la escalabilidad a millones de puntos finales. Sin embargo, si el tejido tuviera que aprender todas las direcciones IP procedentes de Internet, está claro que no sería escalable.
Conclusión:
Podemos decir que cuando usamos la opción de flooding entonces el unknown unicast dentro del dominio brigde estará inundando todos los puertos de ese dominio brigde para saber y determinar dónde está el dispositivo que queremos encontrar, esta es la misma operación que un switch tradicional y esta opción de flooding en el Bridge Domain es cuando estamos comenzando nuestra implementación de ACI y tenemos el Bridge Domain trabajando como capa 2 pura y con nuestra puerta de enlace por defecto fuera de ACI, la capa 3 todavía no puede influir porque queremos influenciar para que funcione como una capa 2 así que usamos esta opción de flooding.
Opción de hardware proxy, unknown anycast el tráfico que se dirige a un host específico aquí no es conocido por leaf por lo que va a ser dirigido al Spine por lo que leaf va a tomar ese unicast unkonwn y en lugar de inundar el brigde domain para tratar de averiguar dónde está ese tipo va a enviarlo al Spine vertebral que es la que mantiene las tablas y conoce todos los dispositivos que están conectados en todos los leafs, después de eso el Spine encuentra ese dispositivo reenviará el tráfico a ese dispositivo o si no encuentra ese dispositivo, descargará ese tráfico porque asumirá que ese dispositivo o no existe o no está disponible en el tejido en ese instante.
Eso es todo por ahora, un gran abrazo para todos y si lo conoces, deja un like para apoyar mi trabajo
Saludos