Memory/TCAM Exhaustion: Symptome, Nachweise und Mitigation

Memory/TCAM Exhaustion ist eine der unangenehmsten Fehlerklassen in der Netzwerktechnik, weil sie selten als „harte“ Störung startet. Stattdessen beginnt es schleichend: Ein neues ACL-Template wird ausgerollt, ein zusätzlicher VRF kommt dazu, BGP nimmt mehr Prefixe an, ein Security-Team aktiviert neue Signaturen, oder ein Campus-Switch bekommt plötzlich sehr viele MAC-Adressen. Zunächst scheint alles stabil, doch unter der Oberfläche laufen knappe Ressourcen voll: System-RAM, Control-Plane-Speicher, Hardware-Tabellen (TCAM, CAM), FIB/Adjacency-Tabellen, Policy- und QoS-Entries. Wenn diese Ressourcen erschöpft sind, entstehen Fehlerbilder, die wie „zufällige“ Paketverluste, sporadische Routing-Probleme oder instabile Services wirken: Neue Routen werden nicht mehr programmiert, ACLs matchen nicht wie erwartet, einzelne Flows werden im Software-Path verarbeitet, die CPU steigt, oder das Gerät beginnt zu flappen. Professionelles Troubleshooting bei Memory/TCAM Exhaustion bedeutet daher, frühzeitig Symptome zu erkennen, die richtigen Nachweise zu sammeln und Mitigationen zu wählen, die den Betrieb stabilisieren, ohne die Ursache zu verschleiern. Dieser Artikel erklärt die typischen Symptome, zeigt eine belastbare Beweisführung (was ist voll, warum, und mit welcher Auswirkung) und liefert praxistaugliche Mitigation-Strategien – für Campus, Datacenter und WAN gleichermaßen.

Grundlagen: Welche „Memory“-Arten in Netzwerkgeräten wirklich relevant sind

Wenn Teams „Memory“ sagen, meinen sie oft unterschiedliche Dinge. Für eine saubere RCA müssen Sie System-RAM, Control-Plane-Tabellen und Hardware-Speicher strikt trennen, weil ihre Exhaustion unterschiedliche Symptome erzeugt.

