TCAM full - Überraschender Totalausfall
Gestern gegen Mittag gab es bei einem Kunden eine großen Ausfall, drei zentrale Switche (von sechs) haben beinahe gleichzeitig nicht mehr ordnungsgemäß funktioniert. Es folgte stundenlange eine Odyssee, denn nach einem Reboot eines Switches hatte man knapp eine halbe Stunde bis er wieder ausfiel.
Ausgangslage
Nichts geht mehr. Spontan. Ohne Vorwarnung.
Alle Geräte, die hinter der Ausfallstelle sich befinden sind nicht mehr erreichbar. Kunden, Infrastruktur, Monitoring. Da auch DNS Server betroffen sind, gestaltet sich jeder Zugriff extrem zäh. Man wartet also teilweise eine Minute, bis man die Ergebnisse eines Kommandos zu Gesicht bekommt.
Eigentlich ist Redundanz gegeben: Wenn ein Gerät ausfällt, übernimmt ein anderes. Jetzt ist es aber anders. denn drei Geräte sind zeitgleich ausgefallen. Diese dienen dem Großteil der Infrastruktur als Uplink, was die Diagnosemöglichkeiten drastisch einschränkt.
In der Annahme, es handle sich um ein Problem, dass von einer defekten Komponente (z.B. ein Layer2-Loop) an einer Stelle eingespeist wird, wurde zunächst systematisch versucht, diese Stelle einzukreisen. Erfolglos.
Es blieb nichts weiter übrig, als einem der betroffenen Switche das Chassis stromlos zu machen, um Zugriff auf das Gerät zu bekommen und damit mehr Informationen zu erlangen. Vor einem solchen Hart-Reset scheut man normalerweise zurück, weil der komplette Reboot knapp 20 Minuten dauert.
Der Zugriff auf das frisch gebootet Gerät zeigt ... keine Auffälligkeiten. Das ist schlecht. Sehr schlecht. Denn damit gibt es keinen Ansatzpunkt, wo der Fehler her kommen könnte. Nach wenigen Minuten friert jedoch die Verbindung zum Gerät ein und es geht wieder nichts mehr.
In einer der Phasen gelingt es, Zugriff auf das Monitoring zu erlangen, dort findet sich ein erster Hinweis:
Nov 6 12:36:41 172.27.44.252 %C4K_L3HWFORWARDING-4-TCAMFULL: FLC Tcam full, packets will be forwarded in software at reduced rate. Failure due to: add tcam space failed Nov 6 12:38:41 172.27.44.254 %C4K_L3HWFORWARDING-4-TCAMFULL: FLC Tcam full, packets will be forwarded in software at reduced rate. Failure due to: add tcam space failed Nov 6 12:52:12 172.27.44.253 %C4K_L3HWFORWARDING-4-TCAMFULL: FLC Tcam full, packets will be forwarded in software at reduced rate. Failure due to: add tcam space failed
Oops. Die Meldung besagt, dass eine Hardware-Komponente voll gelaufen ist und nun die gesamte Funktion des Gerätes durch Software emuliert werden muss. Dabei die die CPU des Gerätes für eine solche Last gar nicht ausgelegt, sie soll eigentlich nur die Hardware konfigurieren, so dass die Datenströme die CPU selbst nie treffen.
Das erklärt einige der Effekte: Zum einen fällt das Gerät selbst nicht aus, so dass die Umschaltung auf die Redundanztechnik nicht stattfinden kann. Zum anderen erfüllt es seine Funktion nicht mehr ausreichend. Wir haben Paketverluste von 99%, was einer Unbenutzbarkeit gleich kommt.
TCAM - ein teurer Spaß
Was ist nun dieses ominöse TCAM? TCAM ist im Endeffekt eine Hardware, in der Key-Value-Paare abgelegt werden können. Man kann direkt nach dem Schlüssel (Key) suchen und bekommt in einem Takt das Ergebnis aus dem TCAM ausgelesen. Das ist natürlich irre schnell.
Diese gute Einführung in die Funktion des TCAM enthält das schöne Funktionsbild:
Auf einem TCAM Chip sind also Speicherzellen, die parallel die anliegende Datenanfrage mit den abgelegten Werten vergleichen und – wenn alles überein stimmt – die komplette Zeile aktivieren. Kann der Vergleicher nur 0/1, spricht man von CAM – Content Addressable Memory. Kann der Vergleicher auch den anliegenden Wert ignorieren, also einen dritten Zustand abbilden, so spricht man von TCAM – Tenary CAM.
Normalerweise müsste eine CPU den normalen Speicher nach dem Suchwert durchkämmen, um das Ergebnis zu ermitteln. Je nach Algorithmus dauert das, logarithmisches Wachstum der Suchzeit ist aber typisch. Dagegen hat der TCAM eine konstante Suchzeit von eins, das Ergebnis ist instantan verfügbar.
TCAM macht also die Geräte schnell, jedoch auch teuer. Deswegen versucht man den TCAM so effektiv wie möglich zu nutzen. Dabei trifft der Hersteller eine Reihe von Kompromissen.
Ein Teil des TCAM wird für QoS, ein Teil für ACLs, ein Teil für Layer2 (MAC Adressen), ein Teil für Layer3 (Routing), etc. pp, benutzt.
Wer hat meinen TCAM belegt?
Die Meldung im Log deutet darauf hin, dass der Layer3, also der Routing-Teil zu voll wird.
Das Datenblatt des Geräts schreibt:
- 128,000 Flexible NetFlow entries in hardware
- 64,000/32,000 IPv4/IPv6 routing entries for campus access and aggregation deployments
- IPv6 in hardware, providing wire-rate forwarding for IPv6 networks and support for dual stack with innovative resource usage
- Dynamic hardware forwarding-table allocations for ease of IPv4-to-IPv6 migration
- Scalable routing (IPv4, IPv6, and multicast) tables, Layer 2 tables, and access-control-list (ACL) and quality-of-service (QoS) entries to make use of 8 queues per port and comprehensive security policies per port
All diese Punkte haben mit TCAM Kapazitäten zu tun.
Wir haben in dem Netz ca. 2500 IP4 Routen (meist für Kunden mit statischen IPs) und ca. 8000 IPv6 Routen (hauptsächlich IPv6-PD). Das liegt weit unter den Limits.
Wir haben pro Gerät höchstens 35k MAC Adressen, das haben wir aber schon lange im Blick und sorgen dafür, dass diese Werte nicht in kritische Bereiche ansteigen.
Wir haben NetFlow aktiv. Das ist verzichtbar, also wird das abgeschaltet. Keine Besserung.
Wir haben Multipath-Routing aktiv, um Datenpakete über mehrere Leitungswege zu verteilen. Das ist meist auch verzichtbar und wird dort abgeschaltet. Keine Besserung.
Wir haben anti-spoofing ACLs aktiv, die schon wichtig sind. Aber vor der Wahl – gar keine Funktion oder Bösewichter aufhalten – fällt die Entscheidung leicht, besonders, da wir es bisher nicht mit Bösewichtern zu tun hatten und es noch weitere Filter tiefer im Netz gibt. Allerdings auch wieder keine Besserung.
Was bleibt denn noch?
Schauen wir uns das TCAM für Layer3 mal genauer an:
#sh platform hardware ip route summary block# start end mode entries used free group type 0 80 Bit 0 4095 4096 4096 0 3 Dst 1 160 Bit 4096 8190 2048 104 1944 5 Dst 2 160 Bit 8192 12286 2048 439 1609 4 Dst 3 80 Bit 12288 16383 4096 4096 0 3 Dst 4 80 Bit 16384 20479 4096 4096 0 3 Dst 5 80 Bit 20480 24575 4096 4095 1 3 Dst 6 80 Bit 24576 28671 4096 4096 0 3 Dst 7 80 Bit 28672 32767 4096 4094 2 3 Dst 8 80 Bit 32768 36863 4096 4096 0 3 Dst 9 80 Bit 36864 40959 4096 3454 642 3 Dst 10 Unused 40960 45055 4096 0 4096 - - 11 Unused 45056 49151 4096 0 4096 - - 12 Unused 49152 53247 4096 0 4096 - - 13 Unused 53248 57343 4096 0 4096 - - 14 Unused 57344 61439 4096 0 4096 - - 15 Unused 61440 65535 4096 0 4096 - -
Das TCAM ist in 16 Blöcke unterteilt, von denen noch sechs Blöcke frei sind. Die anderen Blöcke sind entweder mit 80bit oder 160bit Schlüsselbreite konfiguriert und verschiedenen Funktionsgruppen zugeordnet. Sie liefern Ziele (vermutlich für Routingentscheidungen).
Auffällig ist, dass die 160bit Blöcke nur die Hälfte der Einträge fassen können, wie die 80bit Blöcke. Es ist jedoch nur logisch, da für die Schlüssel doppelt so viel Platz brauchen.
group# inUse mode type lookup entries free util% rangeId 0 yes 80 Bit uRPF Ipv4 Src 0 0 100 0 1 yes 160 Bit uRPF Ipv6 Src 0 0 100 1 2 yes 160 Bit SpecSrc Src 0 0 100 255 3 yes 80 Bit UC Ipv4 Dst 32768 645 98 0 4 yes 160 Bit MC Ipv4 Dst 2048 1609 21 1 5 yes 160 Bit UC Ipv6 Dst 2048 1944 5 2 6 yes 320 Bit MC Ipv6 Dst 0 0 100 3 7 yes 160 Bit SpecDst Dst 0 0 100 255 8 yes 160 Bit OtherL3 Otr 0 0 100 4 range 0 [ipv4: 0.0.0.0 - ipv4: 255.255.255.255] 1 [ipv6: :: - ipv6: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF] 2 [null] 3 [ipv4: 0.0.0.0 - ipv4: 223.255.255.255] 4 [ipv4: 224.0.0.0 - ipv4: 239.255.255.255] 5 [ipv6: :: - ipv6: FEFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF] 6 [ipv6: FF00:: - ipv6: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF] 7 [null] 8 [ipv4: 0.0.0.0 - ipv6: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF]
Hier haben wir die Verwendungszwecke der TCAM Blöcke. Für reverse Path Filtering (das jetzt abgeschaltet ist) wird also die Source-Adresse als Schlüssel verwendet. Für IPv4/v6 Routing wird die Zieladresse als Schlüssel benutzt. Soweit so wenig überraschend.
Eher überraschend ist, dass Multicast doppelte Breite benötigt. Multicast Routing funktioniert anhand der Zielgruppe (einer IP) und der Quell-IP (einer IP), es ist also doch keine Überraschung.
Was Spec und OtherL3 ist, weiß ich nicht. Das kommt hier schlicht nicht vor.
blocks 0 (0) 1 (0) 2 (0) 3 (8) 0, 3, 4, 5, 6, 7, 8, 9 4 (1) 2 5 (1) 1 6 (0) 7 (0) 8 (0)
Auch die Zuordung der logischen Gruppen zu den physikalischen Blöcken ist nachvollziehbar. Es ist genau das, was bei der Auflistung der Blöcke schon stand.
entity total used free util% Entries 61440 32639 28801 53 uRPF Ipv4 0 0 0 0 uRPF Ipv6 0 0 0 0 UC Ipv4 32768 32091 677 97 MC Ipv4 2048 438 1610 21 UC Ipv6 2048 110 1938 5 MC Ipv6 0 0 0 0 SpecDst 0 0 0 0 SpecSrc 0 0 0 0 OtherL3 0 0 0 0 unused 24576 24576 0 100
Diese Zusammenfassung zeigt die relevanten Kenngrößen.
- Von den (80bit)-Einheiten des TCAM sind 53% belegt.
- IPv4 Routing hat 32091 Einträge aktiv, damit sind von den aktuell allozierten Blöcken 97% belegt.
- IPv4 Multicast hast 438 Einträge, was von dem einzigen allozierten Block 21% ausmacht.
- IPv6 Routing belegt mit 110 Einträgen in dem einzigen allozierten Block 5%
Wesentlich ist hier fest zu halten, das die Aussage im Datenblatt etwas euphemistisch formuliert wurde. Das TCAM wird für alle Protokolle gemeinsam benutzt, dabei passen maximal 32k IPv6 Routen rein, wenn nichts anderes auf der Maschine läuft. 64k IPv4 Routen passen nur, wenn nichts anderes damit gemacht wird. Sobald IPv4 und IPv6 oder Multicast oder uRPF gemischt werden, sinken die entsprechenden freien Blöcke rasant.
Die relevante Kenntgröße zur Überwachung ist also die Prozentzahl rechts oben (53%) oder noch besser die Zahl der freien Blöcke (die man sich als unused/4096 berechnen muss).
Gestern sah das anders aus. Wir hatten über 20000 Einträge bei IPv6 Routing und dazu noch die uRPF Belegungen. Damit war der der TCAM erschöpft.
Weiter oben sprach ich von ca 2500 IPv4 Routen, hier stehen nun 32091. Warum? Mit IPv6 war es gestern ähnlich, warum?
#sh ip route summary IP routing table name is default (0x0) IP routing table maximum-paths is 8 Route Source Networks Subnets Replicates Overhead Memory (bytes) application 0 0 0 0 0 connected 0 50 0 3640 9200 static 2 525 0 40264 96968 ospf 1 2 2084 0 150192 392168 Intra-area: 156 Inter-area: 68 External-1: 1565 External-2: 0 NSSA External-1: 297 NSSA External-2: 0 internal 18 108332 Total 22 2659 0 194096 606668
Die 2681 passen gar nicht mit den 32091 zusammen. Was ist da los?
Der Catalyst routet nicht wie ein normaler Router, sondern ist ein Layer3-Switch. Er benutzt das TCAM, um in einem einzelnen Schritt, das Ziel eines eingehenden Paketes zu ermitteln. Das Verfahren nennt sich Cisco Express Forwarding und ist der Grund dafür, dass die Geräte ebenso schnell switchen wie routen.
#sh ip cef summary IPv4 CEF is enabled for distributed and running VRF Default 32097 prefixes (32093/4 fwd/non-fwd) Table id 0x0 Database epoch: 2 (32097 entries at this epoch)
Das passt sehr gut (die Werte sind dynamisch und der TCAM Wert zeigt nun 32124). Aber was enthält CEF nun genau?
# sh ip cef Prefix Next Hop Interface 5.102.167.0/26 192.168.255.18 Vlan29 5.102.167.128/29 192.168.255.18 Vlan29 10.10.10.10/32 217.17.207.163 Vlan115 10.100.0.0/16 attached Vlan142 10.100.0.0/32 receive Vlan142 10.100.0.1/32 receive 10.100.0.3/32 receive Vlan142 10.100.0.4/32 attached Vlan142 10.100.0.5/32 attached Vlan142 10.100.1.1/32 attached Vlan142 10.100.1.2/32 attached Vlan142 10.100.1.3/32 attached Vlan142 10.100.1.7/32 attached Vlan142 10.100.1.9/32 attached Vlan142 ...
Es enthält die Routing-Einträge (wie erwartet) und alle Nachbarschaftseinträge (unerwartet). Damit ist mit einem Lookup im TCAM sofort ein neuer Layer2-Header verfügbar, der an einem bestimmten Interface raus geblasen werden kann. Er verweist entweder direkt auf die MAC Adresse des Zieles oder auf die MAC Adresse des nächsten Routers.
Dazu kommt, dass diese CEF hier distriuted ist, d.h. die verschiedenen eingesteckten Line-Cards haben ihr eigenes TCAM, dass analog befüllt wurde. Im Idealfall verläßt also eine eingehendes Paket nicht mal die Linecard sondern geht direkt auf einem anderen Port der gleichen Karte wieder raus.
Da diese Einträge im CEF auch die MAC Adressen enthalten, haben sie direkt mit den ARP Tabellen zu tun.
#sh arp summary Total number of entries in the ARP table: 29979. Total number of Dynamic ARP entries: 29800. Total number of Incomplete ARP entries: 143. Total number of Interface ARP entries: 36. Total number of Static ARP entries: 0. Total number of Alias ARP entries: 0. Total number of Simple Application ARP entries: 0. Total number of Application Alias ARP entries: 0. Total number of Application Timer ARP entries: 0.
Das passt also sehr gut zusammen.
Und wieder ist die Dokumentation zumindest ungenau. Es ist also nur dann 64k IPv4 Routen möglich, wenn die Ziele alle zu wenigen externen Geräte weiter geleitet werden müssen. Sobald es verschiedene Ziele für eine Route gibt, reicht das nicht mehr aus. Im Extremfall kann man also höchstens ein fast voll besetztes /16 lokal anbinden und schon geht gar nichts mehr.
Bei IPv6 halbieren sich die erreichbaren Zahlen. Bei Multicast noch einmal.
Ich bin solche Mogel-Aussagen von Cisco nicht gewöhnt. Ich bin ehrlichweise etwas ungehalten.
Lösung
Was nun tun?
Von den Kisten muss zuerst einmal das IPv6 runter. Große Layer2-Segmente mit SLAAC füllen das TCAM so schnell, dass es irgendwann platzt. Deswegen waren auch nur Geräte betroffen, die zwei solche Anbindungen versorgen. Mittlerweile ist die IPv6 Adoption der Endgeräte so weit angestiegen, dass es die TCAM Grenzen gerissen hat. Natürlich ist das allein kein Grund, dass alle drei Geräte gleichzeitig betroffen waren, sie waren aber alle in anderen Konstellationen kurz vor der Grenze und haben deswegen einen weiteren Anstieg anderswo im Netz nicht verkraftet.
IPv6 ist aktuell kein Vertragsbestandteil beim Kunden, deswegen muss für die IPv6-Versorgung eine andere Lösung gefunden werden, die nicht am TCAM knabbert. Wie genau die aussehen wird, ist noch nicht klar.
Nach einem beherzten "no ipv6 nd prefix ..." und einem "no ipv6 address 2a01:..../64" auf den dicken Kunden-Leitungen, ist Ruhe eingekehrt.
Und dabei bleibt es jetzt erst einmal.
Bleibt noch die Frage, ob sich das System selbst heilen kann. Was passiert also, wenn die TCAM-Blöcke nicht mehr von der zugeordneten Gruppe benötigt werden?
block# start end mode entries used free group type 0 80 Bit 0 4095 4096 4096 0 3 Dst 1 160 Bit 4096 8190 2048 56 1992 5 Dst 2 160 Bit 8192 12286 2048 195 1853 4 Dst 3 80 Bit 12288 16383 4096 4094 2 3 Dst 4 80 Bit 16384 20479 4096 4096 0 3 Dst 5 80 Bit 20480 24575 4096 4092 4 3 Dst 6 80 Bit 24576 28671 4096 4019 77 3 Dst 7 160 Bit 28672 32766 2048 0 2048 5 Dst 8 80 Bit 32768 36863 4096 3383 713 3 Dst 9 160 Bit 36864 40958 2048 1 2047 5 Dst 10 160 Bit 40960 45054 2048 3 2045 5 Dst 11 160 Bit 45056 49150 2048 1 2047 5 Dst 12 160 Bit 49152 53246 2048 2 2046 5 Dst 13 Unused 53248 57343 4096 0 4096 - - 14 Unused 57344 61439 4096 0 4096 - - 15 Unused 61440 65535 4096 0 4096 - -
Ganz einfach. Sie sind verloren.
Block 7 wurde für IPv6 Routing allokiert und nun nicht mehr benötigt. Er wird aber nicht als unbenutzt zurück gegeben. Er ist verloren. Ebenso wie die anderen Blöcke 9 bis 12.
Die einzige Möglichkeit TCAM wieder frei zu bekommen, ist also ein Reboot des Geräts. Das kann man aber planen.
Auch für die Kennzahlen der Überwachung ist dieser Zustand lehrreich:
entity total used free util% Entries 51200 24004 27196 46 uRPF Ipv4 0 0 0 0 uRPF Ipv6 0 0 0 0 UC Ipv4 24576 23767 809 96 MC Ipv4 2048 174 1874 8 UC Ipv6 12288 63 12225 0 MC Ipv6 0 0 0 0 SpecDst 0 0 0 0 SpecSrc 0 0 0 0 OtherL3 0 0 0 0 unused 12288 12288 0 100
Mit 46% frei schaut es doch gar nicht so schlecht aus, oder? Aber es sind nur die Hälfte der Blöcke frei, wie beim anderen, weniger belasteten, Gerät.
habt ihr aber gut hin bekommen um die Störung zu beseitigen!! Bloß, da muss doch mal was investiert werden um das für die Zukunft auszuschließen! Oder? Grüsse AKo
5 Kommentare