Mejores prácticas para la combinación de HSRP y ECMP

19

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.

HSRP_Broken_00

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.

HSRP_Broken_01

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.

HSRP_Broken_02

Mike Pennington
fuente
¿Por qué la gente sigue publicando preguntas y luego respondiéndolas? No como en, buscaron y encontraron la respuesta, ¿ya la tenían? Este es un sitio de preguntas y respuestas, no un blog (¡no es que no hayas escrito bien!)
jwbensley
8
@javano: la respuesta automática es explícitamente alentada por SE. ref meta.networkengineering.stackexchange.com/questions/4/…
Craig Constantine
1
@CraigConstantine Sí, lo sé, pero estoy seguro de que las personas publican preguntas y luego responden directamente después, no un período de tiempo más tarde cuando han descubierto la respuesta a la pregunta (incluso si solo son 5 minutos más tarde), responden directamente. porque ya sabían la respuesta antes de publicar la pregunta. Esto me parece un poco extraño.
jwbensley
66
Sin embargo, el hecho es que escribir una Q y una respuesta inmediata se recomienda explícitamente.
Craig Constantine
44
@javano, si resuelve un problema que cree que otras personas enfrentarán, SE desea que el tráfico del motor de búsqueda resuelva ese problema ... no les importa si publico la respuesta al mismo tiempo o no ... de hecho, hay una pequeña casilla de verificación en la parte inferior del formulario web de preguntas para "Responder su propia pregunta: comparta sus conocimientos, preguntas y respuestas al estilo"
Mike Pennington

Respuestas:

14

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.

  • En todas las interfaces Ethernet IOS que enfrentan un conmutador Ethernet: arp timeout 240
  • En todas las interfaces ethernet IOS que se enfrentan a un conmutador ethernet: hold-queue 200 iny hold-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).

  • En todos los conmutadores IOS: mac address-table aging-time 14400o mac 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.

Mike Pennington
fuente
44
Resolvimos este problema eligiendo la primera solución propuesta, pero no estábamos seguros del orden en que IOS limpiaría la tabla, luego configuramos el tiempo de espera de ARP en 293s (el número primo más cercano debajo del tiempo de espera de la tabla de direcciones MAC). Todavía no sé si esta fue una buena opción o no
Marco Marzetti
1
Técnicamente, Cisco IOS dispara el caminante ARP en intervalos de 60 segundos, por lo que debe usar 240 ... No incluí eso en mi respuesta ... editándolo ... Tengo curiosidad por qué eligió un número primo ...
Mike Pennington
ACK. El tiempo de espera ARP menor o igual que el tiempo de espera MAC debe ser BCP. Ni siquiera es necesario que haya HSRP, solo si hay dos enrutadores puede morderte y causar incluso bucles.
ytti
No lo sabia Entonces nuestro truco es totalmente inútil. Elegimos un número primo para minimizar la superposición de los temporizadores.
Marco Marzetti
44
@ MikePennington, gracias. De todos modos tiene razón La resolución de tiempo de espera ARP se implementa en minutos
Marco Marzetti
1

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)

!
ip prefix-list R1-PREFER seq 5 permit 172.17.1.0/24
!
mapa de ruta R1-PREFER-MAP permiso 10
 coincidir con la lista de prefijos de la dirección IP R1-PREFERIR
 establecer métrica 1 1 1 1 1
... (permitir todas las demás rutas)
!
enrutador eigrp 1
 ....
 distribuir-lista ruta-mapa R1-PREFER-MAP out Ser1 / 0
 ....
!

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.

liso
fuente
esencialmente estás respondiendo la pregunta que quieres, en lugar de mi pregunta ... que requiere fhrp y ecmp
Mike Pennington
lo siento, me estoy acostumbrando a este foro y he perdido ese requisito.
smoothbSE
No hay problema ... bienvenido a NE :)
Mike Pennington
0

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.

fredpbaker
fuente
0

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.

Eugene Smirnov
fuente
0

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.

graznar
fuente
0

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:

  • es potencialmente intensivo desde el punto de vista operativo para mantener lo mismo en todas partes
  • hace las cosas más complicadas y difíciles de solucionar
  • como mostró un comentarista reciente, puede tener efectos secundarios inesperados
  • puede no "jugar bien" con futuras mejoras de Cisco

Alternativamente:

  1. 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)

  2. 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):

Cat6k-v15(config)#interface vlan 100
Cat6k-v15(config-if)#standby arp ?
  gratuitous  Setup gratuitous ARP interval and count

Cat6k-v15(config-if)#standby arp gratuitous ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count ?
  <0-60>  Number of gratuitous ARPs to send after group is activated (0 for continuous)

Cat6k-v15(config-if)#standby arp gratuitous count 0 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval ?
  <3-1800>  Gratuitous ARP Interval (sec)

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 

(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).

Weylin Piegorsch
fuente
Lo que llama MC-LAG es ciertamente una opción, pero su disponibilidad en las plataformas IOS clásicas es irregular. También me falta cómo HSRP Gratuitous ARP ayuda a resolver este problema. Usando el ejemplo en mi pregunta, ¿podría explicar cómo HSRP Gratuitous ARP resuelve el tiempo de espera de entrada de ARP de 172.17.1.1? Tenga en cuenta que el GW predeterminado es 172.17.1.254
Mike Pennington
Respuesta larga, así que déjame dividir esto en dos partes. Parte 1 ... El problema con HSRP es que el enrutador responde a una consulta ARP con el MAC virtual. Sin embargo, cuando el enrutador reenvía un datagrama al host, utiliza la dirección MAC física . Los conmutadores borran su tabla de reenvío con bastante rapidez (a menudo 300 segundos o 5 minutos), pero las entradas ARP a menudo se quedan mucho más tiempo que eso (8 horas es común).
Weylin Piegorsch
Parte 2 ... Después de que el conmutador agota el tiempo de espera de la dirección MAC virtual de la tabla de reenvío, el tráfico del servidor al MAC virtual se convierte en "unidifusión desconocida", donde el conmutador adopta de manera predeterminada un comportamiento similar al concentrador e inunda todo el tráfico. puertos Al enviar periódicamente un GARP, el enrutador actualiza la tabla de reenvío de conmutadores. Además, al enviar un GARP, la tabla ARP en el servidor se actualiza, eliminando la necesidad de enviar una consulta ARP.
Weylin Piegorsch
Secundario a mi respuesta de 2 partes, me di cuenta de que la pregunta se hace desde la dirección opuesta: la dirección MAC del servidor se está descargando de los conmutadores, no del MAC virtual del enrutador. Tuvimos este problema específico y terminamos resolviéndolo inicialmente a través de MC-LAG (específicamente VPC), y más tarde, como ya estábamos usando Nexus, cambiamos a FabricPath, también conocido como TRILL, lo que hizo que el problema desapareciera. Pero, ambos dependen del hardware y la topología.
Weylin Piegorsch
Me acabo de dar cuenta de que mi comentario original es válido, pero lamentablemente incompleto. 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.
Weylin Piegorsch
0

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:

  1. 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.

  2. 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.

  3. 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.

Weylin Piegorsch
fuente