Best Practice für die Kombination von HSRP und ECMP

Die Kombination von ECMP (oder anderen Ursachen für asymmetrische Pfade) und HSRP ist in Cisco IOS standardmäßig fehlerhaft. Das Standardverhalten mit diesem Entwurf überflutet den Unicast-Verkehr übermäßig.

Was ist die beste Vorgehensweise für die Verwendung von HSRP mit ECMP, um unbekannte Unicast-Überflutungen zu verhindern?

Details / Hintergrund

Wir haben für viele unserer Einrichtungen eine HSRP-Topologie, die dem ersten Diagramm unten ähnelt. Unsere Cisco WAN-Router bieten kostengünstige Routen zu allen anderen Standorten. Auf diese Weise können wir ständig asymmetrische Routing-Effekte feststellen. Normalerweise weisen wir R1 als HSRP-Primärdaten zu, aber ECMP lässt den Rückdatenverkehr entweder über R1 oder R2 zu.

Das Problem ist, dass wenn PC1 ein Remote-iSCSI-Laufwerk über das WAN bereitstellt, der Datenverkehr den Standort über R1 verlässt, aber über R2 zurückkehren kann. Solange der iSCSI-Verkehr über R1 zurückkehrt, gibt es keine Probleme.

Das Problem tritt auf, wenn der Datenverkehr von PC1 über R2 zurückkehrt. Angenommen, die iSCSI-Sitzung beginnt um 8:00:00 Uhr und beide Router und beide Switches lernen gleichzeitig den Mac von PC1. Zwischen 8:00:00 und 8:00:05 gibt es keine Überschwemmungsprobleme, da beide Switches immer noch die MAC-Adresse von PC1 in ihrer CAM-Tabelle haben.

Fünf Minuten nach dem Start der iSCSI-Sitzung läuft der CAM-Eintrag von S2 für den Mac von PC1 aus der CAM-Tabelle aus und S2 überflutet den Datenverkehr von PC1 über alle Ports (in diesem Fall zu Po1, Gi0 / 3 und Gi0 / 4). Wenn die iSCSI-Sitzung von PC1 viel Bandbreite beansprucht, kann dieses unbekannte Unicast-Flooding nicht-triviale Kapazität von den Verbindungen zu PC3 und PC4 beanspruchen.

Cisco IOS-Switches haben einen Standard-CAM-Timer von 300 Sekunden ...

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

Der Standard-ARP-Timer der Cisco IOS-Benutzeroberfläche beträgt jedoch 4 Stunden.

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

Daher beginnt S2 nach fünf Minuten, den iSCSI-Verkehr von PC1 zu überfluten.

Die einfache Antwort besteht darin, den CAM-Timer gleich oder etwas länger als den ARP-Timer der entsprechenden Schnittstelle zu machen. Es stehen jedoch mindestens drei verschiedene Optionen zur Auswahl:

Option 1: Senken Sie alle Schnittstellen-ARP-Timer

Diese Option funktioniert am besten, wenn Sie ein Layer2-Switch-Netzwerk mit einer angemessenen Größe, einer angemessenen Anzahl von ARP-Einträgen und wenigen gerouteten Schnittstellen haben. Diese Methode ist auch vorzuziehen, wenn Sie möchten, dass PC-Mac-Einträge schnell aus der Topologie altern.

• Auf allen IOS-Ethernet-Schnittstellen, die einem Ethernet-Switch zugewandt sind: arp timeout 240
• Auf allen IOS-Ethernet-Schnittstellen, die einem Ethernet-Switch zugewandt sind: hold-queue 200 inund um hold-queue 200 outzu vermeiden, dass ARP-Pakete bei regelmäßigen ARP-Aktualisierungen verworfen werden (diese Grenzwerte können höher oder niedriger sein, je nachdem, wie viele ARP-Aktualisierungen Sie Ihrer Meinung nach gleichzeitig ausführen müssen). Wenn Sie Werte für " Selektives Verwerfen von Paketen" anpassen , sollten Sie die Richtlinien in dem von mir verknüpften Papier befolgen.

