博馬娛樂城

博馬娛樂城

In this sample chapter from LISP Network Deployment and Troubleshooting: The Complete Guide to LISP Implementation on IOS-XE, IOS-XR, and NX-OS, you will explore LISP core architecture and components, including the roles and functionality of xTRs, PxTRs, MR/MS, and ALT.

Locator/ID Separation Protocol (LISP) architecture is a feature-rich architecture that not only does the separation of device identity and location but also brings down operational expenses (opex), provides a Border Gateway Protocol (BGP)–free multihoming network, enables multi address-family (AF) support, provides a highly scalable virtual private network (VPN) solution, enables host mobility in data centers, and much more. To understand how all these functionalities and benefits are achieved, it is important to know the underlying architectural components of LISP and also understand how LISP works. This chapter explores the details of the architecture of LISP.

This chapter covers the following topics:

• LISP architecture

• LISP Canonical Address Format (LCAF)

• LISP packet headers

• LISP control plane messages

• LISP Database Architecture: LISP-DDT

• LISP architecture on Cisco platforms

LISP Architecture

LISP, defined in RFC 6830, is a routing and addressing architecture of the Internet Protocol. The LISP routing architecture was designed to solve issues related to scaling, multihoming, inter-site traffic engineering, and mobility. An address on the Internet today combines location (how the device is attached to the network) and identity semantics in a single 32-bit (IPv4 address) or 128-bit (IPv6 address) number. The purpose of LISP is to separate the location from the identity. In simple words, with LISP, where you are (the network layer locator) in a network that can change, but who you are (the network layer identifier) in the network remains the same. LISP separates the end user device identifiers from the routing locators used by others to reach them. The LISP routing architecture design creates a new paradigm, splitting the device identity—that is, the endpoint identifier (EID)—from its location—that is, the routing locator (RLOC).

In order to further understand how LISP does the locator/ID separation, it is important to first learn about the architectural components of LISP. The following are some of the functions or components that form the LISP architecture:

• Ingress tunnel router (ITR): The ITR receives the packets from the site-facing interfaces and encapsulates them to the remote LISP site or natively forwards the packets to a non-LISP site.

• Egress tunnel router (ETR): The ETR receives the packets from core-facing interfaces and de-encapsulates them to deliver them to local EIDs at the site.

• Proxy ingress tunnel router (PITR): A PITR is an infrastructure LISP network entity that receives packets from non-LISP sites and encapsulates the packets to LISP sites or natively forwards them to non-LISP sites.

• Proxy egress tunnel router (PETR): A PETR is an infrastructure LISP network entity that de-encapsulates packets from LISP sites to deliver them to non-LISP sites.

• Map server (MS): An MS configures LISP site policy to authenticate when LISP sites try to register to the MS. It also performs the following functions:

  • Provides a service interface to the ALT router and injects routes in the ALT BGP when the site registers.

  • Receives MAP requests over the ALT router and encapsulates them to registered ETRs.

• Map resolver (MR): The MR performs the following functions:

  • Receives MAP requests, which are encapsulated by ITRs.

  • Provides a service interface to the ALT router, de-encapsulates MAP requests, and forwards on the ALT topology.

  • Sends negative MAP replies in response to MAP requests for non-LISP sites.

• ALT router (ALT): An ALT router is a router that runs External Border Gateway Protocol (eBGP) over an alternate Generic Routing Encapsulation (GRE) tunnel topology. It is an off-the-shelf router that does not run LISP. The ALT router simply forwards MAP requests according to the BGP Routing Information Base (RIB). ALT routers are used to aggregate BGP connections and to summarize EID prefix routes.

• LISP Delegated Database Tree (LISP-DDT): LISP-DDT is a hierarchical distributed database authority that provides EID-to-RLOC mappings. It is statically populated with the EID namespace and other nodes, called DDT nodes. Each DDT node is authoritative for one or more EID prefixes, or “child” DDT nodes, for more specific EID prefixes addressed by an authoritative DDT node.

The following sections discuss these components and features in detail.

Routing Locators and Endpoint Identifiers

