
OPERATIONAL DEFECT DATABASE
...

...
A switch can unexpectedly reload due to a critical software exception, cause by a memory allocation error. Exception to IOS Thread: Frame pointer 0xXXXXXXX, PC = 0xXXXXXXX UNIX-EXT-SIGNAL: Segmentation fault(11), Process = SISF Main Thread When this issue is encountered, a long-term increase in the size of the Crimson IOS Private Operational Database will be observed. In the output of "show process memory platform detailed name iosd smaps | begin IOS_PRIV_OPER_DB" the Size and Rss counters are rapidly increasing: Switch#show proc mem plat detailed name iosd smaps | begin IOS_PRIV_OPER_DB 8c80000000-8ccf5a1000 rw-s 00000000 00:28 88415 /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB Size: 1300100 kB Rss: 1295284 kB Note that the immediate symptoms of this issue may vary depending on which feature is first unable to allocate new memory when it needs to, but the database size increase will always be present.
This problem may happen over time as device-tracking MAC entries with attached IPv6 addresses are created and removed from the SISF database. IPv4 addresses do not trigger this issue. Note that this is triggered by the presence of IPv6 addresses in the network; no specific IPv6 configuration on the affected device is required.
A periodic reboot of the affected device will reset the memory usage. The "device-tracking tdl-disable" service-internal command may be used to disable the SISF Crimson DB entirely and avoid this issue; however, this means that no SISF data will be available via the Crimson DB to any consumer (e.g. DNAC). This command requires service-internal to remain enabled to persist through reloads.
When devices are detected in the network, SISF adds entries for the MAC and IP addresses to the Crimson DB, and creates a linkage between the two to indicate their association. On deletion, memory in the linkage between MAC and IPv6 entries is not entirely freed. Over time, as millions of such linkages are created and deleted in response to network events, the switch's Crimson memory is exhausted. This issue was introduced in a new feature in 17.2.1 and 16.12.3. It exists in all releases from there until the releases where it has been fixed; it is fixed in 17.3.6, 17.6.4 and 17.9.1. It is in PI code and may therefore be observed on any platform that supports both Crimson and SISF.
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.