Broadcast Belastung pro VLAN

Die Broadcast- und Multicast-Belastung im Netz zu ermitteln ist mit SNMP und geeigneten Switchen relativ einfach.

In aller Regel werden diese Informationen aber nur für physikalischen Netzwerkinterfaces oder aggregierte Portgruppen ausgewiesen. Bei Trunkports ist dies die Summe aller VLANs. Zum generellen Monitoring ist dies völlig ausreichen. Wenn die Summe aber plötzlich ansteigt, wäre es gut zu wissen welches VLAN genau dafür verantwortlich ist.

Hier kommt man mit reinem SNMP-Monitoring meistens nicht mehr weiter.
Die entsprechenden OIDs werden zwar meistens noch erzeugt, enthalten aber keine Werte mehr.

Rx-Broadcast OID
keine Werte für
VLAN-, Bridge- oder LAG-Interfaces…

Diese Daten werden vom MAC-Sublayer direkt an die Schnittstellen weitergegeben (siehe IEEE 802.3-2018, „5.2.2 DTE MAC Sublayer Management facilities“ und RFC2863, Absatz 3.1.8). Höhere Schichten (die VLAN/Bridge/LAG… Interfaces erzeugen) messen offensichtlich nicht (immer?) selbst.

 

Wireshark

Wenn man einen Wireshark an einen solchen Trunkport hängt (oder einen Mirror-Port desselben anlegt), kann man mit ein paar Filtern und dem I/O Graph Tool das betroffene VLAN leicht herausfinden.

 

Vorüberlegung

Was soll überhaupt ermittelt werden?
Broadcast und ggf. Multicast Traffic der einzelnen VLANs über die Zeit, ggf. noch die Summe um eine Relation zu haben.

 


Hier bietet sich das I/G-Bit der MAC-Adresse (Least Significant Bit) an:

Quelle: IEEE 802.3-2018

 

3.2.3.1 Address designation

A MAC sublayer address is one of two types:

a) Individual Address. The address associated with a particular station on the network.
b) Group Address. A multidestination address, associated with one or more stations on a given network. There are two kinds of multicast addresses:
1) Multicast-Group Address. An address associated by higher-level convention with a group of logically related stations.
2) Broadcast Address. A distinguished, predefined multicast address that always denotes the set of all stations on a given LAN.
Quelle: IEEE 802.3-2018

 


 

Für Broadcast-Traffic gibt es diesen Filter:

(eth.dst[0:6] == FF:FF:FF:FF:FF:FF)
Dieser Filter zeigt IPv4 Broadcast-Traffic basierend auf der Layer-2 Destination MAC-Adresse an.

 

Für Multicast-Traffic, der je nach IPv4 und IPv6 anderen MAC-Adressen nutzt:

(eth.dst[0:3] == 01-00-5E)
Dieser Filter zeigt nur IPv4-Multicast an.

(eth.dst[0:2] == 33-33)
Dieser Filter zeigt nur IPv6-Multicast an.

 

Wenn Broadcast und Multicast-Traffic zusammen angezeigt werden sollte:

(eth.dst.ig == 1)
Dieser Filter zeigt Broadcast und Multicast-Traffic basierend auf dem I/G-Bit der MAC-Adresse an.

 

VLANs filtern

!(vlan.id)
Das native-VLAN, sollte es auf dem Trunk ein untagged VLAN geben.

(vlan.id == 100)
Spezifische VLAN-ID (hier VLAN-ID 100).

Würden keine VLAN-Filter angelegt werden, würde der Broadcast/Multicast-Traffic wieder aufsummiert werden.

 

Logische Operatoren

Wireshark verfügt über einige logische Operatoren mit deren Hilfe man Filter verketten kann:

&& <-- logisches UND/AND
|| <-- logisches ODER/OR
! <-- logisches NICHT/NOT

 

verkettete Filterausdrücke:

Native-VLAN und Broadcast/Multicast-Traffic:

!(vlan.id) && (eth.dst.ig == 1)

 

VLAN mit ID und Broadcast/Multicast-Traffic:

(vlan.id == 100) && (eth.dst.ig == 1)

 

I/O Graph

Nun müssen die Filter noch grafisch dargestellt werden.
Dazu in Wireshark über „Statistiken“ -> „I/O Graph“ gehen:

 

 

In diesem Fenster müssen die Filter mit einem Klick auf das „+“ angelegt werden.

Danach im Feld „Display Filter“ die entsprechenden Filterausdrücke einfügen.
Am besten noch gut unterscheidbare Farben wählen und unter „SMA Period“ zum Beispiel „10 interval SMA“ wählen, dies glättet die Werte etwas.

Zur Vereinfachung können die VLAN dann mit einem Klick auf das Kopier-Icon kopiert werden. Es muss dann nur noch die VLAN-ID geändert werden.

 

Die Broad- und Multicast Last pro VLAN in Frames/Sekunde.

 

Für das obige Diagramm wurden folgende Filter verwendet:

  • !(vlan.id) && (eth.dst.ig == 1)
    Native-VLAN + Broadcast/Multicast-Traffic

 

  • (vlan.id == 1) && (eth.dst.ig == 1)
    VLAN-ID 1 + Broadcast/Multicast-Traffic

 

  • (vlan.id == 162) && (eth.dst.ig == 1)
    VLAN-ID 162 + Broadcast/Multicast-Traffic

 

  • (vlan.id == 222) && (eth.dst.ig == 1)
    VLAN-ID 222 + Broadcast/Multicast-Traffic

 

  • (vlan.id == 324) && (eth.dst.ig == 1)
    VLAN-ID 324 + Broadcast/Multicast-Traffic

 

  • (vlan.id == 333) && (eth.dst.ig == 1)
    VLAN-ID 333 + Broadcast/Multicast-Traffic

 

  • (vlan.id == 887) && (eth.dst.ig == 1)
    VLAN-ID 887 + Broadcast/Multicast-Traffic

 

  • (vlan.id == 888) && (eth.dst.ig == 1)
    VLAN-ID 888 + Broadcast/Multicast-Traffic

 

  • (vlan.id == 889) && (eth.dst.ig == 1)
    VLAN-ID 889 + Broadcast/Multicast-Traffic

 

  • (eth.dst.ig == 1)
    Die Summer des gesamten Broadcast/Multicast-Traffics

 


 

Aufteilung Broadcast- Multicast und Unicast-Traffic (alle VLANs):

 

ohne Unicast-Traffic

 

mit Unicast-Traffic

Möglich wäre es hier natürlich auch wieder nach VLANs zu filtern.
Dazu (vlan.id == 100) && bzw. !(vlan.id) && voranstellen.

 

Schlussgedanken:

Die vorgestellte Methode stellt ein „per VLAN Broadcast Monitoring“ dar.
Sollte eine entsprechende Auswertungen nicht direkt über SNMP möglich sein.

 

Referenzen:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.