Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

IPv6 Migration example using LISP

I am going to demonstrate an easiest IPv6 migration using Location Identity Separation Protocol (LISP). LISP works by separating IP address from its location in network. This IP address(es) at LISP site is called Endpoint ID (EID) and its location which is also an IP address is called Routing Locator (RLOC). Cisco has built a LISP beta network which is a mapping database which holds all EID to RLOC mapping. LISP router registers its RLOC address with EID space to a map server (MS). Whenever LISP router receives a packet from this EID space it tries to queries Map Resolver (MR) to get EID to RLOC mapping. Once this mapping information is available it will start encapsulating packets to destination EID RLOC address. Note that this tunnel is not static but instead it is dynamic tunnel based of destination RLOC address. Router that does encapsulation is Egress Tunnel Router (ETR) and router that does de-capsulation is called Ingress Tunnel Router (ITR). Normally both functionalities are implemented on same router, in such case, it is called xTR.

Note that a LISP site can only accept LISP encapsulated traffic from internet for EID space. If LISP site needs to talk to non LISP site, it requires another router which can accept a LISP encapsulated packet and sends to destination using regular IP forwarding, it is called Proxy Ingress Tunnel Router (PITR). Same way, router that accepts non LISP packets and encapsulates to a LISP site towards ITR is called PETR. Normally both functionalities are implemented on same router, in such case, it is called PxTR. Proxy routers does not registers EID space to mapping database but it advertizes EID space/prefix into routing domain (internet).

LISP specification allows tunnelling of IPv6 packets over IPv4 network between two IPv4 RLOC addresses. This can be used to provider IPv6 connectivity and mobility. The underlying application does not aware of this encapsulation.

What I am doing in following example is providing IPv6 internet connectivity for IPv6 only server sitting in IPv4 only cloud using Cisco Cloud services router (CSR).

Diagram:

CSR-1000v.jpg

Consider above diagram. We have a CSR router, with Gig3 interface is connected to VXLAN segment 5002 which is IPv6 only LAN and it provides default gateway and DHCPv6 functionalities to servers in this LAN segment. Servers in this LAN segment can use SLAAC to get IPv6 address and DHCPv6 to get DNSv6 info Gig1 interface is connected to External LAN which has public IPv4 address and it can talk to IPv4 only network. Cisco has created a beta network to test LISP. I got an IPv6 prefix from this beta network to test LISP functionality for IPv6 migration use case. I assigned 2001:DB8:1142:B::1/64 to Gig3. Lets see the configuration.

Configuration:

!

interface GigabitEthernet1

! RLOC address

description outside interface facing IPv4 internet

ip address 66.xxx.xxx.126 255.255.255.240

no ip unreachables

negotiation auto

!

interface GigabitEthernet3

description LISP EID space

ip tcp adjust-mss 1380 ! Adjust the TCP MSS to accomodate LISP encapsulation overhead.

negotiation auto

ipv6 address 2610:D0:1142:B::1/64

ipv6 enable

ipv6 mtu 1400

ipv6 nd other-config-flag  ! to signal End server to get DNS info issue a DHCPv6 request

ipv6 nd router-preference High

ipv6 dhcp server DNS_SERVER_POOL

!

! Supply DNS information of Google DNS.

ip name-server 2001:4860:4860::8888

ip name-server 2001:4860:4860::8844

ip domain lookup source-interface GigabitEthernet3

ipv6 general-prefix LISP_EID 2610:D0:1142:B::/64

ipv6 unicast-routing

ipv6 dhcp pool DNS_SERVER_POOL

dns-server 2001:4860:4860::8888

dns-server 2001:4860:4860::8844

domain-name foo.com

ip route 0.0.0.0 0.0.0.0 66.xxx.xxx.113

Now so far we have only seen regular IPv6 configuration etc. Following is LISP config which will glue IPv4 and IPv6 network.

router lisp

locator-set TOR01

! We choose interface because if IP address of RLOC changes you do not need to update this info.

  IPv4-interface GigabitEthernet1 priority 1 weight 100

! alternativly you can specify which IP address to use for RLOC

  66.xxx.xxx.126 priority 1 weight 100

  exit

!

eid-table default instance-id 0

  database-mapping 2610:D0:1142::/48 locator-set TOR01

  loc-reach-algorithm rloc-probing

  exit

! Proxy router pXTR given by LISP beta network

ipv6 use-petr 69.31.31.98 priority 1 weight 50

ipv6 use-petr 129.250.1.63 priority 1 weight 50

no ipv6 map-cache-persistent

! Map resolver where EID will be registered to. This should be reachable all the time

ipv6 itr map-resolver 69.31.31.98

ipv6 itr map-resolver 129.250.1.63

ipv6 itr map-resolver 173.36.254.164

ipv6 itr map-resolver 206.223.132.89

! define router as ITR

ipv6 itr

! map server to find out EID to RLOC mapping when encapsulating using LISP

ipv6 etr map-server 69.31.31.98 key *****

ipv6 etr map-server 129.250.1.63 key *****

ipv6 etr map-server 173.36.254.164 key *****

ipv6 etr map-server 206.223.132.89 key *****

! defines router as ETR

ipv6 etr

exit

Verification:

Now so far we have only seen regular IPv6 configuration etc. Following is LISP config which will glue IPv4 and IPv6 network.

CSR1000v-test#lig self ipv6

