11-14-2013 09:49 AM - edited 03-01-2019 04:59 PM
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:
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.
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?
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: