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:

cam-architecture

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.

Avatar
Jens Hofer 30.09.2022 21:58
Prinzipell sind aber alle Sachen, die du als "überraschend" bezeichnest klar bei Cisco dokumentiert oder zumindest über den Sales Contact erfragbar. Ich habe irgendwie das Gefühl, dass die Devices bei euch auf gut Glück eingesetzt werden ohne sich über die Kapazitätsgrenzen Gedanken zu machen.
Avatar
Lutz Donnerhacke 09.11.2020 11:54
Ja, neue Technik ist schon länger in der Pipeline, aber da hängt ein Konzern dran und die verkomplizieren den Bestellprozess.
Avatar
Florian Lohoff 09.11.2020 10:54
Der 4500er so wie 6500er und 7600er sind und bleiben halt Switche. Da sind die resourcen wenn man routing macht wirklich eng. Und wenn einem die Dinger so um die ohren fliegen weil die in Software Forwarding gehen ists halt echt fies das wieder ans laufen zu bringen. Oft sitzen die Kisten ja mit "zwingenden Featuren" so voll das dann guter Rat teuer ist. Als L3 Gerät dann lieber nen MX oder ERX und dann die 4500er oder einen EX als "Port Extender" da dran.
Avatar
Andi 09.11.2020 09:16
"IPv6 ist aktuell kein Vertragsbestandteil beim Kunden" - das ist ein Armutszeugnis für einen Internetprovider.
Avatar
Andreas Kohlberg 09.11.2020 08:27
Hallo,
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

Post a comment

Verwandter Inhalt