LISP – Separate MS / MR

This is part of a series of posts – The Lisp Papers.

In the previous LISP post, Practical LISP – Basic Control Plane, the network topology had a single device that delivered both MS and MR functions. While this demonstrated a simple LISP network, it is not a practical deployment. In reality, any number of MS and MR devices will communicate over an Alternative Logical Topology (ALT).

An ALT is nothing more than a tunnelled overlay network that runs BGP to disseminate EID addresses. It also acts as the environment that delivers Mapping Requests or data probes. The Mapping Request / Reply action has been largely covered under the previous post. Data Probes weren’t.

Data Probes

Data Probes are used to ensure that the first initial frames aren’t dropped while a Mapping Request is sent and Response is received. This delay is similar to DNS but with a small proviso. As DNS requests occur within the client, the dropping of the first few frames doesn’t occur as the network layer isn’t engaged until a destination address has been resolved. However, the LISP map doesn’t occur in the client stack and an ITR will not buffer the frames until the destination ETR(s) have been located. As such, a few packets will generally be dropped until the Mapping Response has been received.

To get around this, Data Probes can be used. This is quite simply using the initial packets received by the ITR to act as a mapping request. The data packet is encapsulated with a LISP header and forwarded to the MR. The LISP packet addressed to the EID and encapsulated within a GRE header, which is destination addressed to the next hop specified by the BGP routing used over the ALT. The GRE packet will potentially be decapsulated and encapsulated multiple times as it traverses the ALT. The ALT will use BGP routing to forward the packet to the EID prefix source, which is the MS. Once at the MS, the LISP packet is forwarded on to the ETR, where the Data Packet is decapsulated and forwarded on to the EID Destination.

So we have 3 different levels of source / destination addresses, which can best be understood using the following diagram:

Data Probes seem to be a good idea, but the ALT draft does draw attention to some concerns:

It is worth noting that there has been a great deal of discussion and controversy about whether Data Probes are a good idea. On the one hand, using them offers a method of avoiding the “first packet drop” problem when an ITR does not have a mapping for a particular EID-prefix. On the other hand, forwarding data packets on the ALT would require that it either be engineered to support relatively high traffic rates, which is not generally feasible for a tunneled network, or that it be carefully designed to aggressively rate-limit traffic to avoid congestion or DoS attacks. There may also be issues caused by different latency or other performance characteristics between the ALT path taken by an initial Data Probe and the “Internet” path taken by subsequent packets on the same flow once a mapping is in place on an ITR. For these reasons, the use of Data Probes is not recommended at this time; they should only be originated an ITR when explicitly configured to do so and such configuration should only be enabled when performing experiments intended to test the viability of using Data Probes.

Cisco provides support for data probes on the Nexus platform using the command:
ip lisp itr send-data-probe
No support for data probes seems to be available in IOS (15.1(4)XB4 or 15.1.4M).

The ALT

The ALT does not directly communicate the RLOC to EID mapping. It simply provides a low-capacity environment to deliver the initial Mapping Requests, addressed to the EID required. The Mapping response will traverse the standard RLOC environment, with the source the responding ETR and the destination would be the requesting ITR.

To explore the configuration required to support a separated MS and MR function connecting over the ALT, the following topology will be used:

The configurations use the new LISP CLI format.
MR Configuration
The MR configuration now includes a GRE tunnel to the MS and an IPv4 VRF SAFI BGP peer to the remote side of the BGP peer tunnel. LISP is redistributed into this BGP SAFI.

vrf definition LISP
 rd 1:1
 !
 address-family ipv4
 exit-address-family
!
interface Loopback0
 ip address 10.255.255.0 255.255.255.255
!
interface Tunnel0
 vrf forwarding LISP
 ip address 10.0.0.1 255.255.255.252
 tunnel source Loopback0
 tunnel destination 10.255.255.4
!
router lisp
 ipv4 map-resolver
 ipv4 alt-vrf LISP
 exit
!
router bgp 65001
 bgp log-neighbor-changes
 !
 address-family ipv4 vrf LISP
  redistribute lisp
  neighbor 10.0.0.2 remote-as 65002
  neighbor 10.0.0.2 activate
 exit-address-family

MS Configuration
The reciprocal configuration is specified

vrf definition LISP
 rd 1:1
 !
 address-family ipv4
 exit-address-family
!
interface Loopback0
 ip address 10.255.255.4 255.255.255.255
!
interface Tunnel0
 vrf forwarding LISP
 ip address 10.0.0.2 255.255.255.252
 tunnel source Loopback0
 tunnel destination 10.255.255.0
!
router lisp
 site CustomerA
  authentication-key cisco
  eid-prefix 10.1.1.0/24 accept-more-specifics
  exit
 !
 site CustomerB
  authentication-key cisco
  eid-prefix 10.1.2.0/24 accept-more-specifics
  exit
 !
 ipv4 map-server
 ipv4 alt-vrf LISP
 exit
!
router bgp 65002
 bgp log-neighbor-changes
 !
 address-family ipv4 vrf LISP
  redistribute lisp
  neighbor 10.0.0.1 remote-as 65001
  neighbor 10.0.0.1 activate
 exit-address-family

xTRs modified configuration
Previously, the xTRs pointed to a single address for both the MS and MR addresses. Now we point the MS and MR elements in the xTR configuration to the separate addresses specified above:
xTR1

router lisp
 database-mapping 10.1.1.0/24 10.255.255.1 priority 2 weight 50
 ipv4 itr map-resolver 10.255.255.0
 ipv4 itr
 ipv4 etr map-server 10.255.255.4 key cisco
 ipv4 etr
 exit

xTR2

router lisp
 database-mapping 10.1.2.0/24 10.255.255.1 priority 2 weight 50
 ipv4 itr map-resolver 10.255.255.0
 ipv4 itr
 ipv4 etr map-server 10.255.255.4 key cisco
 ipv4 etr
 exit

This topology peers the MS directly with the MR. However, it is reasonable to assume that xTR1 would use a MS / MR combination and xTR2 would use another. Further, direct peering is not likely. Instead, the MR would likely peer with a chain of ALT routers before reaching the MS, similar to how the Internet operates with BGP peering from source AS to destination AS.

As BGP is used to interconnect MS and MR devices over the ALT, the standard BGP prefix aggregation mechanisms and best practices could be followed.

ALT in Action

To really get to grips with the Mapping Request, it is important to examine the packets.  The following wireshark frame captures were taken (made available here with the excellent services of Cloudshark):

xTR1 to MR
MR to MS
MS to xTR2

The Mapping Response is presented below. This bypasses the ALT and is sent directly from xTR2 to xTR1.
xTR2 to xTR1

Use the following table to decipher the traces, or for more detail, refer to the detailed diagram and configurations:

Monitoring the ALT Network
The MR now contains a couple BGP prefixes within the LISP VRF:

MR#sh ip bgp vpnv4 vrf LISP
BGP table version is 3, local router ID is 10.255.255.0
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf LISP)
*> 10.1.1.0/24      10.0.0.2                 1             0 65002 ?
*> 10.1.2.0/24      10.0.0.2                 1             0 65002 ?

The networks 10.1.1.0/24 and 10.1.2.0/24 are the EIDs address spaces for Customer A and Customer B, respectively. 10.0.0.2 refers to the MS tunnel endpoint, which is used to establish the BGP Peer with the MR.