LISP 101

LISP 101:

***
Warning! This is a long post! I tend to be long winded anyway, but this one got a little lengthy… Its also “101” for a reason — its my first lab attempt with LISP so if I’ve got something wrong here, please let me know!
***

LISP has seemed to me to be a bit of a buzz word. Its been around a good while now, I’ve heard about it, I’ve read about it, and I guess that I have a basic handle on the general idea, but thats about it. Its seems to be pretty cool, however since customers (that I work with at least) aren’t deploying it, its just seemed to be this academic exercise rather than a “real” thing.

As I’ve got a bit of a pause in my CCIE Service Provider studies due to a short staff aug project away from home (and away from my precious CRS!) I guess now is a good time for me to get a better grasp on this crazy LISP contraption.

So before jumping into any configs and verification, lets talk about the 101 — the what and the why in my layman’s terms.

What is LISP: LISP is a protocol to help define a devices identity (on the Internet presumably), and furthermore to help that device maintain its identity as it moves about. This is the whole location/ID separation that LISP is talking about. So basically there are two main parts — an endpoint identifier, and a resource locator: EID, and RLOC. Endpoints (EID, hosts) are mapped to a public facing resource locator (RLOC). The Endpoint retains its identity even as it bounces about behind different RLOCs.

What the hell does that mean/what is it for: LISP has a few main use cases. It seems that at its genesis it was created simply as a means to help keep the default free zone (public Internet) routing table small. Obviously the Internet routing table is big, and its only been getting bigger, now add to that the IPv6 routing table, and the potential size of an IPv6 routing table when fully deployed, and things get a bit out of hand. LISP can help keep the size of the routing table down by “hiding” EIDs behind RLOCs — the default free zone now only has to contain routing information for the public facing RLOCs, and LISP takes care of locating the EIDs via the Map Server/Resolver function (which we will hit in the lab a bit). Thats pretty cool stuff.

LISP has also grown into being a quasi dynamic DNS service. Think about vMotion in an enterprise customer. Some flavor of DCI is used to stretch layer 2 across these two data centers, but somehow some way the rest of the wold needs to know that the server actually moved from DC1 to the DR site. Today this is often handled by something like an F5 GTM (or something similar) that updates DNS to point to the new server location — it knows about this because it has its “hooks” into the server environment. LISP can basically eliminate the need for these semi real-time DNS updates, because it already helps to map an EID to a RLOC, this is LISP VM-Mobility. The endpoint (EID) never changes but the physical location does — so the RLOC to reach the EID is all that needs to be updated!

Alright, now for some important terms:
EID: Endpoint Identifier; this is the actual host/vm/device.
RLOC: Resource Locator; basically a public facing interface that can be associated with one/multiple EIDs. The RLOC is basically the HOW you reach the EID.
ITR/ETR/xTR: These terms are a bit annoying since it seems to me that almost always you will just have “xTRs” or an ingress/egress tunnel router. Obviously ITR = ingress tunnel router and ETR = egress tunnel router. These are the routers that encapsulate and de-capsulate LISP traffic; they also perform “normal” IP forwarding to non-lisp networks.
MS: Map Server; is exactly what it sounds like. Its the server that contains the information for the LISP domain — the ETRs register the EIDs that they “own” to the Map Server.
MR: Map Resolver; this router receives map requests, and can send “negative” requests back if the request is for a non-LISP EID.
ALT: I’m not going to get into this yet, because I’m not entirely sure I know enough to say anything about it yet! My understanding is that its basically an overlay on the regular network that is intended to keep the EID topology organized… I’ll lab this up at a later date and try to figure it out a bit more!
PITR/PETR: I’ve not lab’d a topo with PITR/PETR just yet, and as such I’m not sure I can define these in my own words well enough (hopefully to come soon), so here is the definition straight from Cisco:

– PITR: A Proxy ITR provides connectivity between non-LISP sites and LISP sites by advertising coarse-aggregate prefixes for the LISP EID namespace into the Internet DFZ (RLOC namespace) and forwarding this non-LISP traffic to LISP sites.
– PETR: A Proxy ETR allows IPv6 LISP sites without native IPv6 RLOC connectivity to reach LISP sites that only have IPv6 RLOC connectivity. In addition, the PETR also allows LISP sites with Unicast Reverse Path Forwarding (URPF) restrictions to reach non-LISP sites.

