7.4 VLAN- und Switching-Fehleranalyse

Ein Client besitzt eine gültige IP-Konfiguration, kann aber bestimmte Geräte, Server oder Netze nicht erreichen. Andere Clients am gleichen Standort funktionieren möglicherweise problemlos. In solchen Fällen kann die Ursache auf der Sicherungsschicht liegen:

falsches Access-VLAN,
VLAN auf einem Switch nicht vorhanden,
VLAN auf einem Trunk nicht zugelassen,
Native-VLAN-Mismatch,
fehlerhafte Portkonfiguration,
blockierter Port durch Spanning Tree,
gestörter EtherChannel,
falsche MAC-Adresszuordnung,
Port-Security-Verletzung,
Schleife oder MAC-Flapping,
physischer Fehler an Port oder Verkabelung.

Die Diagnose muss vom betroffenen Endgerät über jeden beteiligten Switch bis zum Gateway beziehungsweise Zielsystem erfolgen.

Ein Symptom ist noch keine Ursache. Ein erreichbarer Switch beweist nicht, dass das betroffene VLAN auf dem vollständigen Datenpfad korrekt transportiert wird.

1. Typische Fehlerbilder

Beobachtung	Mögliche Ursache
nur ein Client ist betroffen	Access-Port, Kabel, Netzwerkkarte, VLAN-Zuordnung oder Port-Security
alle Clients an einem Switch sind betroffen	Uplink, Trunk, EtherChannel, STP oder Switchausfall
nur ein VLAN ist betroffen	VLAN fehlt, Trunk-Liste, SVI, Gateway oder STP-Instanz
Clients im gleichen VLAN kommunizieren nicht	falsches VLAN, Port-Isolation, Private VLAN, ACL oder lokale Firewall
lokale Geräte sind erreichbar, Gateway nicht	Uplink, Trunk, SVI oder Gateway
Gateway erreichbar, andere VLANs nicht	Routing, ACL oder Firewall statt reines Layer-2-Problem
Fehler tritt nur an einem Standort auf	lokaler Switch, Trunk, Standort-Uplink oder VLAN-Bereitstellung
Fehler tritt nur an einem Port auf	Portkonfiguration, Kabel, Port-Security oder Hardware
Verbindung funktioniert nach Umstecken	unterschiedliche VLAN- oder Portkonfiguration
Verbindung fällt wiederholt kurz aus	Link-Flapping, STP-Änderungen, EtherChannel oder Hardware
IP-Telefon funktioniert, angeschlossener PC nicht	Voice-VLAN korrekt, Data-VLAN oder Trunk zum Telefon fehlerhaft
DHCP funktioniert nicht, statische IP teilweise schon	DHCP-Relay, DHCP-Serverpfad oder falsches VLAN
MAC-Adresse erscheint ständig an anderen Ports	Schleife, falsch verbundene Switches oder MAC-Flapping

2. Sollzustand vor der Diagnose feststellen

Vor der Fehlersuche muss bekannt sein, wie der Port und der Datenpfad vorgesehen sind.

Zu dokumentieren sind:

betroffener Client,
MAC-Adresse des Clients,
Switchname,
physischer Switchport,
vorgesehenes Access-VLAN,
gegebenenfalls Voice-VLAN,
IP-Subnetz des VLANs,
vorgesehene Gateway-Adresse,
beteiligte Uplinks,
beteiligte Trunks,
erlaubte VLANs auf jedem Trunk,
Native VLAN,
zuständiges SVI oder Router-Subinterface,
mögliche EtherChannels,
verwendete Spanning-Tree-Variante,
Zeitpunkt und Umfang der Störung.

Beispiel:

Client:              client01
MAC-Adresse:         00:11:22:33:44:55
Switch:              access-sw01
Port:                GigabitEthernet1/0/12
Access-VLAN:         20
IP-Netz:             192.0.2.0/24
Gateway:             192.0.2.1
Uplink:               GigabitEthernet1/0/48
Trunk-VLANs:          10,20,30
Distribution-Switch: dist-sw01
SVI:                  Vlan20

Ohne diesen Sollzustand lässt sich eine vorhandene Konfiguration nicht zuverlässig als richtig oder falsch bewerten.

3. Umfang der Störung bestimmen

Zuerst prüfen:

ist nur ein Client betroffen,
sind mehrere Clients am gleichen Portpfad betroffen,
betrifft der Fehler alle Ports eines Switches,
betrifft der Fehler nur ein VLAN,
betrifft er mehrere VLANs,
betrifft er nur einen Switch,
betrifft er mehrere Switches,
funktioniert die Kommunikation innerhalb des VLANs,
funktioniert die Kommunikation zum Gateway,
funktioniert die Kommunikation zwischen VLANs,
begann die Störung nach einer Änderung?

Vergleichstests

Vergleich	Aussage
anderer Client am gleichen Port	grenzt Client und Port gegeneinander ab
gleicher Client an bekannt funktionierendem Port	prüft Client gegen Switchport
anderer Client im gleichen VLAN	prüft Umfang innerhalb des VLANs
Client in anderem VLAN am gleichen Switch	grenzt VLAN gegen allgemeinen Switchfehler ab
gleiches VLAN an anderem Switch	grenzt lokalen Switch oder Uplink ein
Gateway desselben VLANs	prüft den Layer-2-Pfad bis zum Gateway
Ziel im gleichen Subnetz	prüft lokale Layer-2-Kommunikation
Ziel in anderem Subnetz	bezieht zusätzlich Routing und Firewall ein

