Cisco Locator ID Separation Protocol (LISP)

Lessons Discussion
21

Hello Samir

Yes, that is the case. It works similar to the Route Distinguisher (RD) for MPLS VPN as mentioned in the lesson.

Yes it has to be because within the map request, you have the EID which is the IP address, and if that is in a range that overlaps, you need the instance ID to make the addresses unique.

As mentioned in the link you shared, the instance ID is bound to the associated VRF much in the same way as MPLS VPN operates. As you can see however from the size of the document you shared, the implementation is much more involved and complex, but this is the basic underlying principle involved.

I hope this has been helpful!

Laz

22

Hi Laz,

Yes it has, thanks.

One more question: Does Cisco’s SD-WAN use LISP or traditional routing?

Thanks,

Sam

23

Hello Samir

Cisco’s SD-WAN solutions deliver a complete SD-WAN fabric as a WAN overlay to interconnect campuses, branches, data centers, and cloud applications. It uses a multitude of protocols including traditional routing, but it can also leverage LISP. At Cisco Live Europe in January 2020, a Cisco engineer did a talk called Cisco LISP Optimized Software Defined Networks. If you do a search for this, you should find the related video content.

I hope this has been helpful!

Laz

24

Hi,

Okay thanks. I’ll take a look, although sounds a little too in depth for ENCOR.

Another question…

I understand how LISP works if each site is on a different subnet. And I can follow packet walks in both the LISP and VXLAN in the lessons. But I have also been reading about LISP and VXLAN, and how it is used by SD-Access.

So if, as per an SD-Access environment, the same subnet exist at multiple edge nodes/LISP sites, and you have two endpoints on the same site, how does the edge node (iTR) handle it? Because it shouldn’t need to send a MAP-REQUEST. Or does it?

eg.

  1. LISP site 1 and LISP site 2 are on the same subnet. And Host A and Host B are on LISP site 1.
  2. Host A sends an ARP request for Host B’s MAC, but as it is on the same site, ARP will behave as per normal and Host B will respond directly.

However, the edge node/iTR also receives the ARP request. so what happens then? Does it ignore it? And if so how does it know to do that? Or does it still forward a MAP-REQUEST to the Map Resolver, just in case the endpoint has roamed to a different site?

Thanks again for the help,

Sam

25

Hello Samir

LISP does indeed support overlapping subnets, however, within the LAN of the LISP site, regular routing and switching take place. This means that the ITR doesn’t do anything with an ARP that is meant for a host on the same subnet. The host will need to send something to the default gateway which is the ITR before the ITR can do anything with it, and send it to another LISP site.

Something that is helpful concerning overlapping subnets can be found in this is found at this Cisco documentation, on page 1, where it says:

Because IP-based connectivity within each Layer 3 overlay is an abstraction from the physical connectivity, multiple IP networks can be a part of each virtual network. In multi-tenant style deployments where you relinquish control of the addressing for each tenant’s Layer 3 overlay, you likely have to allow for some nonunique IP address space appearing in more than one overlay. You can support the overlapping IP address space requirement by preserving the traffic separation beyond the fabric border using typical virtualization techniques—including adding devices to remediate addressing conflicts (typically using network address translation) and provisioning to enable communication with permitted common external IP services such as DNS and the Internet.

So in order to make overlapping address spaces work in a LISP configuration, you must make the appropriate adjustments within the local LAN such as NAT…

I hope this has been helpful!

Laz

26

Hi Laz,

Thanks very much, it has been helpful.

Sam

1 Like
27

Hi,
Can you please explain to me this part of the lisp lesson im confused ?

Is there an entry that matches 192.168.2.102? If so:
Use regular IP routing.
If not, we use LISP encapsulation if any of the following three checks is true:
We have a default route.
We don’t have a route
We have a route with Null0 as the next-hop.
Is the source IP a registered EID-prefix in the local map-cache?
If not, forward the packet with regular IP routing.
If so, the ITR:
Selects a UDP source port.
Sets the UDP destination port to 4342.
Sends an encapsulated Map-Request to the MR for 192.168.2.102.

question
192.168.2.102 Do I check the destination and then the source IP address? I wonder if you check both processes.

