SD Access migration

[KevinR99]

Hi

I am trying to work out the best/most efficient method to get clients migrated from old switches to new ones in SD Access.  I have a requirement to maintain much of my address space so I need to have a scenario where clients can be on the same subnet inside and outside SDA for a period.  I'll use a L2 Border to facilitate this.

I've come to the conclusion that when I first migrate users in a subnet I need to move the gateway for that subnet into SDA.  However, I cannot pre-create the SDA Anycast gateway and leave it shutdown as DNAC doesn't have this feature.  Until I create the Anycast gateway and the associated vlan name/ID I don't have the address pools available in the Port assignment area.  So, again I can't preconfigure my new Edge ports until I have the Anycast gateways in place.  So on the first occasion I migrate a subnet int SDA I have a bit of work to do at migration time.  I was hoping to find a way to be able to pre-assign the ports on the edge switches.

When I create an Anycast gateway I usually allow DNAC to select the Vlan ID.  So I thought if I create a template with a vlan ID I pre-define I could push out the vlan and the edge port configurations in one provisioning task.  Then at migration time I create the Anycast gateways and define the vlan ID's to use in line with what I used in my template.  This works to an extent.  However, when I do this and then go to the Port assignment area my Edge ports in the GUI do not reflect what I pushed out in the template.  They are all blank and look as if they are all available to be assigned when in fact they have vlan assignments from my template.  Additionally this means I need to track the vlan ID's rather than just letting DNAC get on with it.

Tracking the vlan ID's isn't a great chore but not having the Edge ports reflect what is in the template is.  It seems strange DNAC does not pick up the new Edge port config via a resync and reflect it in the port assignment area.  If I look at the Edge switch details and then the config drift area DNAC does know the port config has changed.

Are there any recommendatins on the most efficient way to do this to save me having to create Anycast gateways and assign what could be a great many ports at the first migration window?

Once I've moved a gateway into SDA subsequent Edge migrations are easier because the address pool is then available to assign to ports in the GUI.  So I can do that work prior to the migration window.

Thanks, Kev.

[balaji.bandi]

i would work with cisco partner when you like to Migrate to new technology, since they have very useful use case as yours and they can suggest you best method to do.

there is some presentation in the cisco live and cisco docs can refer :

https://community.cisco.com/kxiwq67737/attachments/kxiwq67737/5981-discussions-other-network-infra/197124/1/Cisco%20Software%20Defined%20Access%20Migration%20Guide.pdf

https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2020/pdf/DGTL-BRKENS-3822.pdf

again depends on the code of the switch running and what DNAC version you deploying, they need to be supported matrix.

there are pro and cons of each migration, so you need to choose and test offline before you cutover to overall setup.

[jedolphi · Accepted solution]

Hi Kevin, "Are there any recommendations on the most efficient way to do this to save me having to create Anycast gateways and assign what could be a great many ports at the first migration window?". You'll need to do the due diligence on this suggestion please, I don't know your customer environment, BUT, if you create an ACGW in the SDA Fabric then it is not known outside the fabric until you setup BN Layer 3 Handoff. So you could configure all the ACGWs in SDA and not configure BN L3HO BGP until migration time, or,  you could configure the ACGWs and BN L3HOs but temporarily block the ACGW subnets in BGP on the fusion device w/ input prefix list, and then unblock prefixes during migration window. Cheers, Jerome

[KevinR99]

Unfortunately this method didn’t last long for my requirements.  When I create an anycast gateway it may not be known outside the fabric until I unblock it but it is known within the fabric as a null0 route.  So if I have an endpoint already in the fabric that happens to want to reach an anycast gateway subnet I have created but not yet deactivated in the legacy network the fabric traffic gets dumped.  

This is a major migration pain in not being able to pre-create any cast gateways but leave them shutdown to then enable me to preconfigure edge ports ready for repatching.  I cannot assign ports to an address pool unless I have already created the associated anycast gateway.  I cannot use an L2VN to then assign the ports to an address pool because at some point I need to convert that to an anycast gateway and I can’t do that without clearing all ports assigned to the L2VN, creating the Anycast gateway and re-assigning the ports.

If I’m not wrong it is possible in ACI to create a gateway but leave it down in the fabric allowing us to assign ports to the subnet and later shut the legacy gateway and activate the fabric one seamlessly.

Of course I could completely re-address my clients keeping fabric ones and legacy network ones on different subnets but that isn't always possible.

Kev.

[KevinR99]

Good solution, thanks Jerome.