Cisco SDA Part VI - LISP mobility - Solicit Map Requests (SMRs)

We start this post with the assumption that a host mobility event has occurred (see previous post for details on host mobility) and that the EID is moved from behind xTR2 to behind xTR6.

The state of the topology is like so:

When a mobility event like this occurs, only the MS/MR is notified of this, along with the original RLOC. Remember that LISP works using a pull based model. This implies that the actual datapath remains unchanged on the xTRs even after a mobility event. What this means is that if tries to reach, the data-plane programming still points to xTR2.

Confirm the same by looking at the LISP map-cache and the CEF table on xTR4:

So, how does the LISP infrastructure inform xTR4 that the EID has actually moved and it no longer exists behind xTR2? This is where SMRs (solicit map requests) come into play.

After the host mobility event, consider the next packet that hits xTR4, destined for Based on the CEF table seen above, xTR4 encapsulates this and sends it to xTR2.

When xTR2 receives this, it checks its LISP database, where it finds no entry for this EID. It generates a map request (with the 'S' bit set) and sends that to the source RLOC, xTR4, in this case. This map request is called a SMR (solicit map request).

Essentially, what xTR2 is trying to convey is that the destination EID is no longer behind it and the originating RLOC should ask the MS/MR again for information on where this EID is now.

The SMR packet looks like this (notice that the 'S' bit is set):

When xTR4 gets this SMR, it generates an encapsulated map request (with the 's' bit set) and sends that to the MS/MR. The MS/MR forwards this to xTR6, since that is the RLOC for as registered in its site database. xTR6 sends a Map Reply back to xTR4.

The Map Request generated on receipt of a SMR looks like this (notice the 's' bit is set; the purpose of the 's' bit is simply to signify that this map request was invoked by the receipt of a SMR):

Once this map reply is received by xTR4, it now updates its LISP map-cache table (and the corresponding entry in the CEF table as well) to point to xTR6 as the RLOC for this EID.

Post this, traffic destined to now gets directed to xTR6.

For any queries, concerns or conversations, please email