Hardware vs. Software Forwarding: Auswirkungen auf Latenz und Throughput

Ob ein Cisco Router in Hardware oder in Software forwardet, entscheidet oft über das Nutzererlebnis: Latenz, Jitter und maximaler Throughput hängen stark davon ab, ob Pakete im Fast Path (ASIC/QFP/Hardware-Data-Plane) bleiben oder die CPU (Software-Forwarding/Punt) involvieren. In stabilen Enterprise-Designs ist das Ziel klar: Transit-Traffic soll hardwarebeschleunigt laufen, während die CPU für Control- und Management-Plane reserviert bleibt. Dieses Verständnis hilft dir, Performance-Probleme sauber zu erklären und gezielt zu troubleshoot’n.

Definitionen: Was bedeutet Hardware-Forwarding und Software-Forwarding?

Hardware-Forwarding bedeutet, dass die Weiterleitung über spezialisierte Forwarding-Hardware erfolgt (z. B. ASIC oder QFP), basierend auf programmierten Tabellen (FIB/Adjacency). Software-Forwarding bedeutet, dass Pakete von der CPU verarbeitet werden, typischerweise in Ausnahmefällen (Punt/Exception) oder wenn ein Feature Hardware-Forwarding umgeht.

• Hardware-Forwarding: Fast Path, hohe PPS, niedrige Latenz
• Software-Forwarding: CPU-Pfad, begrenzte PPS, höhere/variablere Latenz
• Hybrid: Mischbetrieb ist normal (Control Plane in CPU, Transit in Hardware)

Merker

$\text{Transit in Hardware} \to \text{stabiler Throughput}, \text{Transit in CPU} \to \text{Jitter/Limit}$

Auswirkungen auf Latenz: Warum CPU-Pfade „spiky“ sind

Die CPU arbeitet mit Scheduling, Interrupts und Kontextwechseln. Wenn Pakete in die CPU puntet werden, konkurrieren sie mit Routing, Management und anderen Prozessen. Das erzeugt variable Verzögerung (Jitter) und kann unter Last plötzlich eskalieren.

• Hardware: konstante Pipeline-Latenz
• CPU: Scheduling-Latenz, abhängig von CPU-Auslastung
• Symptom: Ping-Latenz „springt“, obwohl Link nicht voll ist

Indizien im Betrieb

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

Auswirkungen auf Throughput: PPS ist oft der wahre Limit-Faktor

Throughput ist nicht nur „Mbit/s“, sondern auch „Pakete pro Sekunde“. Software-Forwarding wird häufig pps-limitiert: Viele kleine Pakete (z. B. VoIP, DNS, Scans) belasten die CPU stärker als wenige große. Hardware-Forwarding kann deutlich mehr pps verarbeiten.

• Viele kleine Pakete → CPU schnell am Limit
• Große Pakete → Throughput kann ok sein, pps bleibt niedriger
• VPN/Fragmentierung erhöht pps und verschärft CPU-Limits

PPS-Denkmodell

$\text{Throughput}\approx \text{pps}\times \text{PacketSize}\times 8$

Warum Pakete die Hardware verlassen: Punt- und Exception-Gründe

CPU-Pfade sind oft „by design“ für Control-Plane-Traffic (Pakete an Router-IP). Problematisch ist es, wenn Transit-Traffic puntet. Typische Ursachen sind Adjacency-Probleme, MTU/Fragmentierung, bestimmte Policy-Features oder unvollständige Hardware-Unterstützung.

• Pakete an Router-IP: ICMP, SSH, SNMP, Routing-Protokolle
• Adjacency incomplete: ARP/ND nicht aufgelöst (Glean)
• MTU/Fragmentierung: Overlays, PMTUD-Probleme
• Features: PBR, bestimmte NAT/Inspection-Kombinationen

Wie du erkennst, ob Hardware oder CPU forwardet

Du kombinierst drei Blickwinkel: CEF/FIB (Forwarding-Entscheidung), CPU/CoPP (Punt-Indizien) und Hardware-Drops (z. B. QFP-Statistiken). Damit kannst du „gefühlt langsam“ in messbare Ursachen übersetzen.

CEF und Adjacency prüfen

show ip cef 8.8.8.8 detail
show adjacency detail

CPU und Control Plane prüfen

show processes cpu sorted
show policy-map control-plane

Hardware-Drops prüfen (wenn QFP vorhanden)

show platform hardware qfp active statistics drop

Praxisbeispiele: Typische Performance-Symptome richtig zuordnen

Diese Muster helfen, schnell die richtige Hypothese zu wählen – ohne sofort an „mehr Bandbreite“ zu denken.

• CPU hoch, Link nicht voll, Latenz spiky → Punt/Control-Plane-Last
• Link voll, Drops in QoS/class-default → Congestion/Queueing, nicht CPU
• Nur große Downloads hängen → MTU/PMTUD, Fragmentierung, MSS
• NAT/VPN aktiv, Throughput niedriger als erwartet → Crypto/Feature-Overhead

Optimierungsansätze: Wie du im Fast Path bleibst

Die beste Performance ist meist Designarbeit: Transit so bauen, dass Hardware-Forwarding möglich bleibt, und CPU-Pfade schützen. Dadurch steigt Throughput und Latenz bleibt stabil.

• Adjacency stabil halten (ARP/ND, VLANs, Next-Hop)
• MTU/MSS standardisieren in Overlays/VPN
• Feature-Stack minimieren (PBR/NAT/Inspection nur gezielt)
• CoPP aktivieren und Management-Exposure reduzieren

MSS-Clamping (typischer VPN-Fix)

interface tunnel0
 ip tcp adjust-mss 1360

Verifikation: Erfolg nachweisen statt vermuten

Nach Tuning misst du erneut: CPU sinkt, Drops sinken, Throughput steigt und Latenz bleibt stabil. Wichtig ist ein reproduzierbarer Test und ein Messfenster.

show processes cpu sorted
show interfaces <wan> | include rate|drops|error
show policy-map interface <wan>
show policy-map control-plane
ping <remote-ip> repeat 100

Quick-Reference: 60-Sekunden-Check „Hardware vs. CPU“

Diese Checks liefern dir schnell Indizien, ob Forwarding hardwarebeschleunigt läuft oder ob Punt/Exceptions dominieren.

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

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.