Lisp-Vm Mobility WP
Lisp-Vm Mobility WP
VM Mobility Solution
White Paper
NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT
ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR
THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION
PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO
LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of
UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE
PROVIDED "AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL
DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR
INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to
the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar,
Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified
Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without
Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone,
iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking
Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest
Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in
the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (0809R)
IP Mobility Overview
The increasing use of virtualization in the data center has enabled an unprecedented degree of
flexibility in managing servers and workloads. One important aspect of this newfound
flexibility is mobility. As workloads are hosted on virtual servers, they are decoupled from
the physical infrastructure and become mobile by definition.
As end-points become detached from the physical infrastructure and are mobile, the routing
infrastructure is challenged to evolve from a topology centric addressing model to a more
flexible architecture. This new architecture is capable of allowing IP addresses to freely and
efficiently move across the infrastructure.
There are several ways of adding mobility to the IP infrastructure, and each of them
addresses the problem with different degrees of effectiveness. LISP-VM mobility is poised to
provide a solution for mobility of Virtual Machines with optimal effectiveness. This
document describes the LISP-VM Mobility solution, contrasts it with other IP mobility
options, and provides specific guidance for deploying and configuring the LISP-VM mobility
solution.
IP Mobility Requirements
The requirements for an IP mobility solution can be generalized to a few key aspects. In
order to do a fair comparison of existing solutions and clearly understand the added benefit
of the LISP VM-mobility solution, we will quickly touch on the different aspects that must
be addressed in an IP mobility solution.
Redirection. The ultimate goal of IP mobility is to steer traffic to the valid location of the
end-point. This aspect is generally addressed by providing some sort of re-direction
mechanism to enhance the traffic steering already provided by basic routing. Redirection can
be achieved by replacing the destination address with a surrogate address that is
representative of the new location of the end-point. Different techniques will allow the
redirection of traffic either by replacing the destination’s address altogether or by leveraging
a level of indirection in the addressing such as that achieved with tunnels and encapsulations.
The different approaches impact applications to different degrees. The ultimate goal of IP
mobility is to provide a solution that is totally transparent to the applications and allows for
the preservation of established sessions, as end-points move around the IP infrastructure.
Scalability. Most techniques create a significant amount of granular state in order to re-direct
traffic effectively. The state is necessary to correlate destination IP addresses to specific
locations, either by means of mapping or translation. This additional state must be handled in
a very efficient manner in order to attain a solution that can support a deployable scale at a
reasonable cost in terms of memory and processing.
Mobile IPv4
Mobile IP is defined for IPv4 in IETF RFC 3344. Basically mobile IPv4 provides a
mechanism to redirect traffic to a mobile node whenever this node moves from its “Home
Network” to a “Foreign Network.” Every host will have a “Home Address” within a “Home
Network” which is front-ended by a router that acts as a “Home Agent” and that advertises
the “Home Network” into the routing protocol. Traffic destined to the “Home Address” will
always be routed to the “Home Agent.” If the mobile node is in its “Home Network” traffic
Mobile IPv6
IETF RFC 3775 defines mobility support in IPv6. IPv6 takes a step beyond IPv4 mobility
and provides optimal data paths between server and client. The process in IPv6 is similar to
that of IPv4 with a few additions.
Rather than having the Home Agent always redirect the traffic to the Care-of-Address (CoA)
for the server that has moved, the Home Agent is taken out of the data path by distributing
the CoA to Home Address Binding information to the client itself. Once the client has the
CoA information for a particular server, it can send traffic directly to the CoA rather than
triangulating it through the Home Address. This provides a direct path from client to server.
Although Mobile IPv6 provides direct path routing for mobile nodes, it is limited to IPv6
enabled end-points, it requires that the entire data path be IPv6 enabled, and it also requires
that the end-points have IPv6 mobility agents installed on them.
Note Customer Edge (CE) devices typically implement ITR and ETR functions at the same
time. When this is the case, the device is referred to as an xTR.
LISP VM-Mobility detects moves by comparing the source in the IP header of traffic
received from a host against a range of prefixes that are allowed to roam. These prefixes are
defined as Dynamic-EIDs in the LISP VM-Mobility solution.
These different deployment scenarios address a variety of business needs, including, but not
limited to:
• Improved Application Availability
• Streamlined Disaster Recovery procedures
• Flexible outsourcing options
• Maximized resource utilization
• Flexible change management
This document discusses both of these modes in detail, and provides configuration steps for
each of the LISP network elements.
Note: Only the F1 series line cards support proxy mode at the time of writing this
document.
• Proxy mode is not supported between M-series cards, so the site facing interfaces can
only be N7K-M132XP-12, N7K-M132XP-12L or F-series linecards.
• Traffic received on M-series linecards other than the M132XP-12 cards will not be
processed by LISP. Therefore combining M132XP-12 cards with other M-series
cards in a LISP enabled VDC will result in two different types of traffic processing
depending on which interface receives the traffic. In deployments where other M-
series cards (N7K-M148GT-11, N7K-M148GT-11L, N7K-M148GS-11, N7K-
M148GS-11L or N7K-M108X2-12L) are part of the same VDC with the F1 and M1-
32 cards, it is critical to ensure that traffic received on any F1 interfaces is internally
sent only to interfaces belonging to M1-32 cards. The "hardware proxy layer-3
forwarding use interface" command can be leveraged to list only these specific
interfaces to be used for proxy-routing purpose.
More details around the differences between these two deployments are described in detail in
the following sections of this paper, specifically when describing the configuration specifics
for each model.
Note: In the scenarios explored in this document, we will focus on having both the Map
Server as well as the Map Resolver functionality collocated in the same network
device. We will also focus on a simple use case that does not require a distributed
Mapping database. Redundancy of the mapping database will be discussed and is not
to be confused with the distribution of the mapping database.
Note: For large scale LISP deployments, the Mapping database can be distributed and
MS/MR functionality dispersed onto different nodes. The distribution of the mapping
database can be achieved in many different ways, LISP-ALT is one example, but there
are many proposals that may be used. Large scale LISP deployments using distributed
mapping databases are not discussed in this document.
The co-located model shown above is particularly advantageous as it reduces the overall
number of managed devices required to roll out a LISP VM-Mobility solution. Notice that
the required configuration in both scenario would remain identical, leveraging unique IP
addresses to identify the Map-Servers and an anycast IP address for the Map-Resolver.
Configuration Steps
1. configure terminal
2. feature lisp
3. ip lisp itr-etr
4. ip lisp database‐mapping EID‐prefix/prefix‐length locator_ip priority priority weight
weight
5. ip lisp etr map‐server map‐server‐address key key‐type authentication‐key
6. ip lisp itr map-resolver <map-resolver-address>
7. exit
Configuration Steps
1. configure terminal
2. lisp dynamic-eid <dynamic-eid-map-name>
3. database-mapping EID‐prefix/prefix‐length locator_ip priority priority weight weight
4. map-notify-group <multicast-group-ip>
5. map-server map‐server‐address key key‐type authentication‐key ( Optional in case to
register Dynamic-EID to a specific Map-Server other than configured in the Global LISP
configuration. If not configured, LISP uses the Map-Server configured in the Global
configuration).
6. exit
7. interface <interface-name>
8. lisp mobility <dynamic-eid-map-name>
9. lisp extended-subnet-mode
10. exit
Configuration Steps
1. configuration terminal
2. router lisp
3. ipv4 itr
4. ipv4 etr
5. database‐mapping EID‐prefix/prefix‐length locator_ip priority priority weight weight
6. ipv4 etr map‐server map‐server‐address key authentication‐key
7. ipv4 lisp itr map-resolver <map-resolver-address>
8. exit
Step 7 ipv4 lisp itr map-resolver Configures the IP address of the LISP
<map-resolver-address> Map‐Resolver to which this router, acting as
an IPv4 LISP ITR, will send lisp map-request
for destination EIDs.
Configuration Steps
1. configure terminal
2. feature lisp
3. ip lisp map-server
4. ip lisp map-resolver
5. lisp site site‐name
6. description
7. authentication-key key‐type password
8. eid-prefix {EID‐prefix } accept-more-specifics
9. exit
Step 2 feature lisp Enables the LISP feature set (if not already
configured). Cisco NX-OS only. To obtain a
grace period for lab experiments on LISP,
please use “license grace-period”. See the
NX-OS Licensing Guide section entitled
Licensing Cisco NX-OS Software Features.
Step 5 lisp site site‐name Creates the indicated LISP site and enters
LISP site configuration mode.
Step 6 description description Enters a description for the LISP site being
configured.
Step 8 eid-prefix {EID‐prefix } accept- Enters the EID‐prefix for which the LISP site
more-specifics being configured is authoritative, and
configures to accept more specific prefixes in
case of dynamic-eid-map configurations in the
ETR.
Note: If the ETR is configured with a
dynamic-eid-map with a prefix to roam, that
prefix should be configured in the Map-Server
with this command.
feature lisp
ip lisp itr-etr
ip lisp database-mapping 10.3.0.0/16 192.168.13.2 priority 1 weight 25
ip lisp database-mapping 10.3.0.0/16 192.168.13.6 priority 1 weight 25
ip lisp database-mapping 10.3.0.0/16 192.168.23.2 priority 1 weight 25
ip lisp database-mapping 10.3.0.0/16 192.168.23.6 priority 1 weight 25
ip lisp itr map-resolver 10.111.10.14
ip lisp etr map-server 10.111.10.14 key 0 cisco
!
lisp dynamic-eid LISP_EXTENDED_SUBNET
database-mapping 10.3.3.0/25 192.168.13.2 priority 1 weight 50
database-mapping 10.3.3.0/25 192.168.13.6 priority 1 weight 50
map-notify-group 239.1.1.2
!
interface Vlan904
ip address 10.3.3.3/24
lisp mobility LISP_EXTENDED_SUBNET
lisp extended-subnet-mode
hsrp 100
priority 190
ip 10.3.3.1
Since in Extended Subnet mode there is a single LISP site spanning between separate DC
locations, each xTR device is configured identically for what concerns the global “ip lisp
database-mapping” configuration, and the RLOCs of all the xTRs belonging to the same
LISP site must be listed.
Note: It is worth pointing out how East and West LISP XTR configurations are almost
identical. The only difference is the IP address of SVI 904.
feature lisp
ip lisp itr-etr
ip lisp database-mapping 10.3.0.0/16 192.168.13.2 priority 1 weight 25
ip lisp database-mapping 10.3.0.0/16 192.168.13.6 priority 1 weight 25
ip lisp database-mapping 10.3.0.0/16 192.168.23.2 priority 1 weight 25
ip lisp database-mapping 10.3.0.0/16 192.168.23.6 priority 1 weight 25
ip lisp itr map-resolver 10.111.10.14
ip lisp etr map-server 10.111.10.14 key 0 cisco
!
lisp dynamic-eid LISP_EXTENDED_SUBNET
router lisp
database-mapping 10.4.4.0/25 192.168.214.1 priority 1 weight 100
ipv4 itr map-resolver 10.111.10.14
ipv4 itr
ipv4 etr map-server 10.111.10.14 key cisco
ipv4 etr
feature lisp
!
ip lisp map-resolver
ip lisp map-server
!
lisp site BRANCH
eid-prefix 10.4.4.0/25
authentication-key 0 cisco
!
lisp site DATA_CENTER
eid-prefix 10.3.0.0/16 accept-more-specifics
authentication-key 0 cisco
Please note that fourth field in the output above would change periodically based on the
periodic registrations from xTR devices belonging to the same LISP site. Also, the output for
dynamic-EID prefix 10.3.0.0/16 highlights the existence of a more specific prefix
(10.3.0.0/16-1), associated to an endpoint that has been dynamically discovered (specific
information for this are shown at Step 3 below).
Step 2: To view site specific EID registration status use “show lisp site <site-name>”.
Step 3: In LISP VM-Mobility within an Extended Subnet use case, a dynamic-EID is always
detected by the xTRs available in the specific DC site where the EID belongs to (or it is
migrated to). This is so the remote sites can send packets to the VM’s current location. Use
“show lisp dynamic-eid summary “ to verify that the DC-xTR has detected the VM in its
current location. The VM1 is currently in West DC-xTR, so it is detected by one of the two
West DC xTRs (the one receiving the first data plane packet from the EID).
Step 4: The Nexus 7000 DC-xTR which detected the VM will notify the dynamic-EID to all
the other DC-xTRs belonging to the same LISP site via Map-Notify message using the
multicast group configured. Use “show lisp dynamic-eid summary” on the second DC-xTR
located in the West DC site:
Note the * next to the dynamic-EID prefix which indicates this was learned via the Map-
Notify mechanism. It is important to notice how only the peer xTR device belonging to the
same West DC site will show the information above. The two xTRs belonging to the same
LISP site but part of the East DC site will receive the EID discovery notification and
internally record this information.
Important: in Extended Subnet mode, the Map-Notify messages are exchanged by
leveraging the OTV logical connection between DC sites. This is important in order to avoid
the requirement of having a multicast enabled transport infrastructure between the different
DC sites. For more information on how to configure OTV data-group to carry multicast
traffic across OTV, please refer to the paper below:
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns949/ns304/ns975/OT
V_intro_wp.pdf
Step 2: Use “show ip lisp map-cache” to verify the remote site EID prefix is cached with its
corresponding RLOC IP.
BR-3825-E-R214#
Note the current location of dynamic-EID 10.3.3.101/32 is in the West Data Center. Refer to
the IP address from Figure 5-3 above.
When the traffic flow uses LISP routing, the final traffic path, mapping database and map-
caches in various xTRs look as shown in Figure 5-4 below.
Once the move is completed, verify in East DC_xTR that VM1 is detected, by using the
following steps.
Step 1: Use “show lisp dynamic-eid summary” to see if VM1 has been detected in East DC
XTR.
Also, it is possible to verify that the xTRs in the West DC site removed the dynamic-ID
entry, as a result of the reception of the Map-Notify multicast message via OTV.
As depicted in output below, dynamic-EID entries are removed in the West DC xTRs.
Step 3: Verify in the Map-Server that the VM1 dynamic-EID locators are updated using
show lisp site <dyn-eid-prefix>.
BR-3825-E-R214#
Verify from the network diagram above to confirm that the locators are updated to reflect the
current VM locations.
The final traffic path would look as shown in Figure 5-8.
Figure 5-8 Final Traffic Path
Configuration Steps
1. configure terminal
2. feature lisp
3. ip lisp itr-etr
4. ip lisp database-mapping EID‐prefix/prefix‐length locator_ip priority priority weight
weight
5. ip lisp etr map-server map‐server‐address key key‐type authentication‐key
6. ip lisp itr map-resolver <map-resolver-address>
7. exit
Step 3 ip lisp itr-etr Enables LISP ITR and ETR functionality for
the IPv4 address family.
Configuration Steps
1. configure terminal
2. lisp dynamic-eid <dynamic-eid-map-name>
3. database-mapping EID‐prefix/prefix‐length locator_ip priority priority weight weight
4. map-notify-group <multicast-group-ip> (Required in case of multi-homing. Optional
otherwise)
5. map-server map‐server‐address key key‐type authentication‐key ( Optional in case to
register Dynamic-EID to a specific Map-Server other than configured in the Global LISP
configuration. If not configured, LISP uses the Map-Server configured in the Global
configuration).
6. exit
7. interface <interface-name>
8. lisp mobility <dynamic-eid-map-name>
9. ip proxy-arp
10. exit
Configuration Steps
1. configuration terminal
2. router lisp
3. ipv4 itr
4. ipv4 etr
5. database-mapping EID‐prefix/prefix‐length locator_ip priority priority weight weight
6. ipv4 etr map-server map‐server‐address key authentication‐key
7. ipv4 lisp itr map-resolver <map-resolver-address>
8. exit
Step 2 router lisp Enables and enters into the router lisp
configuration mode.
Step 3 ipv4 lisp itr Enables LISP ITR functionality for the IPv4
address family.
Step 3 ipv4 lisp etr Enables LISP ETR functionality for the IPv4
address family.
Step 6 ipv4 lisp itr map-resolver Configures the IP address of the LISP
<map-resolver-address> Map‐Resolver to which this router, acting as
an IPv4 LISP ITR, will send lisp map-requests
for destination EID`s.
Configuration Steps
1. configure terminal
2. feature lisp
3. ip lisp map‐server
4. ip lisp map-resolver
5. lisp site site‐name
6. description description
7. authentication‐key key‐type password
8. eid-prefix {EID‐prefix } accept-more-specifics
9. exit
Step 6 description description Enters a description for the LISP site being
configured.
Step 8 eid-prefix {EID‐prefix } Enters the EID‐prefix for which the LISP site
accept-more-specifics being configured is authoritative and
configures the site to accept more specific
optional – in case of dynamic-
prefixes in case of dynamic-EID-map
eid configured on the ETR
configurations in the ETR.
Note: If the ETR is configured with a
dynamic-EID-map with a prefix to roam, that
prefix should be configured in the Map-Server
using this command.
feature lisp
ip lisp itr-etr
ip lisp database-mapping 10.1.1.0/24 192.168.13.2 priority 1 weight 50
ip lisp database-mapping 10.1.1.0/24 192.168.13.6 priority 1 weight 50
ip lisp itr map-resolver 10.111.10.14
ip lisp etr map-server 10.111.10.14 key 0 cisco
lisp dynamic-eid LISP_ACROSS_SUBNET
database-mapping 10.1.1.0/24 192.168.13.2 priority 1 weight 50
database-mapping 10.1.1.0/24 192.168.13.6 priority 1 weight 50
map-notify-group 239.1.1.11
interface Vlan907
ip address 10.1.1.2/24
lisp mobility LISP_ACROSS_SUBNET
ip proxy-arp
hsrp 17
mac-address 0000.0E1D.010C
preempt delay minimum 300
priority 200
ip 10.1.1.1
feature lisp
ip lisp itr-etr
ip lisp database-mapping 10.1.1.0/24 192.168.13.2 priority 1 weight 50
ip lisp database-mapping 10.1.1.0/24 192.168.13.6 priority 2 weight 50
ip lisp itr map-resolver 10.111.10.14
ip lisp etr map-server 10.111.10.14 key 0 cisco
lisp dynamic-eid LISP_ACROSS_SUBNET
database-mapping 10.1.1.0/24 192.168.13.2 priority 1 weight 50
database-mapping 10.1.1.0/24 192.168.13.6 priority 1 weight 50
map-notify-group 239.1.1.11
interface Vlan907
ip address 10.1.1.3/24
lisp mobility LISP_ACROSS_SUBNET
ip proxy-arp
hsrp 17
mac-address 0000.0E1D.010C
priority 190
ip 10.1.1.1
Since in this setup the Nexus 7000 switches are multi-homed, both RLOC IP addresses are
required to be configured identically in all the xTRs belonging to the same LISP/DC site.
Notice also that in the example above the same priority and weight were configured for each
defined RLOC (default behavior). If desired, it is possible to modify these parameters when
the goal is not to load-balance incoming LISP traffic from other xTRs.
feature lisp
ip lisp itr-etr
ip lisp database-mapping 10.2.2.0/24 192.168.23.2 priority 1 weight 50
ip lisp database-mapping 10.2.2.0/24 192.168.23.6 priority 1 weight 50
ip lisp itr map-resolver 10.111.10.14
ip lisp etr map-server 10.111.10.14 key 0 cisco
!
lisp dynamic-eid LISP_ACROSS_SUBNET
database-mapping 10.1.1.0/24 192.168.23.2 priority 1 weight 50
database-mapping 10.1.1.0/24 192.168.23.6 priority 1 weight 50
map-notify-group 239.1.1.12
!
interface Vlan908
ip address 10.2.2.2/24
lisp mobility LISP_ACROSS_SUBNET
ip proxy-arp
hsrp 17
mac-address 0000.0E1D.010C
priority 200
preempt delay minimum 300
ip 10.2.2.1
feature lisp
ip lisp itr-etr
ip lisp database-mapping 10.2.2.0/24 192.168.23.2 priority 1 weight 50
ip lisp database-mapping 10.2.2.0/24 192.168.23.6 priority 1 weight 50
ip lisp itr map-resolver 10.111.10.14
ip lisp etr map-server 10.111.10.14 key 0 cisco
!
lisp dynamic-eid LISP_ACROSS_SUBNET
database-mapping 10.1.1.0/24 192.168.23.2 priority 1 weight 50
database-mapping 10.1.1.0/24 192.168.23.6 priority 1 weight 50
map-notify-group 239.1.1.12
!
interface Vlan908
ip address 10.2.2.3/24
lisp mobility LISP_ACROSS_SUBNET
ip proxy-arp
hsrp 17
mac-address 0000.0E1D.010C
priority 190
ip 10.2.2.1
router lisp
database-mapping 10.4.4.0/24 192.168.214.1 priority 1 weight 100
ipv4 itr map-resolver 10.111.10.14
ipv4 itr
ipv4 etr map-server 10.111.10.14 key cisco
ipv4 etr
feature lisp
ip lisp map-resolver
ip lisp map-server
lisp site BRANCH
eid-prefix 10.4.4.0/24
authentication-key 0 cisco
lisp site DATA_CENTER
eid-prefix 10.1.1.0/24 accept-more-specifics
eid-prefix 10.2.2.0/24
authentication-key 0 cisco
MB1-CORE-LISP-MS1#
Note that in the above example, since DC-xTRs are multi-homed, they will register both
RLOC IP addresses for their EID spaces. Also note that dynamic-EID prefix 10.1.1.0/24 is
registered by the West DC xTR (192.168.13.6), whereas 10.2.2.0/24 is registered by the East
DC xTR (192.168.23.6). VM1 with IP address 10.1.1.65 is initially in the West data center,
so there is no more specific EID mapping registered by the West DC-xTR (hence the “-0” in
the output above). This is a different behavior when compared to the Extended Subnet mode,
where a /32 EID was always detected and registered independently from the specific DC
location.
Step 2: To view site specific EID registration status use show lisp site <site-name>.
Step 2: Use show ip lisp map-cache to verify the remote site EID prefix is cached with its
corresponding RLOC IP.
Step 2: Use show ip lisp map-cache to verify the remote site EID prefix is cached with its
corresponding RLOC IP.
Note the current location of dynamic-EID 10.1.1.0/24 is at West Data Center. Also, the
VM11 10.1.1.65 is in the original West site currently, so there is no more specific EID
mapping registered by the West DC-xTR. Hence the remote xTR relies on the 10.1.1.0/24
prefix to get to the VM1. Refer to the IP address from the previous network diagrams.
When traffic flows are established using LISP routing, the final traffic path, mapping
database and map-caches in various xTRs look as shown below.
Once the move is completed, verify in East DC xTR that the VM11 move is detected
dynamically using the following steps.
Step 1: Use show lisp dynamic-eid summary to see if VM1 is detected in East DC XTR.
The Map-Notify message is now exchanged only between the two xTR devices belonging to
the same DC site.
Step 3: Verify in the Map-Server that the VM11 dynamic-EID locators are updated using
show lisp site <dyn-eid-prefix>.
Once the Map-Server receives the registration for the /32 EID from the xTR device located in
East DC, it communicates this information to the xTRs in West DC that originally registered
the /24 prefix. This is critical in order to ensure that both xTRs in West DC are aware that the
specific /32 workload has been moved to the East side.
Step 4: Since traffic flowing between VM1 and Remote site Host 1 was originally
exchanged between the remote LISP device and one of the West DC xTRs, it is also required
to refresh the information in the map cache of the remote LISP device. Similarly to what was
discussed in Extended Subnet mode, this refresh is triggered by a Solicit Map Request
(SMR) message originated by the West xTR once it receives the first packet destined to
VM11 IP address. This is because, as mentioned above, the West xTRs have been notified by
the Map Server that the workload has been discovered in the East DC site. Therefore, after
the remote LISP device pulls updated information from the Map Server, the traffic path is
finally directed to the East Data Center. Use show ip lisp map-cache in the remote xTR to
verify the map cache update.
Verify from the previous network diagram that the locators are updated to reflect the current
VM1 location.
A new entry, 10.1.1.65/32, is added to the map-cache with its current location. Also note that
there is still a 10.1.1.0/24 map-cache present, and this will be used to send traffic to other
unmoved hosts in West Data Center. The final traffic path would look as shown below.
Figure 6-8 LISP VM-Mobility Extended Subnet Final Traffic Path