DNA SD-Access Interface Configurations

[jamessciortino0060]

Hi.

After upgrading DNA Center to 2.1.2.7, there is a discrepancy between the access interface configuration for my switches.

After provisioning a LAN Automated switch and making it fabric enabled, I would expect the following configuration on my access interfaces:

Switch1# shwo run interface GigabitEthernet5/0/48

switchport mode access
device-tracking attach-policy IPDT_MAX_10
dot1x timeout tx-period 5
dot1x max-reauth-req 3
source template DefaultWiredDot1xClosedAuth
spanning-tree portfast
spanning-tree bpduguard enable

But lately, a lot of the switches being onboarded are missing the command spanning-tree bpduguard enable

Switch2# show run int GigabitEthernet1/0/48

switchport mode access
device-tracking attach-policy IPDT_MAX_10
dot1x timeout tx-period 5
dot1x max-reauth-req 3
source template DefaultWiredDot1xClosedAuth
spanning-tree portfast

Also, I have found that when I onboard stacked switches, the stack members are completely missing their access interface configurations. This has been an ongoing problem since DNA Center 1.3.3.5. Anyone know a workaround to this without having to manually configure the interfaces?

StackedSwitch1# show run int GigabitEthernet1/0/48

device-tracking attach-policy IPDT_MAX_10

I'm running the following versions:

DNA 2.1.2.7

ISE 2.6 Patch 7

IOS-XE 16.12.4

I primarily deploy C9300L's in a stack, and C9410R's.

[Preston Chilcote]

I think you have some very valid concerns here, but I'm not seeing any internal documentation that explains either issue.  It would be great if you could work with TAC to get to the bottom of this and let us know what the final resolution is.

[Rajesh Kongath]

Hi, I have similar issue on 2.2.2.6

TAC is suspecting a potential bug for our case ( new stack members doesn't have any port configuration). We have seen the same behavior for all versions from 1.3.X.X. The workaround suggested in the bug details will still miss the IPDT command or sometime bpduguard command

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa44791

[gerry.schmucker]

Hi James,

I opened the Case which resulted in the mentioned Bug CSCwa44791 , however the TAC Engineer did not document my workaround  

The "easiest" way to have DNAC configure all interfaces of the added Stack-Member is:

1. goto Fabric -> Host-Onboarding

2. select all access-ports from the new switch, (hold-down shift-key if you have more than one added switch.)

3. assign any existing IP-Pool (does not matter which) and deploy it.

4. than select the ports again and choose "clear" and deploy it again.

Now DNAC configures all the Ports as default. 

If Cisco does not provide a fix soon, I will check out if this procedure can be done using a script with DNAC-SDK

Best Regards,

Gerry

[jamessciortino0060]

Gerry,

This is a fantastic workaround and I will definitely give it a shot. Thank you!

If you come up with some code using the DNA-SDK please share your Github link! It would be a great resource for everyone.

[Rajesh Kongath]

Hi Gerry

We had tried this option, but it was never injecting IPDT policy command, did you face the same issue?

[gerry.schmucker]

Hi Rajesh,

the command “device-tracking attach-policy IPDT_POLICY” got pushed during discovery phase in older DNAC, however they push it now during “add to Fabric”.
the funny thing is , if you discover via API and not via GUI you get this command on all the interfaces after discovery-phase as before (without any additional commands) !
I do not remember if this command was there when I added Stackmembers, however I have a couple of Stack Extentions in the next couple of weeks to find out
I think this policy was used to limit the number of Client per port to 10 in earlier Versions of DNAC. However they lifted this limit now.
So far as I saw device-tracking works also without this policy, maybe this policy will disappear in next releaases….

We can still push it with templates as a last resort….. however in my opinion all this are workaround for a bug which hopefully get’s fixed soon.

Cheers ,

Gerry

[jamessciortino0060]

Gerry, 

We just on boarded 6x C9300L switch stacks (each with 3 members) and a C9410R with four line cards. Using 16.12.4 IOS-XE btw.

The IPDT_Policy is missing from every single access interface. However, everything else on the config looks good, including spanning-tree bpdu guard commands.

I thought the IPDT_POLICY was needed to probe devices and maintain the device-tracking database?

[gerry.schmucker]

Hi James,

That’s true however if you have not configured the policy IPDT_POLICY on the interface it fallsback to LISP-DT-GUARD-VLAN , i you can check with “show device-tracking data detail” after removing the IPDT_POLICY.
The differences between the policies are in the amount of mac address and lifetime.
checkout with :

show device-tracking policy IPDT_POLICY
show device-tracking policy LISP-DT-GUARD-VLAN

That’s why it works without the IPDT_POLICY, however we stay on the save side and configure the IPDT_POLICY via template when we re-provison the switch/stack after extending for the moment.
Hopefully, there is soon an “official” solution from Cisco

Cheers,

Gerry

[Rajesh Kongath]

I found a workaround for this issue, 

1. DNAC > Design > Network Settings > Go to the affected site/floor > Disable wired end point data collection
2. DNAC  > Provision > Inventory > Go to affected site > select affected device > Action  > Telemetry > Update telemetry settings > Force. 

Now re-enable wired data end point collection and re-apply telemetry settings with forced ticked. This will add the missing “device-tracking attach-policy IPDT_POLICY”

Hope it helps, Thanks