Wie im Artikel „Broadcast Belastung pro VLAN“ vorgestellt, kann man ein Broadcast-Monitoring mit einem SNMP-Tool seiner Wahl (Zabbix, PRTG…) und WireShark umsetzen. Hier ist zu beachten, dass zwar über SNMP die Summe aller Broadcasts erfasst wird, aber die Zuordnung Broadcast <-> VLAN nicht möglich ist! Mit WireShark ist eine Analyse dahingehend möglich, aber nur wenn der Fehler momentan vorliegt. Ein zurückliegendes Ereignis kann nicht analysiert werden.

Hier stelle eine weitere Methode vor, wie ein Broadcast-Monitoring pro VLAN mit Speicherung der Werte umsetzbar ist.

Dazu wird folgendes Benötigt:

• ein Windows-PC + administrative Rechte
• eine freie/zusätzliche NIC*
• PRTG
• managebarer Switch

* getestet mit einer Amazon-Basic USB-NIC mit ASIX AX88179 Chip.

 

1. Vorarbeit – Switch konfigurieren

Um Broadcasts überhaupt monitoren zu können, müssen diese das System erreichen.
Hier macht es Sinn einen „Monitoring-Port“ mit allen VLAN getaggt zu konfigurieren. Oder einen Backbone-Port zu spiegeln, falls darauf aber ein Native-VLAN angelegt ist, findet keine VLAN-ID-Zuordnung im Monitoring statt (ggf. Kanaldefinitionen anpassen!).

Eingehende Frames an dem Port können in ein Black-Hole-VLAN geforwardet werden.

 

2. Windows einrichten

Im Falle einer USB-NIC diese an einen freien USB-Port anschließen.

Diese NIC wird später automatisch von PRTG in den „Promiscuous-Mode“ versetzt. Eine Einstellung ist dahingehend im System nicht zu tätigen. Für das Vorhaben wäre der Promiscuous-Modus auch gar nicht notwendig, da Broad- und Multicastframes auch im Non-Promiscuous-Mode nicht verworfen werden.

Geprüft (ob der Promiscuous-Mode an ist) kann mit folgendem PowerShell-Befehl werden:

Get-NetAdapter | Format-List -Property ifAlias,PromiscuousMode

 

Eine Alternative zum Promiscuous-Mode ist der Monitor-Mode.
Ist dieser an (MonitorModeEnabled und MonitorMode auf „1“), zeigt der oben genannte Befehl „PromiscuousMode : False“ an. Der Monitor-Mode kann wie hier beschrieben eingestellt werden: https://www.intel.de/content/www/de/de/support/articles/000005498/ethernet-products.html und reicht dann ebenfalls alle empfangenen Frames an ein Monitoring-System durch.

Aber auch dieser Modus wird für dieses Monitoring nicht benötigt.

 

Essentiell wichtig ist, dass die VLAN-Tags nicht vom Treiber entfernt werden, sonst ist später keine Zuordnung Broadcast <-> VLAN möglich! Hier ist (z. B. mit WireShark) zu prüfen, ob in dem empfangen Frames der VLAN-Tag noch vorhanden ist:

 

 

In der NIC sollten alle Einträge bis auf den NPCAP deaktiviert sein.

Für ein Broadcast-Monitoring sind keine IP-Adressen, Clients, QoS… notwendig. Außerdem hat dies den schönen Vorteil, dass der Switch wirklich nur Broadcasts an diese NIC weiterleitet. Ein Unicast-Filtering entfällt somit.

 

Beim oben genannten ASIX-Chip muss unter „Konfigurieren“ -> Erweitert -> Packet Priority & VLAN -> Disable auswählen. Wenn „Enable“ (Standardeinstellung) selektiert ist, werden die VLAN-Tags entfernt!

ACHTUNG: Je nach NIC und Treiber können die Einstellungen auch vertauscht sein! Bei einer Realtek-NIC blieben VLAN-Tags nur mit „Enable“ erhalten. Bei Broadcom muss ein spezieller Eintrag in der Registry vorhanden sein. Eine Auflistung für gängige Hersteller gibt es HIER. Deshalb immer mit WireShark verifizieren ob die Einstellungen stimmt.

 

3. PRTG konfigurieren

Sind die Vorarbeiten abgeschlossen muss noch PRTG eingerichtet werden. Hier wird von einer funktionsfähigen PRTG-Installation auf dem Monitoring-PC ausgegangen.