The IPv4 or IPv6 address of a device represents its identity and location. In the present-day Internet, when a host moves from one location to another location, it is assigned a different IPv4 or IPv6 address, which overloads the location/identity semantic. LISP separates the location and identity of a device through the RLOC and EID. The RLOC represents the IP address of the egress tunnel router (ETR) the host is attached to, and the EID represents the IP address assigned to the host. With LISP, the change in location of a device does not result in a change in its identity. In other words, when the device moves from one location to another, it still retains its IPv4 or IPv6 address; however, the site tunnel router (xTR) is dynamically updated. Ensuring that the identity does not change for the host even with the change in location requires a mapping system. LISP provides the distributed architecture EID-to-RLOC mapping that maps EIDs to RLOCs. Figure 2-1 displays the location and identity separation in a network with EIDs and RLOCs.

Ingress/Egress Tunnel Routers (xTRs)

Both the ITRs and ETRs are also referred to as xTRs. The ITRs and ETRs play a vital role in packet forwarding in the LISP architecture.

An ITR is a router that performs the following tasks:

• Accepts an IP packet from a host and treats the IP destination as an EID

• Performs an EID-to-RLOC mapping lookup in its local map caches or remote map resolver in the event of a missed hit

• Prepends the packet with a LISP header, with the RLOC as the destination IP address

• Forwards the packet to the ETR that is hosting the RLOC

An ETR is a router that performs the following tasks:

• Accepts an IP packet with a LISP header, where the destination IP address is hosted by the router

• Strips the LISP header and forwards the packet based on the next IP header found on the packet

To further understand the functioning of the ITR and ETR routers, examine the topology shown in Figure 2-2. In this topology, there are two LISP sites, Site1 and Site2, with hosts in subnets 100.1.1.0/24 and 200.1.1.0/24. The Internet cloud has four ISP networks, with the subnets 10.0.0.0/8, 20.0.0.0/8, 30.0.0.0/8, and 40.0.0.0/8.

If the host 100.1.1.1 wants to reach host 200.1.1.2, the following control plane lookups happen in a LISP-enabled network:

• Step 1. Host S1 with IP address 100.1.1.1 performs a DNS lookup for destination host D1 with IP address 200.1.1.2.

• Step 2. After the DNS lookup is performed, the host forwards the packet to one of the ITRs, based on the routing and forwarding preference. In this case, the packet is sent to ITR1.

• Step 3. ITR1 receives the packet and checks the IP headers and does not find a relevant next-hop entry for forwarding the received packet with source IP address 100.1.1.1 and destination IP address 200.1.1.2. The ITR then thinks that it might be a potential packet for LISP encapsulation. It performs a lookup in the map cache entry and finds two locator sets for the destination 200.1.1.0/24 subnet.

• Step 4. The ITR creates an overlay from ITR to ETR with LISP encapsulation. The encapsulation of the IP packet happens on the ITR, and the de-encapsulation happens on the ETR.

• Step 5. The ETR forwards the IP packet to the destination host.

Map Servers (MSs) and Map Resolvers (MRs)

The fundamental behavior of LISP is to separate the EID from the RLOC, which allows the host to retain its identity even with a change in location. But the seamless mobility is achieved using the EID-to-RLOC mapping, which is maintained in the distributed database. The map server (MS) learns EID-to-RLOC mapping entries from the ETRs and publishes these mappings to the distributed mapping database. To publish its EID prefixes, an ETR periodically sends its mapping entries to the MS. The MS also receives the map requests via the mapping system and forwards them to the registered ETRs.

The map resolver (MR), on the other hand, accepts LISP encapsulated map requests from an ITR. Based on a map request, two things may happen.

• If the destination IP address is part of the EID namespace, the MR finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system.

• If the destination is not found in the EID namespace, then a negative map reply is sent to the ITR. This means that if the MR receives a map request for a non-LISP site, the MR sends a negative map reply in response.

To understand the functioning of MR/MS routers, examine the topology shown in Figure 2-3.

In this topology, when host S1 with IP address 100.1.1.1 tries to reach host D2 with IP address 200.1.1.2, it sends the packet to one of the local ITRs at the site. Then, if the ITR does not have an entry in its map cache table, the ITR creates a map request looking for the host 200.1.1.2 and sends it to the map resolver (MR). The map request is also LISP encapsulated where the outer header has the source IP address of 20.0.0.2 and destination IP address of 50.0.0.2. Based on the request, the MR forwards the map request to the map server (MS). The MS redirects the packet to the ETR, which has the information about the host prefix/subnet. One important thing to notice in this map request/map reply is that the map request comes toward the mapping system, but the mapping system does not send the reply. The ETR sends the map reply directly to the ITR that raised the map request. This significantly reduces the load on the MR/MS and at the same time helps validate the path between the ETR and the ITR. The map reply contain the mapping entries of the ETRs that hold the destination EIDs.