Some nerd knobs to tweak:
Priority: Priority between RLOCs. Lower is “better.”
Weight: Similar to a GLBP type weight — presumably a weight for hashing packets/flows between multiple equal priority (cost) RLOCs. Not sure how to verify that LISP is actually spreading the love across multiple different weighted RLOCs. As we will see below, equal weight appears to be “working” but outside of that I’ve not seen how to verify that its doing what you’d expect it to do.

So now for some super basic example to see if this is actually doing what it says its doing. Here is our topology:

LISP Drawaing

And our basic setup….

On What I’m calling Customer 1 Edge 1:

interface l0
 description Endpoint ID (EID)
 ip address 192.168.1.1 255.255.255.0
 !
 interface f0/0
 description To Provider1 (RLOC)
 ip address 10.0.0.2 255.255.255.252
 !
 interface f0/1
 description To Provider2 (RLOC)
 ip address 10.0.0.10 255.255.255.252
 !
 interface f0/2
 description To Customer 1 Edge 2 (Internal/EID)
 ip address 192.168.2.2 255.255.255.0
 standby 2 ip 192.168.2.1
 standby 2 priority 110
 standby 2 preempt
 !
 router lisp
 database-mapping 192.168.1.0/24 10.0.0.2 priority 100 weight 100
 database-mapping 192.168.1.0/24 10.0.0.10 priority 100 weight 50
 database-mapping 192.168.2.0/24 10.0.0.2 priority 100 weight 100
 database-mapping 192.168.2.0/24 10.0.0.10 priority 50 weight 50
 ipv4 itr map-resolver 10.10.10.10
 ipv4 itr
 ipv4 etr map-server 10.10.10.10 key lispkey
 ipv4 etr
 !
 ip route 0.0.0.0 0.0.0.0 10.0.0.1
 ip route 0.0.0.0 0.0.0.0 10.0.0.9

Aaaannnnnd over on Customer 1 Edge 2:

interface l0
 description Endpoint ID (EID)
 ip address 192.168.1.2 255.255.255.0
 !
 interface f0/0
 description To Provider2 (RLOC)
 ip address 10.0.0.6 255.255.255.252
 !
 interface f0/1
 description To Customer 1 Edge 1 (Internal/EID)
 ip address 192.168.2.3 255.255.255.0
 standby 2 ip 192.168.2.1
 standby 2 priority 90
 standby 2 preempt
 !
 router lisp
 database-mapping 192.168.1.0/24 10.0.0.6 priority 150 weight 100
 database-mapping 192.168.2.0/24 10.0.0.6 priority 150 weight 100
 ipv4 itr map-resolver 10.10.10.10
 ipv4 itr
 ipv4 etr map-server 10.10.10.10 key lispkey
 ipv4 etr
 !
 ip route 0.0.0.0 0.0.0.0 10.0.0.5

From the above two configs and the drawing we can see that obviously there are two sites that are connected via some “back door” connection. The main site has two connections to two different “uplinks” of some flavor, and the second site has a single uplink. In the descriptions there are obviously some fancy LISP terms — EID and RLOC. The RLOCs are just the “public” facing interfaces, and the EIDs are the “endpoints” in this case being created by a loopback, and an interface on each side that is participating in some lovely HSRP.

Next we have another/different customer site participating in LISP which I’m calling Customer 9 (kinda random, but go with it):

interface l9
 description Endpoint ID (EID)
 ip address 192.168.9.1 255.255.255.0
 !
 interface f0/0
 description To Provider1 (RLOC)
 ip address 10.0.0.34 255.255.255.252
 !
 router lisp
 database-mapping 192.168.9.0/24 10.10.0.34 priority 1 weight 1
 ipv4 itr map-resolver 10.10.10.10
 ipv4 itr
 ipv4 etr map-server 10.10.10.10 key lispkey
 ipv4 etr
 !
 ip route 0.0.0.0 0.0.0.0 10.0.0.33

This is just another site living in the LISP bubble, it could be the same company, or another company that is participating in the LISP domain.

Lastly (since we won’t care about the “providers”) here is the gist of the Map Server / Map Resolver:

interface l0
 description MapServer/MapResolver
 ip address 10.10.10.10 255.255.255.255
 !
 router lisp
 site Cust_192.168.1.0/24
 authentication-key lispkey
 eid-prefix 192.168.1.0/24
 eid-prefix 192.168.2.0/24
 exit
 !
 site Cust9_192.168.9.0/24
 authentication-key lispkey
 eid-prefix 192.168.9.0/24
 exit
 !
 ipv4 map-server
 ipv4 map-resolver
 ipv4 alt-vrf lisp
 exit

