Why You’ll Want LISP Routing – Part 3

Now that we covered how LISP Routing works in Part 1 and Part 2 of this series, let dig into some of the things you can do with it. I would suggest you go back and read the first two posts if you are new to LISP since I am not going to cover that material again. So, lets look at three of the most popular use cases: 1) VM mobility, 2) IPv6 migration, and 3) smarter multi-homing.  I am going to cover the generic use cases, then wrap with some real-world customer use cases.

VM Mobility

Since it seems to be the hottest topic, let start with the mobility solution. From a networking perspective, there are a couple of things that are important with a live migration (ex. VMotion): we want to try and preserve TCP sessions (note: this does not mean “packets don’t get dropped”) and we want to maintain optimal routing (note to server folks: you too care about these things).  We would also like global mobility—basically the server admin should be able to move her VM wherever she want and not be constrained by IP addressing considerations.

Let’s build on the scenario we have been using in the prior posts, where we have a host 192.168.1.12 is chatting with a VM 172.16.4.7.  Assume that we have gone through the whole map-request/map-reply process, so we have something that looks like this:

Now there are a couple of flavors of VM migration.  Live or hot migration is where you move the VM while it is still running.  Neither the VM knows it moved nor does the host accessing it.  For this to work, the source and destination servers need L2 adjacency, so you need some sort of L2 extension technology like OTV or VXLAN and there is also usually some distance limitation involved because of this. Cold migration simply means you are shutting the VM down, moving it and bringing it up somewhere else.  You are not concerned with maintaining connections to existing hosts, but the virtual server still does not know its moved.  The other caveat in this is that you need set up your VMs to use a well-known MAC address to identify its default gateway, so, regardless of where a VM ends up, it does not need to ARP to find its default gateway.

In, this case lets have our VM 172.16.4.7 live migrate to a new segment on a different subnet. Normally, as soon as the VM tried to send traffic, it would fail a uRPF check by 10.200.7.42, since its address should not be found on the interface its now using.  However, since 10.200.7.42 is a LISP router, its configured with dynamic-EID range of addresses that are OK to move.  This gets around the uRPF check, but also protects from random IP addresses connecting into the router and gaining access to the network.

Once 10.200.7.42 notices it has a new server to take care of, it installs a specific /32 address in its routing table and registers the /32 address with a map-register message with the map server.  Note in this case, this would not impact the aggregated route that the MS propagates into the ALT.

The MS now sends a map-notify message back to 10.100.19.21 and lets it know its no longer responsible for 172.16.4.7.  The 10.100.19.21 then installs a “null0” destination in its routing table for the specific /32 address.

Remember, LISP uses a “pull” approach to information propagation and there is no sync mechanism, so we now need to get everyone back in sync.

Any brand new conversations destined for 172.16.4.7 are easy, they will go through the normal LISP map-request/map-reply process, so pretty simple on that front.

Now if 172.16.4.7 initiates traffic back to 192.168.1.12, the router 10.200.7.42 (the xTR serving 172.16.4.7) will send a solicit-map-request message to 10.10.1.1 (the xTR serving 192.168.1.12) telling it to send out a map-request message for 172.16.4.7, even thought it thinks it already has a valid RLOC for that address.  10.10.1.1 will send out a new map-request for 172.16.4.7 which results in 10.200.7.42 sending a map-reply back which then leads 10.10.1.1 to install the /32 EID/RLOC info in its map cache.

Now, if 172.16.4.7 and 192.168.1.12 don’t chat all that often, we may run into a scenario where 10.10.1.1 has stale data in its map cache.  In this case, 10.10.1.1 continues to forward traffic for 172.16.4.7 to 10.100.19.21.  That router knows it no longer has 172.16.4.7 courtesy of the map-notify message it got when 172.16.4.7 initially moved.  As a result, it sends a solicit-map-request message back to 10.10.1.1, which will then initiate to map-request/map-reply process to get updated map data.

