@fryguy_pa


 Powered by Max Banner Ads 

LISP – Locator Identifier Separation Protocol (Say what?)

In Why not? on April 7, 2011 at 10:57

Recently I have been working on a crazy busy project at work as well as preparing for the CCIE SP lab (did not pass).  Well now that is all behind me so I figured I would take some personal time and play with some technology that I have read about, talked about, and even sat through presentations at Cisco Live (aka Networkers) in the past.  What is this technology that has me so interested you might ask.  Well, its LISP – Locator Identifier Separation Protocol (ietf draft can be found here – http://tools.ietf.org/pdf/draft-ietf-lisp-11.pdf).  The next question you may have is why does this interest me?  To be honest, I have no idea – just thought it was a nifty idea.

So, what is LISP?  The easiest way to explain it is to give you a common analogy that we all understand, DNS.  When a user wants to access a website – in this case – blog.fryguy.net, they send a DNS query to the configured DNS server.  The DNS servers then resolves that DNS name to an IP address – 76.74.254.123 – and sends that back to the client.  The client web application then makes a connection to the web server and retrieves the website.

Well, in LISP a very similar thing happens.  If a router needs to send a packet to 76.74.254.123, and that route is not in the local routing table – it sends a query to the LISP Map Resolver.  The LISP Map Resolver then looks at its database and tells the router that the network can be reached via 4.71.170.2.  The router then sends a LISP encapsulated packet to 4.71.170.2 to be then forwarded onto its ultimate destination.

That is a very simple explanation on how it works, and one that I hope most networking folks should be able to understand.  Now lets take it a step further – and think about moving a device around, yet keeping the same IP address (think vmotion).  If you are registering a device location with a server, you can then move that device around and the mapping server will be able to redirect you to the correct site.  There are other things that LISP can do, but I will save the IPv6 one for a future post.

We have host 100.100.100.100/32, called an EID – Endpoint Identifier – that is sitting behind Router A. Router A will register that network, or host in this case, with the LISP Map Server.  It will say to get to the EID prefix of 100.100.100.100/32, send the packet to Router A.  We also have another EID at 200.200.200.200/32 that is sitting behind Router B.  Router B will also register  with the LISP Map Server that host 200.200.200.200/32 is reachable via Router B.  So if 200.200.200.200/32 wants to talk to 100.100.100.100/32, it will send the packet to Router B – Router B will then ask the LISP Mapping Server how to get to 100.100.100.100/32.  The LISP Map server will respond – to get to 100.100.100.100/32, send the packet to Router A.  Router B would then in turn send the packet to Router A, who will then process the packet and forward it onto 100.100.100.100/32.

Now what happens if we move 100.100.100.100/32 to Site C?  In a normal network, we would have to change the IP address of the host to a network that is reachable via Router C.  You typically cannot advertise the same network from two sites and expect things to work correctly.  But with LISP, you can move the host around and not change the IP address.  Why?  Well, the Mapping server is what tells the routers who want to talk to 100.100.100.100/32 how to get to the host.

So lets move 100.100.100.100/32 to a location in Site-C behind Router C.  Router C would then register with the LISP Map server that 100.100.100.100/32 is now reachable via Router C.  The next time that 200.200.200.200/32 goes to talk to 100.100.100.100/32, Router B will query the LISP Map Server who will then tell it, to get to 100.100.100.100/32, send the packet to Router C for processing.

Another use case could be with a multi-homed site, like the picture below.  Typically with BGP you can only “recommend” an ingress point into your network, you have no way of guaranteeing the traffic will only flow into Router B from your upstream ISP.  Sure, you can prepend AS numbers; tweak the mutli-exit discriminator (MED), etc – but it is only a suggestion to your upstream ISP. So what can LISP do for us here?  Easy, you can set a priority to the mapping on the LISP server.  You can say that Router A has a higher priority for ingress traffic then Router B.  The LISP server will then return the path with the lowest Priority listed is the preferred route.  This will help to make sure that the traffic is flowing inbound the way that you want it to.

So lets list out some of the components of a LISP environment:

  • ITR – Ingress Tunnel Router
  • ETR – Egress Tunnel Router
  • EID – End Point Identifier
  • RLOC – Routing Locator
  • MS – Map Server
  • MR – Map Resolver
  • DFZ – Default Free Zone
  • LISP-ALT – LISP – Alternative Logical Toplogy

The Ingress Tunnel Router (ITR) is a router that is deployed as a LISP edge device.  It receives packets from the internal hosts and encapsulates packets to remote LISP sites, or if necessary, forwards packets natively to non-LISP sites. The Egress Tunnel Router (ETR) is a router that is also deployed as a LISP edge device.  It receives packets from external hosts and decapsulates the LISP packets and delivers them to internal hosts (EID)s.  Typically the ITR and ETR are the same devices, so you will commonly see xTR listed for these devices.  An Endpoint Identifier is a host or network behind the xTR device.

The Routing Locator (RLOC) is the outside IP address of the ETR.  When the EID is registered with the mapping server, this is the address that is provided for reach-ability to the EID.  The Map Server (MS) is a critical component that learns EID-to-RLOC mappings, analogous to registering you FQDN and IP to a DNS server, from the ETR.  The Map Resolver (MR) is the server that handles the queries from the ETR for RLOC to EID mappings.  This, again, is analogous to DNS lookup for name to IP address mappings.  The last item I have in that list is DFZ .  The Default Free Zone (DFZ) is a network with no default-route in it, basically you can think of this as the Internet – there is no default route there, the only routes that are reachable are advertised. There are other components as well, but these are the ones that are typically mentioned.  If you can understand what these do, if we add a P for Proxy in front of some of the acronyms (PETR or PITR), you can probably figure out what it is doing and what it means.

When it comes to the LISP – Alternate Logical Topology (LISP-ALT), this is the mapping mechanism that Cisco is supporting.  It is a hybrid push/pull architecture that aggregates EID prefixes that are “pushed”, and may push that information to other ITR routers.  EID-to-RLOC mappings are “pulled” by the ITR when an explicit request is made or triggered.  Basically it seems to be a way to keep the cache on the xTRs up to date with changes.  At least that is what I gather from the information.
So that is a brief overview of what LISP is and does, now lets get to the fun part.  I did a lab based on the information found at lisp4.cisco.com, with some tweaks and plays.  Here is the topology that I am using:

Routers R1, R2, R3, and R4 are all Cisco 3845 ISR routers; R2, R3 and R5 running 15.1(1)XB3 IP BaseK9 code while R1 is running 12.4x code.  The reason R1 is not running 15.x code is insufficient memory and also 12.4 code does not have LISP support, so we can be sure that LISP is transparent to non-LISP devices.  R5 is a 2621XM and R6 is a 3825 router running 12.xIOS code.  The IOS code on these does not matter, for all intense purposes they can be computers, iDevices, etc as they are  the EIDs in this network.  For R1 I had limited Ethernet ports, so in order to save cabling, I trunked the VLANs for R2 and R3 onto the G0/0 interface.

So lets start the fun stuff, the configuration!

Router/Switch Output
Commands
Notes

We will start with R1 as it is the core of the network in the diagram. Nothing fancy going on here, just basic router interface config.  No routing protocols, no default routes, just interfaces with IP addresses. From there we will continue onto R5 and R6 as these are just EID devices – they have no LISP configurations on them, just simple routers.

First R1:
LISP_R1# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
LISP_R1(config)# interface GigabitEthernet0/0
LISP_R1(config-if)# desc [----[ Connection to R2 and R3 via dot1q ]—-]
LISP_R1(config-if)# no ip address
LISP_R1(config-if)# no shut
LISP_R1(config)# interface GigabitEthernet0/0.12
LISP_R1(config)# desc [----[ Connection to R2 via VLAN 12 ]—-]
LISP_R1(config-if)# encapsulation dot1Q 12
LISP_R1(config-if)# ip address 10.1.12.1 255.255.255.0
LISP_R1(config)# interface GigabitEthernet0/0.13
LISP_R1(config-if)# desc [----[ Connection to R3 via VLAN 13 ]—-]
LISP_R1(config-if)# encapsulation dot1Q 13
LISP_R1(config-if)# ip address 10.1.13.1 255.255.255.0
LISP_R1(config)# interface GigabitEthernet0/1
LISP_R1(config-if)# desc [----[ Connection to R4 - LISP MR-MS Server ]—-]
LISP_R1(config-if)# ip address 10.1.14.1 255.255.255.0
LISP_R1(config-if)# no shut
LISP_R1(config)# exit
LISP_R1#

As you can see with R1, there is nothing fancy here at all.  Just a basic router config with a dot1q trunk (due to limited interfaces :)).  There are no dynamic or static routes, only connected:
LISP_R1# sh ip route

