Prática recomendada para a combinação de HSRP e ECMP

A combinação de ECMP (ou outras causas de caminhos assimétricos) e HSRP é interrompida por padrão no Cisco IOS; o comportamento padrão com esse design inunda o tráfego unicast excessivamente.

Qual é a melhor prática para usar o HSRP com ECMP para evitar inundações unicast desconhecidas?

Detalhes / Histórico

Temos uma topologia HSRP semelhante ao primeiro diagrama abaixo para muitas de nossas instalações. Nossos roteadores WAN da Cisco têm rotas de custo igual para todos os outros sites; assim, podemos ver efeitos de roteamento assimétrico o tempo todo. Normalmente, atribuímos R1 ao HSRP primário, mas o ECMP permite o tráfego de retorno por R1 ou R2.

O problema é que, quando o PC1 monta uma unidade iSCSI remota na WAN, o tráfego sai do site via R1, mas pode retornar via R2. Enquanto o tráfego iSCSI retornar via R1, não haverá problemas.

O problema ocorre quando o tráfego do PC1 retorna via R2. Suponha que a sessão iSCSI inicie às 8:00:00, e os roteadores e os dois switches aprendam o mac do PC1 simultaneamente. Entre 8:00:00 e 8:00:05, não há problemas de inundação porque os dois switches ainda têm o endereço mac do PC1 em sua tabela CAM.

Cinco minutos após o início da sessão iSCSI, a entrada CAM do S2 para o mac do PC1 expira da tabela CAM e o S2 inunda o tráfego do PC1 em todas as portas (nesse caso, para Po1, Gi0 / 3 e Gi0 / 4). Se a sessão iSCSI do PC1 consumir muita largura de banda, essa inundação unicast desconhecida poderá sugar capacidade não trivial dos links para o PC3 e PC4.

Os switches Cisco IOS têm um temporizador CAM padrão de 300 segundos ...

S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1    300
17   300

No entanto, o temporizador ARP da interface padrão do Cisco IOS é 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       <--------------

Portanto, o S2 começa a inundar o tráfego iSCSI do PC1 após cinco minutos.

A resposta simples é tornar o temporizador CAM igual ou ligeiramente mais longo que o temporizador ARP da interface correspondente , mas há pelo menos três opções diferentes para selecionar entre ...

Opção 1: abaixe todos os temporizadores ARP da interface

Esta opção funciona melhor se você tiver uma rede comutada layer2 de tamanho decente, um número razoável de entradas ARP e poucas interfaces roteadas. Esse método também é preferível se você quiser ver rapidamente as entradas do Mac para PC fora da topologia.

• Em todas as interfaces Ethernet IOS que enfrentam um comutador Ethernet: arp timeout 240
• Em todas as interfaces Ethernet IOS que enfrentam um comutador Ethernet: hold-queue 200 ine hold-queue 200 outpara evitar a queda de pacotes ARP durante atualizações periódicas do ARP (esses limites podem ser mais altos ou mais baixos, dependendo de quantas atualizações do ARP você achar que precisará manipular ao mesmo tempo). Se você estiver ajustando os valores de Descarte seletivo de pacotes , siga as diretrizes no artigo que eu vinculei.

Isso força o Cisco IOS a atualizar a tabela ARP em quatro minutos, se isso não acontecer de outra maneira para uma determinada entrada ARP. A desvantagem óbvia é que isso não aumenta de tamanho se você tiver muitas entradas de ARP ... os limites variam de acordo com a plataforma. Eu usei isso com algumas centenas de ARPs por roteador no Catalyst 4500/6500 (os SVIs da Camada3) sem problemas.

Opção 2: Aumente o temporizador CAM do switch

Esta opção funciona melhor se você tiver um grande número de entradas ARP (ou seja, milhares, como um ambiente VMWare intenso poderia ver).

• Em todos os comutadores IOS:, mac address-table aging-time 14400ou mac address-table aging-time 14400 vlan <vlan-id>para qualquer Vlan que seja preocupante.

Essa alteração ajusta os temporizadores que a maioria das pessoas supõe que sejam corrigidos em 300 segundos (no Cisco IOS), portanto, inclua isso nos documentos de continuidade. O efeito colateral disso é que as entradas da tabela CAM permanecem por 4 horas após a remoção do PC (o que pode ser bom ou ruim, dependendo do seu PoV). Se 4 horas for muito longa, veja a próxima opção ...

Opção 3: Altere os temporizadores ARP da interface e os temporizadores CAM do switch

Esta opção evita medidores de tempo CAM horrivelmente longos na Opção 2 à custa de mais configurações. Você pode escolher se precisa de 900 segundos, 1800 segundos ou o que for ... apenas verifique se os temporizadores CAM e ARP correspondem; portanto, você precisará configurar as opções 1 e 2 em suas topologias.

Para mim, o ECMP é o verdadeiro problema aqui - portanto, além das etapas acima para limitar a inundação unicast desconhecida, você também pode ajustar as métricas da rota em direção à WAN para que R1 seja preferido em vez de R2 no tráfego de retorno. Uma maneira de conseguir isso é através da lista de distribuição no R2, da seguinte maneira: (EIGRP usado apenas por exemplo, o mesmo pode ser alcançado com OSPF ou BGP com outros comandos)

!
lista de prefixos ip R1-PREFER seq 5 permitir 172.17.1.0/24
!
rota-mapa R1-PREFER-MAP permitir 10
 corresponde à lista de prefixos do endereço IP R1-PREFER
 definir métrica 1 1 1 1 1
