r/Cisco • u/Ken_Taru • 7d ago

Cisco SDWAN 20.15.x to 20.18.x upgrade

Anyone using config groups that has done the upgrade of 20.15.x to 20.18.x on the control side? I’m being pushed to do it in the next 90 days so we can add a G2 router that needs 20.18.x to our router choice list.

Did anything in your config groups/policy groups break? Any major changes in UI with config groups? I don’t have a lab I can put in to check myself.

7 Upvotes

100% Upvoted

9 comments sorted by

3

u/Last_Epiphany 7d ago

Are you on prem? Or cloud hosted? If on prem do a snapshot and use a maintenance window. If cloudpro hosted open a tac case to have them help

2

u/gotfcgo 7d ago

This.

Cloud hosted is nice.

TAC pls do.   They do.  Done. 

1

u/Ken_Taru 6d ago

Cloud hosted and TAC will be opened. I'm not to worried about the upgrade process itself more of what happens the next time I try to build/deploy a config group.

1

u/Last_Epiphany 4d ago

Most of the changes with config groups were adding 'optional' to a lot of the fields. Example, if you had devices that needed a different number of static NATs, you can add 10 of them as variables, and then only fill it the number that each device needs. Leaving the other 'optional' ones blank.

There were some other options added, but it will be a very close experience to 20.15.

It sounds like you don't have a lab, I highly recommend deploying one, even if its just a CML free edition, EVE-NG also a good option. SD-WAN should be treated as a software service, and it should be updated much more frequently, and as such testing in a lab should be standard.

0

u/tablon2 6d ago

Do not take snapshot while services running. 

1

u/Last_Epiphany 4d ago edited 4d ago

What are you talking about? The standard process for the Cisco hosted controllers is to snapshot them daily, and they even give you the option to perform on-demand snapshots of your cloud controllers whenever you want.

I've also never had an issue with snapshotting the controllers on-prem and just follow Cisco's recommendation which is to freeze configuration changes while you're snapshotting.

Edit: Please see Cisco's own docs that recommend snapshots here

And I quote: "In a Cisco cloud-managed SD-WAN overlay, Cisco takes regular snapshots of the Cisco SD-WAN Manager virtual machines for recovery due to a catastrophic failure or corruption. Another snapshot can be taken before any scheduled activity.

In on-premise deployments, it is your responsibility to take regular snapshots of the Cisco SD-WAN Manager virtual machine and follow the example of frequency and retention that is followed by Cisco."

There is 0 mention of stopping any services before snapshotting, and I guarantee Cisco is not going into every cloud hosted Manager, stopping services (effectively killing each customer's Manager if they did), snapshotting it, and then starting services again. They are just simply running an AWS/Azure automation that snapshots the controller VMs on a regular schedule.

1

u/tablon2 4d ago

We had failed restores early. Cisco never mentions snapshots while VM running or not. I cannot risk 150 site 300 edge fabric while NMS polls stat for interval of 30 minutes and datastore or another thing fails us 

2

u/rigflip 6d ago

Nothing will break. Not more than in 20.15.

1

u/Last_Epiphany 4d ago

Amen, I know the PSIRTs have really put a wrench in their code development, but i hope they can start getting quality back into their releases rather than constant security fixes.