Figure 2-4 illustrates an example of an ITR sending a map request for a prefix in a non-LISP site.

In this scenario, if a host connected to the ITR tries to reach a destination that is on a non-LISP site, the ITR (as in the previous scenario) creates a map request and sends it to the MR. The MS performs a lookup to see whether the EID is present in its mapping database. If the MS cannot find a matching entry, it sends a negative map reply back to the originating ITR. On receiving the negative reply, the ITR updates its map cache entry with the tag forward-native, which means that the destination is part of a non-LISP site.

Proxy Ingress/Egress Tunnel Router (PxTR)

Sites cannot all be LISP enabled immediately, and not all segments of the network are not capable of running LISP from day 1. With the gradual migration from non-LISP-enabled sites to LISP-enabled sites, network operators still require that the non-LISP-capable sites be able to send traffic destined to LISP-enabled sites. This is where proxy ingress/egress tunnel routers (PxTRs) come into play.

Proxy ingress tunnel routers (PITRs) allow for non-LISP sites to send packets to LISP sites. A PITR is a new network element that shares many characteristics with a LISP ITR. A PITR allows non-LISP sites to send packets to LISP sites without requiring changes in the protocol or devices at the non-LISP sites. PITRs perform two primary functions:

• Originating EID advertisements: PITRs advertise highly aggregated EID-prefix space on behalf of LISP sites to the non-LISP sites so that the non-LISP sites can reach them.

• Encapsulating legacy Internet traffic: PITRs encapsulate non-LISP Internet traffic into LISP packets and route them toward their destination RLOCs.

Proxy egress tunnel routers (PETRs) are used to allow traffic from LISP sites to non-LISP sites. A PETR acts as an ETR for traffic sourced from LISP sites and destined to non-LISP sites. PETRs are useful in the following cases:

• Avoiding strict uRPF failures: Some providers’ access networks require the source of a packet to be within the address scope of the access networks. PETRs allow for LISP sites to send packets to non-LISP sites in cases where the access network does not allow for the LISP site to send packets with the source address of the site’s EIDs.

• Traversing a different IP protocol: The transit path network between LISP sites and non-LISP sites may not be IPv4 or IPv6 enabled. LISP support for mixed protocol encapsulation allows PETRs to hop over such networks in order to route the traffic between the LISP and non-LISP sites.

The LISP ALT System

The LISP Alternative Logical Topology (ALT) system is defined in RFC 6836. The LISP ALT system is a simple distributed index system that assists the ITR or MR in finding the ETR that holds the RLOC mapping information for a particular EID. ALT is a topology formed using GRE tunnels via which EIDs are routable. It is used to propagate mapping entries to the ITR. The purpose of the ALT system is to advertise EID prefixes in BGP on an alternative topology. The ALT system thus allows for incremental deployment of LISP. Figure 2-5 shows a LISP-enabled topology with ALT routers in the network.

An ALT-only device can be off-the-shelf gear that can be configured on router hardware or even on a Linux host. The device just needs to be BGP and GRE capable. Often users confuse the functionality of LISP ALT system. The ALT system does not distribute the actual EID-to-RLOC mappings but provides a forwarding path from an ITR or MR to an ETR that holds the mapping for a particular EID prefix.

LISP Canonical Address Format (LCAF)

There are two primary numbering spaces in the LISP architecture: EIDs and RLOCs. These addresses are either 32-bit for IPv4 or 128-bit for IPv6 and are encoded inside a LISP control message. Current deployment of LISP allows for only IPv4 and IPv6 AFI encodings, but other arbitrary address family identifier (AFI) values may need encodings for LISP to support them. To support such arbitrary AFIs, LISP introduced LISP Canonical Address Format (LCAF), defined in RFC 8060. IANA has assigned the AFI value 0x4003 (16387) to the LCAF.

The LCAF information gets encoded inside the LISP header. The initial 6 bytes of the canonical address are as follows (see Figure 2-6):

• 2-byte AFI field: Set to 16387.

• 1-byte Rsvd1 field: Reserved for future use. Set to 0.

• 1-byte Flags field: For future use. Set to 0.

• 1-byte Type field: Canonical Address Format encodings.

• 1-byte Rsvd2 field: Reserved for future use. Set to 0.

The Length field is a 2-byte field that holds the value, in bytes. The value of this field represents canonical address payload starting with and including the byte after the Length field.

The Type field can contain various values that represent the kinds of information encoded in the LISP canonical address. The various approved and unapproved values and their use cases are as follows:

• Type 0 (null body): In this case, the size of the Length field is set to 0 (that is, no other fields are part of the LCA payload). If the Length field is set to 0, the minimum length of the LCAF-encoded address will be either 8 bytes or 6 bytes, based on whether the AFI value is encoded as part of the LCA.

• Type 1 (AFI list): The AFI List LCAF type is used in DNS names or URIs as ASCII strings when such information is part of the mapping database system.

• Type 2 (instance ID): The instance IDs can be useful for creating multi-segmented VPNs within a LISP site. When the organizations inside LISP sites are using private addressing, the instance ID can help segregate those addresses.

• Type 3 (AS number): Type 3 is used to encode the AS number in the canonical address when the AS number is stored in the mapping database.

• Type 4 (application data): This type is unapproved.

• Type 5 (geo-coordinates): If the RLOCs are geographically displaced, an ETR may want to send the geographic location in the map reply. In such cases, the ETR sends the LCAF Type 5 with the RLOC’s physical location (latitude and longitude) in its locator set. Figure 2-7 shows a geo-coordinates LCAF.

• Type 7 (NAT traversal): Usually enterprises deploy network address translation (NAT) devices in their networks for security purposes. If a LISP system traverses a NAT device, it is required to convey the global address and mapped port information. In such instances, the NAT traversal LCAF type is used. Figure 2-8 shows a NAT traversal LCAF.

• Type 9 (multicast info): The distributed mapping database holds multicast group information. If an ITR requests an information on a multicast group address EID, the MS may return a replication list of RLOC group addresses or RLOC unicast addresses. A multicast info LCAF allows for encoding of multicast group information for a given VPN as well. For a given VPN, the mapping database holds the three-tuple entry (Instance ID, S-Prefix, G-prefix), where S-Prefix represents the source EID and G-Prefix represents the group EID.

• Type 10 (explicit locator path): Traffic engineering (TE) is the key to ensuring proper network and link utilization. The LISP control messages can be encoded with the explicit locator path (ELP) LCAF type to provide explicit re-encapsulation paths for a given EID prefix lookup in the mapping database to ensure that certain hops are traversed in order to reach a particular destination host. Figure 2-9 shows the ELP LCAF.

• Type 11 (security key): When a locator has a security key associated with it, it needs to be securely transmitted across the LISP system and over the Internet. The security key LCAF is used to encode the key material of the security key.

• Type 12 (source/dest key): Usually all the mapping database lookups are based on the destination EID prefix. But if the xTR requires a lookup based on a particular flow (for example, based on two-tuple entry of a source/destination pair), this LCAF type is used in the LISP control messages.

• Type 13 (replication list entry): The replication list entry LCAF encodes the locator being used for the unicast replication for multicast forwarding, as pointed by the multicast info LCAF. This locator entry is registered by the re-encapsulating tunnel routers that are participating in the overlay distribution tree.

LISP Packet Headers

When an xTR at one site knows about the mapping of the destination EID and the destination RLOC, the data packets from the client are encapsulated with the LISP header and sent to the destination site through the selected path. The xTR at the destination site strips off the LISP header and then forwards the packets to the destination host. LISP supports all four different encapsulations:

• IPv4-in-IPv4 encapsulation

• IPv6-in-IPv4 encapsulation

• IPv4-in-IPv6 encapsulation

• IPv6-in-IPv6 encapsulation

LISP IPv4-in-IPv4 Header Format

With the LISP IPv4-in-IPv4 header format, both the EID and RLOCs have IPv4 packet format. RFC 6830 defines the header shown in Figure 2-10 for such encapsulation.

In this format, the first 20 bytes are the outer header, which is an IPv4 header for the RLOC. It consists the information about the source and the destination RLOC. The outer header is followed by the UDP header, with the destination port 4341. Then comes the LISP header. The LISP header contains five different bits:

• N (nonce present bit): When this bit is set, the lower 24 bits of the initial 32 bits contain a nonce.