Gateway of last resort is not set
10.0.0.0/24 is subnetted, 3 subnets
C       10.1.14.0 is directly connected, GigabitEthernet0/1
C       10.1.13.0 is directly connected, GigabitEthernet0/0.13
C       10.1.12.0 is directly connected, GigabitEthernet0/0.12
LISP_R1#

Now, we can do R5:
LISP_R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
LISP_R5(config)# interface Loopback1
LISP_R5(config-if)# ip address 150.1.125.1 255.255.255.255
LISP_R5(config)# interface Loopback2
LISP_R5(config-if)# ip address 150.1.125.2 255.255.255.255
LISP_R5(config)# interface Loopback3
LISP_R5(config-if)# ip address 150.1.125.3 255.255.255.255
LISP_R5(config)# interface FastEthernet0/1
LISP_R5(config-if)# ip address 150.1.25.5 255.255.255.0
LISP_R5(config)# no shut
LISP_R5(config)# router ospf 1
LISP_R5(config-router)# network 150.1.25.0 0.0.0.255 area 0
LISP_R5(config-router)# network 150.1.125.0 0.0.0.255 area 0
LISP_R5(config)# exit
LISP_R5#

Now with R5 we have a few loopback interafces configured as well.  These loopback interfaces as the EID devices for this lab so that we can demonstrate connectivity.  We have configured a dynamic routing protocol, OSPF, so that this router can learn a default route from R2. Since R2 is not configured yet, we are not learning the default route from R2.