Dies zwingt Cisco IOS, die ARP-Tabelle innerhalb von vier Minuten zu aktualisieren, sofern dies für einen bestimmten ARP-Eintrag nicht anders erfolgt ist. Der offensichtliche Nachteil ist, dass dies nicht gut skaliert, wenn Sie viele ARP-Einträge haben ... die Grenzen variieren je nach Plattform. Ich habe dies mit ein paar hundert ARPs pro Router auf Catalyst 4500/6500 (die Layer3-SVIs) ohne Probleme verwendet.

Option 2: Erhöhen Sie den Schalter CAM-Timer

Diese Option funktioniert am besten, wenn Sie über eine große Anzahl von ARP-Einträgen verfügen (z. B. Tausende, die in einer intensiven VMWare-Umgebung auftreten können).

• Auf allen IOS-Switches: mac address-table aging-time 14400oder mac address-table aging-time 14400 vlan <vlan-id>für jedes betroffene Vlan.

Durch diese Änderung werden die Zeitgeber angepasst, von denen die meisten Leute annehmen, dass sie auf 300 Sekunden festgelegt sind (unter Cisco IOS). Nehmen Sie sie daher unbedingt in die Kontinuitätsdokumentation auf. Dies hat zur Folge, dass CAM-Tabelleneinträge 4 Stunden nach dem Entfernen des PCs bestehen bleiben (was je nach PoV entweder gut oder schlecht sein kann). Wenn 4 Stunden zu lang sind, lesen Sie die nächste Option ...

Option 3: Ändern Sie sowohl die Schnittstellen-ARP-Timer als auch die Switch-CAM-Timer

Diese Option vermeidet abscheulich lange CAM-Timer in Option 2 auf Kosten einer größeren Konfiguration. Sie können wählen, ob Sie 900 Sekunden, 1800 Sekunden oder was auch immer benötigen ... stellen Sie einfach sicher, dass Ihre CAM- und ARP-Timer übereinstimmen; Daher müssen Sie Option 1 und Option 2 in Ihren Topologien konfigurieren.

Für mich ist ECMP hier das eigentliche Problem. Zusätzlich zu den oben genannten Schritten zur Begrenzung der unbekannten Unicast-Überflutung können Sie auch die Routenmetriken für das WAN optimieren, sodass R1 für den Rückverkehr R2 vorgezogen wird. Ein Weg, dies zu erreichen, ist über die Verteilerliste auf R2 wie folgt: (EIGRP wird nur als Beispiel verwendet, dasselbe kann mit OSPF oder BGP mit anderen Befehlen erreicht werden.)

!
IP-Präfix-Liste R1-PREFER SEQ 5 Erlaubnis 172.17.1.0/24
!
Routenkarte R1-PREFER-MAP Genehmigung 10
 IP-Adresse Präfix-Liste R1-PREFER
 Metrik 1 1 1 1 1 einstellen
... (alle anderen Routen zulassen)
!
Router Eigrp 1
 ....
 Verteilerliste Routenkarte R1-PREFER-MAP aus Ser1 / 0
 ....
!

Dies führt dazu, dass das WAN den gesamten Datenverkehr für 172.17.1.0 an R1 weiterleitet. Wenn R1 Se1 / 0 fehlschlägt, wird die Route in Richtung R2 installiert. Sie können diese Metriken weiter optimieren, sodass die Sicherungsroute zu R2 tatsächlich ein praktikabler Nachfolger für ein schnelleres Failover ist. HSRP und Tracking kümmern sich um den ausgehenden Verkehr.

Die Idee, ECMP nicht zu verwenden, wenn HSRP verwendet wird, kann für SERVER in Ordnung sein, bei denen der eingehende Datenverkehr höher ist als der ausgehende Datenverkehr. In einer PC-Situation ist der eingehende Datenverkehr vom WAN (Antworten) höher als der ausgehende Datenverkehr (eingehende Datenverkehr). Wir mögen, dass die meisten Leute nur die ARP-Timer einstellen. Sie können sich mit CAM-Timern herumärgern, ABER wenn Sie eine MDF mit dem Layer-3-Switch und eine IDF mit 2 Erfassungs-Switches und beispielsweise 5 Zugriffs-Switches haben, ist die Konfiguration auf der L3-SVI um ein Vielfaches einfacher als bei allen Zugriffs-Switches.