• L (locator status bits): When this bit is set to 1, the locator status bits (LSBs) in the next 32 bits inside the LISP header are in use. ITRs use LSBs to inform ETRs about the status (up/down) of all ETRs at the local site. These bits are used as a hint to convey router status (up/down) and not path reachability status.

• E (echo nonce request bit): This bit is set to 0 if the N bit is set to 0. It can be set to 1 only when the N bit is set to 1. This is useful when an ITR is also an ETR and the ITR is requesting the nonce to be echoed back to it in the LISP-encapsulated packets.

• V (map version bit): When this bit is set, the N bit is set to 0. With this bit set to 1, the lower 24 bits of the initial 32 bits of the LISP header are encoded with the map version. With the V bit set, the LISP header is encoded as shown in Figure 2-11.

• I (instance ID bit): When this bit is set, the LSBs are reduced from 32 bits to 8 bits, and the higher-order 24 bits are used for the instance ID.

After the LISP header, the next 20 bytes account for the inner IP header, which represents the source and destination EIDs.

LISP IPv6-in-IPv6 Header Format

With the LISP IPv6-in-IPv6 header format, both the EID and the RLOC are IPv6 based. Figure 2-12 shows the LISP IPv6-in-IPv6 header format, as defined in RFC 6830.

In this case, the outer header is a 40-byte IPv6 header containing information about the source and the destination RLOCs. The UDP header and the LISP header remain the same as described earlier. The inner header in this format is again a 40-byte IPv6 header with the information about the source and destination EIDs.

LISP Control Plane Messages

A LISP control plane message is a User Datagram Protocol (UDP) message with either a source or destination UDP port of 4342. The control plane packet is either in IPv4 or IPv6 format. Figure 2-13 shows the IPv4 control plane message format, and Figure 2-14 shows the IPv6 control plane message format. From the packet headers shown in Figures 2-13 and 2-14, notice that LISP message formats are similar to the previously discussed packet headers; however, in place of the LISP header, there is a LISP message, and there is no header for the EID.

These are the various LISP control plane messages, as defined in RFC 6830:

• Type 0: Reserved

• Type 1: LISP map request

• Type 2: LISP map reply

• Type 3: LISP map register

• Type 4: LISP map notify

• Type 8: LISP encapsulated control message

LISP Map Request

As defined in RFC 6830, a map request is initiated by the ITR and sent to the ETR of interest by the map server. A map request is initiated by an xTR when

• It needs a mapping for an EID.

• It wants to test an RLOC for reachability.

• It wants to refresh a mapping before TTL expiration.

• It receives from the ETR a solicitation for a map request (SMR) in case of a virtual host move.

As stated earlier, map requests can also be LISP encapsulated with a LISP type value set to encapsulated control message when sent from an ITR to an MR. In addition, map requests are LISP encapsulated the same way from an MS to an ETR. When a map request is sent, the source UDP port is chosen by the xTR (sender), but the destination UDP port is always 4342.

Figure 2-15 shows the map request message format. The map request contains information about the EID prefix, EID prefix length, and AFI that it belongs to, the ITR-RLOC address, and the ITR-RLOC AFI to which the ITR-RLOC address belongs. Note that at the end of the map request message, there is a map reply record. This field is useful when the M bit (the map data present bit) is set and can be used by an ETR to update its map cache entry for the EID-to-RLOC mapping for the source EID. When the M bit is set, it indicates that the map reply record segment is included in the map request.

LISP Map Reply

In response to a map request, the ETR sends a map reply with the EID-to-RLOC mapping information that is requested either in the destination field of the IP header of a data probe or the EID record of a map request. The RLOCs are globally routable IP addresses of all ETRs for the LISP site. In a map reply message for the map request message, the destination address is copied from the source address of the data probe message. The map reply can have an empty locator set. This kind of reply message is called a negative map reply message. The map reply is sent with the source UDP port number 4342, and the destination UDP port number is copied from the source port of either the map request or the invoking data packet.

Figure 2-16 shows the map reply message format. In the map reply, the record consists of information about the EID and the locator along with the respective AFI. It also contains a record time-to-live (TTL) field. The value of this field is the time, in minutes, the recipient of the map reply stores the mapping. If the TTL value is set to 0, the entry is removed from the cache immediately. If the value is set to 0xffffffff, the recipient decides locally how long it wants to save the entry in the map cache. Note that in Cisco’s implementation, when there is just 1 minute left for the map cache entry to expire, the xTR initiates another map request to update its map cache before the entry expires.

