Tag Archives: ip

Consider learning LISP

No, not the infamous programming language! But LISP as Location/Identifier Separation Protocol. (I know I am repeating the joke everyone does but I couldn’t help).

But what is it about? It is actually at first difficult to conceive, as we are all so used that IP addresses identify both a person (or a company) and its location. It is like this by design because Internet is based on a hierarchical routing model.

What I wrote below is just a bad summary of this article by David Meyer. See it as a memo or as a short introduction if you don’t want to get deep into LISP. Otherwise, jump immediately to the original article or to Packetlife which gives some more links.

Now, why would we want to change it? Because with the growing lack of IPv4 free blocks, it became very difficult for the network providers to maintain contiguous blocks. So now the routing tables are bigger than they should be and not optimized. Customers want multihomming and mobility, while providers want to limit the routing overload. Two different point of views which can’t be satisfied with the hierarchical routing of today. BGP partially addresses some of these issues, but it has limits and misconfigurations with deep impacts (eg blackholes) happen regularly. Note that IPv6 can’t be of any help in this case.

But LISP tries. And in a nice way, as it is totally transparent to the end-users. Only the core network of the providers are impacted.

Basically, the customer IP stack remains untouched during the transit. With LISP, the customer IP address is only the identifier, no more the locator.

Then, LISP add a new IP stack on routers configured by the provider. These routers, named ITR (Ingress Tunnel Router) and ETR (Egress Tunnel Router) according to the direction of the flow, encapsulate the packets with the new IP stack with their own address as origin. A little bit as a proxy but at a lower level, their purpose is to route the packets on behalf of the customer.

In short, the role of an ITR is to find the appropriate ETR for the destination, to route the packet correctly. LISP comes with a directory used for the ETR lookup. The directory is supposed to be “manually” maintained by the provider (the overload should be acceptable because we are in a core network, where changes in topology don’t happen all the time). Now that the ITR knows what the location for the recipient is, it sends out the packet with the ETR as destination IP. The way back works just the same.

Between the ITR and the ETR, of course, there can be a number of different providers and routers, not supporting LISP, the routing part being handled by classic routing protocoles like BGP.

You should see clearly now the beauty of LISP : if a customer moves with his IP block, for the provider it is just a matter of updating the location within the LISP directory. There are also some great features like support of load balancing in the case of multi-homing . LISP appears to be efficient and straightforward, but not yet validated by the IETF. Keep an eye on this work in progress!