Implementing OpenLISP with LISP+ALT Attilla de Groot [email protected] [email protected] April 14, 2009 Abstract Due to the exponential growth of the BGP routing table in the “default-free-zone” the Locator ID Separation Protocol (LISP) is being developed. OpenLISP is one of the implementations of this protocol, however it does not have the function to route locator and endpoint id addresses. This document describes how a lisp daemon should in- teract with OpenLISP, GRE and Quagga to use LISP+ALT as a control plane. 1 Implementing OpenLISP with LISP+ALT Contents 1 Introduction3 2 Scalability of Internet Routing4 2.1 BGP and the Default-Free-Zone.................4 2.2 Splitting location and ID.....................5 3 Locator ID Separation Protocol7 3.1 Encapsulation...........................7 3.2 Mapping information.......................8 3.2.1 Life of a Packet in the LISP Protocol.......... 10 3.3 Mapping system.......................... 11 3.3.1 LISP+ALT......................... 11 3.3.2 Routing in LISP+ALT.................. 12 3.3.3 LISP4............................ 13 4 OpenLISP 14 4.1 Packet encapsulation....................... 14 4.1.1 Incoming packets..................... 14 4.1.2 Outgoing packets..................... 14 4.1.3 MTU Management.................... 15 4.2 Mappingtable implementation................. 16 4.2.1 Command line tools................... 16 4.2.2 API............................. 17 5 Implementing OpenLISP with LISP+ALT 19 5.1 Gre................................. 19 5.2 Bgp................................. 20 5.3 Encapsulation........................... 21 5.4 Mapping Information....................... 21 5.4.1 Requirements....................... 22 5.4.2 Functional Design.................... 22 6 Conclusion 24 6.1 Further research.......................... 24 2 Implementing OpenLISP with LISP+ALT 1 Introduction Over the last ten years the Internet has grown exponentially. Not only the number of connected hosts has increased, but also the number of routable prefixes. This has lead to the discussion of creating a more scalable solu- tion to reduce the routing table size in the “default-free-zone” (DFZ). The growth of the routing table and a possible solution are explained in Section 2. There have been several protocols suggested in the Routing Research Group that provide a locator id split; the Locator ID Separation Protocol [1] (LISP) is one of them. The locator ID Separation protocol is a mapping and encapsulation implementation of the locator id split. To realise a locator id split a table with mappings between locator and end points is needed. The LISP+ALT system [2] is an overlay network based on already available protocols that provides a mapping system. In Section3 the LISP protocol and the LISP+ALT system is explained. At the time of writing there are two implementations of the lisp proto- col. One is a propriatary implementation on the Cisco NX-OS [3] operating system. The other implementation is OpenLISP [4] developed by the Bel- gium university of Louvain. The implementation of OpenLISP is explained in section4. There is currently no integration between a LISP+ALT network and the OpenLISP implementation. Since the system is based on already available protocols this lead to the following research question: Is it possible to let the OpenLISP implementation interoperate with a LISP+ALT network by using existing open source software? In the next sections the practical deployment of OpenLISP in the LISP+ALT network is studied. Some current impediments with the OpenLISP imple- mentation are identified and recommendations for further research are pre- sented. 3 Implementing OpenLISP with LISP+ALT 2 Scalability of Internet Routing The growth of the routing table in the “default-free-zone” (DFZ) has lead to discussions in the Routing Research Group [5] on a more scalable routing system. It is commonly agreed upon that splitting the routing and iden- tification space (IP-adresses) into a locator and endpoint IDs is the way to provide scalability. In the Internet Research Task Force [5] several drafts have been submitted with protocols to provide such a locator ID split. The LISP protocol provides this through a map and encapsulation solution. 2.1 BGP and the Default-Free-Zone Currently, the BGP [6] protocol is used for inter-domain routing. Every do- main can be seen in BGP terms as an autonomous system (AS). Every AS has one or more IP subnets which are announced between BGP speakers that have a peering relationship. A simplified representation can be seen in Figure1. AS100 AS200 1.1.0.0/16 2.2.0.0/16 Internet AS300 AS400 3.3.0.0/16 4.4.0.0/16 Figure 1: BGP Routing Assuming that every AS has one BGP speaker and AS400 has a peering with AS200 and AS300 the routing table of the AS400 BGP router would look like table ??. Over the last 15 years the Internet has grown to over 30.000 autonomous systems and the use of classless inter-domain routing [7] has lead to a rout- ing table with almost 300.000 entries as can be seen in figure2. This is 4 Implementing OpenLISP with LISP+ALT Network Next Hop Path 3.3.0.0/16 3.3.0.1 400 300 2.2.0.0/16 2.2.0.1 400 200 1.1.0.0/16 3.3.0.1 400 300 100 2.2.0.1 400 200 100 Table 1: BGP FIB for AS400 Figure 2: Growth of the BGP Table - 1994 to Present [8] caused by more provider independent address space that has been given out over the last few years and less provider aggregation. Another factor of table growth is multihoming, where two providers announce the same subnet. BGP was not ment to be used for traffic engineering. However routing updates are abused to control traffic flows in the network. This causes a more dynamic routing table and more entries if subnets are separately an- nounced and thus more growth of the Forwarding Information Base (FIB). The FIB is finally loaded into high speed memory, because for every IP packet a lookup has to be done. This kind of memory is costly in design and manufacturing. Having a large FIB increases the operational cost of having a router in de DFZ. 2.2 Splitting location and ID In current (inter)network routing an IP-address is used as the location and identifier. Discussions in the RRG have lead to the conlusion that split- 5 Implementing OpenLISP with LISP+ALT ting location and identifier is a commonly accepted solution to limit the growth of the routing table. If such a system is used in Internet routing this will lead to a situation where every AS has one or a few locators that represent multiple subnets. The routing table will then only contain locator addresses. The ids for the endpoints will be stored in a seperate mapping table. As result of a locator ID split we will have a more stable DFZ, because no routing updates are needed if an endpoint prefix is moved, fragmentation of the identity space is not an issue because of the RLOC to end ID mapping, and in a multihoming situation only one mapping for the endpoint prefix is needed. To implement a location/ID split addressing, headers, and protocols need to be adjusted. Several proposals have been made for this implemen- tation [9, 10]. The Locator ID separation protocol is a map and encapsula- tion implementation of the location/ID split approach. 6 Implementing OpenLISP with LISP+ALT 3 Locator ID Separation Protocol The Locator ID Separation Protocol (LISP) is an implementation of the en- capsulation solution for the locator id split. The development of the LISP protocol continued at the IETF after the Internet Architecture Board [11] routing and adressing workshop in 2006 [12]. At the time of writing an IETF workgroup is being setup for further development of the protocol. Although the size of the routing table is one of the main problems LISP should solve, it also adresses traffic engineering. By using priority and weight from the authoritative side you can control your ingress traffic and load balance your traffic over multiple LISP devices. The LISP protocol can be devided into two sections: packet encapsula- tion and mapping. The data plane takes care of the encapsulation proces and problems that may occur in this process. As is explained in Section 2.2 a seperate mapping table is needed. The protocol provides for mechanisms to fill and update the mapping table. 3.1 Encapsulation To reduce the routing table an original IP packet is encapsulated with two new headers as seen in Figure3. The LISP header includes the locator reach- ability information and a nonce. This header is then encapsulated with another ip header that is used to route the packet. This is send to the well- known LISP UDP port 4341. Since the encapsulation process uses standard IP headers, nothing in the protocol excludes the use of IPV6 either as locator IDs or as endpoint IDs. To prepend a LISP header and outer ip header two new devices are in- troduced into the network. • An Ingress Tunnel Router (ITR) that adds a LISP header, encapsulates it with another IP-header and sends it to the destination router. • An Egress Tunnel Router (ETR) that removes the extra headers and sends the packet to the final destination. Both functions can be combined in one device and is named an XTR. As with every encapsulation protocol the MTU might be a problem. Since lisp adds additional headers the packet becomes larger and could exceed the maximum MTU in the path. According to the draft most traffic paths can accommodate a path MTU of at least 4470 bytes. It has to be de- termined in a deployment pilot if and what problems are caused by adding the extra headers.