Device Template for router deployed as Cloud OnRamp for Multicloud?

[Evgeniy]

We deployed Cloud OnRamp for Multicloud for Azure. Tested the work - everything is ok. BUT we have found that SD-WAN Manager created BGP sessions with Azure, needed static routes, VRFs, and other important configuration elements in the step when you create the mapping between the VPN and vNet. And super important point is that this entire config is not in the template! So, when we tried to change the configuration and apply the "feature templates / device template", we saw that SD-WAN Manager tried to entirely erase the previously created config (BGP, VRFs, static routes, etc..), which destroys Cloud OnRamp for Multicloud... )

Did anyone have such experience? Is there any normal solution for this? Because it looks like Cloud Gateways configured with Cloud OnRamp for Multicloud can't use Device Templates..

At this moment we are using the workaround, which is based on adding the entirely removed config (BGP, static routes, VRF, etc.) with the CLI Add-On template. But as for me it's a stupid situation that we need to do this...

[evgeniy.semenets]

The same problem

[michael-maass]

Same issue in AWS.  This is extremely frustrating when you need to control what gets redistributed between OMP and BGP.  Even when you try to use a CLI template, if you don't do the entire part that is built with the on-ramp automation it gets wiped out, and this is basically the whole C8000v config.  TAC is not helpful at all lately.

[Evgeniy · Accepted solution]

We have an update - hope it will be helpful for somebody. The solution is just to ignore all red lines when you compare existing and new configuration. Obvious it's an area for improvement (I mean how it looks like), but finally everything works properly. I mean when you configure something on those Cloud OnRamp for Multicloud routers, all your settings will not be removed (even if config diff shows so) - it's a hidden automatic process, so don't be afraid just ignore red lines. SD-WAN Manager will not delete your Cloud OnRamp settings. We tested that many-many times during the PoC.

[michael-maass]

I agree this isn't optimal, but I was pleased to find that when I simply log into the C8000v pair in the CGW after the full config is built with CoR for multicloud I can turn it into a full CLI device template and control it without breaking redistribution or any of the other functionality provided by the automation.  This worked in our Azure VWAN and AWS regions.   I hope Cisco continues to improve AWS/Azure integration but for now this seems to be a perfect workaround for enterprises with a global multi-cloud integration that rely on SD-WAN for their connectivity,