ICX VLAN-based Mirroring

Ist ja völlig wirr. Kein Mensch macht sowas weil es nicht skaliert und bei Switches extrem kontraproduktiv ist weil diese die Frames in CPU kopieren müssen.
Genau dafür gibt es ja Flow Protokolle wie sFlow, NetFlow und IPFIX womit alle sinnvollen IDS Systeme ja auch arbeiten. Sollte dir zu denken geben wenn der "Dienstleister" sowas nicht kennt.

Ist oben ja schon gesagt worden und eine Binse für einen Netzwerker. SPAN Ports sind Mirror Ports!!
Oder haben die Typen keine Ahnung und reden von RSPAN Ports?!
Beides kostet übrigens unnötig CPU, denn auch bei einem lokalen SPAN Port muss die Switch CPU alle Frames kopieren. Wenn du 8 VLAN spiegelst dann 8mal. Bei 1 oder 10Gig Ports mit entsprechender Last kann das einen Switch je nach Ausstattung in die Knie zwingen.
Von RSPAN gar nicht mal zu reden der diesen Traffic noch in IP encapsulieren muss und durchs Netz schicken muss. Sowas können nur Premium Switches mit entsprechend potenter CPU.

Generell ist das Unsinn mit Mirroring Traffic zu analysieren. Macht man in der Praxis nie oder wenn dann lediglich temporär zum Troubleshooting aber aus guten Gründen niemals dauerhaft.
Dazu nutzt man immer Flow Protokolle wie sFlow, NetFlow bzw. IPFIX. Liegt ja auch auf der Hand, denn die skalieren eben je nach Bandbreite und Last.
Mit einem Mirror siehst du auch niemals den L2 Traffic eines Netzsegments. Höchstens Router oder Firewall Ports erfasst dann aber lediglich nur diesen Traffic. Das zeigt schon das Skalierungsdilemma was du hast wenn du z.B. noch 3 Server monitoren willst, 2 NAS und 2 Firewalls.
Wenn man es richtig macht führt kein Weg an Flow Protokollen vorbei. Professionelle Systeme nutzen diese auch.
Oha, dann hast du nicht richtig gesucht. Gerade das ist ein Paradebeispiel für die Anwendung von Flow Protokollen.
Das hatte Foundry schon anno dunnemals 2006 in sein "Iron View" Management integriert und konnte so sFlow Daten zur Intrusion Detection nutzen indem es sie auswertete Warnings versendete und über das Management z.B. Malware Ports vom Netz kappte.
https://www.networkworld.com/article/2311943/foundry-adds-snort-to-lan-s ...
Brocade hat das weiterentwickelt, Thema "IronShield 360 Closed-Loop".
https://www.cnct.de/fileadmin/user_upload/pdf/PDF-Foundry/Foundry_Datenb ...
Die FastIron Switches waren bekanntlich die Vorgänger der ICXe!
InMon ist auch so ein Pionier die sowas gepusht haben und auch einen Menge freie Tools dafür haben. Das ist also seit 20 Jahren best Practise und machen alle anderen Hersteller ebenso die Flow Protokolle supporten. Wie sollte es auch sonst gehen..?!
Wenn du nach "Snort sFlow" bei Dr. Google suchst bekommst du Tausende von Treffern zu diesem Klassiker.

Da darf man dann raten von wem die TAPs und Sensoren kommen. Meist ist das ein Eingangstor um so weiter teure proprietäre HW an den Man zu bringen. Solche Konzepte sind schlecht, da wenig flexibel und skalierbar. Du musst für jedes Segment oder Port einen neuen Tap oder Probe beschaffen was immer Geld kostet unnd wieviel sollen es denn im Endgeffekt sein. Und wer will auf Dauer laufende Mirror Ports auf seiner Infrastruktur haben die rein dem Troubleshooting dienen sollten, das klingt etwas abstrus. Teure Materialachlacht mit der Gefahr eines Vendor Locks. Normal ein NoGo.
Genau dafür gibt es die Flow Protokolle. Wenn die ein IDS Hersteller nicht supportet sollte dir das zu denken geben. Sogar Allerweltsprodukte wie PRTG basieren auf sowas, denen würde nie einfallen Mirror Ports zu verwenden... Aber nundenn.
Genau dafür ist es ja auch da. Es ist nicht gedacht um im Dauerbetrieb zu laufen. Die Gründe dafür wurden oben schon genannt.
Nicht weiter verwunderlich, weil der Switch das in CPU erledigen muss. Die Port Asics können das nicht.
Was per se schonmal gut ist, denn die haben eine entsprechend skalierbare CPU welche aber endlich ist.
Das Mirroring kann laut Monitoring Guide (Seite 67) sowohl auf dem virtuellen LAG Interface definiert sein als auch einzeln auf den LAG Memberports. Ggf. solltest du den Weg mal gehen.
RSTP kann man natürlich abschalten, da LACP Lags eine eigene Loop Prevention Option haben. Das hat aber den gravierenden Nachteil das der Spanning Tree damit dann inkonsistent ist. Gut, wenn der Router auf der anderen Seite nicht aktiv am Spanning Tree teilnimmt, dann wäre das tolerabel.
Was aber nie passieren darf ist das der LAG oder einzelne Memberports down oder in den Blocking Mode gehen. Das wäre u.a. ein Indiz das da etwas mit dem Spanning Tree gründlich schiefgeht.
Arbeitest du mit dem klassischen PVRSTP auf den ICXen?
State up/down Toggeling zeigt aber eher das etwas physisch nicht stimmt, denn das ist ein physischer Linkverlust! RSTP Blocking nimmt niemals den Link physisch runter.
Link up/downs sind oft Folgen von Speed und Duplex Fehlern oder falsch erkannten SFP Optiken wenn man mal von klassischen Kabelfehlern usw. absieht.
Generell arbeitet die Mirror Funktion vom ICX mit der aktuellen 8.0.95er problemlos und unauffällig.

