LISP Architecture on Cisco Platforms
LISP is supported on various Cisco platforms, but primarily the Cisco platforms are characterized based on the operating system software running on them. Cisco platforms support LISP on IOS/IOS-XE, IOS-XR, and NX-OS software. LISP offers a number of distinct functions and features, including xTR/MS/MR, IGP Assist, and ESM/ASM Multi-hop. Not all hardware supports all functions or features. Users should validate that a particular platform supports key features before implementing it.
The Cisco IOS/IOS-XE software does not have a distributed architecture similar to that of IOS-XR or NX-OS. On IOS/IOS-XE platforms, the LISP control plane functionality is maintained by the LISP control process, which works in conjunction with RIB and Cisco Express Forwarding (CEF) to provide the forwarding architecture for LISP. This section focuses on the LISP architecture on IOS-XR and NX-OS platforms as there are various software components that work together to provide the LISP functionality.
LISP Software Architecture on NX-OS
The LISP control plane software is a conditional feature running on NX-OS. The process is enabled when the user enables the LISP feature and configures LISP functions. To enable LISP and its functions on NX-OS, a user must configure feature lisp. When LISP is configured, LISP interacts with various software components on the NX-OS platform to exchange the control plane information and program the hardware to forward LISP-encapsulated packets. Figure 2-21 shows the software architecture of LISP on NX-OS platform.
)
FIGURE 2-21 Software Architecture of LISP on NX-OS
A number of software interactions take place on the NX-OS platform:
The map cache entries are equivalent to the routing entries on the NX-OS platform. They are managed by the Unicast Routing Information Base (URIB)/Unicast IPv6 RIB (U6RIB) process on NX-OS.
As with other routing protocols, with LISP the map cache entries are pushed down the forwarding plane using the application programming interfaces (APIs) provided by the Unicast Forwarding Distribution Manager (UFDM) process. The LISP process interacts with the UFDM process via Message Transaction Service (MTS), which provides the feature of inter-process communication on NX-OS.
The software forwarding takes place in the netstack process. LISP publish the map cache entries in the shared database. A library (LISP API) is provided to access the shared database and also do the LISP encapsulation/decapsulation of the data packets.
Netstack can request an update from the shared database by sending MTS messages to LISP. The LISP API provides the interface to send these messages.
The information is passed on to UFDM, which then presents the information to hardware to form the adjacencies. This allows for programming the Forwarding Information Base (FIB) and performing hardware-based forwarding. This is very similar to how IPv4 or IPv6 unicast routes are programmed in the hardware.
LISP Software Architecture on IOS-XR
On IOS-XR, no separate feature package information envelope (PIE) is required to enable LISP. The LISP software architecture is somewhat similar to that on NX-OS, except that the process names are different between the two platforms. Figure 2-22 shows the software architecture of the LISP control plane on the IOS-XR platform. On IOS-XR, the LISP process handles the core logic of the LISP control plane and interacts with other system components to provide the complete LISP functionality.
)
FIGURE 2-22 LISP Software Architecture on IOS-XR
The LISP process collaborates with the IPv4/IPv6 RIB, UDP, and NetIO processes, as shown in Figure 2-21. Also, the LISP process interacts with the sysdb process for learning configuration and providing the output for the show commands, the RSI agent for learning VRF configuration, the ifmgr process for learning about interfaces, and other processes that are not shown in the Figure 2-21. The threading model of IOS-XR software for LISP process allows for processing of different packets to be handled by separate threads. While various threads interact with NetIO and UDP processes, the main thread runs the LISP finite state machine (FSM).
The LISP process creates a UDP socket on port 4342 for sending/receiving the map request, map register, and map reply messages. When the socket is created, a corresponding binding entry is created in Local Packet Transport Service (LPTS) and gets programmed in line card ternary content-addressable memory (TCAM). The LPTS is a system-level protocol policer, and the system accounts for LISP features when enabled by creating an entry in LPTS. If the hardware is not programmed, the LISP process needs to add an LPTS entry for UDP port 4341 on the route processor (RP) by directly interacting with the LPTS infrastructure.
NetIO is used for servicing the control plane packets on the IOS-XR platform. NetIO is a slow-path switching engine that comes into play when the hardware is not programmed to forward LISP-encapsulated packets and software-based forwarding is done by the system. Normally, all data plane packets should be hardware switched and not software switched. The main functions of NetIO from a LISP functionality perspective are as follows:
It facilitates the rx/tx of LISP control plane messages on UDP port 4342.
If hardware forwarding is not programmed, the NetIO process de-encapsulates the received LISP-encapsulated messages on UDP port 4341 and switches them out on the inner IP header.
If hardware forwarding is not programmed, NetIO encapsulates the LISP-eligible packets by performing a lookup in the map cache table in the FIB shared memory and then switches them out on the outer IP.
If the match for a packet is not found in the unicast routing table or map cache table, it is punted to the LISP process to trigger a map request. This punt action is also performed by the NetIO process.
The NetIO process punts the packets containing updates to the RLOC status bits. The LISP process initiates the RLOC probing to learn the new and correct status bits.
RIB is actually a set of two processes: ipv4_rib and ipv6_rib. The map cache and map db (mapping database) are pushed into the FIB via RIB to take advantage of the existing point-to-multipoint distribution mechanism between the centralized RIB and all the FIB instances running on various nodes (for example, RPs, line cards, service cards). A LISP process also registers with RIB to get notified about the up/down changes to the RLOCs of an ETR’s database mapping. When it is notified of any such changes, it recomputes the RLOC status bits and reprograms FIB via RIB.