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.
Respostas:
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.
arp timeout 240hold-queue 200 inehold-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).
mac address-table aging-time 14400oumac 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.
fonte
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)
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.
fonte
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.
fonte
Pode-se usar uma pilha de switches para atenuar esse problema de entrada de endereço MAC expirada no segundo switch.
fonte
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.
fonte
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:
Alternativamente:
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)
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):
(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.)
fonte
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:
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.
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.
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.
fonte