Meilleure pratique pour la combinaison de HSRP et ECMP

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.

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.

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.

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.

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.

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.

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.

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.

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

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.