Wenn Endgeräte „nicht erreichbar“ sind, VLANs scheinbar nicht stimmen oder du einen Layer-2-Angriff vermutest, sind zwei Tabellen entscheidend: die ARP-Tabelle (IP → MAC) und die MAC Address Table (MAC → Port/VLAN). In Cisco-Netzen bekommst du damit sehr schnell Klarheit, wo ein Gerät wirklich hängt, ob MACs flappen, ob ein Switch floodet oder ob ARP-Spoofing im Spiel ist. Dieser Leitfaden erklärt show mac address-table praxisnah, zeigt typische Workflows (Client finden, Uplink verfolgen, Flapping erkennen) und ergänzt die wichtigsten ARP-Checks.
Grundprinzip: ARP-Tabelle vs. MAC Address Table
Beide Tabellen beantworten unterschiedliche Fragen. Erst zusammen ergibt sich das vollständige Bild vom „IP-Paket bis zum Switchport“.
- ARP (L3): Welche MAC gehört zu einer IP? (IP → MAC)
- MAC Table (L2): An welchem Port/VLAN ist diese MAC gelernt? (MAC → Port/VLAN)
- Praxis: IP bekannt → ARP liefert MAC → MAC Table liefert Port
Die drei Standard-Commands
show ip arp
show mac address-table
show mac address-table dynamic
show mac address-table richtig lesen: Spalten und Bedeutung
Der Output enthält typischerweise VLAN, MAC-Adresse, Typ (dynamic/static) und das Interface. Genau diese vier Werte brauchst du für fast jedes Layer-2-Troubleshooting.
- VLAN: in welchem Broadcast-Domain-Kontext die MAC gelernt wurde
- MAC Address: Hardware-Adresse des Endgeräts oder nächster Hop
- Type: dynamic (gelernt) oder static (fix eingetragen)
- Ports: Interface oder Port-Channel, über den die MAC erreichbar ist
MAC Table anzeigen (Grundansicht)
show mac address-table
Praxis-Workflow 1: Client über IP finden (ARP → MAC → Port)
Wenn du die IP eines Clients kennst, ist das der schnellste Weg zur physikalischen Lokation. Wichtig: ARP sitzt meist auf dem L3-Gateway (SVI) oder auf einem Router, nicht zwingend auf dem Access-Switch.
1) MAC zur IP ermitteln
show ip arp | include 10.1.10.55
2) MAC im VLAN auf dem Switch suchen
show mac address-table | include aaaa.bbbb.cccc
show mac address-table vlan 10 | include aaaa.bbbb.cccc
3) Port prüfen und verifizieren
show interfaces status | include Gi1/0/10
show interfaces gigabitEthernet 1/0/10 switchport
Praxis-Workflow 2: Port „rückwärts“ prüfen (Was hängt an diesem Port?)
Wenn du einen verdächtigen Port hast (z. B. Loop, Rogue-Switch, MAC Flood), prüfe, wie viele MACs dort gelernt werden. Ein normaler Client-Port hat meist 1 MAC (oder 2 bei Phone+PC). Viele MACs sind verdächtig.
MACs auf einem Interface anzeigen
show mac address-table interface gigabitEthernet 1/0/10
show mac address-table dynamic interface gigabitEthernet 1/0/10
Interpretation (Faustregeln)
- 1 MAC: typischer Client
- 2 MACs: häufig Phone + PC
- Viele MACs: AP/Hypervisor/Unmanaged Switch oder Angriff/Loop
Praxis-Workflow 3: Uplinks und Port-Channels erkennen (MACs landen auf PoX)
Wenn die MAC Table einen Port-Channel zeigt, ist das gut: Der Traffic geht über den gebündelten Uplink. Wenn du hingegen erwartest, dass es ein Port-Channel ist, aber MACs auf Einzelports landen, ist EtherChannel oft nicht sauber gebündelt.
MACs auf Port-Channel ansehen
show mac address-table interface port-channel 1
show etherchannel summary
Hinweis
STP und MAC Learning sollten bei einem sauberen Bundle den Port-Channel sehen, nicht die einzelnen Member-Interfaces.
MAC-Flapping erkennen: Wenn MACs „wandern“
MAC-Flapping ist ein starkes Loop- oder Topologieproblem: Dieselbe MAC wird abwechselnd auf unterschiedlichen Ports gelernt. Das verursacht Unicast Flooding, TCNs und sporadische Ausfälle.
Logs auf MAC-Flapping prüfen
show logging | include MACFLAP|MAC move|FLAP
MAC gezielt beobachten
show mac address-table | include aaaa.bbbb.cccc
Typische Ursachen
- Layer-2-Loop (Patchfehler, Rogue-Switch)
- Falsch konfigurierter EtherChannel (parallele Links ohne Bundle)
- Split-Brain bei Stacks/MEC/Peer-Link-Problemen
MAC Address Table Overflow: Angriffsmuster erkennen
Bei MAC Flooding steigt die Anzahl dynamischer MACs sprunghaft. Dadurch wird Unknown-Unicast Flooding wahrscheinlicher. Ein starker Hinweis ist ein einzelner Access-Port mit sehr vielen MACs in kurzer Zeit.
MAC Table Größe und Dynamik prüfen
show mac address-table count
show mac address-table dynamic
show mac address-table interface gigabitEthernet 1/0/10
Abwehrmaßnahmen (Kurzliste)
- Port Security (MAC-Limits)
- Storm Control (Unknown-Unicast)
- 802.1X/MAB für kontrollierten Zugang
ARP praxisnah prüfen: Typische ARP-Probleme und Indikatoren
ARP-Probleme wirken wie „IP-Probleme“, sind aber oft Layer 2: falsche Zuordnung, ARP Spoofing oder fehlende Bindings bei DAI/IPSG. Prüfe ARP-Einträge auf Plausibilität.
ARP-Tabellen prüfen
show ip arp
show ip arp vlan 10
Warnsignale im ARP-Kontext
- Gateway-IP zeigt auf eine unerwartete MAC (Spoofing-Verdacht)
- Viele ARP-Änderungen in kurzer Zeit (Instabilität/Angriff)
- ARP-Requests ohne Antworten (VLAN/Trunk/Port down)
DAI/DHCP Snooping Kontext: Wenn ARP/MAC „nicht passt“
In gehärteten Netzen können DAI und DHCP Snooping ARP-/DHCP-Traffic droppen. Dann wirkt es so, als ob ARP/MAC „kaputt“ wäre, obwohl Security greift. Prüfe deshalb Bindings und DAI-Status.
show ip dhcp snooping binding
show ip arp inspection vlan 10
show logging | include DHCP|SNOOP|ARP|INSPECTION|DAI
Checkliste: Häufige Fragen, die du mit MAC/ARP sofort beantwortest
- Wo hängt der Client wirklich? (MAC → Port)
- Ist der Client im richtigen VLAN? (VLAN-Spalte)
- Ist es ein Edge-Port oder ein Uplink? (Gi vs. Po)
- Gibt es Loops/MAC-Flapping? (Logs, wechselnder Port)
- Gibt es MAC Flooding? (viele MACs auf einem Port, count steigt)
- Passt IP → MAC (ARP) zu MAC → Port (MAC Table)?
Best Practices: MAC/ARP-Auswertung im Betrieb standardisieren
Wenn du MAC/ARP konsequent nutzt, wird Troubleshooting schneller und sicherer. Entscheidend ist ein sauberer Pfad: Management-Zugriff, NTP-Zeit und zentrale Logs.
- NTP + Syslog, damit Events korrelierbar sind
- Port-Descriptions und Patchfeld-Dokumentation pflegen
- Edge-Standards: Port Security, DHCP Snooping, DAI, Storm Control
- Regelmäßige Checks auf MAC-Flapping und ungewöhnliche MAC-Anstiege
copy running-config startup-config
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.
