Remote Client communication After Mobility Event

Remote Client communication After Mobility Event

Here we will see , when workload will move from West DC to East DC how its control plane will be populated and how traffic will flow , Let’s see the sequence of events as per figure :

Let’s suppose, Workload from West DC has been migrated to East DC with Same IP and MAC address.  As soon as Work load send IP traffic it will be hit by /32 Null0 routes ( Which was installed on East DC when Work Load 10.11.11.11/32 was on West DC) , which further result first packet failure event and causing for dynamic-EID discovery at East DC.

xTR which will discover the workload, will replace the /32 Null0 routes to valid /32 Local routes and will send map-notify-group message to SVI 100, due to which other Peer xTR in East DC will also come to know and will update its routing table from /32 Null0 route to 10.11.11.11/32 Routes and also when the multicast message will be received to West DC xTR, they will replace specific /32 routes to /32 Null0 routes.

The discovering xTR at East DC will also send the Map-Register-Message for /32 EID address to map server and map server will updates its entry by replacing the original RLOC for /32 Route to 3.3.3.3 and 3.3.3.2.

Now in order to establish successful communication between Remote LISP client to Workload present in East DC , one  more step is to be completed which is , to update the map-cache information in map-cache of remote xTR.

The work flow would be like this, that from Remote LISP, the packet will be sent to West DC as per old Map information in its map-Cache. Once one of the xTR will receive the packet, after Work load move will decaptsulate the packet, and will perform the routing lookup where it will hit for Null0 routes and due to which  packet will be dropped and punted to CPU which is signal to handle the packet by LISP process.