SD Access Border types and L2VN conversion

[KevinR99]

Hi

When I define a Border type in SDA by selecting or deselecting the Default to all Virtual Networks and Do not import external routes I can no longer change those selections.  So if I have initially selected an Anywhere Border because that was appropriate at the time but things change and I now prefer to change my Border type why can I no longer change this without decomissioning my Border and re-adding it again.  What are the technical challenges that mean I cannot make this change in service?

Also, if I initially routed a vlan outside my fabric by means of a L2VN and L2 handoff but now want to route it inside the fabric by an Anycast gateway I cannot convert the L2VN to an Anycast gateway.  So I need to clear all my port assignments in the L2VN on every edge, delete the L2VN, create the Anycast gateway then re-assign the original ports to the gateway address pool.  What are the technical challenges around just converting the L2VN to an Anycast gateway.  In a non-SDA network it's as simple as creating an SVI and routing it.  No need to change the vlan id or even clear the ports.

Hopefully these features will be available in the near future.

Thanks, Kev.

[Torbjørn]

I agree with you @KevinR99, especially on the second one. It has cost me a few hours at this point... 

I would suggest submitting these with "Make a wish" on your Catalyst Center. You can find this by clicking the question mark in the top right of the UI and selecting "Make a wish".

[Andrii Oliinyk]

Guys, let me to complement u. CatC lacks of:
1) automate L3-handoff in single VLAN
2) support VLAN-translation on L2-handoff
3) stp bpdu-guard support on trunks to servers
etc etc etc...
it's just a 0.1% of my experience on "cannots" in CatC. & yeah, i dont believe in "make a whish" unless somebody will bring reliable positive statistics on its usability.

[Torbjørn]

They do actually respond to suggestions there sometimes, but I have yet to see any of my suggested improvements outside of simple bugfixes actually be implemented. I don't think there is a better way to propose these changes unfortunately

[jedolphi]

i dont believe in "make a whish"

We do review and prioritise the MAWs, and the more MAWs there are for a use case the more likely it will be priortised.

What are the technical challenges that mean I cannot make this change in service?

The automation needs to be written and tested, including accounting for what can happen to overlay/production traffic if this change is made while packets are flowing.

cannot convert the L2VN to an Anycast gateway

Please do raise an MAW if you have not already. And may I suggest you also raise it to your Cisco sales team.

[KevinR99]

I have made a wish on the L2VN to Anycast gateway issue and received feedback that the feature is roadmapped.  Still to find that destination on the roadmap as of 2.3.7.7

Regarding the Border change.  I'd be surprised if there have not already been many MAWs on that feature.  After all, we do like to make changes to our networks after we install them.  In a traditional network world this would be as simple as redistributing routes which can be done easily, quickly and without impact.  It seems SDA has over complicated this.  I have the "intent" to do this but SDA doesn't have the ability to convert my "business intent" into reality.  So for now I need to remove a Border/CP from my fabric then re-add it with different boxes ticked whilst "accounting for what can happen to overlay/production traffic if this change is made while packets are flowing"

[KevinR99]

Does anyone have experience of dropping a Border out of the fabric, changing its Border type and re-adding?  Whilst in theory it would seem a straight forward task there may be unknown unknowns.  In other words, I seem to have covered all the bases regarding what the impact will be but it's impossible to know all the scenarios that could go wrong without just doing it.  The things I would think I need to watch out for are ensuring the surviving Border can reach all external destinations and making sure I have a path from DNAC to my removed Border's Lo0 address to be able to push out config.  My INFRA_VN L3 handoff to the external world will be deleted but I have several inter-Border underlay links configured by LAN Automation which should retain connectivity from DNAC to the removed Border via the surviving one and across the LAN Auto links.  

So, DNAC should update all my Edges as the Border is removed leaving only one path out of the fabric via the surviving Border.  When I re-add my Border all Edges are then updated to have a lisp session to the newly added Border.  Likewise, the same scenario happens as I remove/re-add my second Border.

One question.  I have seen issues before where an Edge may be off for some reason.  In that case the DNAC Task is listed as failed even though if you look at the task details it has been successful on all the other devices.  What is the process whereby DNAC ensures any devices that were offline at the time of a change are updated once they come back online?

Thanks, Kev.

[jedolphi]

Hi Kevin, CP co-located on BN? LISP Pub/Sub or LISP/BGP?

[KevinR99]

Jerome

Yes, 2 x BN/CP nodes and Lisp Pub/Sub.

[jedolphi]

Hi Kevin, it's not entirely uncommon to remove and re-add BN role due to a change in BN type (e.g. I+E to E). There is a feature req to make this possible without delete/recreate but timelines can't be shared right now. In the interrum you are correct, removing BN/CP changes all Edge Nodes and Fabric WLC and recreating BN/CP again changes all Edge Nodes and Fabric WLCs. If an Edge Node happens to be offline then the configuraiton changes will run to completion (as opposed to roll back) but the offline Edge Nodes are skipped (obviously!) and their changes are queued for later. Once Edge Node is recovered you can prompt Catalyst Center to push any queued changes via the Fabric Site > Site Actions > Show Task Status > Reconfigure Failed Fabric devices.

[jedolphi]

In addition, on BN to be removed, you can manually shut EBGP peers and confirm apps/reachabilitiy continue to work before deleting the BN from SDA UI.