LISP_R5# sh ip route
Gateway of last resort is not set

150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       150.1.25.0/24 is directly connected, FastEthernet0/1
C       150.1.125.2/32 is directly connected, Loopback2
C       150.1.125.3/32 is directly connected, Loopback3
C       150.1.125.1/32 is directly connected, Loopback1
LISP_R5#

and finally R6:
LISP_R6# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
LISP_R6(config)# interface Loopback1
LISP_R6(config)# ip address 150.1.136.1 255.255.255.255
LISP_R6(config)# interface Loopback2
LISP_R6(config)# ip address 150.1.136.2 255.255.255.255
LISP_R6(config)# interface Loopback3
LISP_R6(config)# ip address 150.1.136.3 255.255.255.255
LISP_R6(config)# interface GigabitEthernet0/1
LISP_R6(config)# ip address 150.1.36.6 255.255.255.0
LISP_R6(config)# router ospf 1
LISP_R6(config)# network 150.1.36.0 0.0.0.255 area 0
LISP_R6(config)# network 150.1.136.0 0.0.0.255 area 0
LISP_R6(config)# exit
LISP_R6#

Now with R6, like R5, we have a few loopback interafces configured as well.  These loopback interfaces as the EID devices for this lab so that we can demonstrate connectivity.  We have configured a dynamic routing protocol, OSPF, so that this router can learn a default route from R3. Since R3 is not configured yet, we are not learning the default route from R3.

LISP_R6# sh ip route
Gateway of last resort is not set

150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       150.1.136.3/32 is directly connected, Loopback3
C       150.1.136.2/32 is directly connected, Loopback2
C       150.1.136.1/32 is directly connected, Loopback1
C       150.1.36.0/24 is directly connected, GigabitEthernet0/1
LISP_R6#

So that covers all the non-LISP routers in the diagram, now lets move onto R4, the LISP Mapping server in this topology and I will discuss the configuration in-line with the config.

R4:
LISP_R4_MP_MR# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
First we can configure the interface that connects R4 to R1
LISP_R4_MP_MR(config)# interface GigabitEthernet0/0

LISP_R4_MP_MR(config-if)# ip address 10.1.14.4 255.255.255.0
LISP_R4_MP_MR(config-if)# no shut
We will add a route to 10.0.0.0/8 network so R4 knows how to talk to R2 and R3.  We are only doing this because we are not running BGP in our core and we need to tell R4 how to talk to the other routers in its network.
LISP_R4_MP_MR(config)# ip route 10.0.0.0 255.0.0.0 10.1.14.1

Now we can configure a VRF for the LISP routes.  If you are wondering why the command is vrf definition, that is because 15.x the command changed from ip vrf. Since we are also only dealing with IPv4 (for now), we need to define the ipv4 address family.
LISP_R4_MP_MR(config)# vrf definition lisp
LISP_R4_MP_MR(config-vrf)# rd 1:1

LISP_R4_MP_MR(config-vrf-af)# address-family ipv4
LISP_R4_MP_MR(config-vrf)# exit-address-family
Now we will define our first LISP site, Site-A.  We will configure our authentication key as well as what EID prefixes are associated with that location.  Here we are configuring some mappings for Site-A as 150.1.25.0/24 and 150.1.125.0/24.
LISP_R4_MP_MR(config)# lisp site Site-A

LISP_R4_MP_MR(config-lisp-site)# description R2 and R5
LISP_R4_MP_MR(config-lisp-site)# authentication-key Fryguy
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 150.1.25.0/24
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 150.1.125.0/24
Now we will define our second LISP site, Site-B.  We will configure our authentication key as well as what EID prefixes are associated with that location.  Here we are configuring some mappings for Site-A as 150.1.36.0/24 and 150.1.136.0/24
LISP_R4_MP_MR(config)# lisp site Site-B
LISP_R4_MP_MR(config-lisp-site)# description R3 and R6
LISP_R4_MP_MR(config-lisp-site)# authentication-key Fryguy
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 150.1.36.0/24
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 150.1.136.0/24
Now we can define this device as a LISP Map Server and Map Resolver
LISP_R4_MP_MR(config)# ip lisp map-server

LISP_R4_MP_MR(config)# ip lisp map-resolver
Now we can enable the ALT service on this router, we just need to tell it what VRF this data will reside in – hence the reason we created the LISP VRF before.
LISP_R4_MP_MR(config)# ip lisp alt-vrf lisp

Now that we have everything configured on R4, we can look at the lisp site summary and check the site configuration.
LISP_R4_MP_MR# sh lisp site summary
———– IPv4 ———–                                              ———– IPv6 ———–
Site name            Configured Registered Incons Configured Registered Incons
Site-A                                       2 0            0                     0                    0          0
Site-B                                        2 0            0                    0                     0         0

Number of configured sites:                     2
Number of registered sites:                     0
Sites with inconsistent registrations:          0
IPv4
Number of configured EID prefixes:            4
Number of registered EID prefixes:            0
LISP_R4_MP_MR#

As you can see, we have 4 EID prefixes configured, but none registered.  There are none registered because R2 and R3 have not been setup yet.  But once they are, R4 will accept the registrations and the numbers will change accordingly. Also notice that the only address family currently listed is IPv4- we have not done any configuration for IPv6 yet under the VRF.

Now R2:
LISP_R2# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
We can start by configuring the ITR and ETR interfaces on the router.  G0/0 is the ETR and G0/1 is the ITR interface.
LISP_R2(config)# interface GigabitEthernet0/0
LISP_R2(config)# desc [----[ ETR Interface ]—–]
LISP_R2(config-if)# ip address 10.1.12.2 255.255.255.0
LISP_R2(config-if)# no shut
LISP_R2(config)# interface GigabitEthernet0/1
LISP_R2(config)# desc [----[ ITR Interface ]—–]
LISP_R2(config-if)# ip address 150.1.25.2 255.255.255.0
LISP_R2(config-if)# no shut
Now we can configure a routing protocol (OSPF here) for the ITR side of the network.  This will allow R2 to send R5 a default route via the default-information originate always command.  This is necessary because R5, the EID, does not know about LISP.
LISP_R2(config)# router ospf 1

LISP_R2(config-router)# network 150.1.25.0 0.0.0.255 area 0
LISP_R2(config-router)# default-information originate always
We will now add a static route for the 10/8 network.  This is being added so the router knows how to route to other 10/8 networks. Notice this is not a default route.
LISP_R2(config-router)# ip route 10.0.0.0 255.0.0.0 10.1.12.1

Now we can configure our LISP database mappings, assign the priority for ingress traffic, as well as any weights for load balancing we would like.
LISP_R2(config)# ip lisp database-mapping 150.1.25.0/24 10.1.12.2 priority 1 weight 100
LISP_R2(config)# ip lisp database-mapping 150.1.125.0/24 10.1.12.2 priority 1 weight 100
Next we can configure the LISP map resolver, here it is R4 – 10.1.14.4
LISP_R2(config)# ip lisp itr map-resolver 10.1.14.4

…and we can configure the router as an ingress LISP router (ITR)
LISP_R2(config)# ip lisp itr
Once you enter that command (or if you enter the etr command first), the router will create a LISP interface automagically

