I’m focusing on three business use cases here:
(1) Efficient Multi-Homing
(2) IPv6 Enablement
(3) Multi-Tenancy and Large-Scale VPNs
Case No. 1- Efficient Multi-Homing
It is difficult to split loads on your WAN when you have two WAN links from different carriers. The most common solution is to use the routing protocol Border Gateway Protocol (BGP). The configuration for BGP multi-homing is not simple. It requires a registered Autonomous System Number (ASN) assigned to your company as well as registered IP address block from the American Registry for Internet Numbers (ARIN). With LISP, none of this is required. The solution with LISP is a low cost alternative for multi-homing and a simple way to provide ingress traffic engineering.
The built-in multi-homing and traffic engineering features are one of the primary benefits of LISP implementation. Multi-homing with LISP is the ability to efficiently adjust the load on each WAN link. This is done very simply by setting the route-locator (RLOC) weight. This enables you to manage and balance the utilization of the ingress bandwidth by setting the priorities. This design offers a preference of some Egress Tunnel Routers (ETRs) over others, allowing some systems to act as primary ETRs and others as backups, thus inherently providing multi-homing. This is implemented using the priority field with lower priority systems being preferable over higher systems. Below is an example of the configuration that you would use on an ASR 1K where you have two links connected to the WAN and set the two links to equally split the load:
10.10.10.1 priority 10 weight 50
10.10.10.2 priority 10 weight 50
The map server (covered later in more detail) responds to the querying Ingress Tunnel Router (ITR) which can offer a list of ETR to utilize. The benefit of this design is that it allows traffic distribution to be controlled. This is accomplished while eliminating the need for BGP peering with upstream service providers. There is also no need for ASNs or a registered routable IP addresses.
This is a very attractive solution where customers have an active and backup link. The backup link will usually remain idle as long as the primary link is active. Using this LISP use case you can have both links active and load sharing. If there is a failure, there is no convergence and your clients will not see a delay. This also allows small companies to add a low cost secondary link, such as a cable modem, for higher availability.
Case No. 2- IPv6 Enablement
Companies wanting to use IPv6 often have issues because their current WAN only supports IPv4 traffic. With LISP, a company can transition to IPv6 in phases while still having other sites and the core network on IPv4. This technique is an efficient way to create and operate IPv6 islands within the corporate network. This can be done using the existing IPv4 core with no carrier involvement or extra costs. LISP provides support for both IPv4 and IPv6 Endpoint ID (EID) and RLOCs. There is a growing need for companies to have a website capable of IPv6 on the Internet. With LISP, you can easily support:
- IPv4-to-IPv4 over IPv4
- IPv4-to-IPv4 over IPv6
- IPv6-to-IPv6 over IPv6
- IPv6-to-IPv6 over IPv4
Implementing an IPv6 transition strategy with LISP has several benefits over each of preceding approaches, because it can simplify the initial rollout of IPv6 by encapsulating IPv6 host packets within IPv4 headers or IPv4 host packets within IPv6 headers.
Enterprises wishing to establish an IPv6 web presence or deploy a private IPv6 VPN only require a few changes to an existing IPv4 network infrastructure using the LISP. LISP lets a company retain the existing IPv4 WAN connectivity, enabling quick and efficient migration to IPv6.
Case No. 3- Multi-Tenancy and Large-Scale VPNs
LISP implements location and ID separation which creates two namespaces – one for RLOCs (locations) and one for EIDs (ID). These namespaces provide tenant separation using the LISP mapping system because LISP binds virtual routing and forwarding (VRF) to instance IDs. The IDs are included in the LISP header to provide data plane traffic separation.
EIDs are segmented at the mapping server to provide VPN and tenant logical separation for each EID handled by LISP. The segmented EID is encoded in the LISP control plane as designed in the standard definition of the protocol. However, the LISP data plane also has the necessary fields to support the segmentation of traffic into multiple VPNs. LISP binds VRFs to instance IDs, so that these IDs are included in the LISP header to provide data plane traffic separation.
The LISP multi-tenancy solution is designed to exceed the scalability of current segmentation solutions significantly, because it uses an on-demand routing model, which does not require the maintenance of traditional routing adjacencies. The on-demand routing model uses a mapping system, which only sends the LISP router or switches routes that are being used. By contrast, in traditional routing, all routes are learned to everything that is in the domain. This results in routing tables with thousands of routes that have to be stored in your device memory and checked for availability, frequently using CPU cycles. With LISP, it uses less memory and CPU on your devices because it only knows and stores the routes that your clients need to conduct their business.
The LISP multi-tenancy solution also supports VPNs across enterprise networks to extend the network segmentation beyond local network boundaries. Campus LISP virtualization extends segmented services using VPN to transport. This is done with multiple VRFs utilizing the LISP mapping system. Each VRF is tied to instance IDs for the EID in the VRF. This use case enables all the new VRFs to be transported over one WAN network separated logically using VPNs.
My next LISP blog update will discuss LISP and mobility. Stay tuned!