Updated: Nov 6, 2019
Continuing on from the previous post, we take a look at actual host mobility events and how the LISP infrastructure facilitates this. Our goal for this post is to have the simulated host (126.96.36.199) move from behind xTR2 to behind xTR4 (simulated via R10). A working assumption used in the post is that there is no active traffic destined for the host that is moving (we will look at this in the SMR post).
The topology is a slightly modified version of what we used in the last post:
There are certain baselines we need to establish from the get go - 188.8.131.52/32 has been learnt dynamically and installed in the site database of the MS/MR, with a RLOC of xTR2 (184.108.40.206). Let's confirm this:
On xTR2, this entry is also present in its LISP database:
Additionally, xTR4 needs to be provisioned for 220.127.116.11/24 as a dynamic EID:
So, now that we have these baselines established, let's move 18.104.22.168 to R10.
When this happens, some traffic (can be control-plane or data-plane) is generated from 22.214.171.124 and it hits xTR4. xTR4 dynamically learns this, installs it in its LISP database and sends a Map Register to the MS/MR. The MS/MR accepts this and installs it in its site database.
At the same time, the MS/MR knew that there was a previously registered RLOC against this specific /32 entry. It informs the original RLOC (xTR2, in this case) of this new RLOC learn by sending it a Map Notify as well.
This Map Notify is as follows:
When xTR2 receives this Map Notify, it realizes that the host has "moved away". It deletes the /32 entry from its LISP database and sends a Map Register back to the MS/MR with an action of 'Drop'.
This packet looks like so:
On receiving this Map Register, the MS/MR removes xTR2 as a RLOC for 126.96.36.199/32. This action completes the host move.