Note: It occurred to me that I’ve been calling the Map Server / Map resolver router by both ‘maprouter’ as well as ‘mapserver’ throughout this post. Any reference to either mapserver or maprouter refers to the central Map Server / Map Resolver router. I’ve corrected this error in future posts and called it just ‘mapserver’. Sorry!
So in the last two posts we’ve talked about the concept of LISP, as well as seen LISP in action at a very basic level using xTRs, the map-server, and the map-resolver router roles. Before we move on to more advanced concepts, I’d like to dig a little deeper into some of what we’ve already seen. Namely, in this post, I’d like to dig into the map-register event and the interaction between the ETR and the map-server.
The interaction is for the map-register in our example is really quite simple. Let’s take a quick look at the diagram again…
One the router is configured as an ETR (and has it’s map server defined as part of the ETR configuration) the ETR will immediately reach out to it’s defined map server to register it’s prefixes. In our case, the update will come from 10.0.1.2 and be destined for the map server at 10.0.1.1. In addition to the initial update, periodic (appears to be 1 minute intervals) updates will be sent from the ETR to the map-server. Let’s take a quick look at the initial map-register packet….
I highlighted a couple interesting sections. You’ll note the IP source and destination that I’ve already described as well as that the layer 4 protocol is UDP. The port used as the source and the destination is the LISP control port UDP 4342. Within the LISP packet itself you can see the EID prefix for which the ETR is registering as well as what the local RLOC is to reach that prefix. If we were to modify the ETR configuration and add another EID prefix with the ‘database-mapping’ command, we’d see more than one entry in the same map-register packet as shown below…
As you can see, LISP uses a single map-register packet to communicate multiple prefixes.
If we take a look at the debugs running on the mapserver router, this is what we see for the map-register event…
*Nov 6 23:45:49.327: LISP: Processing received Map-Register message from 10.0.1.2 to 10.0.1.1
*Nov 6 23:45:49.327: LISP: Processing Map-Register no proxy, no map-notify, no merge, no security, no mobile-node, 1 record, nonce 0x99B93ACC-0xFB7F5137, key-id 1, auth-data-len 20
*Nov 6 23:45:49.327: LISP: Processing Map-Register mapping record for IID 0 192.168.1.0/24, ttl 1440, action none, authoritative, 1 locator
10.0.1.2 pri/wei=1/100 LpR
*Nov 6 23:45:49.327: LISP-0: MS registration IID 0 prefix 192.168.1.0/24 10.0.1.2 site sitea, Created.
*Nov 6 23:45:49.327: LISP-0: MS registration IID 0 prefix 192.168.1.0/24 10.0.1.2 site sitea, Adding locator 10.0.1.2.
*Nov 6 23:45:49.327: LISP-0: MS EID IID 0 prefix 192.168.1.0/24 site sitea, ALT route update/create.
Pretty straight forward. The debugs on lisp1 are also pretty straight forward…
*Nov 6 23:57:07.591: LISP: Processing ‘etr map-server’ ConfigReq, IID 0 afi=IPv4 sense=1 default=0 under_eid_table=0
*Nov 6 23:57:07.591: LISP-0: IPv4 Map Server IID 0 10.0.1.1, Created.
*Nov 6 23:57:08.267: LISP: Processing ‘etr’ ConfigReq, IID 0 afi=IPv4 sense=1 default=0 under_eid_table=0
*Nov 6 23:57:08.267: LISP-0: IPv4 Map Server IID 0 10.0.1.1, Config changed.
*Nov 6 23:57:08.271: LISP-0: IPv4 Map Server IID 0 10.0.1.1, Config changed.
*Nov 6 23:57:08.275: LISP: Executing work item Net_tx:_0_v4_0_10.0.1.1_registration[normal]
*Nov 6 23:57:08.275: LISP-0: IPv4 Map Server IID 0 10.0.1.1, Sending map-register (src_rloc 10.0.1.2).
*Nov 6 23:57:09.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface LISP0, changed state to up
It’s interesting to note that this is (from what I can discern) a one way UDP communication. That is, the ETR is just sort of throwing it’s updates out to the map-server. If the map-server doesn’t ever get the updates (be creative here, firewall, etc.) the ETR would be none the wiser.
I realize that this post was rather dry, but I feel it’s important to break down the each function of LISP and explore it independently. In my next posts, we’ll be look at the actual map-request and map-reply process.