Als erstes muss unter „Geräte der Probe“ ein Packet Sniffer (Benutzerdef.) Sensor angelegt werden. Hier unter „Netzwerkadapter“ die für das Monitoring eingerichtete NIC auswählen.

Unter „Kanaldefinition“ muss das grundlegende Monitoring eingetragen werden. Hier bietet sich z. B. folgendes an:

#1:Broadcasts/VLAN-IPv4
VlanID[1-4096] and DestinationMAC[FF-FF-FF-FF-FF-FF]

#2:Multicasts/VLAN-IPv4
VlanID[1-4096] and (DestinationIP[224.0.0.0/4] or DestinationMAC[01-80-C2-00-00-00] or DestinationMAC[01-80-C2-00-00-01] or DestinationMAC[01-80-C2-00-00-02] or DestinationMAC[01-80-C2-00-00-03] or DestinationMAC[01-80-C2-00-00-08] or DestinationMAC[01-80-C2-00-00-0D] or DestinationMAC[01-80-C2-00-00-0E] or DestinationMAC[01-80-C2-00-00-21])

#3:Broadcasts/VLAN-IPv6
VlanID[1-4096] and DestinationIP[ff02::1]

#4:Multicasts/VLAN-IPv6
VlanID[1-4096] and DestinationIP[ff00::/8]

• Kanal 1 zeichnet alle Frames mit einem VLAN-Tag und der Destination-MAC FF-FF-FF-FF-FF-FF auf.
  Darauf matchen sowohl limited als auch directed IPv4-Broadcasts.
• Kanal 2 zeichnet alle Frames mit einem VLAN-Tag und der Destination-IP 224.0.0.0/4 und weiterer IEEE-Multicast-Layer2-Adressen auf.
  Damit werden alle IPv4-Multicast-Gruppen die als de-facto-Broadcast im Netz geflutet werden aufgezeichnet (PRTG erlaubt bei MAC-Filtern keine Wildcards).
• Kanal 3 zeichnet alle Frames mit einem VLAN-Tag und der Destination-IP ff02::1 auf.
  Damit werden IPv6-„Broadcasts“ (eigentlich Multicast) erfasst.
• Kanal 4 zeichnet alle Frames mit einem VLAN-Tag und der Destination-IP ff00::/8 auf.
  Damit werden alle übrigen IPv6-Multicast-Gruppen die als de-facto-Broadcast im Netz geflutet werden aufgezeichnet (PRTG erlaubt bei MAC-Filtern keine Wildcards).
• der Kanal „Andere“ erfasst alle übrigen Frames, z. B. LLDP-Frames des Switchports, Loopback-Detections von Switchen, etc…

WICHTIG: In PRTG können einmalig angelegte Kanäle nur in sehr geringem Umfang geändert werden! Ggf. muss der Sensor gelöscht und neu angelegt werden (Verlust der Historie).

 

Unter „Toplists“ kann man nun sehr feingranular Auswertungen bauen, welches VLAN wie viel Broad- und Multicasttraffic verursacht.

 

 

Es bietet sich noch an eine Toplist mit VLAN + Quell-MAC/IP + Ziel-MAC/IP + Ether-Type + Kanal anzulegen. So kann analysiert werden was im Kanal „Andere“ zusammengefasst wird.

 

Es wäre auch denkbar bei der Anlage des Sensors für jedes VLAN einen Kanal (Kanaldefinition) anzulegen und darüber noch Grenzwerte für jedes einzelne VLAN festzulegen. Bei vielen VLANs ist das aber nicht flexibel, da man einmal angelegte Kanäle nicht mehr löschen kann.

Anzeige der Kanäle – ohne angelegte Grenzwerte:

 

Der Promiscuous-Mode wird über den aktivierten Sensor gesteuert:

Wenn der Sensor pausiert wird, wird der Promiscuous-Mode der NIC automatisch auf „False“ gesetzt.

 

Abschließend

Dieses VLAN-granulare Broadcast-Monitoring kann als Ergänzung zum generellen SNMP-basierten Broadcast-Monitoring gesehen werden.

Ein wenig schade ist, dass man in PRTG die Einheiten des Sniffer-Sensors nicht auf „#/Sek.“ (Ereignisse pro Sekunde) umstellen kann. Die Broadcast-Belastung wird normalerweise immer in Brodcasts/Sekunde angegeben. Hier sind es KBit/Sek., gerade in Verbindung mit den SNMP-Werten (#/Sek.) hat man dann zwei verschiedene Einheiten.