Man könnte einen Stapel von Schaltern verwenden, um dieses Problem des Ablaufens der MAC-Adresseneingabe im zweiten Schalter zu mildern.

Ah, ich erinnere mich an diesen. Wochen voller Spaß hatten vor ein paar Jobs damit zu tun. Ein Nachteil ist, dass STP-Ereignisse die VLANs in den Fast-Aging-Modus versetzen. Daher hilft es nicht, den MAC-Timer länger als den ARP-Timer einzustellen

Ich habe das Problem gelöst, indem ich ECMP von den Servern zurückgedrängt habe, indem ich zwei schwebende HSRP-Gateways mit jeweils einem primären auf jedem Router erstellt habe. Anschließend haben wir beide Gateways auf jedem Host konfiguriert. Indem wir den Host-Verkehr auf diese Weise auf R1 und R2 zwingen, können wir sicher sein, dass R2 die MAC-Adressen niemals altern lässt.

Idealerweise wäre dies kein Problem, wenn L2 / 3 gelöschte ARP-Einträge wechselt, die veralteten MAC-Adressen zugeordnet sind. Das nächste Paket an die IP würde dann zu einer neuen ARP-Anforderung führen, die sowohl den ARP-Cache als auch die MAC-Tabelle auffüllt. Ich denke, Cisco hat dies letztendlich umgesetzt, aber ich kann es nicht mit Sicherheit sagen.

Zusammenfassung: MC-LAG oder HSRP GARP

Ich war noch nie ein Fan von Timern. Timer werden normalerweise aus vielen Gründen auf eine bestimmte Weise eingestellt. Ändern sie:

• ist potentiell betriebsintensiv, überall gleich zu warten
• erschwert die Behebung von Problemen
• Wie ein kürzlich veröffentlichter Kommentar gezeigt hat, können unerwartete Nebenwirkungen auftreten
• kann mit zukünftigen Cisco-Verbesserungen nicht "schön spielen"

Abwechselnd:

1. Verwenden Sie MC-LAG (in der Cisco-Dokumentation auch als "MEC" bezeichnet). Dies ist die beste Option, obwohl Sie die Bereitstellungsszenarien kennen sollten, in denen MC-LAG verwendet werden kann (dies ist keine universelle Lösung und sollte nur nach entsprechenden Recherchen und Tests bereitgestellt werden). MC-LAG-Varianten sind hardwareabhängig. Beispiele sind:

   ein. Stapeln (Kat. 3k)

   b. VSS (Cat4k / 6k)

   c. VPC (Nexus)

   d. Pseudo-mLACP (ASR1k)

   e. MC-LAG (ASR9k)

   f. Clustering (ASA)

2. Aktivieren Sie HSRP, um regelmäßig kostenlose ARP-Pakete zu senden . Zugegeben, dies ähnelt dem Ändern von Timern, ist jedoch eine viel elegantere Änderung als das Manipulieren der CAM-Tabelle und der ARP-Timer. (Beachten Sie jedoch, dass dies von Ihrer Hardware- und Softwarekombination abhängt. Nicht alle HSRP-Implementierungen bieten dies an.)

   Standardmäßig sendet HSRP 3 GARPs nach 0, 2 und 4 Sekunden, nachdem der Router zum Weiterleitungs-Gateway geworden ist. Es gibt jedoch einen Konfigurationsparameter, mit dem Sie die Anzahl der GARPs (einschließlich "unendlich") und das Intervall auswählen können.

Ich benutze MC-LAG ziemlich häufig, insbesondere VSS, VPC und Clustering (ich bin kein Fan von Stacking).

Wenn ich MC-LAG oder GLBP nicht verwenden kann, gilt dies für meine L2 / L3-Grenzrouter auf dem Campus (ich besitze einen Campus mit 350 Gebäuden, daher verwende ich Cat6k ziemlich häufig):

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 

(Ich würde auf all diese Verweise verweisen, aber ich habe auf dieser Website nicht genügend "Ansehen", um mehr als zwei URLs zu veröffentlichen.)