Layer 2 Migration Challenge

[scvvuuren]

Good Day

I was busy with a change for a customer over the weekend but decided to roll back due to the following error messages received on the L2 border.

Oct  3 2020 14:47:07.674 UTC: %LISP-4-MAP_SERVER_CONVERGING: IID 8217 Map-server is converging, unable to send negative map-reply.
Oct  3 2020 14:47:51.811 UTC: %SISF-3-INTERNAL: Internal error, Invalid creation arguments 3 20 50 -Process= "SISF Main Thread", ipl= 0, pid= 371 -Traceback= 1#b32070248316f3a388a1fd2209b0de6c  :55C5259A6000+696A206 :55C5259A6000+68E6123 :55C5259A6000+68E860B :55C5259A6000+688A47C :55C5259A6000+68B0AC9 :55C5259A6000+686E11A :55C5259A6000+69255F1 :55C5259A6000+696E708 :55C5259A6000+AAB5673 :55C5259A6000+696D42B :55C5259A6000+AA8907E

We have about 5 or even more subnets as layer 2 borders currently with no issues so far.

It is only observed when migrating a specific subnet, even after deleting it completely from fabric and re-creating it the same condition applies.

I then did the same process with another subnet, no issues.

The only thing I can think of thus far, if perhaps one of the existing subnets as layer 2 border might be bridged to this subnet in the legacy lan perhaps.

Any ideas, advise?

[Jonathan Cuthbert]

What version of Cisco DNA Center and IOS XE are you on?

Are you experiencing any forwarding or other issues or just receiving a Traceback?

[scvvuuren]

Hi

DNAC 1.3.3.7 with IOS-XE 17.3.1.

I could not observe actual forwarding issues, but did not want to migrate subnet into the fabric until I fully understand the issue and the repercussions of it.

So yesterday I thought about having a look at the MAC entries in the device-tracking database and found 1 particular MAC address 9 times. In different VRF's, but there are no entries in the CAM or ARP tables of this MAC address.

show device-tracking database | i 0000.0000.00fd

Closest thing I could find thus far is this bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvm86310/?rfs=iqvred

What I did find interesting though is in a TrustSec Configuration Guide when they show an example of show device-tracking database the same MAC appears in the document so it does not seem to be something specifically on the customers network. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_cts/configuration/15-sy/sec-cts-15-sy-book/cts_ipv6_sgt_sgacl.html

[scvvuuren]

I thought I would give an update if anyone finds this in future. It does seem to be a bug, https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvv03589. (I don't think it is publicly disclosed yet)

From TAC engineer, it seems to be cosmetic at this stage.

The root cause of this traceback because there is an all zero source mac passed in and trying to create mac entry in SISF.
This traceback won’t cause any crash.