Using LISP for IPv6 tunnelling.
In this post I would like to show how its possible to use a fairly new protocol, LISP, to interconnect IPv6 islands over an IPv4 backbone/core network.
LISP stands for Locator ID Seperation Protocol. As the name suggest, its actually meant to decouple location from identity. This means it can be used for such cool things as mobility, being VM’s or a mobile data connection.
However another aspect of using LISP involves its tunneling mechanism. This is what I will be using in my example to provide the IPv6 islands the ability to communicate over the IPv4-only backbone.
There is alot of terminology involved with LISP, but i will only use some of them here for clarity. If you want to know more about LISP, a good place to start is http://lisp.cisco.com.
The topology i will be using is a modified version of one presented in a Cisco Live presentation called “BRKRST-3046 – Advanced LISP – Whats in it for me?”. I encourage you to view this as well for more information.
Here is the topology:
Some background information about the setup. Both Site 1 and Site 2 are using EIGRP as the IGP. Both IPv4 and IPv6 is being routed internally. A default route is created by R2, R3 and R6 in their respective sites.
The RIB on R1 for both IPv4 and IPv6:
R1#sh ip route eigrp | beg Gateway
Gateway of last resort is 172.16.10.3 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/2560000512] via 172.16.10.3, 1d00h, GigabitEthernet1.100
[170/2560000512] via 172.16.10.2, 1d00h, GigabitEthernet1.100
R1#sh ipv6 route eigrp
<snip>
EX ::/0 [170/2816]
via FE80::250:56FF:FEBE:675D, GigabitEthernet1.100
via FE80::250:56FF:FEBE:9215, GigabitEthernet1.100
And R7:
R7#sh ip ro eigrp | beg Gateway
Gateway of last resort is 172.16.20.6 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/2560000512] via 172.16.20.6, 1d00h, GigabitEthernet1.67
R7#sh ipv6 route eigrp
<snip>
EX ::/0 [170/2816]
via FE80::250:56FF:FEBE:D054, GigabitEthernet1.67
Now in order to get anywhere, we need to setup our LISP infrastructure. This means configuring R2, R3 and R6 as whats known as RLOC’s as well as configuring R5 as a mapping-server and map-resolver. A mapping server/resolver is where RLOC’s register what internal IP scopes they have in their sites. Its also where each RLOC asks for information on how to reach other sites. So obviously they are a very important part of our LISP setup. Here is the relevant configuration on R5:
router lisp site SITE1 authentication-key blah eid-prefix 153.16.1.1/32 eid-prefix 153.16.1.2/32 eid-prefix 172.16.10.0/24 accept-more-specifics eid-prefix 2001::1/128 eid-prefix 2001::2/128 eid-prefix 2001:100::/32 accept-more-specifics exit ! site SITE2 authentication-key blah eid-prefix 153.16.2.1/32 eid-prefix 172.16.20.0/24 eid-prefix 2001::7/128 eid-prefix 2001:67::/32 accept-more-specifics exit ! ipv4 map-server ipv4 map-resolver ipv6 map-server ipv6 map-resolver
On IOS-XE which is what im using to build this lab, all configuration is being done under the router LISP mode.
As can be seen from the configuration, two sites have been defined, SITE1 and SITE2.
An authentication key has been configured for each site. Furthermore, the prefixes that we want to accept from each site has also been configured. If our addressing scheme had been somewhat more thought out we could use the “accept-more-specifics” to accept more specific subnets, but this configuration serves our purpose.
Pay attention to the fact that we do this for each address-family. For our IPv6 example this is really not nessecary, but i wanted to provide both IPv4 and IPv6 connectivity, so i configured both.
Finally I’ve configured R5 as both a map-server and map-resolver for each address-family.
Next up is the configuration for R2:
R2#sh run | sec router lisp router lisp locator-set SITE1 10.1.1.1 priority 10 weight 50 10.1.2.1 priority 10 weight 50 exit ! database-mapping 153.16.1.1/32 locator-set SITE1 database-mapping 153.16.1.2/32 locator-set SITE1 database-mapping 172.16.10.0/24 locator-set SITE1 database-mapping 2001::1/128 locator-set SITE1 database-mapping 2001::2/128 locator-set SITE1 database-mapping 2001:100::/32 locator-set SITE1 ipv4 itr map-resolver 10.1.3.1 ipv4 itr ipv4 etr map-server 10.1.3.1 key blah ipv4 etr ipv6 itr map-resolver 10.1.3.1 ipv6 itr ipv6 etr map-server 10.1.3.1 key blah ipv6 etr
The first part of this configuration lists a “Locator-Set”. This is where you want to list each RLOC for the site in question. For our SITE1 we have 2 RLOC’s with IPv4 addresses in the IPv4 transport cloud being 10.1.1.1 and 10.1.2.1 respectively for R2 and R3.
One of the very cool things about LISP is how you can achieve redundancy and/or load-balancing signaled by the local RLOC’s. By modifying the priority of R3 (10.1.2.1) to 20, we have effectively told the other site(s) that we want to prefer R2 as the egress tunnel router (ETR), so all traffic would be sent to R2. However if we instead leave the priority to the same and modify the weight, we can load-balance traffic. Again this is signaled by the local site and replicated to the remote site(s).
Next up is our mappings. This is where we define which prefixes we want to use in this site. Here we have the loopbacks of R1 and the network used for connectivity in SITE 1. Both for IPv4 and IPv6. Again IPv4 is not nessecary for our example.
Finally, we define a map-resolver and map-server for both ITR (Ingress Tunnel Router) and ETR (Egress Tunnel Router). This is so we can define where we want to send our mapping data as well as where to ask for other ETR’s. We also define ourselves as ITR and ETR for both address-families.
The exact same configuration has been applied on R3:
R3#sh run | sec router lisp router lisp locator-set SITE1 10.1.1.1 priority 10 weight 50 10.1.2.1 priority 10 weight 50 exit ! database-mapping 153.16.1.1/32 locator-set SITE1 database-mapping 153.16.1.2/32 locator-set SITE1 database-mapping 172.16.10.0/24 locator-set SITE1 database-mapping 2001::1/128 locator-set SITE1 database-mapping 2001::2/128 locator-set SITE1 database-mapping 2001:100::/32 locator-set SITE1 ipv4 itr map-resolver 10.1.3.1 ipv4 itr ipv4 etr map-server 10.1.3.1 key blah ipv4 etr ipv6 itr map-resolver 10.1.3.1 ipv6 itr ipv6 etr map-server 10.1.3.1 key blah ipv6 etr
Now for some verification commands on R2:
R2#sh ip lisp
Instance ID: 0
Router-lisp ID: 0
Locator table: default
EID table: default
Ingress Tunnel Router (ITR): enabled
Egress Tunnel Router (ETR): enabled
Proxy-ITR Router (PITR): disabled
Proxy-ETR Router (PETR): disabled
NAT-traversal Router (NAT-RTR): disabled
Mobility First-Hop Router: disabled
Map Server (MS): disabled
Map Resolver (MR): disabled
Delegated Database Tree (DDT): disabled
Map-Request source: 10.1.1.1
ITR Map-Resolver(s): 10.1.3.1
ETR Map-Server(s): 10.1.3.1 (00:00:50)
xTR-ID: 0xA7F25A1D-0x982B7E10-0xDD2D66CC-0x436D28A5
site-ID: unspecified
ITR Solicit Map Request (SMR): accept and process
Max SMRs per map-cache entry: 8 more specifics
Multiple SMR suppression time: 20 secs
ETR accept mapping data: disabled, verify disabled
ETR map-cache TTL: 1d00h
Locator Status Algorithms:
RLOC-probe algorithm: disabled
LSB reports: process
IPv4 RLOC minimum mask length: /0
IPv6 RLOC minimum mask length: /0
Static mappings configured: 0
Map-cache size/limit: 1/1000
Imported route count/limit: 0/1000
Map-cache activity check period: 60 secs
Map-cache FIB updates: established
Total database mapping size: 3
static database size/limit: 3/5000
dynamic database size/limit: 0/1000
route-import database size: 0
Persistent map-cache: interval 01:00:00
Earliest next store: now
Location: bootflash:LISP-MapCache-IPv4-00000000-00100
Lots of output. But pay attention to the fact that both ITR and ETR has been enabled and ITR Map-Resolver(s) and ETR Map-Server(s) has been defined to 10.1.3.1 (R5).
We also want to verify our current map-cache which is the cache maintained by the RLOC’s for what it already “knows” about:
R2#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries ::/0, uptime: 00:00:01, expires: never, via static send map-request Negative cache entry, action: send-map-request
Basically this output tells you that we dont know about any specific networks from other sites just yet.
R6 is very similar to R2 and R3:
R6#sh run | sec router lisp router lisp locator-set SITE2 10.1.4.1 priority 10 weight 50 exit ! database-mapping 153.16.2.1/32 locator-set SITE2 database-mapping 172.16.20.0/24 locator-set SITE2 database-mapping 2001::7/128 locator-set SITE2 ipv4 itr map-resolver 10.1.3.1 ipv4 itr ipv4 etr map-server 10.1.3.1 key blah ipv4 etr ipv6 itr map-resolver 10.1.3.1 ipv6 itr ipv6 etr map-server 10.1.3.1 key blah ipv6 etr
And verification:
R6#sh ip lisp
Instance ID: 0
Router-lisp ID: 0
Locator table: default
EID table: default
Ingress Tunnel Router (ITR): enabled
Egress Tunnel Router (ETR): enabled
Proxy-ITR Router (PITR): disabled
Proxy-ETR Router (PETR): disabled
NAT-traversal Router (NAT-RTR): disabled
Mobility First-Hop Router: disabled
Map Server (MS): disabled
Map Resolver (MR): disabled
Delegated Database Tree (DDT): disabled
Map-Request source: 10.1.4.1
ITR Map-Resolver(s): 10.1.3.1
ETR Map-Server(s): 10.1.3.1 (00:00:38)
xTR-ID: 0xFABA5140-0x6AA2BA6A-0x5F347223-0xF7E0CED0
site-ID: unspecified
ITR Solicit Map Request (SMR): accept and process
Max SMRs per map-cache entry: 8 more specifics
Multiple SMR suppression time: 20 secs
ETR accept mapping data: disabled, verify disabled
ETR map-cache TTL: 1d00h
Locator Status Algorithms:
RLOC-probe algorithm: disabled
LSB reports: process
IPv4 RLOC minimum mask length: /0
IPv6 RLOC minimum mask length: /0
Static mappings configured: 0
Map-cache size/limit: 1/1000
Imported route count/limit: 0/1000
Map-cache activity check period: 60 secs
Map-cache FIB updates: established
Total database mapping size: 2
static database size/limit: 2/5000
dynamic database size/limit: 0/1000
route-import database size: 0
Persistent map-cache: interval 01:00:00
Earliest next store: now
Location: bootflash:LISP-MapCache-IPv4-00000000-00100
Along with the mapping-cache:
R6#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries ::/0, uptime: 00:00:04, expires: never, via static send map-request Negative cache entry, action: send-map-request
If we now try a ping from R1’s loopback0 to R7’s loopback0 we see the following:
R1#ping 2001::7 so loo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001::7, timeout is 2 seconds: Packet sent with a source address of 2001::1 ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 1/1/1 ms
What this tells us is that we have connectivity, but beyond that it also means that for the 2 first ICMP echo’s, location data is being retrieved. Lets now check the mapping-cache on R2:
R2#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:01:08, expires: never, via static send map-request Negative cache entry, action: send-map-request 2001::7/128, uptime: 00:00:07, expires: 23:59:52, via map-reply, complete Locator Uptime State Pri/Wgt 10.1.4.1 00:00:07 up 10/50
Here we see that 2001::7/128 is currently in the cache and in order to get there we need to tunnel our traffic to the RLOC at 10.1.4.1 (R6).
On the remote side we see something similar:
R6#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:01:53, expires: never, via static send map-request Negative cache entry, action: send-map-request 2001::1/128, uptime: 00:01:34, expires: 23:58:25, via map-reply, complete Locator Uptime State Pri/Wgt 10.1.1.1 00:01:34 up 10/50 10.1.2.1 00:01:34 up 10/50
This is the mapping that tells R6 that it can use both RLOC’s to send traffic to (They are both in the up state).
If we try a ping from R1 again:
R1#ping 2001::7 so loo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001::7, timeout is 2 seconds: Packet sent with a source address of 2001::1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/25 ms
We get full connectivity because the cache has already been populated.
Finally lets see what the packet capture looks like on R4:
R4#show monitor capture LISP buffer brief ------------------------------------------------------------- # size timestamp source destination protocol ------------------------------------------------------------- 0 154 0.000000 10.1.1.1 -> 10.1.4.1 UDP 1 154 0.000000 10.1.4.1 -> 10.1.1.1 UDP 2 154 0.001007 10.1.1.1 -> 10.1.4.1 UDP 3 154 0.001007 10.1.4.1 -> 10.1.1.1 UDP 4 154 0.001007 10.1.1.1 -> 10.1.4.1 UDP 5 154 0.001999 10.1.4.1 -> 10.1.1.1 UDP 6 154 0.003006 10.1.1.1 -> 10.1.4.1 UDP 7 154 0.016006 10.1.4.1 -> 10.1.1.1 UDP 8 154 0.025008 10.1.1.1 -> 10.1.4.1 UDP 9 154 0.038008 10.1.4.1 -> 10.1.1.1 UDP 10 162 2.282035 10.1.4.1 -> 10.1.3.1 UDP 11 162 2.282035 10.1.3.1 -> 10.1.4.1 UDP
(I used an EPC (Embedded Packet Capture) on R4 to get the data).
We clearly see that UDP traffic is flowing between R2 and R6.
So this tunneling characteristic is one way we can utilize LISP, but there are many other use cases as I mentioned before.
I hope this has been useful to you.
Until next time, take care!