*Apr  7 13:07:01.127: %LINEPROTO-5-UPDOWN: Line protocol on Interface LISP0, changed state to up
Now we can configure the egress map-server so we know who to register with, again R4 at 10.1.14.4 and the appropriate password.
LISP_R2(config)# ip lisp etr map-server 10.1.14.4 key Fryguy

…and finally enable this router as an egress router for LISP (ETR)
LISP_R2(config)# ip lisp etr

and finally R3:
We will configure this just like R2, just change the networks where necessary.
R3_LISP# conf t

Enter configuration commands, one per line.  End with CNTL/Z.
R3_LISP(config)# interface GigabitEthernet0/0
LISP_R3(config)#
desc [----[ ITR Interface ]—–]
LISP_R3(config-if)# ip address 150.1.36.3 255.255.255.0
LISP_R3(config-if)# no shut
LISP_R3(config)# interface GigabitEthernet0/1
LISP_R3(config)#
desc [----[ ETR Interface ]—–]
LISP_R3(config-if)# ip address 10.1.13.3 255.255.255.0
LISP_R3(config-if)# no shut
LISP_R3(config)# router ospf 1
LISP_R3(config-router)# network 150.1.36.3 0.0.0.0 area 0
LISP_R3(config-router)# default-information originate always
LISP_R3(config)# ip route 10.0.0.0 255.0.0.0 10.1.13.1
LISP_R3(config)# ip lisp database-mapping 150.1.36.0/24 10.1.13.3 priority 1 weight 100
LISP_R3(config)# ip lisp database-mapping 150.1.136.0/24 10.1.13.3 priority 1 weight 100
LISP_R3(config)# ip lisp itr map-resolver 10.1.14.4
LISP_R3(config)# ip lisp itr
*Apr  7 13:08:01.127: %LINEPROTO-5-UPDOWN: Line protocol on Interface LISP0, changed state to up
LISP_R3(config)# ip lisp etr map-server 10.1.14.4 key Fryguy

LISP_R3(config)# ip lisp etr

Ok, whew, configs are done.  So, now what does all this actually look like?  First we can take a look at the routing tables on R5 and R6

R5:
LISP_R5# sh ip route
Gateway of last resort is 150.1.25.2 to network 0.0.0.0

150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       150.1.25.0/24 is directly connected, FastEthernet0/1
C       150.1.125.2/32 is directly connected, Loopback2
C       150.1.125.3/32 is directly connected, Loopback3
C       150.1.125.1/32 is directly connected, Loopback1
O*E2 0.0.0.0/0 [110/1] via 150.1.25.2, 00:12:37, FastEthernet0/1
LISP_R5#

R6:
LISP_R6# sh ip route
Gateway of last resort is 150.1.36.3 to network 0.0.0.0

150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       150.1.136.3/32 is directly connected, Loopback3
C       150.1.136.2/32 is directly connected, Loopback2
C       150.1.136.1/32 is directly connected, Loopback1
C       150.1.36.0/24 is directly connected, GigabitEthernet0/1
O*E2 0.0.0.0/0 [110/1] via 150.1.36.3, 00:01:18, GigabitEthernet0/1
LISP_R6#

As we can see, they both have only the locally connected routes (C) as well as a default route from R2 and R3 prospectively.  The default route is only being propagated as these are EID devices, so they are not aware of anything outside their routing domain.

So lets take a look at the routing table on R2:
LISP_R2# sh ip route
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
S        10.0.0.0/8 [1/0] via 10.1.12.1
C        10.1.12.0/24 is directly connected, GigabitEthernet0/0
L        10.1.12.2/32 is directly connected, GigabitEthernet0/0
150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
C        150.1.25.0/24 is directly connected, GigabitEthernet0/1
L        150.1.25.2/32 is directly connected, GigabitEthernet0/1
O        150.1.125.1/32 [110/11] via 150.1.25.5, 02:51:12, GigabitEthernet0/1
O        150.1.125.2/32 [110/11] via 150.1.25.5, 02:51:12, GigabitEthernet0/1
O        150.1.125.3/32 [110/11] via 150.1.25.5, 02:51:12, GigabitEthernet0/1
LISP_R2#

So we see we do not have a default route (default-free zone – DFZ), we have learned the EID routes from R5, we have a static for the 10/8 network that we configured, and we know about the connected routes.  That is all that we have.  There are no routes for R6 on this router.

