Let's step back for a minute. So far in this series of blog posts on DCI, I've been focusing on extending the Layer 2 domain between data centers with the goal of supporting hot migrations — ie, moving a virtual machine between sites while it's online and servicing users.
Is that the only objective with DCI?
Well if it was, there wouldn't be a need for this blog post :-) Cold migrations have valid use cases too. Cold migrations occur when the virtual machine is shut down in one site and then booted in a new site. As part of that operation, typically an orchestration layer (such as VMware's Site Recovery Manager) will poke and prod the VM to make it ready for operation in the new site. Most notably, it takes care of changing the VM's IP address and default gateway.
Cold migrations do not have a requirement for the same IP subnet in both sites. This is because there's no need to maintain active user sessions during the migration. Different IP subnets in the sites means no stretched Layer 2 which means no risk of combining failure domains!
What if that orchestration layer didn't have to poke at the VM? What if the network itself was smart enough to realize the VM had moved, allowed the VM to keep its IP address, and redirected user traffic to the VM at the new site?
I decided to try a small experiment and deliver the bulk of this post as a video screen cast. In it, I'll demonstrate how a VM can be cold migrated without the need to orchestrate IP address changes.
For more information on LISP:
- RFC 6830: The Locator/ID Separation Protocol
- The LISP Working Group at the IETF
- Deploying LISP Host Mobility Across Subnets (cisco.com)
- lisp.cisco.com - The Cisco engineering team's LISP portal
Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Cisco Systems.