• System-RAM (Control Plane Memory): Speicher für Prozesse, Routing-Datenstrukturen (RIB), Log-Buffer, Telemetrie-Agenten, Management-Dienste. Engpässe führen häufig zu Prozessabstürzen, CPU-Last, Instabilität oder Reboots.
• CAM (Content-Addressable Memory): häufig für MAC-Tabellen (L2 FDB) und andere Lookup-Tabellen. Exhaustion äußert sich oft in Flooding, MAC-Flapping-Indizien oder L2-Anomalien.
• TCAM (Ternary CAM): teurer, aber extrem schneller Speicher für ternäre Matches (0/1/*), typischerweise ACLs, QoS-Klassifizierung, PBR, NetFlow/sFlow-Features, teilweise auch Routing-Funktionen je nach Plattform. Exhaustion ist häufig ein „Feature“-Problem: Regeln können nicht mehr installiert werden oder werden in Software verarbeitet.
• FIB/Forwarding Tables (Hardware/ASIC): Tabellen für Forwarding-Einträge (Prefixe, Next-Hops, ECMP-Set). Exhaustion führt dazu, dass Routen zwar im RIB existieren, aber nicht vollständig in Hardware programmiert werden.
• Adjacency/Neighbor Tables: ARP (IPv4), ND (IPv6) sowie Host- und Next-Hop-Adjacencies in Hardware/Software. Exhaustion erzeugt „neue Flows gehen nicht“ oder „nur manche Ziele brechen“.

Warum TCAM so oft der Engpass ist

TCAM ist knapp, teuer und nicht beliebig skalierbar. Außerdem ist die Nutzung häufig partitioniert: Ein Teil ist für IPv4/IPv6-Routing reserviert, ein Teil für ACLs, ein Teil für QoS/Policy. Je nach Plattform können Sie diese Partitionen konfigurieren – und genau dort entstehen viele Fehlkonfigurationen. Hinzu kommt: TCAM skaliert nicht nur mit der Anzahl der Regeln, sondern auch mit deren Komplexität (z. B. IPv6-ACLs, object-groups, viele Ports, Kombinationen aus L3/L4/L7-Matches).

• IPv6 kostet oft mehr: Viele Plattformen benötigen mehr TCAM-Ressourcen für IPv6-ACLs oder IPv6-FIB-Einträge.
• Mehr VRFs = mehr Tabellen: VRF-Design multipliziert häufig Policy- oder Routing-State.
• „Kleine“ Änderungen sind nicht klein: Ein neues ACL-Template, das auf 200 Interfaces ausgerollt wird, kann TCAM sprengen.
• Feature-Kombinationen: QoS + ACL + PBR + NetFlow kann dieselben TCAM-Bereiche beanspruchen.

Typische Symptome von Memory/TCAM Exhaustion

Die Symptome hängen davon ab, welche Ressource voll ist. Ein wichtiger E-E-A-T-Grundsatz: Verlassen Sie sich nicht auf „es fühlt sich so an“, sondern ordnen Sie Symptome einer Ressourcenkategorie zu.

Symptome bei System-RAM Exhaustion

• Prozesse crashen oder werden neu gestartet: Routing- oder Management-Dienste sterben und kommen wieder.
• CPU steigt sekundär: Garbage Collection, Logging-Overhead, Ausnahmebehandlung, oder Software-Forwarding durch andere Exhaustionen.
• Management wird unzuverlässig: SNMP/gNMI timeouts, CLI zäh, Syslog-Lücken.
• Instabilität bis zum Reload: Watchdogs, Kernel OOM, Supervisor failover.

Symptome bei TCAM Exhaustion

• ACL/QoS/PBR lässt sich nicht mehr programmieren: Deployments scheitern, Regeln werden „skipped“ oder nur teilweise installiert.
• Policy wirkt inkonsistent: Ein Interface matcht, ein anderes nicht – obwohl Konfiguration identisch ist.
• Software-Fallback: Traffic wird in den Slow Path gepuntet → CPU-Anstieg, Latenzspitzen, Drops.
• Feature-Degradation: NetFlow-Export wird unvollständig, QoS-Klassen verhalten sich falsch, oder PBR greift nicht.

Symptome bei FIB/Adjacency Exhaustion

• RIB ≠ FIB: Routing-Protokoll lernt Prefixe, aber Hardware programmiert sie nicht vollständig. Ergebnis: Teile des Traffics laufen falsch oder gar nicht.
• „Neue Ziele gehen nicht“: Bestehende Sessions funktionieren, neue Ziele/Next-Hops brechen, weil Adjacencies fehlen.
• ECMP/Next-Hop-Reduktion: Gerät reduziert ECMP-Set oder markiert Einträge als „unresolved“.

Symptome bei CAM/MAC Table Exhaustion

• Flooding nimmt zu: Unbekannte Unicast wird geflutet, was wie Broadcast-Sturm wirkt.
• MAC Flapping Meldungen: Häufige Updates, L2-Instabilität, Endgeräte verlieren Konnektivität sporadisch.
• Security Features triggern: Port Security oder DHCP Snooping reagiert auf „zu viele MACs“ (je nach Design).

Nachweise: Wie Sie Memory/TCAM Exhaustion belastbar beweisen

Eine gute Beweisführung beantwortet drei Fragen: (1) Welche Ressource ist erschöpft? (2) Wodurch wird sie gefüllt? (3) Welche Auswirkung entsteht dadurch im Datenpfad? Dafür brauchen Sie eine Kombination aus Countern, Logs und Zustandsausgaben.

Beweis 1: Resource Utilization und „Headroom“

• System-RAM: Gesamt- und Prozessspeicher, Fragmentierung, OOM-Events, Restart-Logs.
• TCAM/CAM: Auslastung pro Partition (ACL/QoS/Route), belegte vs. freie Entries, „fail to program“ Meldungen.
• FIB/Adjacency: Anzahl installierter Routes vs. gelernter Routes, unresolved next-hops, adjacency utilization.

Wichtig ist dabei der Trend: Exhaustion ist oft ein Verlauf (z. B. 70% → 85% → 98%), nicht ein einzelner Snapshot.

Beweis 2: Control-Plane Logs und Event-Ketten

• Programmierungsfehler: Meldungen, dass ACL/QoS/Policy nicht in Hardware installiert werden konnte.
• Fallback-Indizien: Hinweise auf Software-Forwarding, punted packets, policy fallback.
• Protokollsymptome: BGP/OSPF Flaps oder Keepalive-Probleme als sekundäre Wirkung von CPU/Control-Plane-Overload.

Wenn Sie Syslog strukturieren, ist RFC 5424 eine gute Referenz für Felder und Severity-Handling.

Beweis 3: Datenpfad-Symptome (Drops, Latenz, Slow Path)

• Interface Discards/Errors: Basissignale, die Ihnen zeigen, ob Congestion/Fehler zusätzlich im Spiel sind. IF-MIB Referenz: RFC 2863.
• Queue Drops pro Klasse: Wenn Fallback/CPU zu Latenz und Drops führt, sehen Sie oft queueing-Drops (vendor-spezifisch).
• Flow Telemetry: Top Talkers und PPS-Spikes zeigen, ob ein Traffic-Muster das Problem verschärft (z. B. scanartige Last, viele kurze Flows). IPFIX Referenz: RFC 7011.

Die häufigsten Auslöser in der Praxis

In vielen Umgebungen wiederholen sich bestimmte Muster, die Ressourcen in kurzer Zeit aufbrauchen. Diese Muster sollten Sie als „RCA Shortcuts“ kennen.

ACL-Explosion durch Template-Rollout

• Ursache: Ein neues, großes ACL-Template wird auf viele Interfaces angewendet; IPv6-Regeln verdoppeln den Footprint.
• Symptom: Teile der ACL fehlen oder werden nicht hardware-programmiert, Policies wirken inkonsistent.
• Nachweis: TCAM-Partition „ACL“ near-full, „programming failed“ Events.

QoS/PBR Feature-Kombination

• Ursache: QoS-Klassifizierung (DSCP trust, class-maps) kombiniert mit Policern/Shapern und PBR.
• Symptom: QoS matcht nicht, Drops entstehen, CPU steigt durch Slow Path.
• Nachweis: TCAM „QoS/Policy“ Partition voll, per-class counters zeigen Lücken.

Routing Table Growth und FIB Pressure

• Ursache: Mehr Prefixe (z. B. Full Table, neue VRFs, weniger Aggregation), mehr ECMP-Next-Hops, häufige Updates.
• Symptom: RIB zeigt Prefixe, FIB install unvollständig; bestimmte Ziele unreachable oder suboptimal.
• Nachweis: „RIB-FIB mismatch“, FIB utilization near-limit, unresolved entries.

ARP/ND/Neighbor Table Exhaustion

• Ursache: Sehr viele Hosts in einem L2/L3-Segment, Proxy-ARP, ND-Stürme, Duplicate IPs.
• Symptom: Neue Flows hängen, sporadische Timeouts, CPU/Control-Plane-Events.
• Nachweis: Neighbor table near-full, ARP/ND rate hoch, CoPP drops (ARP/ND).

MAC Table Exhaustion durch L2-Designfehler

• Ursache: L2-Loop, falsche Trunks, virtualisierte Bridges, zu große Broadcast-Domäne.
• Symptom: Flooding, MAC flapping, STP TCN storms, sporadische Konnektivität.
• Nachweis: MAC table utilization near-full, TCN logs, flapping logs.

Mitigation: Stabilisieren ohne die Ursache zu verschleiern

In einem Incident brauchen Sie häufig sofortige Stabilisierung. Die Kunst ist, eine Mitigation zu wählen, die Headroom zurückgibt, aber die RCA nicht zerstört. Dokumentieren Sie jede Maßnahme mit Zeitpunkt und beobachtetem Effekt.

Mitigation bei System-RAM Pressure

• Noise reduzieren: Debug-Logs deaktivieren, Syslog-Rate limit, Telemetrie-Subscriptions kuratieren.
• Management entlasten: SNMP-Walks reduzieren, Polling-Intervalle erhöhen, nur High-Signal Pfade streamen.
• Prozess-Reset gezielt: Wenn ein einzelner Prozess leakt und der Hersteller es empfiehlt, kann ein kontrollierter Restart stabilisieren (Risiko klar bewerten).
• Plattform-Workaround: Bekannte Bugs/Memory-Leaks häufig nur über Patch/Upgrade dauerhaft lösbar.

Mitigation bei TCAM Exhaustion

• Regeln reduzieren: ACLs konsolidieren (CIDR/Port-Ranges), object-groups sinnvoll nutzen (plattformabhängig), redundante Regeln entfernen.
• Scope reduzieren: Policies nicht auf jedes Interface, sondern nur dort, wo nötig (z. B. Edge statt überall).
• Partitionierung anpassen: Wenn die Plattform TCAM-Partitionen erlaubt, Ressourcen zwischen Routing/ACL/QoS verschieben (mit Wartungsfenster und Test).
• Feature-Triage: Unkritische Features temporär deaktivieren, wenn sie viel TCAM verbrauchen (z. B. bestimmte QoS-Klassen, PBR-Ausnahmen).

Mitigation bei FIB/Route Exhaustion

• Aggregation: Prefixe zusammenfassen (Summarization), weniger spezifische Routen bevorzugen, Policy vereinfachen.
• Limits setzen: max-prefix in BGP, Import-Policies, default-only für bestimmte VRFs, um Wachstum zu kontrollieren.
• Traffic Engineering anpassen: ECMP reduzieren, wenn Next-Hop/Adjacency-Limits kritisch sind (Trade-off: weniger Lastverteilung).

Mitigation bei MAC/Neighbor Exhaustion

• L2-Domänen verkleinern: Segmentierung, mehr VLANs/VRFs, L3 näher an die Edge.
• Storm Control: Broadcast/Unknown-Unicast begrenzen, Loop-Guards konsequent einsetzen.
• Security Features sinnvoll einsetzen: Port Security, DHCP Snooping, ARP Inspection – aber so, dass sie nicht selbst Instabilität erzeugen.

Nachhaltige Fixes: Designentscheidungen, die Exhaustion unwahrscheinlicher machen

Mitigation stabilisiert, aber langfristig hilft nur ein Design, das Headroom und Wachstum einkalkuliert. Besonders in Netzen, die regelmäßig neue Services, VRFs oder Security-Policies bekommen, ist Kapazitätsplanung für TCAM und Tabellen kein „nice to have“.

• Headroom-Policy: Definieren Sie Grenzwerte (z. B. 70% normal, 80% warn, 90% kritisch) pro Ressource (TCAM, FIB, Neighbor, MAC, RAM).
• Change-Impact-Reviews: Jede größere ACL/QoS/PBR-Änderung wird auf TCAM-Impact geprüft (Template-Größe × Anzahl Interfaces).
• Baselines und Trends: Wachstumskurven für Prefixe, MACs, Neighbors und Policy-Entries. Nicht nur „aktueller Stand“.
• Observability: High-Frequency Telemetrie für Hotspots (Queues, CoPP, punt), aber kuratiert, damit die Management-Plane nicht selbst zum Problem wird.
• Vendor-Readiness: Software-Versionen und bekannte Bugs im Blick behalten; Release Notes und Advisories regelmäßig prüfen.

Beweisführung mit Captures und Flows: Wann es sinnvoll ist

Packet Captures sind nicht immer das erste Mittel bei TCAM/FIB-Problemen, aber sie helfen, wenn Sie die Wirkung im Datenpfad belegen müssen: Retransmissions, RSTs, PMTUD-Fehler, oder asymmetrische Auswirkungen auf bestimmte Flows. Flows (NetFlow/IPFIX) sind oft schneller, um betroffene Ziele, Ports und Muster zu identifizieren. Praxisreferenzen sind die tcpdump Manpage und die Wireshark Dokumentation.

• Nutzen von PCAP: Belegt „wie“ sich die Exhaustion auswirkt (Timeouts, Retries, ICMP fehlend, Reset).
• Nutzen von Flows: Belegt „wer/wo“ (Top Talkers, PPS, viele kurze Flows, Zielportmuster).

Runbook: Memory/TCAM Exhaustion in 15 Minuten eingrenzen

• Minute 0–3: Symptomtyp klassifizieren: Policy inkonsistent, neue Routen fehlen, CPU hoch, neue Flows gehen nicht, L2-Flooding? Zeitfenster und betroffene Geräte/Segmente festlegen.
• Minute 3–6: Ressourcenstatus prüfen: RAM, TCAM/CAM, FIB/Adjacency, Neighbor/MAC. Headroom bewerten (Trend, nicht nur Snapshot).
• Minute 6–9: Ursache eingrenzen: Was ist gewachsen? (ACL-Deploy, QoS change, BGP prefix growth, neue VRF, Host-Anzahl). Logs auf „programming failed“, „fallback to software“, „table full“ prüfen.
• Minute 9–12: Impact bestätigen: RIB-FIB mismatch, CoPP/punt/CPU-Indizien, Interface Discards/Errors, queue drops. Optional: Flow Telemetry für Traffic-Muster.
• Minute 12–15: Mitigation wählen: scope reduzieren, Regeln konsolidieren, unkritische Features deaktivieren, Aggregation/Import-Policy anpassen, mgmt load drosseln. Danach verifizieren: Ressourcen sinken, Symptome stabilisieren, und Änderungen dokumentieren.

Weiterführende Quellen

• RFC 2863 für IF-MIB Interfacecounter als Basis zur Abgrenzung von Congestion vs. Plattformproblemen
• RFC 5424 für Syslog-Strukturierung und Ereigniskorrelation in RCA-Workflows
• RFC 7011 für IPFIX (Flow Telemetry), um Wachstumsmuster und Verursacher schnell zu erkennen
• Wireshark Dokumentation für die Verifikation von Datenpfad-Auswirkungen per PCAP
• tcpdump Manpage für zielgerichtete Captures, Ring Buffer und produktionssichere Mitschnitte

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.