Now lets look at R3′s routing table as well:
R3_LISP# sh ip route
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
S        10.0.0.0/8 [1/0] via 10.1.13.1
C        10.1.13.0/24 is directly connected, GigabitEthernet0/1
L        10.1.13.3/32 is directly connected, GigabitEthernet0/1
150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
C        150.1.36.0/24 is directly connected, GigabitEthernet0/0
L        150.1.36.3/32 is directly connected, GigabitEthernet0/0
O        150.1.136.1/32 [110/11] via 150.1.36.6, 1d03h, GigabitEthernet0/0
O        150.1.136.2/32 [110/11] via 150.1.36.6, 1d03h, GigabitEthernet0/0
O        150.1.136.3/32 [110/11] via 150.1.36.6, 1d03h, GigabitEthernet0/0
R3_LISP#

Again, do not have a default route (default-free zone – DFZ), we have learned the EID routes from R6, we have a static for the 10/8 network that we configured, and we know about the connected routes.  That is all that we have.  There are no routes for R5 on this router.

So, by all logical means R5 and R6 should NOT have connectivity.  Well, we can test that by PINGing R6 from R5′s loopback 1 IP address:
LISP_R5# ping 150.1.136.1 source loopback 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.136.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.125.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
LISP_R5#

Hey, it worked!  How does that happen? Did that route show up in R2 suddenly? Let’s check:

LISP_R2# sh ip route 150.1.136.1
% Subnet not in table
LISP_R2#

Nope, not there! So how did that work? Well, lets turn on a debug on R2 and try that again

LISP_R2# debug lisp control-plane all

LISP_R5# ping 150.1.136.1 source loopback 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.136.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.125.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
LISP_R5#

…and scrolled on the R2 console we see a whole bunch of the messages that are displayed below. I have commented on about the interesting lines and put in appropriate explanations.

LISP_R2# debug lisp control-plan all
All LISP control debugging is on
So here we get a request to connect to 150.1.136.1/32.
*Apr  7 03:29:33.571: LISP: Processing data signal for EID prefix 150.1.136.1/32

We notice that we do not have a route (incomplete),
*Apr  7 03:29:33.571: LISP: Remote EID prefix 150.1.136.1/32, Change state to incomplete (method: data-signal, state: unknown, rlocs: 0).
…so we schedule and send a map request.
*Apr  7 03:29:33.571: LISP: Remote EID prefix 150.1.136.1/32, Scheduling map requests (incomplete) (method: data-signal, state: incomplete, rlocs: 0).
..and we send that request to 10.1.14.4
*Apr  7 03:29:33.607: LISP: Send map request for EID prefix 150.1.136.1/32

*Apr  7 03:29:33.607: LISP: Remote EID prefix 150.1.136.1/32, Send map request (1) (method: data-signal, state: incomplete, rlocs: 0).
*Apr  7 03:29:33.607: LISP: AF IPv4, Sending map-request from 150.1.25.2 to 150.1.136.1 for EID 150.1.136.1/32, ITR-RLOCs 1, nonce 0xFE068986-0xFE4F94B7 (encap src 10.1.12.2, dst 10.1.14.4).
We received a Map-Reply message that tells us to talk to 10.1.13.3 for that route
*Apr  7 03:29:33.607: LISP: Processing received Map-Reply message from 10.1.13.3 to 10.1.12.2