Ein Gerät darf nur kontrolliert umgesteckt werden. Vorher müssen ursprünglicher Port, VLAN-Zuordnung und Konfiguration dokumentiert werden.

4. Clientkonfiguration prüfen

Unter Windows:

ipconfig /all

Get-NetAdapter

Get-NetIPConfiguration

Get-NetIPAddress

Get-NetRoute -AddressFamily IPv4

Unter Linux:

ip link show

ip address show

ip route show

Unter macOS:

ifconfig

route -n get default

Zu prüfen sind:

ist der richtige Adapter aktiv,
besitzt der Client eine Adresse aus dem vorgesehenen Subnetz,
stimmt die Präfixlänge,
stimmt das Standardgateway,
stammt die Adresse aus dem erwarteten DHCP-Bereich,
existieren zusätzliche aktive Adapter,
verwendet der Client selbst VLAN-Tagging,
ist eine Bridge oder virtuelle Netzwerkkarte aktiv,
läuft eine VM oder ein Container mit eigener Netzwerkkonfiguration?

Eine gültig aussehende IP-Adresse beweist nicht, dass der Client am richtigen VLAN angeschlossen ist. In verschiedenen VLANs können ähnliche oder versehentlich überlappende Adressbereiche vorkommen.

5. Physische Verbindung und Portstatus prüfen

Am Client prüfen:

Get-NetAdapter |
    Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress

Auf einem Cisco-IOS-/IOS-XE-Switch beispielsweise:

show interfaces status

Gezielten Port prüfen:

show interfaces GigabitEthernet1/0/12

Kurze Fehlerübersicht:

show interfaces counters errors

Zu prüfen sind:

Portstatus,
ausgehandeltes Tempo,
Duplexmodus,
Ein- und Ausgangsfehler,
CRC-Fehler,
Drops,
Link-Flapping,
Zeitpunkt der letzten Statusänderung,
administrativ deaktivierter Port,
Fehlerzustand wie err-disabled.

Typische Bewertungen

Status oder Zähler	Mögliche Ursache
`notconnect`	kein Link, Kabel, Client oder Gegenstelle
`disabled`	Port administrativ deaktiviert
`err-disabled`	Schutzfunktion oder erkannter Fehler
viele CRC-Fehler	Kabel, Stecker, Transceiver, Duplex oder physische Störung
viele Input Errors	physischer Fehler, Überlastung oder fehlerhafte Frames
viele Output Drops	Überlastung oder Warteschlange
Geschwindigkeit unerwartet niedrig	Kabel, Aushandlung oder Gegenstelle
Link wechselt ständig	Kabel, Netzwerkkarte, Transceiver, Energieversorgung oder Port

Zähler sollten zuerst dokumentiert und danach über einen festgelegten Zeitraum erneut abgelesen werden. Ein hoher historischer Wert allein beweist keinen aktuell fortbestehenden Fehler.

6. Nachbarschaft und tatsächlichen Port ermitteln

Cisco Discovery Protocol:

show cdp neighbors

Details:

show cdp neighbors detail

Link Layer Discovery Protocol:

show lldp neighbors

Details:

show lldp neighbors detail

Zu prüfen sind:

welches Gerät tatsächlich angeschlossen ist,
welcher lokale Port verwendet wird,
welcher Gegenstellenport gemeldet wird,
ob statt eines Clients ein weiterer Switch angeschlossen ist,
ob ein IP-Telefon zwischen Client und Switch liegt,
ob die dokumentierte Verkabelung mit der erkannten Topologie übereinstimmt.

CDP oder LLDP kann deaktiviert sein. Ein fehlender Nachbar beweist deshalb nicht, dass keine Verbindung besteht.

7. VLAN-Zuordnung des Access-Ports prüfen

VLAN-Übersicht:

show vlan brief

Portbezogene Switchportinformationen:

show interfaces GigabitEthernet1/0/12 switchport

Relevante Portkonfiguration:

show running-config interface GigabitEthernet1/0/12

Zu prüfen sind:

administrativer Portmodus,
tatsächlich verwendeter Portmodus,
Access-VLAN,
Voice-VLAN,
Native VLAN bei einem Trunk,
erlaubte VLANs,
dynamische oder fest konfigurierte Aushandlung,
zusätzliche Sicherheits- oder Authentifizierungsfunktionen.

Beispiel eines vorgesehenen Access-Ports:

interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 20

Mögliche Fehler

switchport access vlan 10

obwohl der Client VLAN 20 verwenden soll.

Oder der Port arbeitet unerwartet als Trunk:

switchport mode trunk

Eine Konfigurationszeile allein reicht nicht zur Bewertung. Administrative und operative Zustände müssen miteinander verglichen werden.

8. Existenz und Status des VLANs prüfen

show vlan brief

Gezielt:

show vlan id 20

Zu prüfen sind:

existiert VLAN 20,
ist es aktiv,
besitzt es den erwarteten Namen,
sind die vorgesehenen Access-Ports zugeordnet,
existiert das VLAN auf jedem beteiligten Switch,
wurde es möglicherweise gelöscht oder umnummeriert,
ist eine VLAN-Verwaltung wie VTP beteiligt?

Wichtig

Ein Access-Port kann auf ein VLAN verweisen, das auf dem Switch nicht ordnungsgemäß vorhanden oder aktiv ist. Ebenso beweist die Existenz des VLANs auf einem Access-Switch nicht, dass es auf allen weiteren Switches des Pfades verfügbar ist.

VLANs dürfen nicht vorschnell neu angelegt werden. Zuerst muss geklärt werden, ob das VLAN absichtlich entfernt wurde oder über ein vorgesehenes Verwaltungsverfahren bereitgestellt werden soll.

9. MAC-Adresse des Clients ermitteln

Unter Windows:

Get-NetAdapter |
    Format-Table Name, MacAddress, Status

Unter Linux:

ip link show

Unter macOS:

ifconfig

Die MAC-Adresse muss dem tatsächlich verwendeten physischen Adapter zugeordnet werden. WLAN-, Ethernet-, Docking-, VPN- und virtuelle Adapter besitzen unterschiedliche MAC-Adressen.

Beispiel:

00-11-22-33-44-55

Auf Cisco-Switches wird sie normalerweise ohne Trennzeichen oder mit Punktgruppen gesucht:

0011.2233.4455

10. MAC-Adress-Tabelle prüfen

Gesamte Tabelle:

show mac address-table

Bestimmte MAC-Adresse suchen:

show mac address-table address 0011.2233.4455

MAC-Adressen eines VLANs:

show mac address-table vlan 20

MAC-Adressen eines Ports:

show mac address-table interface GigabitEthernet1/0/12

Zu prüfen sind:

wird die Client-MAC gelernt,
wird sie im richtigen VLAN gelernt,
erscheint sie am erwarteten Port,
erscheint sie auf einem Uplink statt am lokalen Clientport,
wechselt sie zwischen mehreren Ports,
fehlt sie vollständig,
ist der Eintrag dynamisch oder statisch?

Bewertung

Beobachtung	Mögliche Ursache
MAC am richtigen Access-Port und VLAN	lokaler Layer-2-Eingang grundsätzlich erkannt
MAC im falschen VLAN	falsche Access-, Voice- oder Tagging-Konfiguration
MAC auf falschem Port	falsche Dokumentation, Verkabelung oder Schleife
MAC nur am Uplink	Client befindet sich hinter einem anderen Gerät
MAC fehlt	Client sendet nicht, falscher Port, Linkproblem oder Filterung
MAC wechselt zwischen Ports	Schleife, doppelte Verbindung oder MAC-Flapping
sehr viele MAC-Adressen am Clientport	möglicherweise weiterer Switch oder Bridge angeschlossen

Die MAC-Adresse muss auf jedem Switch entlang des Pfades verfolgt werden. Auf einem Access-Switch sollte sie am Clientport erscheinen, auf nachgelagerten Switches am jeweiligen Uplink in Richtung des Clients.

11. Layer-2-Pfad anhand der MAC-Adresse verfolgen

Beispiel:

Client
  |
  | Gi1/0/12, VLAN 20
  |
Access-Switch
  |
  | Gi1/0/48, Trunk
  |
Distribution-Switch
  |
  | Port-Channel1, Trunk
  |
Gateway-SVI Vlan20

Prüfung auf dem Access-Switch:

show mac address-table address 0011.2233.4455

Erwartung:

VLAN 20 -> GigabitEthernet1/0/12

Prüfung auf dem Distribution-Switch:

show mac address-table address 0011.2233.4455

Erwartung:

VLAN 20 -> GigabitEthernet1/0/48

oder:

VLAN 20 -> Port-channel1

Verschwindet die MAC-Adresse an einem Übergang, sind insbesondere zu prüfen:

VLAN auf dem nächsten Switch vorhanden,
VLAN am Trunk zugelassen,
Trunk tatsächlich aktiv,
STP-Status des VLANs,
EtherChannel-Zustand,
Native-VLAN-Konfiguration,
physische Verbindung.

12. Trunkstatus prüfen

Trunkübersicht:

show interfaces trunk

Gezielten Port prüfen:

show interfaces GigabitEthernet1/0/48 switchport

Konfiguration anzeigen:

show running-config interface GigabitEthernet1/0/48

Zu prüfen sind:

ist der Port operativ ein Trunk,
wird IEEE 802.1Q verwendet,
welches Native VLAN ist konfiguriert,
welche VLANs sind administrativ zugelassen,
welche VLANs sind aktiv,
welche VLANs werden tatsächlich weitergeleitet,
welche VLANs sind durch Spanning Tree nicht blockiert?

Beispiel:

interface GigabitEthernet1/0/48
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30

Wenn VLAN 20 benötigt wird, muss es auf jedem Trunk des vollständigen Pfades zugelassen und aktiv sein.

13. Allowed-VLAN-Liste auf jedem Trunk vergleichen

show interfaces trunk

Beispiel eines Fehlers:

Access-Switch:
Allowed VLANs: 10,20,30

Distribution-Switch:
Allowed VLANs: 10,30

VLAN 20 ist nur auf einer Seite zugelassen. Geräte in VLAN 10 und VLAN 30 funktionieren, während VLAN 20 den Trunk nicht vollständig passieren kann.

Typische Ursachen

