CEF Exception Handling: Wenn Pakete die Fast Path verlassen

CEF (Cisco Express Forwarding) ist der Standard-Fast-Path auf Cisco Routern: Pakete werden über FIB und Adjacency extrem effizient weitergeleitet. Sobald jedoch „Exceptions“ auftreten, verlassen Pakete den Fast Path und werden anders verarbeitet – häufig als Punt zur CPU (Control Plane) oder als spezielle Exception-Queue in der Hardware. Genau dort entstehen typische Performance- und Stabilitätsprobleme: hohe CPU bei hohem pps, sporadische Drops oder „Traffic geht, aber langsam“. Wer CEF Exception Handling versteht, kann diese Fälle sauber erkennen, belegen und mit gezielten Fixes wieder in den Fast Path zurückführen.

Fast Path vs. Exception Path: das Grundmodell

Im Normalfall trifft CEF eine Forwarding-Entscheidung in der FIB und nutzt die Adjacency (Layer-2 Encapsulation). Exceptions entstehen, wenn das Paket nicht „CEF-forwardable“ ist oder ein Feature eine Sonderbehandlung erzwingt.

• Fast Path: FIB/Adjacency → schnelle Weiterleitung
• Exception: Sonderpfad → zusätzliche Verarbeitung, oft CPU/Queue-Limit
• Ziel: Transit-Traffic möglichst ohne Exceptions

Merker

$\text{Exception} \to \text{mehr Processing} \to \text{weniger Durchsatz}$

Was „CEF Exception Handling“ technisch bedeutet

CEF kann Pakete in verschiedene Exception-Kategorien einsortieren: „Punt“ zur CPU, „Drop“ in der Hardware, oder „Glean/Adjacency“-Behandlung, wenn Layer-2-Informationen fehlen. Die genauen Pfade sind plattformabhängig (z. B. QFP/ASIC), aber die Symptome sind in der Praxis sehr ähnlich.

• Punt: Paket wird an CPU/IOSd gegeben
• Glean/Incomplete: Next-Hop L2 fehlt, ARP/ND wird angestoßen
• Drop: Paket wird verworfen (Policy/Invalid/Resource)

Die häufigsten Gründe, warum Pakete den Fast Path verlassen

Unter Realbedingungen sind es meist wenige Muster: Adjacency-Probleme, Fragmentierung/MTU, Control-Plane-Traffic, oder Feature-Stacks (NAT/PBR/Inspection), die Hardware-Forwarding einschränken.

• Adjacency „incomplete“ (ARP/ND nicht aufgelöst)
• Fragmentierung/PMTUD-Sonderfälle (VPN/Overlays, DF/ICMP)
• PBR/Policy-Features (Traffic wird umgelenkt/neu bewertet)
• Control-Plane-Traffic (an Router-IP) statt Transit
• Malformed/Exceptions (Header/Checksum/TTL/Optionen)

Erkennen: Symptome eines Exception-/Punt-Problems

CEF-Exceptions sind selten „sauber sichtbar“ in einem einzigen Output. Du erkennst sie über Korrelation: CPU steigt mit pps, während Interfaces nicht zwingend voll sind; CoPP-Drops steigen; oder QFP/Hardware-Drops zeigen Exception-Reasons.

• Hohe CPU bei hoher Paketzahl (pps), nicht unbedingt bei hoher Bandbreite
• Control-Plane Policers droppen (CoPP) bei Last
• „Sporadische“ Drops ohne physische Errors
• Probleme treten erst unter Last auf

Erste Checks

show processes cpu sorted
show policy-map control-plane
show interfaces | include rate|drops|error
show platform hardware qfp active statistics drop

Adjacency Exceptions: Glean, Incomplete und ARP/ND

Wenn die Adjacency fehlt oder „incomplete“ ist, kann CEF nicht normal forwarden. Der Router versucht dann, L2-Informationen zu lernen (ARP/ND). Bis dahin werden Pakete gedroppt oder über Sonderpfade verarbeitet.

Diagnose

show ip cef <destination> detail
show adjacency detail | include Incomplete|incomplete|Glean|glean
show arp | include <next-hop-ip>