... (permitir todas as outras rotas)
!
roteador eigrp 1
 ....
 mapa de rotas da lista de distribuição R1-PREFER-MAP out Ser1 / 0
 ....
!

Isso resultará na WAN encaminhando todo o tráfego para 172.17.1.0 para R1. Se R1 Se1 / 0 falhar, a rota será instalada em direção ao R2. Você pode ajustar ainda mais essas métricas para que a rota de backup para o R2 seja realmente um sucessor possível para um failover mais rápido. O HSRP e o rastreamento cuidarão do tráfego de saída.

A idéia de não usar o ECMP se o HSRP estiver em uso pode ser boa para SERVERS em que o tráfego de entrada pode ser maior que o tráfego de saída, em uma situação de PC EM GERAL, o tráfego de entrada da WAN (respostas) é maior que o tráfego de saída (entrada). Gostamos que a maioria das pessoas defina os temporizadores do ARP. você pode mexer com os temporizadores CAM, mas se você digitar um MDF com o comutador de camada 3 e um IDF com 2 comutadores de coleta e dizer 5 comutadores de acesso, é MUITO mais fácil de configurar no L3 SVI do que fazer todos os comutadores de acesso.

Pode-se usar uma pilha de switches para atenuar esse problema de entrada de endereço MAC expirada no segundo switch.

Ah, eu lembro desse. Semanas de diversão foram tratadas com isso alguns empregos atrás. Uma desvantagem é que os eventos STP colocam as vlans no modo de envelhecimento rápido, portanto, definir o temporizador MAC por mais tempo do que o temporizador ARP não ajuda

Resolvi o problema forçando o ECMP de volta dos servidores, criando dois gateways HSRP flutuantes, com um primário em cada roteador. Em seguida, configuramos os dois gateways em cada host. Ao forçar o tráfego do host para R1 e R2 dessa maneira, teríamos certeza de que o R2 nunca ultrapassaria os endereços MAC.

Idealmente, isso não seria um problema se os comutadores L2 / 3 eliminassem as entradas ARP associadas aos endereços MAC antigos. O próximo pacote para o IP resultaria em uma nova solicitação ARP, preenchendo o cache ARP e a tabela MAC. Acho que a Cisco acabou implementando isso, mas não posso dizer com certeza.

Resumo: MC-LAG ou HSRP GARP

Eu nunca fui fã de ajustar temporizadores. Os temporizadores são definidos de uma certa maneira, geralmente por vários motivos. Alterando-os:

• é potencialmente operacionalmente intenso para manter em todos os lugares a mesma
• torna as coisas mais complicadas e difíceis de solucionar
• como mostrou um comentarista recente, pode ter efeitos colaterais inesperados
• pode não "funcionar bem" com futuros aprimoramentos da Cisco

Alternativamente:

1. Use MC-LAG (aka "MEC" na documentação da Cisco). Esta é sua melhor opção, embora você deva entender os cenários de implantação nos quais o MC-LAG pode ser usado (não é uma solução universal e só deve ser implantada após pesquisas e testes apropriados). As variantes do MC-LAG dependem do hardware. Exemplos são:

   uma. Empilhamento (Cat 3k)

   b. VSS (Cat4k / 6k)

   c. VPC (Nexus)

   d. Pseudo mLACP (ASR1k)

   e MC-LAG (ASR9k)

   f. Agrupamento (ASA)

2. Habilite o HSRP para enviar periodicamente pacotes ARP gratuitos . É verdade que isso é semelhante à alteração de cronômetros, mas é uma alteração muito mais graciosa do que manipular a tabela CAM e os cronômetros ARP. (Observe que isso depende da combinação de hardware e software, nem todas as implementações do HSRP oferecem isso.)

   Por padrão, o HSRP envia 3 GARPs, em 0, 2 e 4 segundos após o roteador se tornar o gateway de encaminhamento. No entanto, há um parâmetro de configuração que permite escolher o número de GARPs (incluindo "infinito") e o intervalo.

Eu uso o MC-LAG bastante extensivamente, particularmente VSS, VPC e Clustering (não sou fã de empilhamento).

Onde não posso usar o MC-LAG ou o GLBP, é isso que aplico aos meus roteadores de limite L2 / L3 do campus (eu tenho um campus de 350 edifícios e uso muito o 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 

(Eu publicaria referências a tudo isso, mas não tenho uma "reputação" alta o suficiente neste site para postar mais de dois URLs.)

Acabei de perceber que meu comentário original é válido - mas lamentavelmente incompleto. A recomendação de design neutro do fornecedor é construir em triângulos, não retângulos. Então:

1. Não apenas o MC-LAG, mas o MC-LAG nas duas camadas. Então você está lidando com uma tabela CAM compartilhada no nível do switch e do roteador.

2. Se você não puder fazer isso, MC-LAG o roteador ou o switch e MC-LAG para a outra camada com link adicional (ou seja, malha completa entre roteadores e switches). O STP garantirá a topologia sem loop.

3. Se você não puder fazer isso, ainda faça a malha completa dos roteadores e switches. O STP garantirá a topologia sem loop, e as tabelas CAM do switch ainda conhecerão todas as regras de encaminhamento MAC apropriadas. O servidor sempre envia seu MAC e, se você configurar os HSP GARPS em intervalos de 1 minuto, os comutadores também não esquecerão o HSRP vMAC.

As opções preferidas estão nessa ordem. Mas, no mínimo, instale esse par extra de links.