Even if there is a destination for 192.168.2.102 in the FIB table, is the source IP address checked?

28

I believe both conditions must be met. I also almost have the same question. When he mentions “use regular ip routing” im guessing he means the routing table and forward as we would normally, if not use the LISP method by sending a MR/MS.

My Question is, when the route is learned through the MR/MS process and installed in FIB, do i now route normally or does it still go through the MR/MS process again?

29

Hello @masters4 ,

With any of these “does this happen and/or in what order” kinda questions, it’s best to look at a debug. For example, these two debug commands for LISP:

  • debug lisp control-plane all
  • debug lisp detail

When I send a ping from H1 to H2, you see this on ITR1:

XTR1#                      
*Oct  4 15:00:36.878: LISP-0: AF IID 0 IPv4, 192.168.2.102 does not match configured dyn-EID groups.
*Oct  4 15:00:36.879: LISP: FWD message queue event.
*Oct  4 15:00:36.880: LISP: Processing data signal for EID prefix IID 0 192.168.2.102/32
*Oct  4 15:00:36.880: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Created (sources: <>, state: unknown, rlocs: 0).
*Oct  4 15:00:36.880: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Added source transient (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:36.880: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Schedule forwarding table update (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:36.881: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Source transient has no async callback (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:36.881: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, forwarding data signal for 192.168.2.102 (local EID 192.168.1.101) (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:36.881: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Change state to incomplete (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:36.881: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Schedule forwarding table update, on queue (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:36.882: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, [incomplete] Scheduling map requests delay 00:00:00 min_elapsed 00:00:01 (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:36.882: LISP-0: Map Request IID 0 prefix 192.168.2.102/32 remote EID prefix[LL], Starting request timer with delay of 00:00:00.
*Oct  4 15:00:36.882: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Placing on idle queue (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:36.882: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Schedule expiration timer at 00:01:00 (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:36.882: LISP: Processed 1 global IPC messages.
*Oct  4 15:00:36.883: LISP-0: AF IID 0 IPv4, Checkpointed 1 remote EID entries.
*Oct  4 15:00:36.883: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Update forwarding state (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:36.885: LISP-0: AF IID 0 IPv4, Updated 1 remote EID entries in forwarding table.
*Oct  4 15:00:37.014: LISP: Timer event (map request).
*Oct  4 15:00:37.014: LISP-0: AF IID 0 IPv4, Local map request source address not cached, using dest.
*Oct  4 15:00:37.014: LISP-0: Map Request IID 0 prefix 192.168.2.102/32 remote EID prefix[LL], Queueing remote EID prefix map request on IPv4 queue (1/4).
*Oct  4 15:00:37.015: LISP-0: IID 0 Request processing of remote EID prefix map requests to IPv4.
*Oct  4 15:00:37.015: LISP: Send map request type remote EID prefix
*Oct  4 15:00:37.015: LISP: Send map request for EID prefix IID 0 192.168.2.102/32
*Oct  4 15:00:37.016: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Send map request (1) (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:37.016: LISP-0: AF IID 0 IPv4, Local map request source address not cached, using dest.
*Oct  4 15:00:37.016: LISP: TOPO default IPv4, Route locator 192.168.123.3 resolved via /24 pfx, src 192.168.123.1 nh 192.168.123.3 if GigabitEthernet0/1 (state: UP).
*Oct  4 15:00:37.016: LISP-0: Added mapping record locator 192.168.123.1 (priority 10, weight 10, local, reachable).
*Oct  4 15:00:37.017: LISP-0: Built mapping. Prefix = 192.168.1.0/24, #locators = 1, TTL = 1440, action = none.
*Oct  4 15:00:37.017: LISP-0: EID-AF IPv4, Sending map-request from 192.168.2.102 to 192.168.2.102 for EID 192.168.2.102/32, ITR-RLOCs 1, nonce 0x9FE013E1-0x15CA7DBD (encap src 192.168.123.1, dst 192.168.123.3).
*Oct  4 15:00:37.017: LISP: IPv4, Sending control packet out of GigabitEthernet0/1 with next hop 192.168.123.3.
*Oct  4 15:00:37.017: LISP: Set initial min output if hold queue size to 40 (intf GigabitEthernet0/1).
*Oct  4 15:00:37.020: LISP-0: Map Request IID 0 prefix 192.168.2.102/32 remote EID prefix[LL], Starting request timer with delay of 00:00:01.
*Oct  4 15:00:37.020: LISP-0: Processed 1 map requests.
*Oct  4 15:00:38.106: LISP: Timer event (map request).
*Oct  4 15:00:38.106: LISP-0: AF IID 0 IPv4, Local map request source address not cached, using dest.
*Oct  4 15:00:38.106: LISP-0: Map Request IID 0 prefix 192.168.2.102/32 remote EID prefix[LL], Queueing remote EID prefix map request on IPv4 queue (2/4).
*Oct  4 15:00:38.107: LISP-0: IID 0 Request processing of remote EID prefix map requests to IPv4.
*Oct  4 15:00:38.107: LISP: Send map request type remote EID prefix
*Oct  4 15:00:38.107: LISP: Send map request for EID prefix IID 0 192.168.2.102/32
*Oct  4 15:00:38.107: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Send map request (2) (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:38.107: LISP-0: AF IID 0 IPv4, Local map request source address not cached, using dest.
*Oct  4 15:00:38.108: LISP: TOPO default IPv4, Route locator 192.168.123.3 resolved via /24 pfx, src 192.168.123.1 nh 192.168.123.3 if GigabitEthernet0/1 (state: UP).
*Oct  4 15:00:38.108: LISP-0: Added mapping record locator 192.168.123.1 (priority 10, weight 10, local, reachable).
*Oct  4 15:00:38.108: LISP-0: Built mapping. Prefix = 192.168.1.0/24, #locators = 1, TTL = 1440, action = none.
*Oct  4 15:00:38.108: LISP-0: EID-AF IPv4, Sending map-request from 192.168.2.102 to 192.168.2.102 for EID 192.168.2.102/32, ITR-RLOCs 1, nonce 0x9FE013E1-0x15CA7DBD (encap src 192.168.123.1, dst 192.168.123.3).
*Oct  4 15:00:38.109: LISP: IPv4, Sending control packet out of GigabitEthernet0/1 with next hop 192.168.123.3.
*Oct  4 15:00:38.109: LISP: Set initial min output if hold queue size to 40 (intf GigabitEthernet0/1).
*Oct  4 15:00:38.110: LISP-0: Map Request IID 0 prefix 192.168.2.102/32 remote EID prefix[LL], Starting request timer with delay of 00:00:02.
*Oct  4 15:00:38.110: LISP-0: Processed 1 map requests.
*Oct  4 15:00:38.119: LISP: Net receive queuing packet for LISP process.
*Oct  4 15:00:38.120: LISP-0: Received packet datagramsize 68, encsize 0, size 68.
*Oct  4 15:00:38.120: LISP: Processing received Map-Reply(2) message on GigabitEthernet0/1 from 192.168.123.2:4342 to 192.168.123.1:4342
*Oct  4 15:00:38.120: LISP: Received map reply nonce 0x9FE013E1-0x15CA7DBD, records 1
*Oct  4 15:00:38.121: LISP: Parsing mapping record for EID prefix IID 0 192.168.2.0/24
*Oct  4 15:00:38.121: LISP-0: Mapping Record has 1 locators (action none).
*Oct  4 15:00:38.121: LISP: Processing Map-Reply mapping record for IID 0 192.168.2.0/24, ttl 1440, action none, authoritative, 1 locator
        192.168.123.2 pri/wei=10/10 LpR
*Oct  4 15:00:38.121: LISP-0: Map Request IID 0 prefix 192.168.2.102/32 remote EID prefix[LL], Received reply with rtt 12ms.
*Oct  4 15:00:38.122: LISP: Processing mapping information for EID prefix IID 0 192.168.2.0/24
*Oct  4 15:00:38.122: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Created (sources: <>, state: unknown, rlocs: 0).
*Oct  4 15:00:38.122: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Added source transient (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:38.122: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Schedule forwarding table update (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:38.122: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Source transient has no async callback (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:38.123: LISP-0: AF IID 0 IPv4, Persistent db: ignore writing request, disabled.
*Oct  4 15:00:38.123: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Change state to complete (sources: , state: unknown, rlocs: 0).
*Oct  4 15:00:38.123: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Schedule forwarding table update, on queue (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.123: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Starting idle timer (delay 00:02:30) (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.124: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Placing on active queue (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.124: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Deleting more specific incomplete entries (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.124: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Removing source transient (sources: , state: incomplete, rlocs: 0).
*Oct  4 15:00:38.124: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Change state to deleted (sources: <>, state: incomplete, rlocs: 0).
*Oct  4 15:00:38.124: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Schedule forwarding table update (sources: <>, state: deleted, rlocs: 0).
*Oct  4 15:00:38.125: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Schedule forwarding table update, on queue (sources: <>, state: deleted, rlocs: 0).
*Oct  4 15:00:38.125: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Skip entry (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.125: LISP-0: Remote shrRLOC 192.168.123.2, Schedule update of dependent rrloc_set_elems.
*Oct  4 15:00:38.125: LISP: RIB Watch Group default 192.168.123.2/32 , created.
*Oct  4 15:00:38.126: LISP: RIB Watch Group default 192.168.123.2/32 , scheduling RIB update.
*Oct  4 15:00:38.126: LISP-0: Remote shrRLOC 192.168.123.2, Created.
*Oct  4 15:00:38.126: LISP-0: Remote RLOCset 0xD0BF678 1 RLOCs, Created
        192.168.123.2 pri/wei=10/10.
*Oct  4 15:00:38.126: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Changing RLOC set 0x0 -> 0xD0BF678 (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.126: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, RLOCs pending rwatch update, defer fwd update (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.126: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, 1 RLOCs pending rwatch update, defer fwd update (sources: , state: complete, rlocs: 0).
*Oct  4 15:00:38.127: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Change RLOC set elem NULL -> [RRLOCset 0xD0BF678 1/1] 192.168.123.2 pri/wei=10/10 (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.127: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24 [RRLOCset 0xD0BF678 1/1] 192.168.123.2 pri/wei=10/10, No probe local R (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.127: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24 [RRLOCset 0xD0BF678 1/1] 192.168.123.2 pri/wei=10/10, [none] Setting locator last reported state to up, was unknown (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.127: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24 [RRLOCset 0xD0BF678 1/1] 192.168.123.2 pri/wei=10/10, Setting locator reported state to up (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.128: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Recalculated RLOC status bits from 0x0 to 0x1 (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.128: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, 1 RLOCs pending rwatch update, defer fwd update (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.128: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24 [RRLOCset 0xD0BF678 1/1] 192.168.123.2 pri/wei=10/10, Created (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.128: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Schedule expiration timer at 23:59:52 (+refresh) (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.129: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Map-reply from 192.168.123.2 returned less specific 192.168.2.0/24 (sources: <>, state: deleted, rlocs: 0).
*Oct  4 15:00:38.129: LISP: Processed 1 control packets.
*Oct  4 15:00:38.129: LISP-0: AF IID 0 IPv4, Checkpointed 2 remote EID entries.
*Oct  4 15:00:38.129: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Remove from forwarding (sources: <>, state: deleted, rlocs: 0).
*Oct  4 15:00:38.130: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, Delete (sources: <>, state: deleted, rlocs: 0).
*Oct  4 15:00:38.131: LISP-0: AF IID 0 IPv4, Updated 1 remote EID entries in forwarding table.
*Oct  4 15:00:38.131: LISP: RIB Watch Group default 192.168.123.2/32 , installing in RIB.
*Oct  4 15:00:38.132: LISP: Route watch OS notification.
*Oct  4 15:00:38.132: LISP: TOPO default IPv4, Updated 1 watch groups in RIB done (state: UP).
*Oct  4 15:00:38.132: LISP: RIB Next-hop default GigabitEthernet0/1 192.168.123.2 lcl UNSPEC, created.
*Oct  4 15:00:38.132: LISP: RIB Next-hop default GigabitEthernet0/1 192.168.123.2 lcl 192.168.123.1, notified.
*Oct  4 15:00:38.132: LISP: Processed 1 RIB watch group OS notifications.
*Oct  4 15:00:38.133: LISP: Processed 1 next-hop watch-group notifications.
*Oct  4 15:00:38.133: LISP-0: Remote shrRLOC 192.168.123.2, Schedule update of dependent rrloc_set_elems.
*Oct  4 15:00:38.133: LISP-0: Remote shrRLOC 192.168.123.2, Reachability notification, up* allow* remote.
*Oct  4 15:00:38.133: LISP-0: Remote shrRLOC 192.168.123.2, Schedule update of all dependent rrloc.
*Oct  4 15:00:38.133: LISP-0: Remote shrRLOC 192.168.123.2, Schedule update of dependent rrloc_set_elems.
*Oct  4 15:00:38.134: LISP-0: Remote shrRLOC 192.168.123.2, Next-hop interface address changed.
*Oct  4 15:00:38.134: LISP: Processed 1 RIB watch notifications.
*Oct  4 15:00:38.134: LISP-0: Remote RLOCset elem [RRLOCset 0xD0BF678 1/1] 192.168.123.2 pri/wei=10/10, Updating from shared RLOC.
*Oct  4 15:00:38.134: LISP-0: Remote RLOCset 0xD0BF678 1 RLOCs, Schedule update
        192.168.123.2 pri/wei=10/10.
*Oct  4 15:00:38.134: LISP-0: Remote RLOCset 0xD0BF678 1 RLOCs, Schedule update
        192.168.123.2 pri/wei=10/10.
*Oct  4 15:00:38.135: LISP-0: Updated 1 remote RLOC set elements.
*Oct  4 15:00:38.135: LISP-0: Updated 1 dependent RLOCs.
*Oct  4 15:00:38.135: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, No more RLOCs pending rwatch update, schedule deferred fwd update (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.135: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Schedule forwarding table update (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.136: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Schedule forwarding table update, on queue (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.136: LISP-0: Updated 1 remote RLOC EID prefixes from RLOC set.
*Oct  4 15:00:38.136: LISP-0: AF IID 0 IPv4, Checkpointed 1 remote EID entries.
*Oct  4 15:00:38.136: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Update forwarding state (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.136: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Changing best usable locator priority from 255 to 10 (sources: , state: complete, rlocs: 1).
*Oct  4 15:00:38.142: LISP-0: AF IID 0 IPv4, Updated 1 remote EID entries in forwarding table.
*Oct  4 15:00:42.034: LISP: Net receive queuing packet for LISP process.
*Oct  4 15:00:42.034: LISP-0: Received packet datagramsize 120, encsize 0, size 120.
*Oct  4 15:00:42.035: LISP: Processing received Encap-Control(8) message on GigabitEthernet0/1 from 192.168.123.3:4342 to 192.168.123.1:4342
*Oct  4 15:00:42.035: LISP-0: decapsulating LISP control packet.
*Oct  4 15:00:42.035: LISP: Processing received Map-Request(1) message on GigabitEthernet0/1 from 192.168.1.101:4342 to 192.168.1.101:4342
*Oct  4 15:00:42.035: LISP: Allocating map request parsing buffer for 1 prefixes.
*Oct  4 15:00:42.036: LISP-0: Map request record parse, EID prefix 192.168.1.101/32.
*Oct  4 15:00:42.036: LISP: Received map request for IID 0 192.168.1.101/32, source_eid IID 0 192.168.2.102, ITR-RLOCs: 192.168.123.2, records 1, nonce 0x72D96C94-0x06EB3997
*Oct  4 15:00:42.036: LISP: Parsing mapping record for EID prefix IID 0 192.168.2.0/24
*Oct  4 15:00:42.036: LISP-0: Mapping Record has 1 locators (action none).
*Oct  4 15:00:42.036: LISP: Processing map request record for EID prefix IID 0 192.168.1.101/32
*Oct  4 15:00:42.037: LISP: TOPO default IPv4, Route locator 192.168.123.2 resolved via /24 pfx, src 192.168.123.1 nh 192.168.123.2 if GigabitEthernet0/1 (state: UP).
*Oct  4 15:00:42.037: LISP-0: Added mapping record locator 192.168.123.1 (priority 10, weight 10, local, reachable).
*Oct  4 15:00:42.037: LISP-0: Built mapping. Prefix = 192.168.1.0/24, #locators = 1, TTL = 1440, action = none.
*Oct  4 15:00:42.038: LISP-0: Sending map-reply from 192.168.123.1 to 192.168.123.2.
*Oct  4 15:00:42.038: LISP: IPv4, Sending control packet out of GigabitEthernet0/1 with next hop 192.168.123.2.
*Oct  4 15:00:42.038: LISP: Set initial min output if hold queue size to 40 (intf GigabitEthernet0/1).
*Oct  4 15:00:42.039: LISP: Processing mapping information for EID prefix IID 0 192.168.2.0/24
*Oct  4 15:00:42.039: LISP-0: AF IID 0 IPv4, Not configured to accept unsolicited mapping.
*Oct  4 15:00:42.040: LISP: Processed 1 control packets.
*Oct  4 15:01:00.926: LISP: Timer event (AF remote EID activity).
*Oct  4 15:01:00.926: LISP-0: AF IID 0 IPv4, Remote EID prefix activity check timer fired.
*Oct  4 15:01:00.926: LISP-0: Remote EID IID 0 prefix 0.0.0.0/0, Data out activity (0 -> 1) (sources: , state: send-map-request, rlocs: 0).
*Oct  4 15:01:00.927: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Data out activity (0 -> 3) (sources: , state: complete, rlocs: 1).
*Oct  4 15:01:00.927: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Resetting idle timer (delay 00:02:30) (sources: , state: complete, rlocs: 1).
*Oct  4 15:01:00.927: LISP-0: Remote EID IID 0 prefix 192.168.2.0/24, Placing on active queue (sources: , state: complete, rlocs: 1).
*Oct  4 15:01:00.927: LISP-0: AF IID 0 IPv4, Updated activity of 2 remote EID entries.

In the first few lines, it’s working on the destination. There is a mention about the source in line 8:

*Oct  4 15:00:36.881: LISP-0: Remote EID IID 0 prefix 192.168.2.102/32, forwarding data signal for 192.168.2.102 (local EID 192.168.1.101) (sources: , state: unknown, rlocs: 0).

If I add an entry in the FIB, it won’t do anything with LISP. Here’s an example:

XTR1(config)#ip route 192.168.2.0 255.255.255.0 GigabitEthernet 0/2

When you send a ping from H1 to H2 you see this:

*Oct  4 15:17:29.425: LISP-0: AF IID 0 IPv4, 192.168.2.102 does not match configured dyn-EID groups.
*Oct  4 15:17:33.411: LISP-0: AF IID 0 IPv4, 192.168.2.102 does not match configured dyn-EID groups.
*Oct  4 15:17:35.419: LISP-0: AF IID 0 IPv4, 192.168.2.102 does not match configured dyn-EID groups.
*Oct  4 15:17:37.419: LISP-0: AF IID 0 IPv4, 192.168.2.102 does not match configured dyn-EID groups.

I hope this helps!

Rene

2 Likes
30

Hello Eric

Within an ITR, there is the FIB which deals with “regular” IP routing, and there is the local map-cache that stores registered EID-prefixes.

When a route is learned through normal IP routing means, it is placed in the FIB. When it is learned via LISP using the MR/MS process, it is placed in the map-cache.

Therefore, if any route is learned through the MR/MS process, it will be placed in the map-cache, so the scenario you describe won’t happen. In any case, if an ITR receives an IP packet from H1 to a destination in the map-cache that has already been learned via the MR/MS process, this process is not repeated, since the information is already cached within the local ITR.

I hope this has been helpful!

Laz

31

Hello. First time to comment on the forum. I have a question regarding Cisco’s explanation of LISP in terms of routing architecture. The ENCORE book states, “LISP separates IP addresses into endpoint identifiers (EIDs) and routing locators (RLOCs). This way, end points can roam from site to site, and the only thing that changes is their RLOC; the EID remains the same.” (ENCORE p.466). My question is this: if an endpoint roams to another site, won’t it receive a new IP address thereby changing the EID? And if that EID is mapped to the same RLOC, it would seem that the EID is changing and not the RLOC. Perhaps my assumptions are incorrect. Any help/clarification on this would be helpful! Thanks!

32

Hello Joshua

You bring up a good point. When a host moves from one site to another, the IP address of the host itself must be dealt with in order to ensure that the same host can be reached in the same way using LISP, even though it has physically moved.

There are two fundamental ways that such a situation can be configured. These two options are called:

The first involves physically extending the subnet to a different site using OTV, VPLS, or other LAN extension technologies. In this way, when a host moves, it can maintain the same IP address, thus the problem of changing IP addresses is eliminated.

The second solution allows a host to be migrated to a remote IP subnet while retaining its original IP address.

To see a general overview of these two options, take a look at this Cisco documentation that describes these two use cases. For more information about each option, click on the links shared above that will direct you to Cisco documentation that explains how these options are configured in detail.

I hope this has been helpful!

Laz

1 Like
33

Laz,

I’m definitely going to check out both of those options you mentioned! Thanks for the info!

1 Like
34

So I’m trying to wrap my head around how the EID/RLOCK mapping works. Say two companies are using the same private address space, say 192.168.0.0/24. If I tried to reach someone in that address space, how would the MS know to which EID-TO-RLOCK mapping I was trying to reach?

Best regards
//Christian

35

Hello Christian

LISP does not solve the “problem” of overlapping subnets at multiple sites. For all of your LISP sites, you must ensure that IP addressing is unique.

However, in some scenarios, such as in a multi-tenant deployment where each tenant is responsible for their own IP addressing, there must be some provisioning for overlapping subnets. In this case, overlapping IP address spaces can be achieved by preserving the traffic separation beyond the fabric border and by employing NAT.

More info about this can be found here:

I hope this has been helpful!

Laz

36

HI Lazaros

Thank you for the explanation, that makes it much clearer

Christian

1 Like
37

First, It seems like LISP sites would have both ITR and ETR services. It makes sense that EIDs in other LISP sites would be populated in the LISP local map cache. How does the EID 192.168.1.0/24 get into the ITRs LISP local map cache? When an EID is behind an ITR is it automatically installed in the local map cache? Is there functionality that would prevent an EID from installed in a the LISP local map cache because you intend for that specific prefix to use regular IP routing?

38

Hello Justin

Yes, that is the case. You can either have a separate ITR and ETR device for each LISP site, or you can have what is known as a Tunnel Router (xTR) which performs both functions. For a particular direction of traffic, a router at a LISP site will function as either an ITR (outbound) or an ETR (inbound). It is the direction of traffic, and more specifically the encapsulation or decapsulation process that determines an ITR or ETR.

How does an EID get into the ITR’s LISP local map-cache? Well, the process is described in detail in the Map-Request and Map-Reply section of the lesson. This section explains how an ITR will request mapping information from an MS/MR, and the MS/MR will request it from an ETR. But where does the information originate?

Mapping information for LISP is configured in the ETR using the LISP database-mapping command. This command is typically configured on the CPE at the LISP site. The ETR contains this information and provides it to the MS/MR whenever a map request is received. That way the MS/MR populates its database, and in turn, the ITR will also populate its database based on the destination information it has requested over time. You can find out more information about this command here.

Using this command you can then choose what prefixes internal to your LISP site will be shared and reachable via LISP, and which will not be.

I hope this has been helpful!

Laz

39

Very nice Lesson! Thanks!
Out of curiosity: I guess the LISP mechanism adds some delay, is it something we have to worry about in a large production network? thanks

40

Hello Giacomo

The amount of delay introduced by LISP is comparable to the amount of delay added by using DNS instead of the IP address to reach a web site. Initially, your PC will communicate with a DNS server to gain the IP address of the desired destination. However, because the DNS cache keeps a list of mappings locally, all subsequent requests to that web site will have no delay.

Similarly, with LISP, the initial delay comes from the initial querying of the MS/MR to find the EID to RLOC mapping of the intended destination. This information is then saved within the ITR, so all future communications to the same location can take place without any additional lookups.

From these examples, you can see that the delay introduced by LISP is negligible and doesn’t need to be considered in a large production network.

I hope this has been helpful!

Laz

1 Like