DNA Center Application policy causes ISIS neighbors to drop

[eagles-nest]

Hi

I've had an interesting side effect when playing around with DNAC application policies.

I built my underlay with ISIS as recommended.  I then discover my devices via loopbacks advertised in the underlay. 

All has been working fine generally.  So I decided to see what Application policies would do to get an idea of the config deployed.  Bear in mind there is no data traffic running in this test network other than some basic pings from a laptop to the internet.

I left the Application policy as configured by default in DNAC.  All "Business relevant" applications were left as set out the box.  My idea was to see what is deployed and from that maybe tweak to suit my needs. 

So I called the Application Profile "Test-QoS" and attached it to the default CVD_QUEUEING_PROFILE.  I then deployed to all devices in my test site.

The first thing that happened is all my ISIS neighbours dropped and DNAC no longer could reach my devices.  ISIS is used to advertise the loopbacks that DNAC manages via so no ISIS neighbours no loopback routes and no DNAC reachability.

Fortunately I have OOB management via all the management interfaces.  So I jumped on and removed the QoS policies applied to the underlay and immediately my ISIS neighbours re-formed, routes were advertised in the underlay and DNAC re-established connectivity.

So as a further test I selected a single Edge device and re-deployed the policy.  Same again, ISIS neighbours dropped.  I have two /30 links from Edge to Border so I removed the DNAC policy from one interface and the ISIS neighbour re-established. 

As a further test I configured OSPF on the /30 links.  OSPF neighbours were formed immediately across both /30's.  One /30 had the DNAC policy and one didn't.  The one that had the policy formed an OSPF relationship but not an ISIS relationship.  The interface that didn't have the DNAC policy formed both OSPF and ISIS neighbour relationships.

So it seems clear that something in the DNAC policy drops ISIS traffic.

I'm going to play around with the Application and queuing policies to see what resolves the situation.  However, is there something I've done wrong here in building my underlay, discovering via loopbacks advertised in the underlay and then applying an out of the box policy from DNAC?  I wouldn't expect the out the box policy to have any impact on routing protocols.

Thanks, Stuart.

[eagles-nest]

I've done a bit more troubleshooting and investigation on this issue.

As a starting point I commonly deploy auto-qos on a switch.  This generally provides enough or a basis from which to build.  It prioritizes voice traffic and gives a bandwidth allocation to other traffic and I can then tweak that as required.

I deployed auto-qos on the interfaces running ISIS and there was no impact.  The ISIS neighbour relationships were maintained.

However, I then deleted the auto-qos and re-applied a policy via DNAC and the ISIS neighbours dropped as before.

So obviously the DNAC applied policy has a problem with non-IP traffic since the ISIS neighbours are not based on IP.

When I look at the the policy map on the interface that relates to matching DSCP values but ISIS does not have DSCP values. Looking at the interface I can see output discards incrementing slowly which I assume may be my ISIS traffic.

I found an old Cisco document about how routing updates are queued on an interface with QoS applied and it refers to the pak_priority field

https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html 

However, this is a very old document.  I am working on a Cat9200 as my edge device.

As always, any input is appreciated.

Stuart.

[Preston Chilcote]

Nice work on pinning the problem down.  That certainly doesn't sound like expected behavior to me.  Please open a case with TAC for this so they can determine the best way to fix it going forward.

[ChuckMcF]

Thank you for sharing what you found. I am very interested in any resolution that you find. Unfortunately we don’t have test equipment yet to try this out however our live network is built with IS-IS as the underlay. After reading your post I’m very glad I kicked the can on implementing QoS via DNAC until we finished a few other projects. Looking forward to your next posts.

Chuck

[Gurudatt Pai]

Hi

Is this happening with Cat3850/3650 or also with the Cat9ks ?

Did you try lowering the MTU on the IS-IS enabled interfaces ?

Regards

Guru