GRE VPN Endpoint Migration
Re-addressing a live site-to-site VPN looks trivial and breaks production. This lab gives you a two-site enterprise network on a GRE tunnel and has you migrate the endpoints to new ISP IPs while DNS, LDAP and web keep serving, which is how a real cutover is actually judged.
Not a mockup, this is the real topology
The problem
After moving a site-to-site GRE tunnel onto new ISP IPs, the tunnel shows up and you can ping the new endpoint, but the remote site can't reach DNS, LDAP or web, and the routes that used to be learned over the tunnel have disappeared.
What you'll practice
- Audit a two-site GRE VPN and map service dependencies (DNS, LDAP, web)
- Migrate tunnel source and destination to new ISP IPs
- Re-establish the routing adjacency that runs across the tunnel
- Verify overlay route propagation and tunnel MTU
- Confirm cross-site service reachability after cutover
The topology
Two sites, Chicago and Austin, each with edge and core routers behind a zone-based firewall, connected across an ISP backbone by a GRE tunnel. Services at each site depend on the tunnel, so a mis-migrated endpoint shows up as broken applications, not just a down interface.
Topology diagram
Frequently asked
Is the tunnel the problem, or the routing?
That's the lesson: the tunnel line-protocol can come up on the new IPs while the routing that rides over it never re-forms, so services stay dark until you fix the overlay, not the tunnel.
Does this map to SVPN?
Yes. Site-to-site tunnel configuration, migration and troubleshooting are core Cisco Secure VPN (SVPN) topics, exercised here on a real dual-site topology.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.