OPERATIONAL DEFECT DATABASE
...
...
A Catalyst switch can unexpectedly reload due to a critical software exception. The reload can be seen due to a segmentation fault on process SSF8472 From crashinfo file. "UNIX-EXT-SIGNAL: Segmentation fault(11), Process = SFF8472" SISF error logs seen prior to the reload: SISF_DB_IOS_ERR: sisf add or update record error (Not enough space) SISF_DB_IOS_ERR: TDL MAC xxxx.yyyy.zzzz differs from BT entry MAC xxxx.yyyy.zzzz SISF_DB_IOS_ERR: sisf delete record error (Invalid argument) SISF_DB_IOS_ERR: Unable to find IPv6 entry in mac xxxx.yyyy.zzzz for ip_key SISF_DB_IOS_ERR: Unable to unset binding entry for key and mac xxxx.yyyy.zzzz SISF_DB_IOS_ERR: Unable to find IP and zone in mac record xxxx.yyyy.zzzz SISF_DB_IOS_ERR: Unable to set up MAC's IP binding for xxxx.yyyy.zzzz SISF_DB_IOS_ERR: Unable to set binding entry for key and mac xxxx.yyyy.zzzz SISF_DB_IOS_ERR: MAC record update failed for mac xxxx.yyyy.zzzz address key SISF_DB_IOS_ERR: Unable to update binding from mac record - address is SISF_DB_IOS_ERR: Unable to add/update new binding for mac xxxx.yyyy.zzzz, address , SISF_DB_IOS_ERR: sisf add or update record error (Not enough space)
This issue may happen in mixed IPv4/IPv6 networks over a long period of time as a result of normal SISF operation. 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. This workaround will prevent further memory leakage due to this issue, but will not recover any memory that has already been leaked; a reboot will do this. The "device-tracking tdl-disable" only disables publication of SISF data in the Crimson database; normal functionality and operation of SISF is not impacted by this.
SISF database entries are published via the Crimson operational database. When an entry changes, the process to update the corresponding Crimson database entry involves a search to find it. SISF maintains a static IP address structure for use in IP database lookups, in order to reduce the overhead of these; it is used for both IPv4 and IPv6. When an IPv4 lookup follows an IPv6 one, the IPv6 address used for the previous search is leaked rather than being freed properly. Over time, these cumulative leaks will eventualy exhaust the Crimson IOS operational database, at which point this issue may be observed. 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 16.12.8, 17.3.5, 17.6.3, 17.7.2, 17.8.1 and 17.9.1. It is in PI code and may therefore be observed on any platform that supports both Crimson and SISF. Note that CSCwb25610 is a very similar issue (it isn't possible to distinguish it from this one in the field as the symptoms are the same) but is fixed in a later set of releases.
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.