LISP Map Register Message

As explained in RFC 6833, an xTR sends a map register message to an MS to register its associated EID prefixes and also includes one or more RLOCs to be used by the MS when forwarding map requests. An MS can send a map reply in response to a map request on behalf of the xTR upon request. It is done by setting the P bit (the proxy map replay bit) in the map register message. The map register message is sent with the destination UDP port number 4342 and a random source UDP port. Figure 2-17 shows the map register message format. The map register message format is similar to the map reply message format, except that there are a few extra bits in a map reply message, and have an additional 8 bytes of key ID, authentication data length, and authentication data.

LISP Map Notify Message

An MS sends a map notify message to an xTR to confirm that the map register message was received and processed. An xTR requests that a map notify be returned by setting the M bit in the map register message. The map notify uses 4342 as both the source and destination UDP port number. Figure 2-18 shows the map notify message format.

LISP Database Architecture: LISP-DDT

The real magic that overcomes the challenges of the Internet and provides the LISP functionality is the mapping database. The mapping database contains the EID-to-RLOC mappings, which make it possible to identify which EIDs map to what locators. This mapping database allows support for millions of sites and changes happening across the sites. You can deploy multiple stand-alone MRs and MSs, but for a truly globally scaled MS, a hierarchical mapping system is required. In addition, a scaled and resilient mapping system needs to have an interface to the mapping system. LISP Delegated Database Tree (LISP-DDT) is one such mapping system that provides scalability and resiliency in a LISP-enabled network.

LISP-DDT provides a hierarchy for instance IDs and EID prefixes. LISP-DDT defines a new device type called a DDT node. DDT nodes are preconfigured with delegations that are based on static and secure delegation hierarchy, much like DNS. The parent DDT node is configured with a set of more specific sub-prefixes that are further delegated to other DDT nodes lower in the hierarchy. The DDT map resolvers send map requests to a preconfigured DDT node RLOC. The DDT nodes return map referral messages in response to the map request messages. The map referral message is a new LISP message type that assists with traversing the database tree. When the DDT node responds with a map referral message, it indicates either of the following:

• It is able to or will be able to find the requested mapping.

• Another DDT node is queried for more specific information.

Before discussing what different map referral messages mean, it’s vital to understand the extended EID prefix (XEID prefix). In order to have uniquely identifying prefixes in the mapping database, a unique database index key is created. This index key is formed by logically prepending and appending several fields to the EID prefix. These fields include a 16-bit database ID (DBID) field, a 32-bit instance ID (IID) field, a 16-bit AFI field, and a variable-length EID prefix field. The resulting concatenation of these fields is called an XEID prefix. All the EID prefixes in DDT are DDT clients and are referred to as XEID prefixes.

A map referral message can indicate two kinds of responses:

• Positive referrals: These responses are used to discover a DDT node’s RLOC for a given EID prefix:

  • Type 0 (NODE-REFERRAL): This type indicates that the replying DDT node delegated an XEID prefix that matches the requested XEID to one or more other DDT nodes. The map referral message contains a map record with additional information, most significantly the set of RLOCs to which the prefix was delegated.

  • Type 1 (MS-REFERRAL): This type indicates that the replying DDT node delegated an XEID prefix that matches the requested XEID to one or more DDT map servers.

  • Type 2 (MS-ACK): This type indicates that a replying DDT map server received a DDT map request that matches an authoritative XEID prefix for which it has one or more registered ETRs. This means that the request can be forwarded to one of those ETRs to provide an answer to the querying ITR.

• Negative referrals: These responses are used to indicate the following actions:

  • Type 3 (MS-NOT-REGISTERED): This type indicates that the replying DDT map server received a map request for one of its configured XEID prefixes that has no ETRs registered.

  • Type 4 (DELEGATION-HOLE): This type indicates that the requested XEID matches a non-delegated sub-prefix of the XEID space. This is a non-LISP “hole” that was not delegated to any DDT map server or ETR.

  • Type 5 (NOT-AUTHORITATIVE): This type indicates that the replying DDT node received a map request for an XEID request for which it is not authoritative. This occur if a cached referral becomes invalid due to a change in the database hierarchy.