*Apr  7 03:29:33.607: LISP: Received map reply nonce 0xFE068986-0xFE4F94B7, records 1
*Apr  7 03:29:33.607: LISP: Map Request prefix 150.1.136.1/32 remote EID prefix, Received reply with rtt 0ms.
*Apr  7 03:29:33.607: LISP: Processing mapping information for EID prefix 150.1.136.0/24
*Apr  7 03:29:33.607: LISP: Remote EID prefix 150.1.136.0/24, Change state to complete (method: map-reply, state: unknown, rlocs: 0).
*Apr  7 03:29:33.607: LISP: Remote EID prefix 150.1.136.0/24, Starting idle timer (method: map-reply, state: complete, rlocs: 0).
*Apr  7 03:29:33.607: LISP: Remote EID prefix 150.1.136.1/32, Change state to deleted (method: data-signal, state: incomplete, rlocs: 0).
*Apr  7 03:29:33.607: LISP: Remote EID prefix 150.1.136.0/24, Recalculated RLOC status bits from 0×0 to 0×1 (method: map-reply, state: complete, rlocs: 1).
*Apr  7 03:29:33.607: LISP RIB_RWATCH: (default:ipv4:base) T 10.1.13.3/32 EVENT Track start
*Apr  7 03:29:33.607: LISP RIB_RWATCH: (default:ipv4:base) N 10.1.13.3/32 Adding track
*Apr  7 03:29:33.607: LISP RIB_RWATCH: (default:ipv4:base) N 10.1.13.3/32 QP Schedule query
*Apr  7 03:29:33.607: LISP RIB_RWATCH: (default:ipv4:base) T 10.1.13.3/32 EVENT Query found route
*Apr  7 03:29:33.607: LISP RIB_RWATCH: (default:ipv4:base) R 10.0.0.0/8  d=1 p=1 -> 10.1.12.1 (base) 0 Updating
*Apr  7 03:29:33.607: LISP RIB_RWATCH: Adding to client notification queue
..and now we add it to our LISP cache on the router so we do not have to requery (think DNS caching)
*Apr  7 03:29:33.607: LISP: Remote EID prefix 150.1.136.0/24 locator 10.1.13.3 priority 1 weight 100, Added locator (method: map-reply, state: complete, rlocs: 1).
*Apr  7 03:29:33.607: LISP RIB_RWATCH: (default:ipv4:base) W 10.1.13.3/32 c=0x705AAD20 Client notified reachable
LISP_R2#

As you can see, all that took place in less then a second!

Now if we go back to R2 and look at the lisp map-cache we will see what we have an entry for the 150.1.136.0/24 network that tells us to talk to 10.1.13.3
LISP_R2# sh ip lisp map-cache
LISP IPv4 Mapping Cache, 2 entries

0.0.0.0/0, uptime: 00:07:08, expires: never, via static
Negative cache entry, action: send-map-request
150.1.136.0/24, uptime: 00:06:56, expires: 23:52:56, via map-reply, complete
Locator    Uptime    State      Pri/Wgt
10.1.13.3  00:06:56  up           1/100
LISP_R2#

And on R3 we will see a similar output from the show ip lisp map-cache command:
R3_LISP# sh ip lisp map-cache
LISP IPv4 Mapping Cache, 2 entries

0.0.0.0/0, uptime: 00:07:59, expires: never, via static
Negative cache entry, action: send-map-request
150.1.125.0/24, uptime: 00:07:53, expires: 23:51:59, via map-reply, complete
Locator    Uptime    State      Pri/Wgt
10.1.12.2  00:07:53  up           1/100
R3_LISP#

Now lets go to R4 (Mapping Server/Resolver) and see what is there via the show lisp site and show lisp site summary:
LISP_R4_MP_MR# sh lisp site
LISP Site Registration Information

Site Name      Last      Up   Who Last             Inst     EID Prefix
Register          Registered           ID
Site-A              00:00:37  yes  10.1.12.2                     150.1.25.0/24
………………..00:00:37  yes  10.1.12.2                     150.1.125.0/24
Site-B               00:00:01  yes  10.1.13.3                     150.1.36.0/24
………………..00:00:01  yes  10.1.13.3                     150.1.136.0/24
LISP_R4_MP_MR#
LISP_R4_MP_MR#

LISP_R4_MP_MR# sh lisp site summary
———– IPv4 ———–              ———– IPv6 ———–
Site name            Configured Registered Incons Configured Registered Incons
Site-A                                       2                    2             0                    0                     0        0
Site-B                                        2                   2              0                    0                     0        0

Number of configured sites:                     2
Number of registered sites:                     2
Sites with inconsistent registrations:          0
IPv4
Number of configured EID prefixes:            4
Number of registered EID prefixes:            4
LISP_R4_MP_MR#

That is a basic overview of LISP and how it works.  I will admit that I did not talk about LISP encapsulation within the communication between the RLOCs and such, but below is a diagram (from the IETF Draft) of the header packet for the communication.  Since we do need some tunnel headers, and they are prepended to the original packet, so one may need to be cautious of MTU issues.   If you want the details on that, I suggest you read the IETF document as it has all the information contained within it.


Configuration Files for the routers are below, I have tweaked some configs in this blog (Interface descriptions) that are not referenced in the config files below.  Besides that, these are the configs that are on these routers as I write this blog. I suggest your right-click and do Save As as they are all text files.
LISP_R1
LISP_R2
LISP_R3
LISP_R4
LISP_R5
LISP_R6

Create PDF    Send article as PDF   

 Powered by Max Banner Ads 
%d bloggers like this: