LISP Lab

Expand the topology

Now let’s expand our topology to see how LISP works in a company by adding two routers R5 & R6 at two sites as shown below:

The configurations for R5, R6 and additional configurations for R1, R2, R3 are listed below:

R5 interface e0/0 ip address 192.168.15.5 255.255.255.0 no shut int lo0 ip address 5.5.5.5 255.255.255.255 int lo1 ip address 55.55.55.55 255.255.255.255 router ospf 1 network 192.168.15.0 0.0.0.255 area 0 network 5.5.5.5 0.0.0.0 area 0 network 55.55.55.55 0.0.0.0 area 0	R6 interface e0/0 ip address 192.168.26.6 255.255.255.0 no shut int lo0 ip address 6.6.6.6 255.255.255.255 int lo1 ip address 66.66.66.66 255.255.255.255 router ospf 1 network 192.168.26.0 0.0.0.255 area 0 network 6.6.6.6 0.0.0.0 area 0 network 66.66.66.66 0.0.0.0 area 0
R1 (additional config) interface e0/1 ip address 192.168.15.1 255.255.255.0 no shut router ospf 1 network 192.168.15.0 0.0.0.255 area 0 default-information originate always router lisp database-mapping 5.5.5.0/24 10.10.14.1 priority 1 weight 100 database-mapping 55.55.55.55/32 10.10.14.1 priority 1 weight 100 database-mapping 192.168.15.0/24 10.10.14.1 priority 1 weight 100	R2 (additional config) interface e0/1 ip address 192.168.26.2 255.255.255.0 no shut router ospf 1 network 192.168.26.0 0.0.0.255 area 0 default-information originate always router lisp database-mapping 6.6.6.0/24 10.10.24.2 priority 1 weight 100 database-mapping 66.66.66.66/32 10.10.24.2 priority 1 weight 100 database-mapping 192.168.26.0/24 10.10.24.2 priority 1 weight 100
R3 (additional config) lisp site siteA eid-prefix 5.5.5.0/24 eid-prefix 55.55.55.55/32 eid-prefix 192.168.15.0/24 lisp site siteB eid-prefix 6.6.6.0/24 eid-prefix 66.66.66.66/32 eid-prefix 192.168.26.0/24

The configuration above is simple and the main point here is assigning different EIDs (5.5.5.0/24, 55.55.55.55/32, 192.168.15.0/24 on R1 and 6.6.6.0/24, 66.66.66.66/32, 192.168.26.0/24 on R2) to the same RLOCs (10.10.14.1 on R1 & 10.10.24.2 on R2). Therefore the communication destined to these EIDs will be sent to R1 & R2 where they are encapsulated into LISP packet before sending out to R4.

Please notice that we inject a default route to downstream OSPF routers so that they can send unknown traffic to R1 & R2. you

If configuring correctly, you can see all the configured EIDs on the MS/MR.

And ping from R5 to R6 is successful.

Before ending this lab, we wish to show how traffic flows from R5 to R6 so we have a deeper understanding of LISP.

How traffic flows through LISP-enabled site

Suppose R5 (192.168.15.5) wants to talk to R6 (6.6.6.6). R5 may queries a DNS server to get the IP address of R6. R5 realizes the destination address does not belong to its local subnet so it forwards packets to its default gateway, which is R1, a LISP enabled device. R1 lookups its routing table (RIB). If the route matches one of the following condition:
– default route (0.0.0.0/0 or ::/0)
– no route
– a route with a Null0 next-hop
then proceed with LISP encap process, otherwise forward natively.

In this case, R1 does not find any matched route in its routing table (no route) so the packet is proceeded with LISP encapsulation process.
Next R1 checks if the source address (192.168.15.5) of the packet is within a local EID prefix (configured with the “database-mapping” or “map-cache” command). Because it matches so the packet is eligible for LISP encapsulation.

R1 continues checking the map-cache, trying to find a matching destination but at this moment only the default entry 0.0.0.0/0 is available so it has to send a Map Request message to the MR then it drops the packets (this is also the reason why one or two first ping failed).

MR check its site database to see if any RLOC registered this EID. It finds siteB has the EID Prefix of 6.6.6.0/24 (should verify with the “show lisp site 6.6.6.6” command), with a RLOC of 10.10.24.2. With “no-proxy-reply” flag, MR must forward the Map Request to R2 with RLOC of 10.10.24.2.

When R2 receives this message, it checks its database to see that it is responsible for this EID so it sends a Map Reply back to R1 with its own RLOC 10.10.24.2.

R1 receives the Map Reply message and the destination EID has been added to the map-cache.

Now it has enough information to send packets to R2. R1 encapsulates the IP packet with LISP encapsulation and sends it to R2. R2 receives and decapsulates it then forward to R6.

This is the LISP packet forwarding flow chart, taking from the link below for your reference:

Good reference: http://lisp.cisco.com/docs/LISP-IOS_PacketForwarding.pd

Note: According to Cisco guide, there are two ways of configuring LISP:

“When configuring a device as a LISP ingress tunnel router (ITR) to resolve IPv4 EID-to-RLOC mappings for destination EIDs, you can configure the device to use one of the following two options:

– Send map requests to a map resolver—the ITR sends map requests in a LISP encapsulated control message (ECM) header with either an IPv4 or IPv6 map-resolver RLOC as its destination address (depending on the configuration). For this option, use the ipv4 itr map-resolver command instead of the ipv4 alt-vrf command.

– Send map requests directly over the LISP ALT using the VRF instance specified when configuring this command – the ITR sends map requests directly over the ALT (without the additional LISP ECM header). The destination of the map request is the EID being queried. For this option, use the ipv4 alt-vrf command.

When using the ALT, you must configure the correct address family (IPv4 or IPv6) for resolving EID-to-RLOC mappings. If an IPv4 EID mapping is required, configure the ipv4 alt-vrf command and specify a VRF that enables the IPv4 address-family and connects to an IPv4-capable ALT.”

Reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_lisp/command/ip-lisp-cr-book/lisp-rtr-ipv4-config-cmds.html

In this lab we used the first option without ipv4 alt-vrf, vrf definition and address-family ipv4 command. If you want to use this option then R3 should have these commands:

R3 vrf definition LISP_tut rd 1:1 address-family ipv4 exit-address-family ip lisp alt-vrf LISP_tut //Remove command “ip lisp map-resolver”

On the MS/MR side, we first configure a VRF with RD of 1:1 or any value we want. The command “vrf definition …” has been used in IOS v15 to replace for the old “ip vrf” command. Also we need to specify LISP is used for IPv4, not IPv6 with the “address-family ipv4” command.