Information About LISP Parallel 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 Parallel Model Virtualization
LISP parallel model virtualization ties virtualized EID space associated with VRFs to RLOCs associated with the same or different VRFs. 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 as well.
The example illustrated in the figure above shows virtualized EID space associated with a VRF (and bound to an Instance ID) being tied to locator space associated with the same VRF, in this case - Pink/Pink and Blue/Blue. However, this is not required; the EID VRF does not need to match the RLOC VRF. In any case, a mapping system must be reachable via the associated locator space. Multiple parallel instantiations can be defined.
In the most general case, shared model and parallel model may be combined such that multiple EID VRFs share a common RLOC VRF, and multiple instantiations of this architecture are implemented on the same platform, as shown in the figure below.
As shown in the figure above, shared and parallel models are combined to associate several EID instances to one shared RLOC VRF, and then several other EID instances to another shared RLOC VRF.
LISP Parallel Model Virtualization Architecture
Architecturally, LISP parallel model virtualization can be deployed in single or multitenancy configurations. In the parallel model multitenancy case, a set of xTRs is shared (virtualized) among multiple customers, and each customer uses their own private (segmented) core infrastructure and mapping system. All sites associated with the customer use the same instance ID and are part of a VPN using their own EID namespace as shown in the figure below.
LISP Parallel Model Virtualization Implementation Considerations and Caveats
When the LISP Parallel Model Virtualization is implemented, several important considerations and caveats are important. Each router lisp value instantiation is considered by Cisco IOS XE software to be a separate process. Instance IDs must be unique only within a router lisp instantiation. 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)# vrf definition gamma
xTR-1(config-vrf)# address-family ipv4
xTR-1(config-vrf-af)# exit
xTR-1(config-vrf)# vrf definition delta
xTR-1(config-vrf)# address-family ipv4
xTR-1(config-vrf-af)# exit
xTR-1(config-vrf)# exit
xTR-1(config)# router lisp 1
xTR-1(config-router-lisp)# locator-table vrf alpha
xTR-1(config-router-lisp)# eid-table vrf beta instance-id 101
xTR-1(config-router-lisp-eid-table)# exit
xTR-1(config-router-lisp)# exit
xTR-1(config)# router lisp 2
xTR-1(config-router-lisp)# locator-table vrf gamma
xTR-1(config-router-lisp)# eid-table vrf delta instance-id 101
xTR-1(config-router-lisp-eid-table)# exit
xTR-1(config-router-lisp)# eid-table vrf beta instance-id 201
The vrf beta table is not available for use as an EID table (in use by router lisp 1 EID instance 101 VRF)
In the above example, four VRFs are created; alpha, beta, gamma, and delta. The router lisp instantiation router lisp 1 is created and associated with the locator-table VRF named alpha. Next, the EID table VRF named beta is specified and associated with instance ID 101. Next, a new router lisp instantiation, router lisp 2, is created and associated with the locator-table VRF named gamma. Next, EID table VRF named delta is specified and also associated with instance ID 101. These two instance IDs are unrelated to each other; one is relevant only within router lisp 1 and the other is only relevant within router lisp 2.
In the above example, also observe that while under router lisp 2, an attempt is made to configure an EID table VRF named beta. Note that the router is unable to use this EID table VRF since it (beta) is already associated with an eid-table command within the router lisp 1 instantiation.
You can re-use an instance ID, and which EID VRF it is decapsulated into depends on the router lisp instantiation and locator-table VRF that it is associated with. You cannot connect the same EID VRF to more than one locator-table VRF, however.