Mapping information for EID 2610:D0:1142:: from 66.xxx.xxx.126 with RTT 103 msecs

2610:D0:1142::/48, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete

  Locator         Uptime    State      Pri/Wgt

  66.xxx.xxx.126  00:00:00  up, self     1/100

Ping to LISP site

CSR1000v-test#ping ipv6 www.lisp6.net source gig 3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2610:D0:1304::11, timeout is 2 seconds:

Packet sent with a source address of 2610:D0:1142:B::1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/69 ms

Ping to Non LISP site.

CSR1000v-test#ping ipv6 www.google.com source gig 3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2607:F8B0:4006:802::1010, timeout is 2 seconds:

Packet sent with a source address of 2610:D0:1142:B::1

..!!!

Success rate is 60 percent (3/5), round-trip min/avg/max = 128/128/129 ms

Note that you will see few pings loss initially because it takes few seconds to get mapping information but this is just first time only. Router will cache the maping information on memory for subsequent packets.

CSR1000v-test#sh ipv6 lisp map-cache detail

LISP IPv6 Mapping Cache for EID-table default (IID 0), 4 entries

::/0, uptime: 00:06:04, expires: never, via static send map-request

  Sources: static send map-request

  State: send-map-request, last modified: 00:06:04, map-source: local

  Idle, Packets out: 2 (~ 00:00:03 ago)

  Configured as EID address space

  Negative cache entry, action: send-map-request

2606::/15, uptime: 00:00:41, expires: 00:14:18, via map-reply, forward-native

  Sources: map-reply

  State: forward-native, last modified: 00:00:41, map-source: 173.36.254.164

  Active, Packets out: 8 (~ 00:00:03 ago)

  Encapsulating to proxy ETR

2610:D0:1142::/48, uptime: 00:03:42, expires: 23:58:15, via map-reply, self, complete

  Sources: map-reply

  State: complete, last modified: 00:03:42, map-source: 66.xxx.xxx.126

  Idle, Packets out: 0

  Locator         Uptime    State      Pri/Wgt

  66.xxx.xxx.126  00:03:42  up, self     1/100

    Last up-down state change:         00:03:42, state change count: 1

    Last route reachability change:    00:03:42, state change count: 1

    Last priority / weight change:     never/never

    RLOC-probing loc-status algorithm:

      Last RLOC-probe sent:            00:01:44 (rtt 0ms)

      Next RLOC-probe in:              00:00:07

      Latched to ITR-RLOC:             66.xxx.xxx.126

2610:D0:1304::/48, uptime: 00:02:39, expires: 23:59:19, via map-reply, complete

  Sources: map-reply

  State: complete, last modified: 00:02:39, map-source: 173.36.254.162

  Active, Packets out: 32 (~ 00:00:03 ago)

  Locator         Uptime    State      Pri/Wgt

  173.36.254.162  00:02:39  up           1/50

    Last up-down state change:         00:02:39, state change count: 1

    Last route reachability change:    never, state change count: 0

    Last priority / weight change:     never/never

    RLOC-probing loc-status algorithm:

      Last RLOC-probe sent:            00:00:40 (rtt 69ms)

      Next RLOC-probe in:              00:00:18

      Latched to ITR-RLOC:             66.xxx.xxx.126

  173.36.254.177  00:02:39  up           1/50

    Last up-down state change:         00:02:39, state change count: 1

    Last route reachability change:    never, state change count: 0

    Last priority / weight change:     never/never

    RLOC-probing loc-status algorithm:

      Last RLOC-probe sent:            00:00:42 (rtt 70ms)

      Next RLOC-probe in:              00:00:16

      Latched to ITR-RLOC:             66.xxx.xxx.126

As you can see When pinging to google.com router does not get mapping information for it so it will start encapsulating to PxTR. But when ping to lisp6.cisco.com which is a lisp site we got two RLOC address to encapsulate to. Router chooses one of this RLOC address based to criteria like weight and start encapsulating packets towards it.

Conclusion:

LISP follows a network-based map-and-encapsulate scheme which is very flexible in IPv6 transition use case. In above example if interface gig 1 IP address changes LISP will register EID with new RLOC and everything continue to work. You can take snapshot of this vApp with this CSR and then run it in different cloud provider with different RLOC, without changing IP addresses on each end systems.

Version history
Revision #:
1 of 1
Last update:
‎11-14-2013 09:49 AM
Updated by:
 
Comments
New Member

If you are using LISP with a Proxy xTR (use-petr) what considerations needs to be done in regards of MTU and TCP MSS?

In my case for example i need IPv6 Proxy xTR to obtain native ipv6 access over an IPv4 access , and i use IPv4 Proxy xTR in order to maintain symmetric traffic flows (address space advertised from the proxy not from the xTR router where the end subnets resides)

I find here that ipv6 MTU is adjusted to 1400 on the EID interface. Why? if the RLOC is an ipv4 interface, shouldn't we account just for 36 bytes ?

also, while IPv6 MTU is advertised to the hosts via RA, is not the case for IPv4. I don't think is a solution to set the mtu manually on every device within my subnet.

thoughts? ideas?

Bronze

TCP MSS should be 20 bytes less than inner IP MTU. All LISP packets are sent with DF=1 in the outer IP header.

LISP reacts to PMTUD on a per-destination locator basis means if it receives ICMP packet too big message it will lower down MTU. 

It might be possible that proxy xTR you are using it self has 1400 bytes set on its locator IPv4 address.