Meilleure pratique pour la combinaison de HSRP et ECMP

19

La combinaison d' ECMP (ou d'autres causes de chemins asymétriques) et HSRP est cassée par défaut dans Cisco IOS; le comportement par défaut avec cette conception inonde excessivement le trafic unicast.

Quelle est la meilleure pratique pour utiliser HSRP avec ECMP pour éviter les inondations unicast inconnues?

Détails / Contexte

Nous avons une topologie HSRP similaire au premier diagramme ci-dessous pour bon nombre de nos installations. Nos routeurs Cisco WAN ont des routes à coût égal vers tous les autres sites; ainsi nous pouvons voir des effets de routage asymétriques tout le temps. Normalement, nous attribuons R1 au HSRP principal, mais ECMP autorise le trafic de retour via R1 ou R2.

Le problème est que lorsque PC1 monte un lecteur iSCSI distant sur le WAN, le trafic quitte le site via R1, mais peut revenir via R2. Tant que le trafic iSCSI revient via R1, il n'y a aucun problème.

HSRP_Broken_00

Le problème se produit lorsque le trafic de PC1 revient via R2. Supposons que la session iSCSI commence à 8:00:00 et que les routeurs et les deux commutateurs apprennent le mac de PC1 simultanément. Entre 8:00:00 et 8:00:05, il n'y a aucun problème d'inondation car les deux commutateurs ont toujours l'adresse MAC de PC1 dans leur table CAM.

HSRP_Broken_01

Cinq minutes après le début de la session iSCSI, l'entrée CAM de S2 pour le mac de PC1 expire de la table CAM et S2 inonde le trafic de PC1 sur tous les ports (dans ce cas vers Po1, Gi0 / 3 et Gi0 / 4). Si la session iSCSI de PC1 consomme beaucoup de bande passante, cette inondation unicast inconnue peut aspirer une capacité non triviale des liens vers PC3 et PC4.

Les commutateurs Cisco IOS ont un minuteur CAM par défaut de 300 secondes ...

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

Cependant, le temporisateur ARP de l'interface par défaut de Cisco IOS est de 4 heures ...

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

Par conséquent, S2 commence à inonder le trafic iSCSI de PC1 après cinq minutes.

HSRP_Broken_02