So, that should give you a good idea of how LISP can (and should) be part of your VM mobility strategy and why L2 extension, by itself is not sufficient..  Now, the reality is that mobility is a much broader concept.  With LISP we can move entire topologies by simply updating the RLOC in the map database.  You can fail over your data center to a DR site, leave everything alone, and simply update the RLOC.  Or, if you deploy containerized data centers, you can drop your data center wherever you want and again, simply update the map database with the new RLOC.  And then there is the end node.  There is actually a lot of cool work going on with LISP and end node mobility, but its something I am going to have to tackle in a subsequent post.  If you are curious, check out the draft for LISP Mobile Node.

IPv6 Migration

Next, lets take a look at various IPv6 scenarios.  Let’s start with the fact that the Internet core is still IPv4 and does not seem to be changing anytime soon.  Let’s also assume we don’t want to do translation–I know this is a topic of passionate debate, which I am not going near, at least for this post. 🙂

If we look at the following scenarios:

1. This is pretty basic—two IPv6 LISP sites wanted to use the IPv4 core, so you would see traffic being exchanged with an IPv4 outer address and an IPv6 inner address
2. In the second scenario, we have an IPv6 LISP site with an IPv4 ISP communicating to a dual stack non-LISP site with an dual stack ISP.  In this case the PxTR acts as an intermediary, with a tunneled IPv4 path between the source and PxTR (IPv4 outer address, IPv6 inner address), followed with a natively forwarded IPv6 path between the PxTR between the destination site.
3. The final flow is similar example, where we need to use the PxTR because the destination site is not in the mapping database.

Along those lines, the inverse is also true: we can have an IPv6 core (say a cable provider or a university campus) connecting islands of IPv4. With LISP, we can still connect islands of IPv4 and we can connect LISP with non-LISP sites using PxTRs as an intermediary.

Traffic Engineering 

Finally, lets look at traffic engineering with regards to multi-homing.  With the increasing depending on Internet connectivity, multi-homing has almost become a de facto design practice, but not without some challenges for both the enterprise and the service provider. In my first post, I mentioned that the map-reply message actually includes some policy info, so lets take a closer look at that. Within the map-reply message, for each EID-prefix, you get one or more RLOCs and each RLOC has an associated priority and weighting.

This allows me to do a couple of things.  With the priority value, I can set up load-sharing as well as set up primary and back-up RLOCs.  With the weighting, I can control how my inbound links are utilized.  In the example above, I have the traffic equally split, but I may want to split it 70/30 between the two links.  Why would I want to do this?  I might have different service providers with different cost structure, I might be looking to protect bandwidth to maintain SLAs, I might have certain links optimized for certain types of traffic.  The use cases vary but the key point is that it’s relatively straightforward to do this.  Up to this point, ingress traffic engineering has been tricky—you end up have to do things like manipulating BGP or disaggregating and leaking addresses across links or providers.  With LISP, it becomes pretty straightforward to implement and will benefit enterprises and service providers alike.  This mechanism lets you easily set-up active/active multi-homing without having to reconfigure BGP.  This and the weighting priority lets enterprises make the most of the bandwidth they have paid for.  Finally it makes it easier to change ISPs. For service providers, LISP can greatly simplify the routes they must maintain, which is very desirable.  It also lower the barrier for switching ISPs–kinda like number portability with cell phones. You’ll see some more examples of traffic engineering in the customer examples below.

User Case Studies

So, lets wrap up by taking a look at what customers are doing with LISP in the real world:

Qualcomm shares their experiences with LISP for DCI and VM Mobility

https://www.youtube.com/watch?v=OqZTumKsjZo

Lufthansa Airlines  explains how they use LISP mobility features to keep their planes internet connected and they circle the globe

https://www.youtube.com/watch?v=N194Vlx3iXo

NJEDge discusses their deployment of LISP for traffic engineering across their state-wide educational network

https://www.youtube.com/watch?v=ckwXKAsy_00

Here is an additional write-up on NJEDge:  

VXNet relates experiences as a LISP-based service provider

https://www.youtube.com/watch?v=eV76UpyVl5c

Finally, here is a write-up one of the use cases I did not touch on–a European service provider, InTouch NV, that has created an innovative, high-scale VPN service.

One more thing, I want to give a plug to CiscoLive365. The videos were excerpts above from the LISP panel at last summer’s CiscoLive. If you have not checked out CiscoLive365, you should–it’s is a great resource for folks–it has free access to most of the content from CiscoLive events as well as other useful stuff.