VLAN bei einer Änderung aus der Liste entfernt,
VLAN nur auf einer Trunkseite ergänzt,
falscher Uplink bearbeitet,
VLAN-Liste versehentlich vollständig ersetzt,
EtherChannel-Mitglieder besitzen unterschiedliche Konfigurationen,
VLAN existiert auf einem Switch nicht.

Eine Allowed-VLAN-Liste darf nicht pauschal auf „alle VLANs“ erweitert werden. Dadurch können Segmentierung, Sicherheit und vorgesehene Netzgrenzen verändert werden.

14. Native VLAN prüfen

Auf beiden Seiten des Trunks:

show interfaces trunk

show interfaces <trunk-port> switchport

Beispiel eines Mismatch:

Switch A: Native VLAN 999
Switch B: Native VLAN 1

Mögliche Auswirkungen:

ungetaggter Verkehr landet auf beiden Seiten in unterschiedlichen VLANs,
Spanning Tree meldet eine PVID-Inkonsistenz,
ein Port oder VLAN wird durch Schutzmechanismen blockiert,
Verwaltungs- oder Steuerverkehr erreicht ein falsches VLAN,
Sicherheitsrisiken durch unbeabsichtigte VLAN-Zuordnung.

Native VLANs müssen entsprechend der vorgesehenen Architektur auf beiden Seiten übereinstimmen. Ein Mismatch darf nicht dadurch „gelöst“ werden, dass wahllos VLAN 1 verwendet wird.

15. Access-Port und Trunk nicht verwechseln

Access-Port

transportiert normalerweise den Datenverkehr genau eines Data-VLANs,
Endgerät sendet üblicherweise ungetaggte Ethernet-Frames,
Switch ordnet eingehende Frames dem Access-VLAN zu.

Trunk-Port

transportiert mehrere VLANs,
VLAN-Zuordnung erfolgt normalerweise über IEEE 802.1Q-Tags,
Native-VLAN-Verkehr kann abhängig von der Konfiguration ungetaggt sein.

Typische Fehlkonfigurationen

Seite A	Seite B	Mögliche Folge
Access VLAN 20	Access VLAN 20	korrekt für eine einfache Verbindung im selben VLAN
Trunk	Trunk	korrekt, wenn VLANs und Native VLAN übereinstimmen
Access	Trunk	VLAN-Mismatch und unerwartete Zuordnung
Access VLAN 10	Access VLAN 20	ungetaggter Verkehr wird verschiedenen VLANs zugeordnet
Trunk mit VLAN 20	Trunk ohne VLAN 20	VLAN 20 kann den Pfad nicht vollständig nutzen
Trunk Native 999	Trunk Native 1	Native-VLAN-Mismatch

16. Clientseitiges VLAN-Tagging berücksichtigen

Ein normaler Arbeitsplatzclient sendet an einem Access-Port gewöhnlich keine VLAN-Tags. VLAN-Tagging am Client kann jedoch vorkommen bei:

Servern mit mehreren VLANs,
Hypervisoren,
virtuellen Switches,
Containernetzwerken,
Firewalls,
Access Points,
IP-Telefonen,
Netzwerktestgeräten,
speziellen Netzwerkkartentreibern.

Zu prüfen sind:

ist am Client eine VLAN-ID konfiguriert,
erwartet der Switch einen Access-Port oder Trunk,
stimmt die VLAN-ID des Clients mit der Switchkonfiguration überein,
entfernt der Netzwerkkartentreiber VLAN-Tags,
existiert ein Hypervisor-vSwitch mit eigener VLAN-Zuordnung,
wird das Tag bereits an einer anderen Ebene hinzugefügt?

Beispiel eines Fehlers:

Server-NIC taggt VLAN 20
Switchport ist Access-Port in VLAN 20

Abhängig von Gerät und Konfiguration kann der getaggte Frame verworfen oder unerwartet verarbeitet werden.

17. Voice-VLAN und IP-Telefone prüfen

Beispiel:

interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 20
 switchport voice vlan 30

Dabei kann gelten:

PC-Daten:       VLAN 20
Telefonverkehr: VLAN 30

Zu prüfen sind:

funktioniert nur Telefonie oder nur der PC,
ist das Data-VLAN korrekt,
ist das Voice-VLAN korrekt,
erkennt das Telefon die VLAN-Information,
ist der PC-Port des Telefons aktiv,
wird das Telefon per LLDP-MED oder CDP konfiguriert,
sind beide VLANs auf dem Uplink zugelassen,
existieren DHCP und Gateway in beiden VLANs?

Dass das Telefon funktioniert, beweist nicht, dass auch das Data-VLAN korrekt eingerichtet ist.

18. ARP beziehungsweise Neighbor Cache prüfen

Unter Windows:

Get-NetNeighbor

arp -a

Unter Linux:

ip neighbor show

Unter macOS:

arp -a

Zu prüfen sind:

besitzt der Client einen Eintrag für das Gateway,
ist der Eintrag erreichbar oder unvollständig,
stimmt die MAC-Adresse des Gateways,
ändert sich die Gateway-MAC unerwartet,
antworten Geräte im gleichen Subnetz auf ARP?

Bewertung