Assuming that the RLOCs have reachability to the Map Resolver/Server (in our case via default routing, and the “ISPs” doing some fancy ISIS), some magic begins to happen. Lets first look at the routing table on Customer 1 Edge 1 to see what that looks like:

CE1#sh ip route
 Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 10.0.0.9 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.0.9
 [1/0] via 10.0.0.1
 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
 C 10.0.0.0/30 is directly connected, Ethernet0/0
 L 10.0.0.2/32 is directly connected, Ethernet0/0
 C 10.0.0.8/30 is directly connected, Ethernet0/1
 L 10.0.0.10/32 is directly connected, Ethernet0/1
 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
 C 192.168.1.0/24 is directly connected, Loopback0
 L 192.168.1.1/32 is directly connected, Loopback0
 192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
 C 192.168.2.0/24 is directly connected, Ethernet0/2
 L 192.168.2.2/32 is directly connected, Ethernet0/2

Nothing at all even a little bit exciting here… equal cost default routes out of its two paths to the providers, and local/connected stuff for everything else.

So, what happens when we try to ping 192.168.9.1 which has been advertised to the LISP Map Server via our “CE9” router, and similarly configured on the Map Server?

CE1#ping 192.168.9.1
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 192.168.9.1, timeout is 2 seconds:
 U.U.U
 Success rate is 0 percent (0/5)
 CE1#

Well… that didn’t work out as planned eh?? But lets take a step back and think about how this traffic would flow in this situation. First things first, we know we don’t have a route for this prefix, but we do have a default route. The default route is being learned via static, and is going out over our two “public” interfaces. So likely our source address is one of those two public interfaces, and the packet is getting punted out toward the “Internet,” only to be dropped at the “provider” since they surely don’t have a route for it. So, lets try and source the ping form an interface that we are “advertising” into the LISP domain:

CE1#ping 192.168.9.1 sou 192.168.1.1
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 192.168.9.1, timeout is 2 seconds:
 Packet sent with a source address of 192.168.1.1
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/11 ms
 CE1#

Well hey, that looks like it actually worked…. crazy eh?! So lets look at the route table yet again:

CE1#sh ip route
 Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 10.0.0.9 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.0.9
 [1/0] via 10.0.0.1
 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
 C 10.0.0.0/30 is directly connected, Ethernet0/0
 L 10.0.0.2/32 is directly connected, Ethernet0/0
 C 10.0.0.8/30 is directly connected, Ethernet0/1
 L 10.0.0.10/32 is directly connected, Ethernet0/1
 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
 C 192.168.1.0/24 is directly connected, Loopback0
 L 192.168.1.1/32 is directly connected, Loopback0
 192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
 C 192.168.2.0/24 is directly connected, Ethernet0/2
 L 192.168.2.2/32 is directly connected, Ethernet0/2

Same story huh? So how the hell did that work? Lets try and see what LISP thinks about that route:

CE1#sh ip lisp map-cache
 LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries
0.0.0.0/0, uptime: 02:10:21, expires: never, via static send map-request
 Negative cache entry, action: send-map-request
 192.168.9.0/24, uptime: 02:10:16, expires: 21:49:37, via map-reply, complete
 Locator Uptime State Pri/Wgt
 10.10.0.34 02:10:16 up 1/1

When we examine the LISP map-cache, we can see that we “know” about that 192.168.9.0 subnet. We can see the RLOC (locator column) that is advertising the LISP EID subnet. We also can see that it is “up,” the priority and weight. So kind of an interesting scenario here where we actually don’t really “know” about the route in the route table, but lets see what CEF thinks about this prefix:

CE1#sh ip cef 192.168.9.0 d
 192.168.9.0/24, epoch 0, flags subtree context, check lisp eligibility, default route
 SC owned: LISP remote EID - locator status bits 0x00000001
 LISP remote EID: 5 packets 430 bytes fwd action encap
 LISP source path list
 nexthop 10.10.0.34 LISP0
 2 IPL sources [active source]
 Dependent covered prefix type inherit cover 0.0.0.0/0
 recursive via 0.0.0.0/0
 recursive via 10.0.0.1
 attached to Ethernet0/0
 recursive via 10.0.0.9
 attached to Ethernet0/1
 CE1#

Whoa, kind of a lot of things happening there. Some key things — we see that we have two valid next hops, those are of course both of our “upstream” connections. We can also see “LISP” indicated a few times; we see that the remote EID is getting some packets sent at it, and there is a “fwd action encap.” So pretty cool stuff right? How about the other side of the connection? We know that we just have the default route, so lets look at the lisp map-cache and see what CEF thinks over there:

CE9#sh ip lisp map-cache
 LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries
0.0.0.0/0, uptime: 02:19:54, expires: never, via static send map-request
 Negative cache entry, action: send-map-request
 192.168.1.0/24, uptime: 02:19:49, expires: 21:40:03, via map-reply, complete
 Locator Uptime State Pri/Wgt
 10.0.0.2 02:19:49 up 100/100
 10.0.0.10 02:19:49 up 100/50
CE9#sh ip cef 192.168.1.0 d
 192.168.1.0/24, epoch 0, flags subtree context, check lisp eligibility, default route
 SC owned: LISP remote EID - locator status bits 0x00000003
 LISP remote EID: 5 packets 500 bytes fwd action encap
 LISP source path list
 nexthop 10.0.0.10 LISP0
 nexthop 10.0.0.2 LISP0
 2 IPL sources [active source]
 Dependent covered prefix type inherit cover 0.0.0.0/0
 recursive via 0.0.0.0/0
 recursive via 10.10.0.33
 attached to Ethernet0/0
 CE9#

So kinda the same stuff we are seeing on the other side. We can see the map-cache showing there we learned about the LISP prefix form the other site. We can see from this side that this prefix (192.168.1.0/24) is being advertised from two different RLOCs — 10.0.0.2 and 10.0.0.10, we also see the priorities and weights assigned to those RLOCs for that EID. In the CEF output we see the same stuff we would expect. This is the part where I’m not sure that I see how weight is working. Clearly we have the two next hops, but I don’t see how to verify how the packets/flows are distributed across the multiple paths. If this was EIGRP or BGP doing unequal cost I would normally look for the load share in the “show ip route X.X.X.X” output, but that gives us a big fat lot of nothing:

CE9#sh ip route 192.168.1.0
 % Network not in table

I won’t bother showing configurations of the priorities changing, you can take my word, or lab it for yourself that lower priorities win (even the context sensitive help spells that out nice and simply).

So last item before we wrap up this post — lets take a peak at how the Map Server sees the registration of the sites:

MapRelay-MapServer#sh lisp site
 LISP Site Registration Information
Site Name Last Up Who Last Inst EID Prefix
 Register Registered ID
 CE1_192.168.1. 00:00:58 yes 10.0.0.10 192.168.1.0/24
 00:00:58 yes 10.0.0.10 192.168.2.0/24
 CE9_192.168.9. 00:00:06 yes 10.10.0.34 192.168.9.0/24
 MapRelay-MapServer#

We can see the two sites, and the “Customer 1” site registering two EID prefixes up to the Map Server. Adding the “detail” syntax to this command provides some more output to help see whats going on here.

Thats all I want to include in this post as far as configs go, but before I wrap up I want to point out an issue that I ran into lab’ing this up that a quick search of my pal Google didn’t immediately turn up.

I ran into an issue where I was seeing everything kind of look right-ish, but pings were failing between my LISP EIDs across the sites. The Map Server showed the registration of the sites was A-OK, but I was seeing “drops” instead of “complete” in the map-cache entries on the xTR devices as shown here:

CE1#sh ip lisp map-cache
 LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries
0.0.0.0/0, uptime: 00:01:31, expires: never, via static send map-request
 Negative cache entry, action: send-map-request
 192.168.9.0/24, uptime: 00:01:27, expires: 00:00:18, via map-reply, drop
 Negative cache entry, action: drop
 CE1#

So what gives, and why does our pal Google not help? Well it turns out I shouldn’t drink while setting up things I’ve never done before. After looking at configs for like… a while… I realized that I had typed the incorrect RLOC IP on the database-mapping entry on the EID. Fix that, and POW! things started working as anticipated. Just figured I’d call that out since it was a simple easy mistake to make and the intertubes didn’t seem to point that out for me.

So to recap this whole adventure. LISP is cool. LISP can do some neato things (which we will hopefully cover more of later — particularly VM Mobility). LISP doesn’t appear to be getting the traction it maybe deserves in the real world. LISP could potentially “solve” the Internet routing table size creep, but again, only if its adoption rapidly speeds up. IF LISP adoption speeds up, the LISP database may get unruly… BUT its probably not too terrible of a deal since DNS seems to be coping just fine, and LISP actually is a more “locked down” controlled database that would presumably be less susceptible to DNS type vulnerabilities.

More to come with LISP in the hopefully near future… because I think its neat 😀

Advertisements

One thought on “LISP 101

  1. Hi, could you please clarify one thing: does general service provider route LISP packets by default or just drop it?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s