LISP – Finding the Optimized Path for your Workload

Blog

Jan 18, 2012 5:11 PM
Jan 18th, 2012
Jake Howering
Jake Howering | January 6, 2012 at 8:56 am PST
reposted from  Blogs.cisco.com

--------------------------------------------------------------------------

Update: LISP solves the problem from client to server, IE Ingress  Path Optimization.  FHRP solves the problem from server to client, IE  Egress Path Optimization.  You can check out Egress Path Optimization here.

We recently published a Data Center Interconnect -- DCI-  related  document on cisco.com and I wanted to get it in front of you.   Locator/Identifier Separator Protoc0l -- LISP -- provides the path  optimization technology to forward transactions via the most direct  path, ultimately meaning better application performance. The link for  the LISP Virtual Machine Mobility paper is below.

As a side note, LISP can be used many other ways and here’s a pointer to one of  our LISP pages.

For our purposes in DCI, we use LISP for path optimization and we can  see here why the  need arises. The box on the left shows an existing  transaction that looks pretty direct.  The middle box shows the workload  is now in a new data center but the transaction is suboptimal, it still  goes through the firsts data center.  The box on the right shows the  desired path, the direct path from user to workload withouth going  through the first data center.  It’s pretty easy to see the need here  for path optimization and the desire to have the direct path to the new  data center location as shown on the far right box.

LISP provides dynamic tunnel encapsulation between the two locations  and this allows the ability to direct traffic to the desired location.   Let’s look at another set of pictures.

On the left we see a LISP session from the client to data center  Alpha. On the right we see a LISP session from the client to data center  Beta. The LISP session redirects to data center Beta *automatically* so  this is all transparent and without operational intervention.  Pretty  cool! The details of this are in the link below.

In our workload mobility environment, there are two LISP “modes” to  think about.  LISP ASM refers to “Across Subnet Mode” and that’s where  you have a Layer 3 network between the two data centers.  Clearly, this  is pretty common :) and  LISP ASM can be used in cases where you spin-up, instantiate, a  new workload in the new data center, as part of a  Disaster Recovery  plan and strategy, or for non-live workload mobility requirements.

LISP ESM refers to “Extended Subnet Mode” and refers to when you have  a Layer 2 extension between data centers.  Layer 2 extensions includes  technologies like VPLS, OTV, FabricPaht/Trill, etc and enables live  workoad mobility between data centers, among others.

Here’s the link to the LISP Virtual Machine Mobility Solution. Enjoy !

Average Rating: 0 (0 ratings)

Actions

Login or Register to take actions

This Blog

Posted January 18, 2012 at 5:11 PM
Stats:

Related Content