Beobachtung	Mögliche Eingrenzung
Gateway-Eintrag ist erreichbar	Layer-2-Kommunikation zum Gateway grundsätzlich möglich
Gateway bleibt `Incomplete`	ARP-Anfrage oder Antwort erreicht das Ziel nicht
falsche Gateway-MAC	falsches Gerät, doppelte IP, Fehlkonfiguration oder Angriff
lokales Ziel im gleichen VLAN nicht auflösbar	Layer-2-Pfad, Zielgerät oder lokale Firewall prüfen
Gateway erreichbar, anderes Subnetz nicht	Routing, ACL oder Firewall untersuchen

ARP darf erst nach Dokumentation kontrolliert geleert werden. Ein Cache-Reset beseitigt sonst möglicherweise relevante Hinweise.

19. Gateway-SVI prüfen

Auf einem Layer-3-Switch beispielsweise:

show ip interface brief

Gezielt:

show interfaces Vlan20

Konfiguration:

show running-config interface Vlan20

ARP-Tabelle:

show ip arp

Zu prüfen sind:

existiert das SVI,
besitzt es die vorgesehene IP-Adresse,
ist es administrativ aktiv,
ist der Protokollstatus aktiv,
ist das zugehörige VLAN vorhanden und aktiv,
existiert mindestens ein erforderlicher aktiver Layer-2-Pfad,
wird die Client-MAC beziehungsweise IP gelernt,
ist ein Redundanzprotokoll beteiligt?

Typisches Fehlerbild

Vlan20 is administratively up, line protocol is down

Mögliche Ursache:

VLAN 20 existiert nicht aktiv,
kein zugehöriger Layer-2-Port ist aktiv,
VLAN wird nicht über einen funktionierenden Trunk transportiert,
plattformspezifische Voraussetzungen sind nicht erfüllt.

Ein erreichbares SVI in einem anderen VLAN beweist nicht, dass das SVI des betroffenen VLANs funktioniert.

20. Kommunikation innerhalb und außerhalb des VLANs trennen

Vom Client aus nacheinander prüfen:

eigene IP-Konfiguration,
Ziel im gleichen VLAN,
Standardgateway,
Ziel in einem anderen internen VLAN,
externes Ziel.

Windows:

Test-NetConnection -ComputerName <ziel-im-gleichen-vlan>

Test-NetConnection -ComputerName <gateway-ip>

Test-NetConnection -ComputerName <ziel-in-anderem-vlan> -Port <port>

Bewertung

Gleiches VLAN	Gateway	Anderes VLAN	Eingrenzung
fehlerhaft	fehlerhaft	fehlerhaft	Access-VLAN, Layer-2-Pfad oder Client prüfen
erfolgreich	fehlerhaft	fehlerhaft	Gateway-SVI, Trunk oder Gateway prüfen
erfolgreich	erfolgreich	fehlerhaft	Routing, ACL oder Firewall prüfen
erfolgreich	erfolgreich	erfolgreich	konkrete Anwendung oder Zielport prüfen

Ping kann durch eine Firewall blockiert werden. Für die Prüfung eines Dienstes ist zusätzlich der tatsächlich benötigte TCP- oder UDP-Port zu berücksichtigen.

21. Spanning-Tree-Zustand prüfen

Übersicht:

show spanning-tree

Bestimmtes VLAN:

show spanning-tree vlan 20

Bestimmten Port:

show spanning-tree interface GigabitEthernet1/0/48 detail

Zu prüfen sind:

Root Bridge,
Root Port,
Designated Ports,
blockierende beziehungsweise verwerfende Ports,
Kosten und Prioritäten,
Topology Changes,
letzte Statusänderungen,
inkonsistente Ports,
unterschiedliche STP-Modi,
unerwartete Root Bridge.

Ein durch Spanning Tree blockierter redundanter Port ist nicht automatisch fehlerhaft. Die Blockierung kann notwendig sein, um eine Layer-2-Schleife zu verhindern.

Problematisch ist beispielsweise:

der einzige vorgesehene Pfad wird blockiert,
Root Bridge befindet sich unerwartet an einem Access-Switch,
Ports wechseln wiederholt ihren Zustand,
VLANs verwenden unbeabsichtigt unterschiedliche Pfade,
PVID- oder Type-Inconsistency wird gemeldet.

22. Spanning-Tree-Änderungen und Schleifen untersuchen

show spanning-tree detail

Zusätzlich Systemprotokoll prüfen:

show logging

Hinweise auf mögliche Schleifen:

sehr viele Topology Changes,
MAC-Adresse wechselt zwischen Ports,
Broadcast- oder Multicast-Auslastung steigt stark,
Switchmanagement reagiert langsam,
mehrere Ports zeigen ungewöhnlich hohe Auslastung,
Netzwerk fällt periodisch aus,
STP-Root oder Root Port wechselt wiederholt.

Die physische Schleife darf nicht durch dauerhaftes Deaktivieren von Spanning Tree „behoben“ werden. Dadurch kann die Störung massiv verschärft werden.

23. MAC-Flapping prüfen

Protokolle untersuchen:

show logging

MAC-Adresse gezielt suchen:

show mac address-table address <mac-adresse>

Wiederholt prüfen, ob der Port wechselt.

Beispiel:

VLAN 20, MAC 0011.2233.4455:
Gi1/0/47 -> Gi1/0/48 -> Gi1/0/47

Mögliche Ursachen:

Layer-2-Schleife,
zwei aktive Verbindungen desselben Endgeräts ohne korrektes Teaming,
falsch aufgebauter EtherChannel,
nicht verwalteter Switch,
Bridge auf einem Client,
Hypervisor- oder Clusterkonfiguration,
absichtlich bewegte virtuelle MAC-Adresse,
Redundanzprotokoll.

Ein MAC-Wechsel ist nicht immer ein Fehler. Bei Clustern oder Redundanzmechanismen kann eine virtuelle MAC kontrolliert den Port wechseln. Häufigkeit, Zeitpunkt und vorgesehene Architektur müssen berücksichtigt werden.

24. EtherChannel beziehungsweise Port-Channel prüfen

Übersicht:

show etherchannel summary

Port-Channel prüfen:

show interfaces Port-channel1

Trunkstatus:

show interfaces trunk

Konfiguration der Mitglieder vergleichen:

show running-config interface GigabitEthernet1/0/47

show running-config interface GigabitEthernet1/0/48

Zu prüfen sind:

gehören alle vorgesehenen Ports zum Channel,
sind die Ports tatsächlich gebündelt,
verwenden beide Seiten dasselbe Verfahren,
stimmen Access- oder Trunkmodus überein,
stimmen Native VLAN und Allowed-VLAN-Liste überein,
stimmen Geschwindigkeit und Duplex,
ist der Port-Channel durch STP freigegeben,
sind einzelne Mitglieder suspendiert oder eigenständig aktiv?

Typische Fehler

ein Link ist nicht im Bundle,
LACP ist nur auf einer Seite passend konfiguriert,
Mitglieder besitzen unterschiedliche VLAN-Listen,
physische Ports werden einzeln statt über den Port-Channel konfiguriert,
ein paralleler Link bildet unbeabsichtigt eine Schleife.

25. Port-Security prüfen

Auf Cisco-Switches beispielsweise:

show port-security

Gezielter Port:

show port-security interface GigabitEthernet1/0/12

Portstatus:

show interfaces status err-disabled

Zu prüfen sind:

ist Port-Security aktiviert,
wie viele MAC-Adressen sind erlaubt,
welche MAC-Adressen wurden gelernt,
liegt eine Verletzung vor,
welche Reaktion wurde ausgelöst,
wurde der Port deaktiviert,
wurde ein anderes Endgerät oder Dock angeschlossen?

Typisches Fehlerbild

Ein Arbeitsplatz wird von einem PC auf eine Dockingstation umgestellt. Dadurch erscheint eine neue MAC-Adresse. Wenn nur eine bestimmte MAC zugelassen ist, kann der Port den Verkehr verwerfen oder in einen Fehlerzustand wechseln.

Port-Security darf nicht pauschal deaktiviert werden. Zuerst sind vorgesehene Sicherheitsrichtlinie, erlaubte Geräte und tatsächlich erkannte MAC-Adressen zu prüfen.

26. Weitere Schutzfunktionen berücksichtigen

Abhängig von der Umgebung können unter anderem beteiligt sein:

802.1X,
MAC Authentication Bypass,
Dynamic VLAN Assignment,
DHCP Snooping,
Dynamic ARP Inspection,
IP Source Guard,
BPDU Guard,
Root Guard,
Loop Guard,
Storm Control,
Private VLANs,
Port-Isolation,
Access Control Lists,
Network Access Control.

Mögliche Prüfungen auf Cisco-Geräten:

show authentication sessions

show dot1x all

show ip dhcp snooping

show ip arp inspection

show interfaces status err-disabled

show logging

Die tatsächlich verfügbaren Befehle hängen von Plattform und Softwareversion ab.

Typische Fehlerbilder

Beobachtung	Mögliche Funktion
Port erhält nach Anmeldung anderes VLAN	802.1X oder dynamische VLAN-Zuweisung
DHCP-Antworten werden verworfen	DHCP Snooping
ARP-Pakete werden verworfen	Dynamic ARP Inspection
Port nach Anschluss eines Switches deaktiviert	BPDU Guard
Datenverkehr oberhalb eines Grenzwerts verworfen	Storm Control
Clients im gleichen VLAN sehen sich nicht	Port-Isolation oder Private VLAN
nur autorisierte MAC funktioniert	Port-Security oder NAC

27. err-disabled-Ursache untersuchen

show interfaces status err-disabled

show errdisable recovery

show logging

Je nach Plattform können Ursachen sein:

BPDU Guard,
Port-Security,
Link-Flapping,
EtherChannel-Fehlkonfiguration,
UDLD,
Loopback-Erkennung,
DHCP-Ratenbegrenzung,
Sicherheitsverletzung.

Der Port darf nicht einfach wieder aktiviert werden, ohne die Ursache zu beseitigen. Andernfalls tritt der Fehler erneut auf oder eine Schleife wird wieder in Betrieb genommen.

Kontrollierte Wiederaktivierung erst nach Ursachenklärung:

interface <port>
 shutdown
 no shutdown

Dieser Eingriff verändert den Zustand und unterbricht die Verbindung. Er darf nur autorisiert und nach Sicherung der Diagnoseinformationen erfolgen.

28. Paketmitschnitt für VLAN-Tags verwenden

Ein Paketmitschnitt kann zeigen:

ob Frames VLAN-Tags besitzen,
welche VLAN-ID verwendet wird,
ob ARP-Anfragen gesendet werden,
ob ARP-Antworten zurückkommen,
ob DHCP Discover und Offer sichtbar sind,
ob nur eine Richtung des Verkehrs vorhanden ist,
ob LLDP- oder STP-Informationen auftreten.

