La combinación de ECMP (u otras causas de rutas asimétricas) y HSRP se rompe por defecto en Cisco IOS; El comportamiento predeterminado con este diseño inunda excesivamente el tráfico de unidifusión.
¿Cuál es la mejor práctica para usar HSRP con ECMP para evitar inundaciones de unidifusión desconocidas?
Detalles / antecedentes
Tenemos una topología HSRP similar al primer diagrama a continuación para muchas de nuestras instalaciones. Nuestros enrutadores WAN de Cisco tienen rutas de igual costo a todos los demás sitios; así podemos ver efectos de enrutamiento asimétricos todo el tiempo. Normalmente asignamos a R1 como el HSRP primario, pero ECMP permite el tráfico de retorno a través de R1 o R2.
El problema es que cuando la PC1 monta una unidad iSCSI remota a través de la WAN, el tráfico sale del sitio a través de R1, pero podría regresar a través de R2. Mientras el tráfico iSCSI regrese a través de R1, no hay problemas.
El problema ocurre cuando el tráfico de PC1 regresa a través de R2. Suponga que la sesión iSCSI comienza a las 8:00:00, y ambos enrutadores y ambos conmutadores aprenden la PC1 de Mac simultáneamente. Entre las 8:00:00 y las 8:00:05, no hay problemas de inundación porque ambos conmutadores todavía tienen la dirección MAC de la PC1 en su tabla CAM.
Cinco minutos después de que comience la sesión de iSCSI, la entrada CAM de S2 para Mac de PC1 caduca de la tabla CAM y S2 inunda el tráfico de PC1 de todos los puertos (en este caso a Po1, Gi0 / 3 y Gi0 / 4). Si la sesión iSCSI de PC1 consume mucho ancho de banda, esta inundación de unidifusión desconocida puede absorber la capacidad no trivial de los enlaces a PC3 y PC4.
Los switches Cisco IOS tienen un temporizador CAM predeterminado de 300 segundos ...
S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1 300
17 300
Sin embargo, el temporizador ARP de la interfaz predeterminada de Cisco IOS es de 4 horas ...
R2# show interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is AmdP2, address is 000a.dead.beef (bia 000a.dead.beef)
Internet address is 172.17.1.252/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00 <--------------
Por lo tanto, S2 comienza a inundar el tráfico iSCSI de PC1 después de cinco minutos.
Respuestas:
La respuesta simple es hacer que el temporizador CAM sea igual o ligeramente más largo que el temporizador ARP de la interfaz correspondiente , pero hay al menos tres opciones diferentes para seleccionar ...
Opción 1: bajar todos los temporizadores ARP de la interfaz
Esta opción funciona mejor si tiene una red conmutada de capa2 de tamaño decente, un número razonable de entradas ARP y pocas interfaces enrutadas. Este método también es preferible si desea ver que las entradas de Mac para PC caduquen rápidamente de la topología.
arp timeout 240hold-queue 200 inyhold-queue 200 outpara evitar la caída de paquetes ARP durante las actualizaciones periódicas de ARP (estos límites pueden ser mayores o menores dependiendo de cuántas actualizaciones ARP cree que necesitará manejar de una vez). Si está ajustando los valores de Descarte selectivo de paquetes , entonces debe seguir las pautas en el documento que vinculé.Esto obliga a Cisco IOS a actualizar la tabla ARP en cuatro minutos, si no ha sucedido lo contrario para una entrada ARP determinada. La desventaja obvia es que esto no se escala bien si tiene muchas entradas ARP ... los límites varían según la plataforma. He usado esto con unos pocos cientos de ARP por enrutador en Catalyst 4500/6500 (los SVI de Layer3) sin ningún problema.
Opción 2: aumentar el interruptor CAM Temporizadores
Esta opción funciona mejor si tiene una gran cantidad de entradas ARP (es decir, miles, como podría ver un entorno VMWare intenso).
mac address-table aging-time 14400omac address-table aging-time 14400 vlan <vlan-id>para cualquier Vlan que sea preocupante.Este cambio ajusta los temporizadores que la mayoría de las personas suponen que están fijos en 300 segundos (en Cisco IOS), así que asegúrese de incluir esto en los documentos de continuidad. El efecto secundario de esto es que las entradas de la tabla CAM persisten durante 4 horas después de que se retira la PC (que puede ser buena o mala, dependiendo de su PoV). Si 4 horas son demasiado largas, vea la siguiente opción ...
Opción 3: cambie los temporizadores ARP de la interfaz y los temporizadores CAM de conmutador
Esta opción evita los temporizadores CAM horriblemente largos en la Opción 2 a expensas de una mayor configuración. Puede elegir si necesita 900 segundos, 1800 segundos o lo que sea ... solo asegúrese de que sus temporizadores CAM y ARP coincidan; por lo tanto, deberá configurar tanto la Opción 1 como la Opción 2 en sus topologías.
fuente
Para mí, ECMP es el verdadero problema aquí, por lo que, además de los pasos anteriores para limitar las inundaciones de unidifusión desconocidas, también puede ajustar las métricas de ruta hacia la WAN para que R1 sea preferido sobre R2 para el tráfico de retorno. Una forma de lograr esto es a través de la lista de distribución en R2 de la siguiente manera: (EIGRP se usa solo por ejemplo, lo mismo se puede lograr con OSPF o BGP con otros comandos)
Esto dará como resultado que la WAN reenvíe todo el tráfico de 172.17.1.0 a R1. Si R1 Se1 / 0 falla, la ruta se instalará hacia R2. Puede ajustar aún más estas métricas para que la ruta de respaldo a R2 sea realmente un sucesor factible para una conmutación por error más rápida. HSRP y el seguimiento se encargarán del tráfico de salida.
fuente
La idea de no usar ECMP si HSRP está en uso puede estar bien para SERVIDORES donde el tráfico de entrada puede ser mayor que el tráfico de salida, en una situación de PC EN GENERAL el tráfico de entrada de la WAN (respuestas) es mayor que el tráfico de entrada (entrada). Nos gusta que la mayoría de las personas simplemente configuren los temporizadores ARP. puedes meterte con los temporizadores CAM PERO si has dicho un MDF con el interruptor de capa 3 y un IDF con 2 interruptores de colección y decir 5 interruptores de acceso, es MUCHO más fácil configurarlo en el L3 SVI que hacer todos los interruptores de acceso.
fuente
Se podría usar una pila de conmutadores para mitigar este problema de expirar la entrada de la dirección MAC en el segundo conmutador.
fuente
Ah, recuerdo este. Semanas de diversión tuvieron que lidiar con esto hace unos pocos trabajos. Una arruga es que los eventos STP pondrán los vlans en modo de envejecimiento rápido, por lo que configurar el temporizador MAC por más tiempo que el temporizador ARP no ayuda
Resolví el problema obligando a ECMP a regresar de los servidores, creando dos puertas de enlace HSRP flotantes, con una primaria en cada enrutador. Luego configuramos ambas puertas de enlace en cada host. Al forzar el tráfico de host a R1 y R2 de esta manera, estaríamos seguros de que R2 nunca caducaría las direcciones MAC.
Idealmente, esto no sería un problema si los conmutadores L2 / 3 purgaran las entradas ARP asociadas con las direcciones MAC caducadas. El siguiente paquete a la IP daría como resultado una nueva solicitud ARP, completando tanto la caché ARP como la tabla MAC. Creo que Cisco finalmente implementó esto, pero no puedo decirlo con certeza.
fuente
Resumen: MC-LAG o HSRP GARP
Nunca he sido fanático de ajustar los temporizadores. Los temporizadores se configuran de cierta manera, generalmente por muchas razones. Alterándolos:
Alternativamente:
Utilice MC-LAG (también conocido como "MEC" en la documentación de Cisco). Esta es su mejor opción, aunque debe comprender los escenarios de implementación en los que se puede usar MC-LAG (no es una solución universal, y solo debe implementarse después de la investigación y las pruebas adecuadas). Las variantes de MC-LAG dependen del hardware. Ejemplos son:
a. Apilamiento (Cat 3k)
si. VSS (Cat4k / 6k)
C. VPC (Nexus)
re. Pseudo mLACP (ASR1k)
mi. MC-LAG (ASR9k)
F. Agrupación (ASA)
Habilite HSRP para enviar periódicamente paquetes ARP gratuitos . Por supuesto, esto es similar a alterar los temporizadores, pero es una alteración mucho más elegante que manipular la tabla CAM y los temporizadores ARP. (Tenga en cuenta que esto depende de su combinación de hardware y software, no todas las implementaciones de HSRP ofrecen esto).
De forma predeterminada, HSRP envía 3 GARP, a 0, 2 y 4 segundos después de que el enrutador se convierta en la puerta de enlace de reenvío. Sin embargo, hay un parámetro de configuración que le permite elegir el número de GARP (incluido "infinito") y el intervalo.
Uso MC-LAG de manera bastante extensa, particularmente VSS, VPC y Clustering (no soy fanático del apilamiento).
Donde no puedo usar MC-LAG o GLBP, esto es lo que aplico a los enrutadores de límite L2 / L3 de mi campus (tengo un campus de 350 edificios, así que uso bastante Cat6k):
(Publicaría referencias a todo esto, pero no tengo una "reputación" lo suficientemente alta en este sitio para publicar más de dos URL).
fuente
Me acabo de dar cuenta de que mi comentario original es válido, pero lamentablemente incompleto. La recomendación de diseño neutral del proveedor es construir en triángulos, no en rectángulos. Entonces:
No solo MC-LAG, sino MC-LAG en ambas capas. Entonces se trata de una tabla CAM compartida tanto en el nivel del interruptor como en el nivel del enrutador.
Si no puede hacerlo, MC-LAG, ya sea el enrutador o el conmutador, y MC-LAG a la otra capa con un enlace adicional (es decir, malla completa entre enrutadores y conmutadores). STP garantizará una topología sin bucles.
Si no puede hacer eso, aún haga una malla completa de los enrutadores y conmutadores. STP garantizará una topología sin bucles y las tablas CAM de conmutador seguirán conociendo todas las reglas de reenvío MAC apropiadas. El servidor siempre enviará su MAC, y si configura los GARR de HSRP en intervalos de 1 minuto, los conmutadores tampoco olvidarán el vMAC de HSRP.
Las opciones preferidas están en ese orden. Pero al menos, instale ese par adicional de enlaces.
fuente