LISP Mobility with OTV

In previous posts we talked about implementing OTV with ASR routers. OTV is a overlay network to get end-to-end layer 2 connections over a layer 3 (WAN) network. In most implementations is FHRP (First Hop Redundancy Protocol, like HSRP/VRRP) filtering needed. These filters are needed to keep routing in the same datacenter where the traffic originates.
Let’s take another look at the high level design:

When FHRP filtering is active, the Virtual IP (aka.. default gateway for clients) is active in both datacenters. Which means: a packetflow from a server in DC1 is routed on the core switch/router in DC1. If you move (vMotion/ live migrate) that server to DC2, the packetflow is routed on the switch/router in DC2.
If you think this through, the datacenter outgoing trafficflows are efficient: routing will be done on the most nearby router. But… incoming traffic from branch offices is still not efficient: the WAN network does not know where the VM is hosted, so the packets are routed by the normal routing protocols. This could result in inefficient routing: if the IP range is routed to DC1 on the WAN and the VM is hosted in DC2, the Datacenter-Interconnect (OTV) will be used to get the packets to the VM.
This is where LISP mobility comes in.

In high level, you can compare LISP with DNS: when the LISP router on a branch office receives a packet starting a packetflow, it will ask a global server (The Mapping Server / Mapping Resolver) where that IP is located. The result of this query is the IP address of the LISP router in the correct datacenter. The packets are encapsulated and send across the WAN to the LISP router in the correct datacenter, decapsulation will happen en the packet is forwarded through normal layer 2 / 3 protocols to the server. This results in a more efficient traffic flow.
There are a few requirements to implement LISP:

• The WAN has to support a MTU of at least 36 extra bytes! The LISP encapsulation needs 36 bytes for IPv4. 56 bytes are needed for IPv6. A MTU of at least 1536 bytes is recommended
• The LISP router has to be the default gateway for the VLAN’s you want to be available in LISP. This is required for updating the Mapping Server with the correct location of the VMs. A Nexus 7000 series switch is recommended for the datacenters
• Think about your router on the branch offices. LISP requires more CPU power then the regular routing protocols. Most imported is the required bandwidth with the amount of concurrent sessions/packetflows

If you’re compliant with the requirements, let’s continue with the high level design. Let’s say we have a few branch offices and two datacenters, all connected with a MPLS network of a service provider. This service provider is not supporting LISP.

 
The CPE router is managed by the WAN service provider. Next to the CPE, the LISP router is connected and the rest of the branch network is connected to the LISP router.
But.. how does it work?
First, some terminology:

• LISP Mobility: the technology we use to create a more efficient packetflow over the WAN network
• iTR (Ingress Tunnel Router): The router where the LISP tunnel starts. This router receives the packets from clients. This router sends these packets to an eTR router
• eTR (Egress Tunnel Router): The router where the LISP tunnel ends.
• xTR: A router with iTR and eTR functionality
• RLOC (Routing locator): IP addresses (ranges/subnets) on the WAN network. This is non-LISP IP space and routed by the WAN provider. The LISP tunnel between iTR and eTR routers connect over the RLOC network. In the drawing above, all the CPE routers and “outside” interfaces on the LISP routers are RLOC. The RLOC is the result of the LISP query on the Mapping Resolver.
• EID (Endpoint ID): the IPv4/IPv6 address of the endpoint. This could be a client, laptop, phone, tablet, server etc etc
• Mapping Server: xTR’s update the Mapping Server with the EID / RLOC combination
• Mapping Resolver: XTR’s queries the Mapping Resolver for the RLOC address of a specific EID

The high level process:
The xTR in a branch office receives a packetflow for an EID in the datacenters. The xTR does a query for the RLOC IP address to the Mapping Resolver. The result of the query is the RLOC IP address of one of the xTR routers in the datacenters. The Branch xTR encapsulates the original IP packet (including the IP header) and adds a new header with the RLOC IP addresses. This extra header is 36 bytes.
The packet with the new header is send across the WAN to the xTR of one of the datacenters. When the packet arrives, the xTR decapsulates the packets (it removes the extra header) and forwards the original packet by using the standard layer 2/3 protocols. The reverse path (Datacenter to Branch) is exactly the same.
The required configuration will be discussed in a future blog post.