Wireshark-Anzeigefilter für VLAN-Verkehr:

vlan

Bestimmte VLAN-ID:

vlan.id == 20

ARP:

arp

DHCP:

dhcp

LLDP:

lldp

STP:

stp

Wichtig

Ein Endgerät an einem normalen Access-Port sieht üblicherweise keine IEEE-802.1Q-Tags für sein Access-VLAN. Der Switch fügt die VLAN-Zuordnung intern hinzu beziehungsweise entfernt das Tag am Access-Port.

Für eine aussagekräftige Analyse auf einem Switch kann ein kontrolliert konfigurierter Mirror- oder SPAN-Port erforderlich sein. Mitschnitte dürfen nur autorisiert erfolgen und können vertrauliche Daten, Adressen, Namen und Anmeldeinformationen enthalten.

Netzwerkkarten und Treiber können VLAN-Tags vor der Übergabe an die Aufzeichnungssoftware verarbeiten. Das Fehlen eines sichtbaren Tags beweist daher nicht in jedem Mitschnitt, dass auf dem beobachteten Netzwerkpfad kein Tag verwendet wurde.

29. Beispiel für eine systematische Diagnose

Symptom

Ein Client erhält keine Verbindung zu internen Diensten. Andere Clients am gleichen Switch funktionieren.

Sollzustand

Clientport:    GigabitEthernet1/0/12
Access-VLAN:   20
Gateway:       192.0.2.1
Uplink:        GigabitEthernet1/0/48

Clientprüfung

ipconfig /all

Ergebnis:

IPv4-Adresse: 192.0.2.45
Gateway:      192.0.2.1

Portprüfung

show interfaces GigabitEthernet1/0/12 switchport

Ergebnis:

Operational Mode: static access
Access Mode VLAN: 20

MAC-Prüfung

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 20    0011.2233.4455    DYNAMIC    Gi1/0/12

Der Client wird am richtigen lokalen Port und im richtigen VLAN gelernt.

Trunkprüfung

show interfaces trunk

Ergebnis am Access-Switch:

Port Gi1/0/48
Allowed VLANs: 10,20,30

Ergebnis am Distribution-Switch:

Port Gi1/0/48
Allowed VLANs: 10,30

Festgestellte Ursache

VLAN 20 war auf der Distribution-Seite des Trunks nicht zugelassen. Dadurch wurde die Client-MAC am Access-Switch gelernt, der Datenverkehr erreichte jedoch nicht das Gateway.

Kontrollierte Maßnahme

Nach Prüfung des Sollzustands und Sicherung der Konfiguration wurde VLAN 20 auf der fehlenden Trunkseite ergänzt.

Nachprüfung

Auf beiden Switches:

show interfaces trunk

Ergebnis:

Allowed VLANs: 10,20,30

MAC-Adresse auf dem Distribution-Switch:

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 20    0011.2233.4455    DYNAMIC    Gi1/0/48

Clienttest:

Test-NetConnection -ComputerName 192.0.2.1

Der Client erreicht anschließend das Gateway und die vorgesehenen Dienste.

30. Beispiel „Port sieht korrekt aus, Client ist trotzdem im falschen VLAN“

Symptom

Der Client ist an Port GigabitEthernet1/0/12 dokumentiert. Die Prüfung dieses Ports zeigt das richtige VLAN. Der Client erhält trotzdem eine Adresse aus einem anderen Subnetz.

Prüfung der MAC-Adresse

show mac address-table address 0011.2233.4455

Ergebnis:

VLAN 30    0011.2233.4455    DYNAMIC    Gi1/0/18

Festgestellte Ursache

Der Client war physisch an Port GigabitEthernet1/0/18 angeschlossen. Die Dokumentation war veraltet. Port 18 gehörte zu VLAN 30.

Lehre

Nicht nur den dokumentierten Port prüfen. Der tatsächliche Port muss anhand von MAC-Adresse, LLDP/CDP, Verkabelung oder Portstatus bestätigt werden.

31. Ungeeignete Sofortmaßnahmen

Nicht als erste Maßnahme verwenden:

Switch ohne Diagnose neu starten,
Portkonfiguration vollständig löschen,
VLAN vorschnell neu anlegen,
alle VLANs auf jedem Trunk erlauben,
Native VLAN wahllos auf VLAN 1 setzen,
Spanning Tree deaktivieren,
blockierte STP-Ports ungeprüft freigeben,
EtherChannel auflösen,
Port-Security pauschal deaktivieren,
802.1X oder NAC umgehen,
BPDU Guard deaktivieren,
DHCP Snooping oder ARP Inspection deaktivieren,
MAC-Tabelle vor der Dokumentation vollständig löschen,
alle Schnittstellen gleichzeitig zurücksetzen,
redundante Links abziehen, ohne die Topologie zu prüfen,
Firewall oder ACL als vermeintlichen VLAN-Test deaktivieren,
mehrere Konfigurationsänderungen gleichzeitig durchführen,
ausschließlich mit ping testen,
einen erreichbaren Switch mit einem funktionierenden VLAN-Pfad gleichsetzen.