Gefährlich und nicht gut. So hast du einen inkonsistenten Spanning Tree.
Catalysten oder die SG/CBS Billigschiene??
Bei Catalysten wäre das unsinnig, denn die ICX gehen sofort automatisch in den "pvst-mode" an den Ports wo sie Cisco PVSTP+ "sehen". Sie sind also automatisch kompatibel. Da wäre es ein großer Fehler es zu deaktivieren weil die ICXe es ja supporten und somit zu ihrem PVRSTP kompatibel ist.
Man kann es an den Ports auch mit dem Kommando "pvst-mode" erzwingen.

Bei der SG/CBS SoHo Billigschiene gibt es nur Single Span bzw. nur die CBS können PVSTP+ mit den Cisco proprietären BPDUs. Auf den Ciscos sollte man dann immer PVSTP+ aktivieren um eine Inkonsistenz zu vermeiden.
Bei den SGs die kein PVSTP+ können hat man 2 Optionen:

• STP abschalten auf beiden Seiten! so das keine BPDU Frames gegenseitig gesendet werden. Das gilt besonderst für die VLANs. Ausnahme ist hier das Default VLAN 1. Hier könnte man RSTP passieren lassen sofern man als Native VLAN konsistent im Netz 1 nutzt. Kann aber gefährlich werden wenn das native VLAN einmal wehcselt weil dann VLAN spezifische BPDUs in das Single Span VLAN geraten können und so Chaos anrichten können. Das erfordert also eine sehr genaue Konfig.
• Globaler Wechsel auf MSTP: In jedem Falle die sicherste Variante wenn man vermeiden möchte auf lange Sicht mit einem inkonsitenten Spanning Tree zu arbeiten.

Wie vermutet...
Ganz sauber hört sich das aber alles in Bezug auf den Spanning Tree nicht an.

Ja, in jedem Fall! Global killst du den STP ja dann komplett was man niemals will.
Immer nur dediziert auf den Uplink Ports mit no span deaktiveren zu Devices die nicht kompatibel sind!
Oha, dann machst du ja gar kein Per VLAN Spanning Tree. Damit wäre dann das Ausschalten auf den alten Ciscos auch kompletter Unsinn, denn die supporten ja gerade Single Span!! Das wäre völlig widersinnig dann und du hättest völlig unnötig einen inkonsistenten Spanning Tree damit.
Extrem wichtig ist das wenn du die ICXe schon auf Single Spann umgestellt hast das auch auf allen anderen beteiligten ICXen und auch allen nicht Brocade, Ruckus Switches ein Single Spann Verfahren benutzt wird. Das MUSS netzwerkweit einheitlich sein !

Single Span hat zwar den Vorteil das es auch mit dem dümmsten Blödmarkt Dödelswitch kompatibel ist weil alle das können sofern sie denn überhaupt STP können. Man hat also quasi einen universalen Spanning Tree. Aufs moderne RSTP sollte es natürlich gesetzt sein und die Root und Backup Root Priority sollte ein Muss sein, keine Frage!
Nachteil ist aber das der Spanning Tree global für alle VLANs gilt. Wenn du als Admin also ein kleines Test VLAN irgendwo hast und da rumpelt es im Spanning Tree dann rumpelt es auch in allen beteiligten VLANs. In größeren, segmentierten netzen ist das ein gravierender Nachteil.
PVSTP überwindet das. Wenn es in deinem Test VLAN wieder rumpelt juckt das die anderen VLANs nicht da die ja ihren eigenen Prozess haben.

Single Span und PVST sind nicht kompatibel! Man darf sie also keinesfalls mischen weil so falsche BPDU Frames in falsche VLANs kommen. Das wird leider aus Unwissenheit oft nicht beachtet mit dann fatalen Folgen für die Netzwerk Stabilität. Das Forum ist voll von solchen Threads...
Die ICXe arbeiten im Default deshalb immer mit PVSTP wie es bei PVSTP fähigen Premiium Switches generell üblich ist. Da muss man dann im Mischbetrieb mit nur Single Spann fähigen Switches genau aufpassen beim Setup !
Hier findest du einen Thread der diese Thematik am Beispiel einer MSTP Migration recht anschaulich schildert:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)

Da du deinen ICXen aber das PVSTP ja eh schon komplett abgewöhnt hast und nur noch Single Spann machst wäre es also unsinnig das auf den Ciscos weiter deaktiviert zu lassen, denn dafür gibt es dann keinerlei Grund mehr.
Jepp! Das ist richtig.
Zusätzlich muss zwingend in den VLANs "spanning-tree" konfiguriert sein bei einer single Spann Konfig. Eine korrekte Single Spann Konfig sähe so aus:
(Backup Root Switch der Root Switch hat eine 8192 Priority)
Eine PVSTP Konfig sieht etwas anders aus aber ähnlich.
Der Cisco SG der der dazu werkelnde Root Switch ist sieht dann so aus:
Richtig, das ist in der Tat dann OK..., wenn man denn mit Single Span leben will! 😉
Du musst nur drauf achten das es überall konsistent ist und solltest dann auch das RSTP auf den Ciscos im Single Span Mode dringenst wieder aktivieren.

Wenn's das denn nun war bitte nicht vergessen deinen Thread hier dann auch als erledigt zu markieren!