Provision switch config

[eagles-nest]

Hi

We have deployed a test DNA Center server in our lab to test its functionality.  We have a small network of switches to play with but at this stage we are not doing an SD Access deployment.  We are just seeing what we can do with DNA-C to manage a standard network deployment.

I have created a test template to deploy some simple configuration.  One thing we would like to test is deployment of an access-list across all switches. 

When I try to do this I get an error saying "Device doesn't have a loopback 0 interface......"

The device is just a L2 switch and we have no wish to manage via loopback addresses.  We want to simply use a management vlan and assign an IP address to that.

Does anyone have any experience of this and are we able to manage via an address other than a loopback address?

Thanks for any input, Stuart.

[AndiBuchmann157]

DNAC uses the Loopback 0 as the preferred Management interface which i and almost All documents recommend to do so.

How did you get your Devices in the inventory? By scanning via IP range?

[eagles-nest]

That’s exactly how I got the devices in m inventory, by scanning specific IP ranges. The addresses are vlan interfaces on a management vlan.

Regards, Stuart.

[eagles-nest]

The problem I'm seeing is described here

So to try to circumvent this issue I assigned a /32 address to Lo0 on a switch, re-discovered it and defined the device to be managed by Lo0 using the Preferred management IP drop down box.

I then created a simple template to push out an access list but still got the same error.

Is it possibly the case that we can just push out configs when the switch has been deployed in SD-Access mode and has a loopback assigned to it by DNA-C?  If that's the case are we limited in what we can manage/provision when the switches are just in a standard, non SD-Access, setup?  This would seem strange because when I initially discover the device there is an option to turn on Device Controllability.  See below

When I have device controllability enabled DNAC seems to push out some IP Device tracking config even when my switch is managed via a non-loopback address.  So if it can push out that config why won't it push out a simple template?

Thanks for any input, Stuart.

[AndiBuchmann157]

what device models are you trying to configure? catalyst 9k?

Did you wait till your Switch is in a "managed" state after rediscovering it and then trying to push the config again?

I am right now reimaging my DNAC...it will be back online tomorrow or wednesday..then i could try to test your case in a sda deployment.

the points what "management" tasks are possible just by running a dnac without sda is quite interessting.

[eagles-nest]

Andi

Good point.  Some of my switches were in Last Sync Status "In Progress" as opposed to "Managed".

I have 2 switches in "Managed" state now.  One has been manually configured with a Loopback0 address and one is using an interface Vlan100 address.  The switch with the loopback address has successfully had a template pushed out to it.  I pushed a simple access list config.  The switch with the Vlan 100 address failed with the same error complaining of no loopback address.

This is ludicrous.  I can discover the switch with any address and during discovery IPDT config is pushed out.  So DNAC is capable of pushing out config.  I can use command runner to run commands and get output but when I try to push out a template I need a loopback 0 interface !!!

I can configure Loop addresses but it means I need to add static routes on my Core via the vlan address to get to the loopback.  It's extra work.  I don't see the logic in this.

Maybe I'm missing something in how I'm doing this?

Regards, Stuart.

[ammahend]

I did not notice this since I was using lookback throughout.

But obviously some of the reasons why it might be mandatory can be resiliency moreover ISIS is default routing for LAN automation (Underlay) and A common convention in IS-IS is to embed the loopback IP address into the unique NET, or system
ID. For example, a loopback IP address 10.4.32.1 resulting in NET 49.0000.0100.0403.2001.00, that might be another reason.

A

[eagles-nest]

I appreciate your reply.  However, the principal reason for the question was in the initial post.

"we are not doing an SD Access deployment.  We are just seeing what we can do with DNA-C to manage a standard network deployment."

ISIS, loopbacks, underlays etc imply we are deploying an SD Access topology.  We are not at this stage.  We are simply testing what DNA-C can do for a standard Core/L2 Access switch topology. 

My point still stands.  Why, during device discovery, can DNA-C push out IPDT configs using the vlan interface IP address but refuses to push out simple config templates we are testing unless we put a Lo0 address on the device?  Does this mean DNA-C is not suitable unless we go full SD Access mode?

Thanks, Stuart.

[AndiBuchmann157]

Hi Stuart,

using / creating a Loopback Interface has IMO nothing to do with deploying or using SDA. A Loopback Interface is a common used technology in  some routing technologies (BGP, OSPF, .... ).

If everything you want is working (pushing configs, assurance, etc.) is working when you just use ad addintional interface (e.g. Loopback) on your devices, where is the problem?

Don'get me wrong but i don't get your point t :)

[eagles-nest]

Thank you for your reply.

However, my points are 2 fold.

1. If some config can be pushed out without a loopback address (IPDT for example) why does it refuse to push a template out unless I use a loopback.  Why not just allow me to use any reachable IP address on the switch?  It would be easier.

2. Using loopbacks adds a further level of config I don't want to add/manage.  I would need to add the loopback to the switch then add a static route on my Core to get to the loopback via the vlan interface I already have on the switch.  So I'm having to add additional config to the access switch and the Core simply to apply a loopback and make it reachable from the Core. 

To use loopbacks needs additional routing config which I don't want to have to add.

[AndiBuchmann157]

Very good points indeed. Didnt think about additional routing stuff. 

Maybe we are missing out a point but i feel like there is jo way around loopbacks. I think someone of Cisco can help to clear this point.. Maybe ask the Cisco pre sales Team? :/