In a recent project, we were deploying entire sites using DNA Center Templates. The entire switch config was contained within these templates and things like IP addresses and switch stack sizes were defined by variables on the templates.

I came across a problem though during the deployment of these templates, order of operations.

I’ve written about Cisco DNA Center templating before and you can find those posts here.

Something you may be familiar with is the way Cisco switches can overwrite commands, negate commands, or otherwise not do exactly what it is that you want it to do.

For example, you may be familiar with the way a Cisco switch will erase all of your AAA commands if you reissue the command ‘aaa new-model’. If you’re unlucky enough to lose your connection to said switch after running the ‘aaa new-model’ command, you’re going to have a bad time getting back in.

And this is the crux of this blog post, to discuss some areas of the config that you may want to avoid or ways to avoid accidentally losing your connection to the switch while deploying a template to a switch.

Passive Interface Default

Most secure routing designs will encourage you to use passive interfaces on client facing interfaces. This is a great idea because a compromised client could potentially form an adjacency with your sites router and use your routing table for reconnaissance or inject routes causing either a denial of service or to re-route traffic from other clients to the compromised machine.

But here’s the problem you may not know, if you reissue the command ‘passive-interface default’, the command-line interpreter will remove any interfaces that you have already negated as a passive interface. Now, this can cause a huge issue if you’re using routes learned by that dynamic routing protocol to get back to the DNA Center appliance, you’re going to lose you connection and need to go fix this problem manually.

My advice for sidestepping this problem is to either change your template to no longer deploy ‘passive-interface default’ under your routing protocol and instead manually turn on passive-interface for each client facing subnet or to configure your template to include a floating static default route.

If you’re unfamiliar with a floating static, it’s a static route that has had the administrative distance turned down below that of any of your dynamic routing protocols. That way, this static route will only ever be installed into the routing table if the dynamic routing protocol were to stop learning a default route.

Ip route 0.0.0.0 0.0.0.0 10.15.20.1 254

Long story short, ‘passive-interface default’ can kill your connectivity before DNA has a chance to execute the rest of the template.

IP Routing

To bootstrap some of the switches onto the network, we were using the ‘ip default-gateway’ command for initial connection to DNA center. Of course, this works fine but we then started noticing an issue that the initial provision would always fail and then we had to fix it from the console. The problem was pretty obvious when we checked out the failure logs, DNA was losing connectivity when it ran the command ‘ip routing’. This command disables the functionality of the ‘ip default-gateway’ command and instead looks for routes coming from either static routes or a dynamic routing protocol. The fix was to edit our bootstrap script to turn on ip routing manually and set a static default instead of a default gateway.

IPv6 Addresses

This may be somewhat limited in scope for most people in 2020 as IPv6 still hasn’t really gone mainstream in most enterprises but if you’re one of the few deploying it, you should remember that Cisco switches will accept any number of IPv6 addresses on an interface. This may be problematic if you accidentally key in a variable incorrectly as the switch will just accept the new address and add it to the list rather than overwrite the old one like its IPv4 behavior.

To be honest, I don’t know of any way to automate the removal of an errant IPv6 address using DNA Center templates without also removing legitimate ones in the process and potentially locking itself out of the device. Best to just remove these manually.

Negating Default Commands

One of the small annoyances that we’ve been running into on a major project of mine is that upon a switch finishing the plug and play process, DNA will push a device tracking policy to all access ports. The command, “device-tracking attach-policy IPDT_POLICY”, will then prevent that port from being configured as a port-channel. Unfortunately, if you attempt to negate the device tracking policy on ports that do not have it configured, it will give an error that will stop the provisioning of the template. Again, unfortunately, there doesn’t seem to be a way to automate this away in the template and you may need to manually remove any instances of this device-tracking policy on any interfaces you attempt to configure as a port-channel if it fails the first time.