Data-Plane Performance Tuning: CEF, Punt Paths und typische Bottlenecks

Data-Plane-Performance auf Cisco Routern steht und fällt damit, ob Traffic im „Fast Path“ (Hardware/CEF) bleibt oder in die CPU „puntet“. Viele Performance-Probleme sehen aus wie „WAN ist langsam“, sind aber in Wirklichkeit Punt-Paths, suboptimale CEF-Programmierung oder Features, die Hardware-Forwarding umgehen. Wer CEF, FIB/Adjacency und Punt-Mechanismen versteht, kann Bottlenecks gezielt finden: erst messen (Counters/CPU/CEF), dann Ursachen isolieren (Feature, Packet-Type, MTU, Fragmentation) und schließlich optimieren (Design/Config).

Grundmodell: Fast Path vs. Punt Path

Ein Router forwardet idealerweise über CEF (Cisco Express Forwarding): Lookup in der FIB und Weiterleitung über Adjacencies. „Punt“ bedeutet: Das Paket wird an die CPU/Control Plane gegeben, weil es nicht im Fast Path verarbeitet werden kann oder weil ein Feature es erzwingt.

• Fast Path: CEF/FIB + Adjacency, hohe PPS/Throughput
• Punt Path: CPU verarbeitet Pakete, PPS limitiert, höhere Latenz
• Ziel: möglichst wenig Punt für Transit-Traffic

Merker

$\text{Hohe pps} + \text{CPU hoch} \to \text{oft Punt}$

CEF verstehen: FIB, Adjacency und warum das schneller ist

CEF trennt Routing (RIB) von Forwarding (FIB). Das Routing-Protokoll berechnet Routen in der RIB; CEF programmiert daraus die FIB und Adjacencies (z. B. Next-Hop MAC, Encapsulation). Dadurch werden pro Paket keine „teuren“ Route-Lookups nötig.

• RIB: Routing-Entscheidung (show ip route)
• FIB: Forwarding-Tabelle (show ip cef)
• Adjacency: Layer-2-Informationen für Next-Hop

CEF Checks

show ip cef
show ip cef 8.8.8.8
show adjacency
show adjacency detail

Typische Punt-Gründe: Welche Pakete landen in der CPU?

Viele Punt-Fälle sind logisch: Pakete an den Router selbst (Control/Management), ARP/ND, oder Pakete, die Hardware nicht decapsulieren kann. Kritisch wird es, wenn Transit-Traffic puntet – dann bricht Performance unter Last ein.

• Control/Management: Traffic an Router-IP (SSH, SNMP, Routing)
• ARP/ND und Ausnahmefälle (Adjacency unvollständig)
• Fragmentierung/ICMP/PMTUD-Sonderfälle (plattformabhängig)
• Features: bestimmte NAT/Inspection/Policy-Funktionen können punt erzwingen

Bottleneck 1: Adjacency-Probleme (ARP/Incomplete)

Wenn CEF kein gültiges Next-Hop L2 hat, kann Forwarding stoppen oder puntet. Du siehst dann „incomplete“ Adjacencies oder ARP, das nicht aufgelöst wird. Das wirkt wie „Routing ok, aber nichts geht“.

Diagnose

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

Typische Ursachen

• Next-Hop down oder falsches VLAN/Subinterface
• ARP wird gefiltert (ACL, DAI, L2-Security außerhalb)
• Falsche Mask/Gateway (L3-Designfehler)

Bottleneck 2: Fragmentierung und MTU – hohe PPS, niedriger Throughput

Wenn MTU zu groß ist oder PMTUD nicht funktioniert, entstehen Fragmentierung und Retransmits. Fragmentierung erhöht PPS massiv (mehr Pakete pro Datenmenge) und belastet Queues/CPU. In VPN/Overlays ist MSS-Clamping ein häufiges Tuning-Element.

• Symptom: große Transfers langsam/instabil, kleine Pings ok
• Symptom: Drops/Errors steigen, CPU/pps hoch
• Fix: MTU/MSS anpassen, PMTUD nicht blocken

DF-Ping und MTU Checks

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

MSS-Clamp (typisch bei VPN/Overlays)

interface tunnel0
 ip tcp adjust-mss 1360

Bottleneck 3: Policy/Features, die Hardware-Forwarding umgehen

Ein häufiger Enterprise-Pitfall ist „Feature stacking“ am Edge: NAT + ACL + PBR + Inspection + NetFlow + VPN. Je nach Plattform können einzelne Features Hardware-Forwarding einschränken oder punt-paths erzeugen. Dann zeigt sich: CPU steigt mit Traffic, obwohl Link nicht voll ist.

• PBR kann Traffic in einen anderen Processing-Pfad zwingen
• Bestimmte Inspection/Firewall-Funktionen sind stateful und CPU-lastig
• NetFlow/Telemetry erzeugt zusätzliche Verarbeitung (meist ok, aber messen)

Checks: CPU und Policy Counters korrelieren

show processes cpu sorted
show policy-map interface <wan>
show ip nat statistics

Punt sichtbar machen: Wie du CPU-Forwarding-Indizien findest

Ein Punt-Problem erkennst du selten mit einem einzelnen Befehl, sondern durch Korrelation: steigende CPU, hohe pps, Drops in Control-Plane, und Traffic-Probleme, die bei niedriger Last verschwinden.

• CPU hoch unter Traffic-Last
• Viele kleine Pakete (pps hoch) → CPU stärker belastet
• Control-Plane Policers droppen (CoPP) bei hoher Last

CoPP/CPU Checks

show processes cpu sorted
show policy-map control-plane
show interfaces <int> | include rate|drops|error

CEF Troubleshooting: RIB vs. FIB Inkonsistenz

Selten, aber kritisch: Routen sehen korrekt aus (show ip route), aber CEF/FIB ist inkonsistent oder zeigt unerwartete Next-Hops. Dann prüfst du gezielt FIB-Entries und Adjacencies.

RIB vs. FIB Gegenprobe

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

Performance-Tuning Patterns: Was in der Praxis wirklich hilft

Tuning ist meist Designarbeit: Features so platzieren, dass sie nicht unnötig CPU-paths erzeugen. Ziel ist eine „clean data plane“: Transit-Traffic bleibt im Fast Path, Control Plane ist geschützt, Monitoring ist gezielt.

• Stateful Features an dedizierte Security-Plattformen auslagern (wenn sinnvoll)
• PBR sparsam und gezielt einsetzen (nur notwendige Flows)
• NAT am Edge, nicht im Core; NAT-Regeln minimal halten
• Overlays: MTU/MSS standardisieren, PMTUD ermöglichen
• CoPP aktivieren, damit Control-Plane nicht das ganze System limitiert

Verifikation nach Tuning: Messpunkte definieren

Nach Änderungen prüfst du, ob CPU sinkt, Throughput steigt und Drops zurückgehen. Nutze feste Messpunkte (gleiche Tests), sonst sind Vergleiche wertlos.

• CPU vorher/nachher unter vergleichbarer Last
• Interface drops/errors vorher/nachher
• CEF/Adjacency stabil

Mess-Commands (Copy & Paste)

show processes cpu sorted
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
show policy-map control-plane
show policy-map interface <wan>

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.