EXECUTIVE SUMMARY: Using Nexus 7010 and ASR 1002, Virtual Machines were successfully migrated seamlessly from one data center to another without the need for IP reconfiguration.

The folks at Cisco have supported the development of Locator/ID Separation Protocol (LISP) in the IETF for some time now. Sometimes referred to as a protocol, and sometimes an architecture, LISP is a mechanism to optimize network flows by managing address families. LISP was originally devised to abstract network areas in order to "divide and conquer" scale, but ended up having the consequence of enabling mobility. The latter ends up being a pretty useful tool for data centers -- this is what we tested.

In a nutshell, using an additional level of mapping, LISP abstracts exceptions in IP routes to avoid long routing tables and reconfiguration of routers. Thus, if a virtual machine would move from one data center to another, it would not have to change its IP address and the routers in the new data center would not have to be configured for the VM’s IP subnet. The LISP-aware nodes would dynamically learn about this new VM with its misfit IP address. Users who cached that VM’s IP address would not have to relearn a new IP, their services would be transparent to the location change, at least from an IP addressing perspective. Without LISP, the administrator would have to change the VM’s IP address, affecting customers much more.

We started by establishing a simple website, hosted on a virtual machine in our "Data Center 1." We connected to that website via a laptop host connected to an ASR 1002, which was positioned to serve as that host's Customer Edge (CE) -- LISP was enabled here. LISP was also enabled on the Nexus 7010s within each of the data centers. These systems were both configured to serve the LISP mapping database. We ensured that caching did not affect our test.

As the next step, we migrated the VM. There are different tools on the market to administer such an operation, but this was not the focus of this test. We used vCloud Director, which Cisco had installed. Once the move operation was completed, we first pinged the server from the ASR 1002, which sent five echo requests per default. The first did not receive a response, as it triggered the LISP to poll and update its database. As a note, this process was perfected during the pre-staging through a software patch, thus the Nexus 7010s were running effectively engineering code. All further echo requests from that same ping operation, were responded to -- just as expected. We refreshed our demo website, and it returned the contents to the client immediately.

In summary, the ASR 1002 and Nexus 7010 automatically detected the new location of the route, and the user could continue to access the website from the new data center -- all without any reconfiguration.

Next Page: Provisioning: Cisco Network Services Manager
Previous Page: Virtual Security Gateway

Back to the Cisco Test Main Page