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 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.
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 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.
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
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:
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
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):
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.