LAN Automation fails when stopped

[mjrduarte]

Hi,

I've bee trying to get LAN Automation to work, but I'm running into some issues.
I have 2 C9500 that are connected via trunks to a pair of C6800 in a VSS. They have a VLAN configured, with an IP address, that is used for management.
I use one of the C9500 as seed, to "LAN Automate" one C9300.

Everything seems to be going well. The 9300 is discovered by the automation process, and configuration is pushed to the device.
When the status changed to Provisioned, it gets added to the inventory, and I can reach it by its loopback0 address (I have a static route for the IP Pool subnet on the C6800 that points to the IP address of the management VLAN on the C9500).

So the next step would be to stop the LAN Automation process, so that the L2 links get converted to L3.
After I stop the automation process, after some time, the C9300 becomes unreachable, and in the session logs of the LAN Automation I see "All L3 links for Tier-2 devices could not be configured within 900 seconds.".

I'm sure I'm doing something wrong, but I can't figure out what.

Any help is appreciated. Thank you.

[andy!doesnt!like!uucp]

LAN-automation deploys EEM script on the EN(s) to convert trunk uplink(s) of latter to routed interfaces. It looks like something prevents this script to complete. Be advised to check the logs & configurations on both seed switch & EN being under automation before LAN-automation is topped & after failure (in assumption u have a mean to connect to failed EN with OoB mgmt or console). btw what is version of your DNAC?

[mjrduarte]

Thank you for your response.
I'm cleaning both 9500 and the 9300 right now, to restart the process.
In the mean time I have a question. Do I have to have the Fusion device (in this case the 6800) previously configured with BGP between the 9500 and it self?

My DNAC version is 2.3.5.5.

Thanks again.

[andy!doesnt!like!uucp]

"Do I have to have the Fusion device (in this case the 6800) previously configured with BGP between the 9500 and it self?"
In production, with IP-transits, this is standard mean to provision end-to-end connectivity between VNs (including INFRA VN which many accounts sometimes falls back into GRT though). Other words unless your deployment fully LISP/VXLAN based (meaning SDA-transit based), VPNv4 MP-BGP is the only scalable (& also supported atm) way. Just recall how do u configure L3-handoffs between BNs & legacy network in DNAC UI from your fabric site to external network. It seems to me that your deployment is kinda lab or test environment though.
getting back to SW, i guess u'd like to take a look at Field Notice: FN74065 - Cisco DNA Center: etcd PKI Certificate Activation Failure Disables User Interface and Causes Other Errors - Software Upgrade Recommended - Cisco
just for the case

[mjrduarte]

This is a production network. We are trying to rollout SDA-Access, alongside our existing network. The 6800 is our "core" switch. It has a bunch of VLANs created and acts as the Layer 3 device for each one of them. It also receives all the uplinks from our access switches (2960S).
My question is if the problem is caused by lack of routing between the 6800 and the fabric network, once LAN Automation stops.
The bug that you refer doesn't seem to be relevant. It does not affect the version of DNAC we have, and we never lose access to DNAC.

[Boort]

Yes, this will cause issues. During stop the loopback0 ip must be reachable.

I suggest adding bgp between your c6800 (fusion) and c9500 (border + control?). If you do this and check the "advertice lan auto address pool" during lan auto DNAC adds a summary route for your lan auto prefix, making sure it is reachable during the whole process.

This issue can also occur if you are running default Deny for your trustsec setup. Is this the case for you?

[andy!doesnt!like!uucp]

if he has static route on FN to Underlay subnet behind the link FN-BN via the BN-side IP of this link absence of BGP is not something preventing from LAN-automation on EN to complete...

[Boort]

Sure. But does he have static routes to both border nodes? Is there routing between the border nodes?

My point is, why try to make it work without BGP when BGP is the best and most dynamic choise. Not to mention that it is "mandatory" when adding more VN's while using ip transit.

[mjrduarte]

Thank you for the clarification.
Trustsec is not in place right now.
One more question.
The 6800 manages all our static routes. Can I safely activate and configure BGP without affecting traffic flow?

[andy!doesnt!like!uucp · Accepted solution]

it depends on accuracy u'll pay to transformation/adding VPNv4 BGP on your FN.
finally, u can implement BN-to-FN peering with light VRF & w/o BGP. But it will be manual work on BN side.
& very finally, brown field migration to SDA is something not suitable for simple peeking advices from support community
encourage u to read  BRKCRS-2812 BRKENS-2008 BRKENS-2827 & other easy findable with searching on CCO
 
the previous security advisory is really about different stuff, but your deployment seems to be unaffected.  

[Boort · Accepted solution]

Hard to say exactly without knowing your configuration, but in general it should cause no issues with your current traffic flow. Apply inbound and outbound rute maps on the FN side to make sure that you only see what you want to see.

What i usually do is configure BGP on the border nodes in GRT manually, then add new ones from DNA Center for the Infra_vn. After everything is good to go i shut the BGP neighbor on the FN side.

[mjrduarte]

Thank you so much for all your help.
I know that this topic is very subjective to the individual topologies and scenarios.
Nevertheless I'm trying to get as much information as possible.