Mike Pennington
la source
Pourquoi les gens continuent-ils à poster des questions et à y répondre eux-mêmes? Non comme dans, la recherche et trouvé la réponse, ils l'avaient déjà? Ceci est un site de questions / réponses, pas un blog (pas que vous n'ayez pas fourni une bonne rédaction!)
jwbensley
8
@javano: l'auto-réponse est explicitement encouragée par SE. ref meta.networkengineering.stackexchange.com/questions/4/…
Craig Constantine
1
@CraigConstantine Oui je sais, mais je suis sûr que les gens postent des questions et répondent ensuite détroit après, pas un certain temps plus tard quand ils ont trouvé la réponse à la question (même si ce n'est que 5 minutes plus tard), ils répondent directement car ils connaissaient déjà la réponse avant de poster la question. Je trouve cela un peu étrange.
jwbensley
6
Pourtant, le fait demeure que l'écriture d'un Q et d'une réponse immédiate est explicitement encouragée.
Craig Constantine
4
@javano, Si vous résolvez un problème auquel vous pensez que d'autres personnes seront confrontées, SE veut que le trafic du moteur de recherche résout ce problème ... peu importe si je poste la réponse en même temps ou non ... en fait, il y a une petite case à cocher au bas du formulaire Web de questions pour "Répondre à votre propre question - partager vos connaissances, style Q & A"
Mike Pennington

Réponses:

14

La réponse simple est de rendre le minuteur CAM égal ou légèrement plus long que le minuteur ARP de l'interface correspondante , mais il y a au moins trois options différentes à sélectionner ...

Option 1: abaisser tous les temporisateurs ARP d'interface

Cette option fonctionne mieux si vous disposez d'un réseau commuté de couche 2 de taille décente, d'un nombre raisonnable d'entrées ARP et de quelques interfaces routées. Cette méthode est également préférable si vous souhaitez voir les entrées Mac PC sortir rapidement de la topologie.

  • Sur toutes les interfaces Ethernet IOS face à un commutateur Ethernet: arp timeout 240
  • Sur toutes les interfaces Ethernet IOS faisant face à un commutateur Ethernet: hold-queue 200 inet hold-queue 200 outpour éviter de perdre des paquets ARP lors des actualisations ARP périodiques (ces limites peuvent être supérieures ou inférieures selon le nombre d'actualisations ARP que vous pensez que vous devrez gérer à la fois). Si vous ajustez les valeurs de rejet sélectif des paquets , vous devez suivre les instructions du document que j'ai lié.

Cela oblige Cisco IOS à actualiser la table ARP dans les quatre minutes, si cela ne s'est pas produit autrement pour une entrée ARP donnée. L'inconvénient évident est que cela ne s'adapte pas bien si vous avez beaucoup d'entrées ARP ... les limites varient selon la plate-forme. J'ai utilisé cela avec quelques centaines d'ARP par routeur sur Catalyst 4500/6500 (les SVI Layer3) sans aucun problème.

Option 2: augmenter le commutateur CAM Timers

Cette option fonctionne mieux si vous avez un grand nombre d'entrées ARP (c'est-à-dire des milliers, comme un environnement VMWare intense pourrait voir).

  • Sur tous les commutateurs IOS: mac address-table aging-time 14400ou mac address-table aging-time 14400 vlan <vlan-id>pour tout Vlan préoccupant.

Ce changement ajuste les temporisateurs que la plupart des gens supposent fixes à 300 secondes (sur Cisco IOS), assurez-vous donc de les inclure dans les documents de continuité. L'effet secondaire est que les entrées de la table CAM persistent pendant 4 heures après le retrait du PC (ce qui peut être bon ou mauvais, selon votre PoV). Si 4 heures c'est trop long, voir l'option suivante ...

Option 3: modifiez à la fois les temporisateurs ARP de l'interface et le commutateur CAM Timers

Cette option évite les temporisateurs CAM d'une durée affreuse dans l'option 2 au détriment de plus de configuration. Vous pouvez choisir si vous avez besoin de 900 secondes, 1800 secondes ou autre ... assurez-vous simplement que vos minuteries CAM et ARP correspondent; ainsi, vous devrez configurer à la fois l'option 1 et l'option 2 dans vos topologies.

Mike Pennington
la source
4
Nous avons trié ce problème en choisissant la première solution proposée, mais nous n'étions pas sûrs de l'ordre dans lequel IOS nettoierait la table, puis nous avons défini le délai d'expiration ARP à 293 s (le nombre premier le plus proche sous le délai d'expiration de la table d'adresse mac). Je ne sais toujours pas si c'était un bon choix ou non
Marco Marzetti
1
Techniquement, Cisco IOS déclenche le marcheur ARP à des intervalles de 60 secondes, vous devriez donc en utiliser 240 ... J'ai négligé d'inclure cela dans ma réponse ... en le modifiant ... je suis curieux de savoir pourquoi vous avez choisi un nombre premier ...
Mike Pennington
ACK. Le délai d'expiration ARP inférieur ou égal au délai d'expiration MAC doit être BCP. Il n'y a même pas besoin d'être HSRP, juste s'il y a deux routeurs, il peut vous mordre et provoquer même des boucles.
ytti
Je ne savais pas. Notre astuce est donc totalement inutile. Nous avons choisi un nombre premier pour minimiser le chevauchement des minuteries.
Marco Marzetti
4
@MikePennington, merci. Quoi qu'il en soit, la résolution du délai d'expiration ARP est mise en œuvre en quelques minutes
Marco Marzetti
1

Pour moi, ECMP est le vrai problème ici - donc en plus des étapes ci-dessus pour limiter les inondations unicast inconnues, vous pouvez également régler les métriques de l'itinéraire vers le WAN afin que R1 soit préféré à R2 pour le trafic de retour. Une façon d'y parvenir est via la liste de distribution sur R2 comme suit: (EIGRP utilisé par exemple uniquement, la même chose peut être obtenue avec OSPF ou BGP avec d'autres commandes)

!
IP prefix-list R1-PREFER seq 5 permit 172.17.1.0/24
!
carte d'itinéraire R1-PREFER-MAP permis 10
 correspondre à la liste de préfixes des adresses IP R1-PREFER
 ensemble métrique 1 1 1 1 1
... (autoriser tous les autres itinéraires)
!
routeur eigrp 1
 ....
 distribuer-liste route-map R1-PREFER-MAP out Ser1 / 0
 ....
!

Il en résultera que le WAN transmettra tout le trafic pour 172.17.1.0 à R1. Si R1 Se1 / 0 échoue, la route sera installée vers R2. Vous pouvez affiner davantage ces mesures afin que la route de sauvegarde vers R2 soit en fait un successeur possible pour un basculement plus rapide. HSRP et le suivi prendront en charge le trafic de sortie.

smoothbSE
la source
essentiellement vous répondez à la question que vous voulez, au lieu de ma question ... qui nécessite à la fois fhrp et ecmp
Mike Pennington
désolé - je m'habitue à ce forum et j'ai raté cette exigence!
smoothbSE
Pas de problème ... bienvenue à NE :)
Mike Pennington
0

L'idée sinon d'utiliser ECMP si HSRP est en cours d'utilisation peut être correcte pour les SERVEURS où le trafic d'entrée peut être plus élevé que le trafic de sortie, dans une situation PC EN GÉNÉRAL, le trafic d'entrée du WAN (réponses) est plus élevé que le trafic de sortie (entrée). Nous aimons que la plupart des gens viennent de régler les temporisateurs ARP. vous pouvez jouer avec les temporisateurs CAM MAIS si vous avez dit un MDF avec le commutateur de couche 3 et un IDF avec 2 commutateurs de collecte et disons 5 commutateurs d'accès, c'est beaucoup plus facile à configurer sur le L3 SVI que de faire tous les commutateurs d'accès.

Fredpbaker
la source
0

On pourrait utiliser une pile de commutateurs pour atténuer ce problème d'expiration de l'entrée d'adresse MAC dans le deuxième commutateur.

Eugene Smirnov
la source
0

Ah, je me souviens de celui-ci. Il y a quelques semaines, on a eu du plaisir à gérer ce problème. Un inconvénient est que les événements STP mettront les réseaux locaux virtuels en mode de vieillissement rapide, donc régler le minuteur MAC plus longtemps que le minuteur ARP n'aide pas

J'ai résolu le problème en forçant ECMP à revenir des serveurs, en créant deux passerelles HSRP flottantes, avec une principale sur chaque routeur. Nous avons ensuite configuré les deux passerelles sur chaque hôte. En forçant le trafic hôte vers R1 et R2 de cette manière, nous serions sûrs que R2 ne vieillirait jamais les adresses MAC.

Idéalement, cela ne serait pas un problème si les commutateurs L2 / 3 purgeaient les entrées ARP associées aux adresses MAC périmées. Le prochain paquet vers l'IP entraînerait alors une nouvelle demande ARP, remplissant à la fois le cache ARP et la table MAC. Je pense que Cisco a finalement implémenté cela, mais je ne peux pas en être sûr.

croasser
la source
0

Résumé: MC-LAG ou HSRP GARP

Je n'ai jamais été fan de peaufiner les chronomètres. Les minuteries sont définies d'une certaine manière, généralement pour de nombreuses raisons. Les modifier:

  • est potentiellement intensif sur le plan opérationnel pour maintenir partout le même
  • rend les choses plus compliquées et difficiles à résoudre
  • comme l'a montré un commentateur récent, peut avoir des effets secondaires inattendus
  • peut ne pas "jouer bien" avec les futures améliorations de Cisco

Alternativement:

  1. Utilisez MC-LAG (alias "MEC" dans la documentation Cisco). C'est votre meilleure option, mais vous devez comprendre les scénarios de déploiement dans lesquels MC-LAG peut être utilisé (ce n'est pas une solution universelle et ne doit être déployé qu'après des recherches et des tests appropriés). Les variantes MC-LAG dépendent du matériel. Voici des exemples:

    une. Empilement (Cat 3k)

    b. VSS (Cat4k / 6k)

    c. VPC (Nexus)

    ré. Pseudo mLACP (ASR1k)

    e. MC-LAG (ASR9k)

    F. Clustering (ASA)

  2. Activez HSRP pour envoyer périodiquement des paquets ARP gratuits . Certes, cela revient à modifier les temporisateurs, mais c'est une altération beaucoup plus gracieuse que de manipuler la table CAM et les temporisateurs ARP. (Notez cependant que cela dépend de votre combinaison matérielle et logicielle, toutes les implémentations HSRP ne le proposent pas.)

    Par défaut, HSRP envoie 3 GARP, à 0, 2 et 4 secondes après que le routeur est devenu la passerelle de transfert. Cependant, il existe un paramètre de configuration qui vous permet de choisir le nombre de GARP (y compris "infini") et l'intervalle.

J'utilise MC-LAG assez largement, en particulier VSS, VPC et Clustering (je ne suis pas un fan de l'empilage).

