DNA Center Brownfield Provisioning

[gbekmezi-DD]

DNAC fails on provisioning brownfield devices that have TACACS configured. What is the intended/recommended workflow for using DNAC to manage brownfield switches? Should TACACS/AAA commands be removed in order to provision? This becomes problematic when there are thousands of devices being managed.

Thanks!

[Flavio Miranda]

What user you are using on the CLI credentials?  This user must have total privileges.

[Preston Chilcote]

If you remove the AAA settings from Design->Network Settings, then you will be able to complete the provision.  You then have 2 choices for the long term:

1) Manage your existing AAA settings via day-N templates. 

2) Use the provision workflow to convert your brownfield AAA configs to the configs that DNA wants to see.  That should enable you to re-enable AAA management via Design->Network settings going forward.

But you want to avoid having AAA configs in Design Settings AND in day-N templates at the same time.

[gbekmezi-DD]

Thanks for the reply and suggestions. How would you go about using the “provision workflow to convert your brownfield AAA configs to the configs that DNA wants to see?”

Is there a way to accomplish this without removing the relevant configurations from the network devices first?

Thanks!

[Preston Chilcote]

You can provision a spare device to see the aaa configs that DNA deploys. 

[gbekmezi-DD]

Thanks for the reply and suggestions. How would you go about using the “provision workflow to convert your brownfield AAA configs to the configs that DNA wants to see?”

Is there a way to accomplish this without removing the relevant configurations from the network devices first?

Thanks!

[Preston Chilcote]

Your template can first unconfigure aaa and the reconfigure it with the same commands DNA expects (in the same template).  Or just unconfigure aaa with a template and reapply AAA in Design Settings, but that takes 2 provisions instead of just 1.

[Tim Bisel]

Sorry to awaken the necro-thread here. But I am running into the same issue and have a question.

If I make the template that removes our current AAA and TACACS config, than reapply the config using the commands that DNA would see if it deployed it, than moved it to a different network or something to reprovision it with a new template and with the AAA and TACACS config instead in the settings. Would this work?

Issue I have is I built ISE to default deny and all of our equipment also will block sign in with local creds if TACACS servers are reachable. And to top it off, all my VLANs are assigned via 802.1x responses and switch is has all access ports assigned to a guest VLAN by default, and if ISE is unreachable falls into a VLAN similar to guest where they lose all internal access. So having a hard time trying to figure out what configs I need to remove so I can get CCC to push the configs, not get locked out of switch, and not kill access to the machines in the switch.

[Mattis Torkelsson]

I have a hard time figuring out how to do this migration without causing major downtime on each and every network device.  sure, remove tacas-settings and reprovision the device is a workaround for the conflicting tacacs-settings. But how about radius and all the .1X-settings ?

- Tim, have you found a way to do this without major maintenance windows ?

Regards M

[Tim Bisel]

Mattis,

No, I think its obvious that this is one of those things that was developed with industry buzzwords in mind and little to no input by someone in the field. Best I have got from anyone is to just not use the provisioning section at all.

[Mattis Torkelsson]

Hi Tim

The team responsible for the wireless infrastructure are planning to use the network hierarchy for as much wireless config as possible. The goal for us is to have one unified network hierarchy for all network devices, switches, AP's WLC etc. I believe this is beneficial for the assurance engine later on (but its just a guess from my side). Having two separate network hierarchy's is a strange solution anyways, it makes more sense to use the same hierarchy for all the devices.

I have done some testing on my own and this method works, but maybe there is a better way.

1. Create a new separate network hierarchy where all the relevant network settings are placed (Radius, Tacacs, DNS-servers etc). Remember to change the shared key to the key that is already configured on the NADs in ISE.
2. SSH to the switch that you are currently working on and migrate the AAA-config with authentication convert-to new-style.
3. Make sure you have access to the device with local credentials (username and enable password).
4. Remove all radius and tacacs-config that might be present on the device. Manually or with a template in DNAC. DNAC vill let you know which commands to remove if you forget any of them.
5. Remove the device from DNAC's inventory.
6. Add the device back into DNAC's inventory, assign & provision it to the new network hierarchy where the necessary radius and tacacs settings where applied in step one. DNAC will create all the necessary config, and after the provisioning is done a client should be able to logon to the network via the same ISE-poilicy sets etc. Tacacs etc should also work by now.

This method calls for scheduled maintenance windows but it seams manageable, the downtime isn't that long compared to regular software upgrades. The problem for me is that the config that is generated is based on IBNS 2.0 (i believe it is IBNS 2.0) and for me that's a kind of hard to read and understand at the moment. It will take some time to get used to for sure.

Regards /M