Remote Client Communicating to EID before & After Mobility Event

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 routes installed. The reason is given below:

West Dc represents home site for 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 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 is moved from West DC to East DC on 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 subnet whereas Source IP belong to subnet , triggers failure event and which leads packet punted to CPU causing dynamic discovery of 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 prefix. This message will inform xTR on West DC that specific host has been discovered on East DC site and further adds /32 Null0 routes for 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 is now connected to East Site because even has been moved to East DC, but remote site has old information in its cache which say that is connected to West DC.


    You are will be the first.


Please login here to comment.