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

The previous blog posts on LISP have considered the forwarding plane. A brief summary of the forwarding plane is as follows:

The control plane is concerned with how the ITR maps a destination to an ETR. In order for this to happen, two primary activities need to be completed.

These functions are known as mapping functions. LISP considered a number of different mechanisms (CONS, NERD and EMACS) to deliver this, but the LISP + ALT (Alternative Logical Topology) mechanism is the version Cisco has made available on its released IOS (LISP + ALT is documented in draft-ietf-lisp-alt) and seems to be the way forward.

These two functions are delivered by two separate services. The registration service is delivered via a Mapping Server (MS), while the lookup via the Mapping Resolver (MR). This is in a general deployment. The draft discusses various potential configurations where the ETR or ITR may be directly connected to the ALT network, but this is for sites that require additional controls and wouldn’t be the general practice.

So broadly speaking, the ETR registers its EIDs with the MS. This is communicated to the MS as a push, which in turn is pushed out over the ALT network. This is similar to how BGP routes in the Internet today, in that user networks advertise their reachability out to the wider BGP-connected network.

The ITR sends a mapping request for the destination EID address to the MR, which then forwards the request to the corresponding ETR over the ALT network. The ETR responds with a mapping reply. This mapping reply contains the RLOC addresses (the ETRs) that should be used for the required EIDs, which is stored in the mapping database. This operates as a pull, in a similar fashion to DNS. Together, this is known as a hybrid push pull system.
The asymmetry between the push from the ETR and the pull from the ITR is the key to keeping the forwarding state small on the ITR and allowing the forwarding plane on these systems to scale. It is what keeps Elbonian prefixes off of your router unless you really need it.
These services are configured as follows:
Mapping Server

vrf definition LISP
 rd 1:1
!enable the Mapping Server service
ip lisp map-server
!configure LISP site
lisp site CustomerA
 authentication-key cisco
 eid-prefix 10.1.1.0/24 accept-more-specifics
lisp site CustomerB
 authentication-key cisco
 eid-prefix 10.1.2.0/24 accept-more-specifics
!enable ALT on the vrf LISP
ip lisp alt-vrf LISP

Mapping Resolver

vrf definition LISP
 rd 1:1
!enable the Map Resolver system
ip lisp map-resolver
ip lisp alt-vrf LISP

Combined

vrf definition LISP
 rd 1:1
ip lisp map-server
ip lisp map-resolver
lisp site CustomerA
 authentication-key cisco
 eid-prefix 10.1.1.0/24 accept-more-specifics
lisp site CustomerB
 authentication-key cisco
 eid-prefix 10.1.2.0/24 accept-more-specifics
ip lisp alt-vrf LISP

Note that the VRF definition is required, even if the Map Server and Map Resolver are located on the same system. My initial configurations assumed that this would not be required, but this makes sense when you consider that the MS and MR are actually two separate processes and in most cases they will need to communicate over the ALT network (more on this in the next post). Even if they are located on the same system, the MR requires an ALT network to forward the mapping request to the MS, and then on to the ETR.
Adding the above configuration to the forwarding topology discussed in the previous LISP post, we would have the following:

xTR1 and xTR2 would register with the MS element of the MSMR system. They would have the same address configured as the MR, so that the configuration for xTR1 would look as follows:

!create a database mapping for the EIDs owned by this site. This is used by the ETR function to register with the Mapping Server
ip lisp database-mapping 10.1.1.0/24 10.255.255.1 priority 2 weight 50
!configure the Map Resolver address that is to be used by this system
ip lisp itr map-resolver 10.255.255.4
!enable the itr function
ip lisp itr
!configure the Map Server address that is to be used by this system
ip lisp etr map-server 10.255.255.4 key cisco
!enable the etr function
ip lisp etr

The full configurations and topology of the Basic LISP testbed is documented here. Obviously, the MS and MR systems are very rarely going to be self-contained. In the next post, I’ll consider the ALT environment and how it joins up the MS and MR environments in greater detail.

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

The previous post considered the LISP Data Plane from a theoretical basis. Before moving onto the control plane, I would like to examine a real functional network running LISP. Cisco has made code available that I used in GNS3. The topology looks like the following (red space is RLOC, green space is EID):

The first point that should be made is that this not a complete LISP network. For this reason, I won’t post my configs yet. Only once the control plane elements have been considered, will the final pieces be added. In spite of this, we have enough to get traffic from Customer A to Customer B, assuming that the EID to RLOC mappings pre-exist.

Core#show ip route

<snip>

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks

C        10.1.3.0/30 is directly connected, GigabitEthernet1/0

C        10.1.3.4/30 is directly connected, GigabitEthernet2/0

O        10.255.255.1/32 [110/2] via 10.1.3.2, 00:14:19, GigabitEthernet1/0

O        10.255.255.2/32 [110/2] via 10.1.3.6, 00:14:29, GigabitEthernet2/0

Core#

If we examine the xTR LISP Map-cache databases:

xTR1#sh ip lisp map-cache

LISP IPv4 Mapping Cache, 2 entries

0.0.0.0/0, uptime: 00:08:55, expires: never, via static

Negative cache entry, action: send-map-request

10.1.2.0/24, uptime: 00:00:33, expires: 23:59:24, via map-reply, complete

Locator       Uptime    State      Pri/Wgt

10.255.255.2 00:00:33  up           2/50

xTR2#sh ip lisp map-cache

LISP IPv4 Mapping Cache, 2 entries

0.0.0.0/0, uptime: 00:09:07, expires: never, via static

Negative cache entry, action: send-map-request

10.1.1.0/24, uptime: 00:00:40, expires: 23:59:17, via map-reply, complete

Locator       Uptime    State      Pri/Wgt

10.255.255.1 00:00:40  up           2/50

Without being too concerned about the majority of the details listed here, we can see that the EID 10.1.2.0/24 is known via RLOC 10.255.255.2 (xTR2′s loopback address) and EID 10.1.1.0/24 via RLOC 10.255.255.1 (xTR1′s loopback address).

If we ping from Customer A to Customer B, a Wireshark capture (on the link between customer A and xTR1) shows that the source will be 10.1.1.2 (in the EID address space for CustomerA) and the destination will be 10.1.2.254 (in the EID address space for CustomerB).

Frame 17 (114 bytes on wire, 114 bytes captured)

[Protocols in frame: eth:ip:icmp:data]

Ethernet II,

Src: ca:05:16:80:00:1c (ca:05:16:80:00:1c),

Dst: ca:02:11:f4:00:1c (ca:02:11:f4:00:1c)

Internet Protocol,

Src: 10.1.1.2 (10.1.1.2),

Dst: 10.1.2.255 (10.1.2.255)

Internet Control Message Protocol

Type: 8 (Echo (ping) request)

Code: 0 ()

Checksum: 0×2360 [correct]

Identifier: 0×0004

Sequence number: 0 (0×0000)

Data (72 bytes)

The return traffic, unsurprisingly, is from Customer B to Customer A.

Frame 18 (114 bytes on wire, 114 bytes captured)

[Protocols in frame: eth:ip:icmp:data]

Ethernet II,

Src: ca:02:11:f4:00:1c (ca:02:11:f4:00:1c),

Dst: ca:05:16:80:00:1c (ca:05:16:80:00:1c)

Internet Protocol,

Src: 10.1.2.255 (10.1.2.255),

Dst: 10.1.1.2 (10.1.1.2)

Internet Control Message Protocol

Type: 0 (Echo (ping) reply)

Code: 0 ()

Checksum: 0x2b60 [correct]

Identifier: 0×0004

Sequence number: 0 (0×0000)

Data (72 bytes)

If the core is oblivious to the EID address space, how are the pings getting through? LISP has encapsulated the traffic in UDP LISP Data (port 4341). The following wireshark capture (on the link between the Core and xTR1) shows that the source and destination icmp packets are encap’ed (or jacked up), and the source and destination IP addresses are xTR1 (10.1.3.2 – outbound interface) and xTR2 (10.255.255.2 – loopback interface referred to in xTR1′s mapping for the 10.1.2.0/24 EID).

Frame 21 (150 bytes on wire, 150 bytes captured)

[Protocols in frame: eth:ip:udp:lisp-data:ip:icmp:data]

Ethernet II,

Src: ca:02:11:f4:00:38 (ca:02:11:f4:00:38),

Dst: ca:04:16:80:00:1c (ca:04:16:80:00:1c)

Internet Protocol,

Src: 10.1.3.2 (10.1.3.2),

Dst: 10.255.255.2 (10.255.255.2)

User Datagram Protocol,

Src Port: hello (1789),

Dst Port: lisp-data (4341)

Locator/ID Separation Protocol (Data)

Internet Protocol,

Src: 10.1.1.2 (10.1.1.2),

Dst: 10.1.2.255 (10.1.2.255)

Internet Control Message Protocol

Type: 8 (Echo (ping) request)

Code: 0 ()

Checksum: 0×2360 [correct]

Identifier: 0×0004

Sequence number: 0 (0×0000)

Data (72 bytes)

The return wireshark capture shows that the return icmp packets are encap’ed , and the source and destination IP addresses are xTR2 (10.1.3.6 – outbound interface) and xTR1 (10.255.255.1 – loopback interface referred to in XTR2′s mapping for the 10.1.1.0/24 EID).

Frame 22 (150 bytes on wire, 150 bytes captured)

[Protocols in frame: eth:ip:udp:lisp-data:ip:icmp:data]

Ethernet II,

Src: ca:04:16:80:00:1c (ca:04:16:80:00:1c),

Dst: ca:02:11:f4:00:38 (ca:02:11:f4:00:38)

Internet Protocol,

Src: 10.1.3.6 (10.1.3.6),

Dst: 10.255.255.1 (10.255.255.1)

User Datagram Protocol,

Src Port: hello (1789),

Dst Port: lisp-data (4341)

Locator/ID Separation Protocol (Data)

Internet Protocol,

Src: 10.1.2.255 (10.1.2.255),

Dst: 10.1.1.2 (10.1.1.2)

Internet Control Message Protocol

Type: 0 (Echo (ping) reply)

Code: 0 ()

Checksum: 0x2b60 [correct]

Identifier: 0×0004

Sequence number: 0 (0×0000)

Data (72 bytes)

The above output shows that LISP at the data plane is basically a dynamic tunneling protocol. Friday’s post will consider the control plane, which will demonstrate that this data plane integrates with a DNS-like distributed EID to RLOC mapping database. The three questions that will have to be answered are:

Postcript: These wireshark decodes were made possible with the use of a special LISP version of wireshark – available here.