Solche Maßnahmen können Diagnoseinformationen beseitigen, Sicherheitsgrenzen verändern oder eine Layer-2-Schleife verursachen.

32. Vollständige Schnellprüfreihenfolge

genaue Störung, Zeitpunkt und Auswirkung dokumentieren.
feststellen, ob ein oder mehrere Clients betroffen sind.
vorgesehenes VLAN, Subnetz und Gateway ermitteln.
tatsächliche Client-MAC-Adresse feststellen.
tatsächlichen Switch und Port ermitteln.
physischen Linkstatus prüfen.
Fehlerzähler dokumentieren.
Portmodus prüfen.
Access- und Voice-VLAN prüfen.
Existenz und Status des VLANs prüfen.
Client-MAC in der MAC-Tabelle suchen.
MAC-Adresse über alle beteiligten Switches verfolgen.
jeden Uplink und Trunk ermitteln.
operativen Trunkstatus prüfen.
Allowed-VLAN-Listen auf beiden Seiten vergleichen.
Native VLAN auf beiden Seiten vergleichen.
VLAN-Existenz auf jedem Switch prüfen.
Spanning-Tree-Zustand für das betroffene VLAN prüfen.
blockierte oder inkonsistente Ports untersuchen.
Topology Changes und MAC-Flapping prüfen.
EtherChannel und seine Mitglieder prüfen.
Port-Security und err-disabled prüfen.
802.1X, NAC und dynamische VLAN-Zuweisung berücksichtigen.
DHCP Snooping, ARP Inspection und IP Source Guard prüfen.
Gateway-SVI und dessen Status prüfen.
ARP- beziehungsweise Neighbor-Einträge untersuchen.
Kommunikation im gleichen VLAN testen.
Gateway separat testen.
Inter-VLAN-Kommunikation separat testen.
bei Bedarf autorisierten Paketmitschnitt durchführen.
genau eine Hypothese formulieren.
genau eine kontrollierte Maßnahme durchführen.
Port-, VLAN-, Trunk-, STP- und MAC-Zustand erneut prüfen.
Clientverbindung und benötigten Dienst erneut testen.
Ursache, Änderung und Nachweis dokumentieren.

33. Checkliste VLAN und Switching

34. Schnellreferenz

Ergebnis	Nächster Schritt
Port ist `notconnect`	Kabel, Client, Transceiver und Gegenstelle prüfen
Port ist `err-disabled`	genaue Schutz- oder Fehlerursache ermitteln
viele neue CRC-Fehler	physischen Pfad und Aushandlung prüfen
Client erhält falsches Subnetz	Access-VLAN, dynamische VLAN-Zuweisung und DHCP prüfen
MAC fehlt vollständig	tatsächlichen Port, Clientübertragung und Link prüfen
MAC erscheint im falschen VLAN	Access-, Voice- oder Client-Tagging prüfen
MAC erscheint am falschen Port	Verkabelung, Dokumentation oder Schleife prüfen
MAC wechselt zwischen Ports	Schleife, Teaming, Cluster oder EtherChannel prüfen
VLAN fehlt auf einem Switch	vorgesehene VLAN-Bereitstellung prüfen
VLAN fehlt in Allowed-Liste	Trunkkonfiguration auf beiden Seiten vergleichen
Native VLAN unterscheidet sich	Mismatch kontrolliert korrigieren
Trunk nur auf einer Seite aktiv	Portmodus und Aushandlung prüfen
nur ein VLAN über Trunk gestört	VLAN-Existenz, Allowed-Liste und STP prüfen
alle VLANs über Uplink gestört	Link, Trunk, EtherChannel und Hardware prüfen
STP blockiert redundanten Port	prüfen, ob Blockierung vorgesehen ist
STP meldet PVID-Inkonsistenz	Native VLAN und Portmodi vergleichen
viele Topology Changes	Schleife, instabilen Link oder Root-Wechsel suchen
gleicher VLAN-Verkehr funktioniert	Layer-2-Pfad grundsätzlich vorhanden
Gateway nicht per ARP erreichbar	VLAN-Pfad, Trunk und SVI prüfen
Gateway erreichbar, andere VLANs nicht	Routing, ACL oder Firewall prüfen
Telefon funktioniert, PC nicht	Data-VLAN und PC-Port des Telefons prüfen
PC funktioniert, Telefon nicht	Voice-VLAN, LLDP/CDP und Voice-DHCP prüfen
nur ein EtherChannel-Mitglied aktiv	LACP und Mitgliedskonfiguration vergleichen
Paketmitschnitt zeigt falsche VLAN-ID	Taggingquelle und Portmodus prüfen
Paketmitschnitt zeigt am Access-Port kein Tag	kann bei einem Access-Port normal sein

Merksatz

Bei VLAN- und Switching-Fehlern wird der Datenpfad nicht erraten, sondern anhand von Portstatus, VLAN-Zuordnung, MAC-Adresse, Trunk, Spanning Tree und Gateway Schritt für Schritt verfolgt. Ein VLAN funktioniert erst dann, wenn es auf jedem beteiligten Switch vorhanden, auf jedem Trunk zugelassen und über einen freigegebenen Layer-2-Pfad bis zum vorgesehenen Gateway transportiert wird.

Quellen und weiterführende Dokumentation

Revision #1
Created 2 August 2026 00:07:33 by Admin
Updated 2 August 2026 12:21:27 by Admin