Lorsque je ne peux pas utiliser MC-LAG ou GLBP, voici ce que j'applique à mes routeurs de frontière de campus L2 / L3 (j'ai un campus de 350 bâtiments, donc j'utilise assez 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 

(Je publierais des références à tout cela, mais je n'ai pas une "réputation" suffisamment élevée sur ce site pour publier plus de deux URL.)

Weylin Piegorsch
la source
Ce que vous appelez MC-LAG est certainement une option, mais sa disponibilité sur les plates-formes IOS classiques est inégale. Je ne comprends pas non plus comment l'ARP gratuit HSRP aide à résoudre ce problème. En utilisant l'exemple de ma question, pourriez-vous expliquer comment l'ARP gratuit HSRP résout le délai d'entrée ARP de 172.17.1.1? Notez que le GW par défaut est 172.17.1.254
Mike Pennington
Réponse longue, alors permettez-moi de diviser cela en deux parties. Partie 1 ... Le problème avec HSRP est que le routeur répond à une requête ARP avec le MAC virtuel. Cependant, lorsque le routeur transfère un datagramme à l'hôte, il utilise l' adresse MAC physique . Les commutateurs effacent leur table de transfert assez rapidement (souvent 300 secondes ou 5 minutes), mais les entrées ARP restent souvent bien plus longtemps que cela (8 heures sont courantes).
Weylin Piegorsch,
Partie 2 ... Une fois que les commutateurs ont expiré l'adresse MAC virtuelle de la table de transfert, le trafic du serveur vers le MAC virtuel devient "unicast inconnu", où le commutateur adopte par défaut un comportement de type concentrateur et inonde le trafic ports. En envoyant périodiquement un GARP, le routeur actualise la table de transfert de commutateur. De plus, en envoyant un GARP, la table ARP sur le serveur est actualisée, éliminant ainsi le besoin d'envoyer une requête ARP.
Weylin Piegorsch
En plus de ma réponse en 2 parties, je viens de réaliser que la question se pose dans la direction opposée: l'adresse MAC du serveur est éliminée des commutateurs, pas du MAC virtuel du routeur. Nous avons eu ce problème spécifique et nous avons fini par le résoudre initialement via MC-LAG (spécifiquement VPC), et plus tard, puisque nous utilisions déjà Nexus, nous sommes passés à FabricPath aka TRILL, ce qui a fait disparaître le problème. Mais, les deux dépendent du matériel et de la topologie.
Weylin Piegorsch
Je viens de réaliser que mon commentaire d'origine est valide - mais malheureusement incomplet. Pas seulement MC-LAG, mais MC-LAG sur les deux couches. Ensuite, vous avez affaire à une table CAM partagée au niveau du commutateur et au niveau du routeur.
Weylin Piegorsch
0

Je viens de réaliser que mon commentaire d'origine est valide - mais malheureusement incomplet. La recommandation de conception indépendante du fournisseur est de construire en triangles, pas en rectangles. Donc:

  1. Pas seulement MC-LAG, mais MC-LAG sur les deux couches. Ensuite, vous avez affaire à une table CAM partagée au niveau du commutateur et au niveau du routeur.

  2. Si vous ne pouvez pas faire cela, MC-LAG soit le routeur ou le commutateur, et MC-LAG vers l'autre couche avec une liaison supplémentaire (c'est-à-dire un maillage complet entre les routeurs et les commutateurs). STP assurera une topologie sans boucle.

  3. Si vous ne pouvez pas faire cela, continuez de mailler complètement les routeurs et les commutateurs. STP assurera une topologie sans boucle et les tables CAM du commutateur connaîtront toujours toutes les règles de transfert MAC appropriées. Le serveur enverra toujours son MAC, et si vous configurez les HSRP GARP à des intervalles de 1 minute, les commutateurs n'oublieront pas non plus le HSRP vMAC.

Les options préférées sont dans cet ordre. Mais à tout le moins, installez cette paire de liens supplémentaires.

Weylin Piegorsch
la source