SD-Access DNAC deployed in a Management VRF

[bclounie]

We have a security policy that mandates that any traffic to access management functions on any router / switch must pass through a firewall and be isolated in a management VRF. In deploying SD-Access,  my understanding is that LAN automation does not have the capability to place the Loopback0 management interface in a distinct VRF.  Given this is true, here is my plan to accommodate the security policy.  In lieu of LAN automation, we manually (or programmatically) set the base configuration (Loopback0 in mgmt VRF, IS-IS, etc) to establish connectivity to DNAC (which is also in the management VRF).  We then discover the new switch and add to inventory.  From there we provision the switch using DNAC as usual.   Are they any problems with this approach ?   Would Cisco TAC support such an approach ?

[andy!doesnt!like!uucp]

Hi 

i can see 2 different topics in your query:

1) what is worth to remember about DNAC placement is it cannot be deployed within SDA Fabric. whether u want it to be in kinda VRF-lite management vrf or just in GRT also behind FW.

2) u can configure SDA site underlay with PnP: How to configure SDA LAN Automation with PnP (Part 1) (labminutes.com)
or u can automate it manually with DayN-templates. in the legacy topologies, migration to L3-access IS-IS driven underlay can be tricky. just f.e. when u use PnP DNAC initially automates setup of switched environment over your underlay with gateway on the seed device, then it migrate it to L3-access IS-IS driven topology by pushing to devices EEM scripts which purpose is to transform flat single subnet into target pure L3 hierarchy. i'm not sure DNAC does the same beyond PnP workflow.

other words, if u still want to automate migration of your brownfield network from legacy to L3-access IS-IS driven underlay u have to consider a lot of precautions to keep remote control over your network & its consistency. there is no universal recipe.

Good luck in your journey  

[bclounie]

thanks for your response.  I think some clarification would be helpful.  The management VRF would be outside of the DNAC managed environment.  In other words the DNAC managed virtual networks (VRFs) would be along side the management VRF using the same underlay network.  This environment would be greenfield which gives us some latitude in the base configuration.  We are leaning towards using DayN templates in lieu of LAN automation.  Our main concern (question) is "Will the Provision application overwrite the base configuration when deploying the Border Nodes and Fabric Edge Nodes?"

[andy!doesnt!like!uucp]

let's put things in order:

" The management VRF would be outside of the DNAC managed environment." - why? your DNAC will manage all your network (SDA-enabled & non-SDA) unless your mgmt VRF spans across DNAC-unmanaged devices. 

"This environment would be greenfield which gives us some latitude in the base configuration.  We are leaning towards using DayN templates in lieu of LAN automation." - i dont see any benefits in complicating this task. i'd stay with underlay automation workflow instead.

"Our main concern (question) is "Will the Provision application overwrite the base configuration when deploying the Border Nodes and Fabric Edge Nodes?" - it wont if u avoid harmful code in network templates (u know - human errors etc)