Information About LISP Shared Model Virtualization
Overview of LISP Virtualization
Deploying physical network infrastructure requires both capital investments for hardware, as well as manpower investments for installation and operational management support. When distinct user groups within an organization desire to control their own networks, it rarely makes economic sense for these user groups to deploy and manage separate physical networks. Physical plants are rarely utilized to their fullest, resulting in stranded capacity (bandwidth, processor, memory, etc.). In addition, the power, rack space, and cooling needs to physical plants do not satisfy modern “green” requirements. Network virtualization offers the opportunity to satisfy organizational needs, while efficiently utilizing physical assets.
The purpose of network virtualization, as shown in the figure below, is to create multiple, logically separated topologies across one common physical infrastructure.
When considering the deployment of a virtualized network environment, take into account both the device and the path level.
Device Level Virtualization
Virtualization at the device level entails the use of the virtual routing and forwarding (VRF) to create multiple instances of Layer 3 routing tables, as illustrated in the figure below. VRFs provide segmentation across IP addresses, allowing for overlapped address space and traffic separation. Separate routing, QoS, security, and management policies can be applied to each VRF instance. An IGP or EGP routing process is typically enabled within a VFR, just as it would be in the global (default) routing table. As described in detail below, LISP binds VRFs to instance IDs for similar purposes.
Path Level Virtualization
VRF table separation is maintained across network paths using any number of traditional mechanisms, as illustrated in the figure below. Single-hop path segmentation (hop-by-hop) is typically accomplished by techniques such as 802.1q VLANs, VPI/VCI PW, or EVN. LISP can also be used. Traditional multi-hop mechanisms include MPLS and GRE tunnels. As described in detail below, LISP binds VRFs to instance IDs (IIDs), and then these IIDs are included in the LISP header to provide data plane (traffic flow) separation for single or multihop needs.
LISP Virtualization at the Device Level
Recalling that LISP implements Locator ID separation and, in so doing, creates two namespaces (EIDs and RLOCs), it is easy to see that LISP virtualization can consider both EID and RLOC namespaces for virtualization. That is, either or both can be virtualized.
-
EID virtualization—Enabled by binding a LISP instance ID to an EID VRF. Instance IDs are numerical tags defined in the LISP canonical address format (LCAF) draft, and are used to maintain address space segmentation in both the control plane and data plane.
-
RLOC virtualization—Tying locator addresses and associated mapping services to the specific VRF within which they are reachable enables RLOC virtualization.
Because LISP considers virtualization of both EID and RLOC namespaces, two models of operation are defined: shared model and parallel model. For completeness, the discussions below begin first with a review of the default (non-virtualized) model of LISP, and then cover the details of shared and parallel models.
Default (Non-Virtualized) LISP Model
By default, LISP is not virtualized in either EID space or RLOC space. That is, unless otherwise configured, both EID and RLOC addresses are resolved in the default (global) routing table. This concept is illustrated in the figure below.
As shown in the figure above, both EID and RLOC addresses are resolved in the default table. The mapping system must also be reachable via the default table. This default model can be thought of as a single instantiation of the parallel model of LISP virtualization where EID and RLOC addresses are within the same namespace such as is the case in this default table.
LISP Shared Model Virtualization
LISP shared model virtualized EID space is created by binding VRFs associated with an EID space to Instance IDs. A common, shared locator space is used by all virtualized EIDs. This concept is illustrated in the figure below.
As shown in the figure above, EID space is virtualized through its association with VRFs, and these VRFs are tied to LISP Instance IDs to segment the control plane and data plane in LISP. A common, shared locator space, the default (global) table as shown in the figure above, is used to resolve RLOC addresses for all virtualized EIDs. The mapping system must also be reachable via the common locator space.
LISP Shared Model Virtualization Architecture
Architecturally, LISP shared model virtualization can be deployed in single or multitenancy configurations. In the shared model single tenancy case, xTRs are dedicated to a customer but share infrastructure with other customers. Each customer and all sites associated with it use the same instance ID and are part of a VPN using their own EID namespace as shown in the figure below.
In the shared model multitenancy case, a set of xTRs is shared (virtualized) among multiple customers. These customers also share a common infrastructure with other single and multitenant customers. Each customer and all sites associated with it use the same instance ID and are part of a VPN using their own EID namespace as shown in the figure below.
LISP Shared Model Virtualization Implementation Considerations and Caveats
When LISP Shared Model is implemented, several important considerations and caveats are important. Instance IDs must be unique to an EID VRF. Review the example below:
xTR-1(config)# vrf definition alpha
xTR-1(config-vrf)# address-family ipv4
xTR-1(config-vrf-af)# exit
xTR-1(config)# vrf definition beta
xTR-1(config-vrf)# address-family ipv4
xTR-1(config-vrf-af)# exit
xTR-1(config-vrf)# exit
xTR-1(config)# router lisp
xTR-1(config-router-lisp)# eid-table vrf alpha instance-id 101
xTR-1(config-router-lisp-eid-table)# exit
xTR-1(config-router-lisp)# eid-table vrf beta instance-id 101
Instance ID 101 is bound to the vrf alpha EID table.
In the above example, two EID VRFs are created: alpha and beta. Under the router lisp command, an EID table VRF named alpha is specified and associated with the instance ID 101. Next, an EID table VRF named beta is specified and also associated with the instance ID 101. As indicated by the router, this is not permissible since instance ID 101 is already associated with the EID VRF named alpha. That is, you cannot connect the same instance-id to more than one EID VRF.