Skip to content
Notifications
Clear all

Walkthrough: Migrating remote site VPNs to Cato tunnels without downtime.

2 Posts
2 Users
0 Reactions
0 Views
(@devops_barbarian)
Estimable Member
Joined: 3 months ago
Posts: 125
Topic starter   [#5490]

Everyone's hyping Cato for SD-WAN but glossing over the migration hell. Main issue: you can't just cut over from legacy IPSec to Cato tunnels. Their PoP handoff and routing will break things if you don't stage it.

Key was running dual tunnels. We kept existing VPNs alive while bringing up Cato SDP links per site. Used Ansible to push configs and control routing metrics. Here's the core playbook snippet that flipped the BGP weight on the old tunnel to deprioritize it, making Cato primary without a hard cut.

```yaml
- name: Adjust BGP weight on legacy tunnel
hosts: edge_routers
vars:
legacy_peer_ip: "{{ site.legacy_tunnel_endpoint }}"
tasks:
- name: Apply weight policy to legacy peer
cisco.ios.ios_bgp:
config:
bgp_as: "{{ our_as }}"
neighbors:
- address: "{{ legacy_peer_ip }}"
route_map:
name: WEIGHT-200-OUT
out: true
state: merged
```

Monitored for a week, then changed the route-map to prepend AS_PATH, killing the old path. Clean. The real pitfall? Their monitoring won't catch your app's specific latency sensitivity. Had to wire up our own prometheus exporter for RTT per tunnel to validate.


Don't panic, have a rollback plan.


   
Quote
(@alexj)
Estimable Member
Joined: 1 week ago
Posts: 131
 

That's a really solid approach, and you're absolutely right about the monitoring gap. The canned dashboard views often miss the internal application thresholds that matter.

Your dual-tunnel method with the staged BGP weight change is exactly the kind of surgical migration we've seen work. It's that last mile validation, like your Prometheus exporter for per-tunnel RTT, that makes or breaks the cutover. So many folks just trust the vendor's "up/down" status and get burned by intermittent jitter.

One thing I'd add from seeing a few of these rollouts: watch your BGP session flapping during that week-long monitoring phase if your legacy tunnels aren't rock solid. I've seen routers get a bit confused and temporarily prefer the old, degraded path if the session resets, which can undo your careful weight planning. A quick inbound route-map on the old peer to tag routes with a lower local-preference can be a good belt-and-suspenders move. Thanks for sharing the Ansible snippet, too - that's gold for anyone trying to automate this.


Let's keep it real.


   
ReplyQuote