Typische Ursachen

• Falsches VLAN/Subinterface (dot1Q), falscher Next-Hop
• ARP wird gefiltert oder L2 ist broken (Switch/VLAN/DAI)
• Asymmetrie/Fehlrouting führt zu „falschem“ Next-Hop

Fragmentierung/MTU als Exception-Trigger

Fragmentierung erhöht pps und kann je nach Plattform Sonderpfade auslösen. Besonders in IPsec/GRE/DMVPN-Szenarien führt Overhead zu PMTUD-Problemen: große Pakete scheitern, kleine funktionieren. Das wirkt wie „Application Issue“, ist aber häufig CEF/MTU/ICMP.

MTU prüfen und DF-Ping testen

show interfaces <int> | include MTU
ping <remote-ip> df-bit size 1472
ping <remote-ip> df-bit size 1400

Praxisfix: MSS-Clamping (TCP)

interface tunnel0
 ip tcp adjust-mss 1360

Policy-bedingte Exceptions: PBR, NAT und Feature-Stacks

Viele Enterprise-Edges nutzen NAT, ACLs, PBR, QoS und VPN parallel. Je nach Plattform kann das Hardware-Forwarding einschränken oder Punt-Pfade für bestimmte Flows erzeugen. Daher ist das „Feature-Audit“ ein Pflichtschritt.

• PBR: kann Traffic in einen Sonderpfad zwingen (Route-Map/Next-Hop)
• NAT: translations/overload kann zusätzliche Verarbeitung verursachen
• QoS/Policing: Drops/remarks können wie „CEF-Probleme“ wirken

Feature-Checks

show ip policy
show route-map
show ip nat statistics
show policy-map interface <wan>

Punt Paths zur Control Plane: wenn Transit-Traffic zur CPU wandert

Punt ist normal für Control-Plane-Traffic, aber gefährlich für Transit. Häufige Punt-Auslöser sind Protokolle an Router-IPs (ICMP, TTL-expired, traceroute), Scans oder L2/L3-Exceptions. Hier schützt CoPP die CPU, aber die eigentliche Lösung ist: Ursachen minimieren.

CoPP und CPU prüfen

show policy-map control-plane
show processes cpu sorted
show logging | include PUNT|COPP|CPU

Management-Exposure reduzieren (Beispiel)

ip access-list standard VTY_MGMT
 permit 10.255.0.0 0.0.255.255
 deny any
line vty 0 15
 transport input ssh
 access-class VTY_MGMT in

Belegführung: RIB vs. FIB und CEF-Details

Wenn du beweisen willst, dass es ein Forwarding-Problem ist, brauchst du die Gegenprobe zwischen Routing (RIB) und Forwarding (FIB). Danach gehst du in CEF-Details und Adjacencies.

show ip route <destination>
show ip cef <destination> detail
show adjacency detail

Praktische Fix-Patterns: zurück in den Fast Path

Die meisten Fixes sind nicht „CEF neu starten“, sondern Design- und Policy-Korrekturen: Adjacency stabilisieren, MTU/MSS standardisieren, Feature-Stacks entschlacken, und Control-Plane schützen.

• Adjacency: L2/VLAN/ARP stabilisieren, Next-Hop korrigieren
• MTU/MSS: VPN/Overlays standardisieren, PMTUD ermöglichen
• Policy: PBR/NAT nur gezielt einsetzen, QoS korrekt dimensionieren
• Control-Plane: CoPP + Management-ACL, um CPU-Spitzen zu vermeiden

Quick-Runbook: CEF Exceptions unter Last eingrenzen

Dieses Runbook liefert dir die wichtigsten Fakten in kurzer Zeit und hilft, die Exception-Kategorie zu bestimmen.

show processes cpu sorted
show policy-map control-plane
show interfaces <wan> | include rate|drops|error
show ip route | include Gateway|0.0.0.0
show ip cef 8.8.8.8 detail
show adjacency detail | include Incomplete|Glean|glean
show platform hardware qfp active statistics drop
show ip nat statistics
show ip policy

Konfiguration speichern

Router# 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.