Figure 2-19 shows a global LISP mapping system using LISP DDT. It is clear from this figure that there are primarily three different LISP nodes:

• DDT root nodes

• DDT map resolver nodes

• DDT map server nodes

The DDT root node forms the logical top of the database hierarchy. It is configured to be authoritative for all IIDs, AFIs, and EIDs included in the DDT hierarchy. The root node also delegates IIDs, AFIs, and EIDs to the lower-level DDT nodes that are authoritative for their piece of hierarchy. DDT root nodes perform the following functions:

• Accept map requests (from DDT map resolvers)

• Compute and return map referral Type 0 messages (positive)

• Compute and return map referral Type 4 messages (negative)

The DDT map resolvers performs the following functions:

• Accept and cache map requests from ITRs and PITRs

• Forward map requests to DDT root nodes

• Accept and follow map referral messages iteratively to query the DDT hierarchy

• Resolve the location of the DDT map server (map referral MS-ACK)

• Detect loops/delegation errors

• Send negative map reply (NMR) messages to ITRs and PITRs

The DDT map server nodes performs the following functions:

• Forward map requests to registered ETRs

• Return proxy map replies to ITRs

• Compute and return map referral DELEGATION-HOLE messages

• Compute and return map referral MS-NOT-REGISTERED messages

LISP-DDT Operations

To understand the LISP-DDT operations, examine the topology shown in Figure 2-20. In this topology, nodes Root-N1, DDT-N2, DDT-N3, and MS are configured with child prefixes and authoritative prefixes. Here are some instances:

• Root-N1 is configured as root for *

• Root-N1 delegates IID=0, 10.0.0.0/8 to DDT-N2

• DDT-N2 delegates IID=0, 10.0.0.0/16 to DDT-N3

• DDT-N3 delegates IID=0, 10.0.0.0/17 to MS

The topology also consists of MR, ITR1 and ITR2, and an ETR1 node. In this topology, MR is configured to point to the DDT root RLOC. The ETR1 node registers its prefix with MS, where the ETR prefix is within the delegation range of the MS node.

When the ITR sends a first map request message to the MR, the MR caches the map request and queues the pending requests. It then checks the referral cache, where it finds no entry. It then forwards the map request to its statically configured DDT root, which is the Root-N1 node in this case. Root-N1 then sends the map referral to the MR. In the map referral, Root-N1 tells the MR which node to try next, which in this case is the DDT-N2 node. This process keeps on happening until the map-request reaches the MS device that has the EID delegation. On receiving the map request, the MS node processes the map request and sends a map referral/MS-ACK to the MR, which then dequeues the pending request and caches the map referral. The MS node also forwards the map request to the ETR. Finally, the ETR sends a map reply to the ITR.

If the MR, on receiving the map request, finds an entry in the referral cache, it sends the map request to the cached referral MS. The MS node receives and processes the map request and sends the map referral/MS-ACK to the MR, which dequeues the pending request and forwards the map request to the ETR. The ETR then sends the map reply to the ITR.

The scenario and operational flow just described occur when the ETR EID prefix is registered with the MS, but imagine what happens when the EID prefix is not registered with the MS node. In such a scenario, the MS node, on receiving the map request, computes the DELEGATION-HOLE and sends a map referral/DELEGATION-HOLE (Type 4, negative referral, message) to the MR. The MR, on receiving the negative map referral, dequeues the pending request and caches the map referral. The MR then sends a negative map reply with the TTL value 15 minutes for the DELEGATION-HOLE to the ITR. The DELEGATION-HOLE set in the ACT (Action) field of the map referral message indicates that the XEID is not a LISP destination.

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.

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.

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.

Summary

This chapter describes the LISP core architecture and components. As discussed in this chapter, various LISP nodes play important roles in LISP. This chapter discusses details of the roles and functionality of xTRs, PxTRs, MR/MS, and ALT. This chapter also describes the various packet formats in exchanging LISP control plane messages. It is important to understand the purpose of various LISP control plane messages and when and from where they are triggered. This chapter also covers how to scale a LISP deployment for the global Internet by using LISP-DDT. The chapter concludes by examining the LISP software architecture on various Cisco platforms.

References

RFC 8060, “LISP Canonical Address Format (LCAF)”

RFC 6830, “The Locator/ID Separation Protocol (LISP)”