The IP Routing Problem
Before discussing LISP, it is useful to compare/contrast how DNS works versus how Internet IP routing works. Both DNS and IP Routing deal with a large databases. With DNS, the database is truly distributed. End user DNS servers (for example, your corporate Internet-attached DNS server) are configured with specific names for their authoritative zones, plus enough information to allow them to look-up any other information they might need. Random DNS entries (for example, www.cisco.com) are not pre-loaded into your DNS server. If you need to resolve this name, the DNS server requests the information from an upstream server. Caching adds some efficiency, but does not change the overall structure. This system has allowed the number of DNS zones to scale well into the millions.The database for IP routing is handled quite differently. In the Internet’s Default Free Zone (DFZ), all routers must have the entire Internet routing database. Summarization can help alleviate this requirement to a degree, but summarization also comes at the price of less accurate routing information. The IPv4 routing database is currently 325,000 routes, give or take a few thousand. Ultimately the IPv6 table will be as large, or more likely considerably larger, and the increased size of the address space will result in larger memory requirements. And remember, this is high-speed router memory, not generic DRAM. Wouldn’t it be great if we could transition IP routing from it’s current ‘replicated database’ model to a distributed database, like DNS? As a matter of fact, that’s the goal of LISP.
Following a Connection in a LISP-Enabled World
Let’s go through a simple example in a fully LISP-enabled environment. A user PC would determine the destination IP address of a web server via DNS and create a standard IP packet, with its own IP as the source and the IP of the web server as the destination. The packet would be routed through the user’s LAN until it reached an Internet gateway.
At this point, the LISP-aware ISP router (in LISP-speak, the Ingress Tunnel Router, or ITR) would perform a lookup for the destination IP address. An answer would come back with the IP address of the Egress Tunnel Router (ETR) for that destination. The ITR would then encapsulate the user’s packet in a LISP packet, with a source IP of the ITR’s ISP interface and a destination of the ETR’s ISP interface. This packet would then be sent through the Internet to the ETR.
The ETR receives the LISP-encapsulated packet, removes the header and routes the native IP packet (with the user’s PC as a source IP and the web server’s IP as a destination) into the local LAN, to the web server. Return traffic from the web server to the user follows the same procedure in reverse (the web server’s ISP router acts as the ITR and the user’s ISP router is the ETR).
As a side note, the “Ingress” and “Egress” designations for Tunnel Routers are relative to the LISP-encapsulated tunnel. The router that encapsulates a packet into LISP is the ingress router.
Tell Me Again… Why Is This Better?
On the surface this seems like extra work for little to no benefit. Let’s dig a bit deeper to see how this helps each component in the path.User PC – Nothing is different
ITR – This router only needs a default route to the Internet. It is not clear from this example, but even if there is redundancy, in a fully LISP-enabled environment, only a default route is required.
Internet PE / P routers – This is where the magic happens. The Internet PE and P routers only need routes for the ISP interfaces of the customer routers. All packets between customers will be encapsulated, with the source and destination IP addresses coming from the WAN circuits. Memory requirements are greatly reduced in these devices.
ETR – Only requires a default route to the Internet.
Web Server – Nothing is different
Drawbacks
So what are the drawbacks to LISP?MTU Issues – At its heart, LISP is a tunneling technology. All tunneling technologies suffer from potential MTU issues.
Complexity – This paradigm is clearly different than what most of us are comfortable with. But we didn’t enter this field thinking nothing would ever change, right?
Delay – The initial packet towards a new destination will likely get dropped, because the destination lookup takes time. After the first packet the destination information is cached, so subsequent packets should flow without delay. According to the Cisco LISP team, testing has shown this isn’t as big of an issue as it appears in theory.
A few optimizations have been suggested to deal with this delay issue. First, a set of common destinations could be pre-programmed into ITRs (subnets associated with Google, for example). Colin McNamara had a particularly interesting suggestion of ITRs performing DNS reply snooping, as it is highly likely that a DNS lookup will be followed quickly by an initial packet to that destination. I’m not sure if this is being worked on, but it seems like a great idea.
Experience the Real LISP site now ... http://lisp4.cisco.com/
Also useful resources of LISP can be found here ..
www.lisp4.net
There are many vendors now moving todays LISP and one of the famours vendors today already implemented LISP are :-
Google & Facebook.
Cool Stuff
ReplyDelete-- Batman