Remote Client Communicating to EID before & After Mobility Event

Remote Client Communication to EID before Mobility Event

Below Figure shows the routing table on DC xTRs, on West DC there is no change in routing table, however in East Dc there is Null0 route for 10.11.11.0/24 routes installed. The reason is given below:

West Dc represents home site for 10.11.11.0/24 which is mobile subnet. And the only routes present in local xTR is /24 subnet, this can cause two immediate consequences:

XTR at local West DC will not dynamically discover workloads that are connected locally to West Site and source IP traffic in the northbound direction (as instead happens in extended subnet). But when the workload will be moved back to original site, then workload will be dynamically discovered and temporarily registered in local dynamic-eid table and with Map-Server.

Traffic when originated from remote site destined to network 10.11.11.0/24 will be sent to West DC by LISP, it will be decapsulated and routed directly to locally attached EID subnet. In this Host mobility across subnet implementation the basic principal is: communication to work load belonging to mobile subnet and connected to home site can be established even though EID prefix is not discovered dynamically

Remote Client Communication to EID after Mobility Event:

Below figure shows events to move a work load from West DC to East DC and How LISP EID updates are done on MS and on DCs XTRS.

• Let’s suppose workload 10.11.11.11/32 is moved from West DC to East DC on 10.12.12.0/24 subnet. The Moved VM retains its IP address and MAC address and sources an IP packet which reaches to xTR of East DC. Since IP packet hits to 10.12.12.0/24 subnet whereas Source IP belong to 10.11.11.0/24 subnet , triggers failure event and which leads packet punted to CPU causing dynamic discovery of 10.11.11.11/32 EID .
• The xTR that discovered the EID /32 will install that routes in its routing table and sends out map-notify-group message on SVI 100 , Where Peer xTR on East will also update its routing table of /32 routes.
• Now discovering xTR sends Map-Register message for /32 EID to Map-Server, Map-Server will add this to the database for that specific EID and its associated RLOC assigned on East DC.
• Now Map-Server will send the Map-Notify-message to xTR in west DC that has registration of 10.11.11.0/24 prefix. This message will inform xTR on West DC that specific host 10.11.11.11/32 has been discovered on East DC site and further adds /32 Null0 routes for 10.11.11.11 host in its routing table.
• West DC xTR will also inform the same message to its Peer xTR and Peer xTR will also update its routing table.

Now one another task has still be left that to update the map-Cache information of remote site that 10.11.11.11/32 is now connected to East Site because even 10.11.11.11/32 has been moved to East DC, but remote site has old information in its cache which say that 10.11.0.0/16 is connected to West DC.