Minderung einer IPv6-fehlerhaften Paket-Multicast-Flut


7

Wir hatten heute Morgen gerade unsere erste IPv6-Multicast-Flut im Netzwerk. Wir haben es geschafft, den fehlerhaften Computer zu stoppen, indem wir die Mac-Adresse blockiert haben mit: mac-address-table static x.x.x vlan x drop

Bevor wir die Mac-Adresse blockiert haben, haben wir eine Wireshark-Erfassung gestartet, damit wir die Pakete später analysieren können.

Nach dem Betrachten der Pakete scheint es, dass die Pakete, die das Netzwerk überfluten, IPv6-DHCP-Anforderungen beschädigt haben, die die IPv6-Multicast-Adresse 33: 33: 00: 01: 00: 02 kontaktieren.

Die Auswirkungen der Flut waren seltsam. Das einzige, was betroffen zu sein schien, waren normale IPv4-DHCP-Anforderungen. Normale Clients konnten keine IP-Adresse erhalten, aber diejenigen, die bereits eine hatten, bevor die Flut begann, hatten keine Probleme ... Die CPUs auf den Switches erreichte ebenfalls einen Höchstwert von 95-100%, schien jedoch keinen Einfluss auf den normalen Verkehrsvermittlungs- / Routing-Betrieb zu haben.

Wir benötigen Hilfe, um festzustellen, wie nur 30 MBit / s IPv6-Multicast-Verkehr die CPU eines 6509 SUP720 auf 100% bringen und normales IPv4-DHCP zum Funktionieren bringen können, und wie wir uns davor schützen können, falls es erneut auftritt.

Jeder Zugriffs- / Client-Port hat die folgende Konfiguration:

 switchport access vlan x
 switchport mode access
 switchport nonegotiate
 switchport block multicast
 switchport block unicast
 switchport port-security maximum 2
 switchport port-security
 switchport port-security aging time 2
 switchport port-security violation restrict
 switchport port-security aging type inactivity
 storm-control broadcast level 5.00 4.00
 storm-control multicast level 5.00 4.00
 spanning-tree portfast
 spanning-tree bpduguard enable

Wird Storm-Control-Multicast nicht auf IPv6-Multicast angewendet?

Hier ist ein Auszug aus der Wireshark-Erfassung mit den "bösen" Paketen auf Dropbox .

Und eine kleine Sammlung von Grafiken, um die Auswirkungen zu veranschaulichen:

CPU Spike Graph

Wir haben auch den fehlerhaften Computer untersucht und konnten den Grund nicht finden oder das Problem nicht reproduzieren ...

Antworten:


7

Hintergrund

Ich bin irgendwo, wo Dropbox-Downloads blockiert werden, sodass ich den erfassten Datenverkehr nicht sehen kann, aber ich gehe davon aus, dass es sich um 64-Byte-Ethernet-Multicasts handelt.

Lassen Sie uns etwas rechnen, um zu sehen, wie viel Verkehr Sie zulassen ...

Ein 64-Byte-Frame besteht aus 672 Bit (einschließlich 8 Byte für Präambel / SFD und 12 Byte für IFG) ...

8 * (8 + 12 + 64) = 672 Bits

Das bedeutet, dass die Gigabit-Ethernet-64-Byte-Frames mit einer Übertragungsrate etwa 1,488 Mpps betragen ...

(1000000000 / 672.0) = 1488095,24 pps

Was bedeutet das für dich? Nun, Ihre aktuelle Konfiguration für die Sturmkontrolle drosselt den Verkehr mit 5% der Leitungsrate, sodass Sie 74,4 kpps Verkehr auf Ihren Switch lassen können, bevor die Sturmkontrolle einsetzt. 74,4 kpps * 64-Byte-Frames sind 38 Mbit / s, was richtig ist bei was deine Grafiken zeigen:

Antworten

Das Fazit ist also, dass Sie zu viel Verkehr zulassen, um die Switch-CPU zu treffen, weshalb die CPU-Auslastung hoch war. 74,4 kpps sind wirklich zu viel, um eine Switch-CPU verarbeiten zu können.

Angenommen, diese Stationen senden nicht viel Multicast oder Broadast, lautet die einfache Antwort, Ihren Datenverkehr so ​​zu drosseln ...

   ! Note that broadcast traffic has the ethernet I/G bit set
   ! which means it is also classified technically as a multicast
   ! for storm-control purposes.  Therefore set your broadcast limit
   ! a little lower than your multicast limit
   storm-control broadcast level 0.4 0.3
   storm-control multicast level 0.5 0.3

Jetzt setzt die Sturmkontrolle ein, wenn ein Port 6 kpps Broadcast (0,4% 1GE-Leitungsrate) oder 7,5 kpps kombiniertes Multicast / Broadcast (0,5% 1GE-Leitungsrate) sendet.

Zu Ihrer Information, ist es wahrscheinlich lohnt sich, in Control Plane Policing , die den Schalter CPU gegen mehrere Ports auf sie ganging up schützt. Denken Sie daran, dass es schwierig sein kann, CPP richtig zu machen. Es ist daher eine gute Idee, es gut zu testen, bevor Sie es in Ihrer Umgebung einführen.


Tolle Antwort Mike, ich wünschte, ich könnte dies mehr als einmal abstimmen! Ich bin mehrmals auf diese Situation gestoßen, in der die Leute unterschätzen, wie wenig Verkehr erforderlich ist, um die CPU in einem Router / Switch zu humpeln. Menschen scheinen sich nie an Pakete pro Sekunde zu erinnern, sie konzentrieren sich auf Bits pro Sekunde. (Ich bin auch schuld daran.)
Brett Lykins

1
Vielen Dank, Brett. Ich denke, wenn Cisco dies richtig macht, können wir die Sturmkontrolle auf den Verkehr in pps oder bps auf jeder Plattform anwenden
Mike Pennington,

Vielen Dank für alle bisherigen Antworten. Storm-Control-Multicast sollte auch für IPv6-Verkehr gelten? Und außerdem scheint es besser zu sein, die Sturmkontrolle mit pps als mit mbps zu verwenden, da dies vorhersehbarer ist ...
mastrboy

Ja, die Sturmkontrolle gilt für IPv6-Verkehr, da die Sturmkontrolle nur den Ethernet-Header betrachtet. IPv4 / IPv6 mcast setzen beide das I / G-Bit im Ethernet-Header. Während es besser ist, pps im Gegensatz zu Mbit / s im Befehl zur Sturmkontrolle zu verwenden, bietet Cisco bei einigen Modellen nur die Option einer prozentualen Leitungsrate von%. Denken Sie daran, zu berechnen, wie viele pps des Datenverkehrs die CPU verarbeiten darf, wenn Sie storm-controlGrenzwerte festlegen
Mike Pennington,
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.