Usage Guidelines

This command configures the LISP database parameters for a specified IPv4 or IPv6 EID-prefix block. Parameters for each IPv4 or IPv6 EID-prefix block include the associated locator, priority, and weight. The IPv4 or IPv6 address specified in the eid-prefix/prefix-length argument of the command syntax is the LISP IPv4 or IPv6 EID-prefix block associated with the site.

Typically, the device registers as being authoritative with a map server. The locator is typically the IPv4 or IPv6 address of any interface used as the RLOC address for the EID prefix assigned to the site but can also be the IPv4 or IPv6 address of a loopback interface. Priority and weight values are associated with the locator address to define traffic policies when multiple RLOCs are defined for the same EID-prefix block.

When a device is configured as an ETR, the LISP database-mapping parameters are advertised within a map-reply message to indicate the EID-prefix block and ingress traffic preferences of the site. An ITR then selects a destination locator (outer header) address for encapsulating packets destined to the EID prefix based on these advertised parameters.

Note

When LISP is configured for virtualization, multitenancy can be achieved by associating a LISP instance ID with a virtual routing and forwarding (VRF) table. The database-mapping command is configured after entering the eid-table command in LISP configuration mode so that the subsequent database-mapping entries are associated with the appropriate LISP instance ID specified in the eid-table command. Additional details on this usage of the database-mapping command with instance IDs can be found on the eid-table command page.

When a LISP site has multiple locators associated with the same EID-prefix block, multiple database-mapping commands are used to configure all of the locators for a given EID-prefix block. Each locator may be assigned the same or a different priority value from 0 to 255. When multiple locators are assigned different priority values, the priority value alone is used to determine which locator to prefer. A lower value indicates a more preferable path. A value of 255 indicates that the locator must not be used for unicast traffic forwarding. When multiple locators have the same priority, they can be used in a load-sharing manner.

In this case, for a given priority, the weight given to each locator is used to determine how to load-balance unicast packets between them. Weight is a value between 0 and 100 and represents the percentage of traffic to be load-shared to that locator. If a nonzero weight value is assigned to any locator for a given EID-prefix block, then all locators with the same priority for that same EID-prefix block must also be assigned a nonzero weight value. If a weight value of zero is assigned to any locator for a given EID-prefix block, then all locators with the same priority for that same EID-prefix block must also be assigned a weight value of zero. A weight value of zero indicates to an ITR receiving the map reply that it may decide how to load-share traffic destined to that EID-prefix block.

When a LISP site is assigned multiple IPv4 or IPv6 EID-prefix blocks, database mapping is configured for each IPv4 or IPv6 EID-prefix block assigned to the site and for each locator by which the IPv4 or IPv6 EID-prefix block is reachable.

Note	Prior to Cisco IOS Release 15.2(3)T and Cisco IOS XE Release 3.6S, a maximum of 10 database-mapping entries were permitted per site. Beginning with Cisco IOS Release 15.2(3)T and Cisco IOS XE Release 3.6S, this limit has been raised to 100 database-mapping entries.

When multiple ETRs are used at a LISP site, the database-mapping command must be configured on all ETRs for all locators by which an IPv4 or IPv6 EID-prefix block is reachable, even when the locator is not local to the specific ETR being configured. For example, if a site uses two ETRs and each has a single locator, both ETRs must be configured with the database-mapping command for the assigned IPv4 or IPv6 EID-prefix block for its own locator as well as the locator of the other ETR. That is, all ETRs will have identical database-mapping command configurations.

When the IPv4 or IPv6 address of an interface to be used as a routing locator is determined dynamically, such as by DHCP, you must specify the name of the interface that will be used as the locator rather than directly configuring the IP address. In this case, use the ipv4-interface interface-name or ipv6-interface interface-name keyword-argument pair of the database-mapping command to configure the appropriate RLOC.

When multiple ETRs are used at a LISP site, you must configure consistent database-mapping commands on all ETRs for all locators—including those local and not local to each ETR. To accomplish this when the database-mapping eid-prefix/prefix-length ipv4-interface interface-name or ipv6-interface interface-name form of the database-mapping command is configured for local locators, the database-mapping eid-prefix/prefix-length auto-discover-rlocs form of the command must be used to indicate that other ETRs within the same LISP site also have dynamic locators. Configuring the auto-discover-rlocs keyword signals to the map server that it should merge all locators for the associated EID prefixes within map-register messages it receives from all of the ETRs within a LISP site and send the merged locator set back to all registering ETRs via a map-notify message.

Note	To reduce the configuration length and complexity when a LISP site contains multiple xTRs, configure the auto-discover-rlocs form of the database-mapping command (even when static addresses are used for local locators).

When the optional down keyword is used with the database-mapping command, the priority value of the specified locator is set to 255 in registrations to the mapping system as well as in advertised mapping records to indicate to remote sites that the locator is down. Using the "down" option eliminates the need to change the priority configuration (to 255) of the same database-mapping command.

Usage Guidelines

Configure this command on an xTR or a PxTR to enable LISP decapsulation filtering. When enabled, the source RLOC addresses of incoming LISP packets are validated against the 'member' filter list. RLOCs that match the filter list are decapsulated while those that do not are dropped. When the member keyword is used, the registered RLOC membership list will be automatically obtained from the Map-Server. When the locator-set locator-set-name keyword-argument pair is used, the prefixes named in the locator-set are used, if included alone, or added to the (downloaded) dynamic list when used in conjunction with the member keyword. Typically, this option is used to add PITRs which do not register with a Map-Server and are thus not automatically included in the registered RLOC membership list.

Usage Guidelines

Use the eid-notify authentication-key command to specify an authentication key that the site gateway uses to authenticate endpoint identifier (EID)-notify messages that are received from a device. This command is configured on a site gateway device. A device that functions both as an ingress tunnel router (ITR) and egress tunnel router (ETR) is known as an xTR .

After the site gateway xTR authenticates an EID-notify message for a particular host discovery and if a different LISP device registers the same host later, as in the case of a virtual machine (VM) move, the site gateway xTR sends a unicast map-notify control plane message to the original first-hop router (FHR) to signal the change in host location.

Usage Guidelines

Use the eid-notify key command to configure a site gateway xTR on a first-hop router (FHR). This ensures that an EID-notify message is sent to the site-gateway xTR upon the discovery of a host. A device that functions both as an ingress tunnel router (ITR) and an egress tunnel router (ETR) is known as an xTR. The key is specific to a site gateway xTR.

The EID-notify message is a special map-notify control plane message that uses the ipv4-address or ipv6-address as the destination IP address that is specified using the eid-notify key command and any of the specified locator-set entries as the source IP address that is configured using the database-mapping dynamic-eid-prefix/prefix-length locator-set name command in LISP EID table dynamic EID configuration mode.

Usage Guidelines

The eid-table command is used to associate a LISP instance ID with either the default routing table, or a VRF table through which its EID address space is reachable. When a LISP instance ID is specified, LISP Map Registration (control plane) messages include this instance ID along with the associated EID prefixes upon registering and LISP data plane packets include this instance ID in the LISP header.

LISP virtualization can be used to support multiple organizations within a LISP site, also known as multitenancy. For example, this may be useful when multiple organizations use private addresses [RFC1918] as EID-prefixes and where these addresses might be duplicated between organizations, or when segmentation of a customer traffic virtual private network (VPN) in general is required. Adding a LISP instance ID in the address encoding makes the entire address unique, thus preventing duplication and providing segmentation. Multiple segments can be created inside a LISP site by associating a LISP instance ID with the specific VRF tables used for these VPNs.

Note

When LISP is configured without virtualization, the eid-table command is not required and all LISP commands are simply entered directly under the router lisp command. The eid-table command is only required for configuring LISP virtualization. However, the eid-table command may be used even when LISP is configured without virtualization by using the eid-table default instance-id 0 command form. When this form of the eid-table command is used, the default keyword can be used only with the instance-id 0 keywords when other instance IDs are specified.

When an instance ID is configured on any LISP device, the same instance ID must be configured on all other LISP devices participating in the same virtualized LISP environment. For example, when an instance ID is configured on an xTR, this instance ID is included with the EID prefixes during registration with the map server. The map server must therefore also be configured to use the same instance ID within the EID prefix configurations for this LISP site in order for the registration to succeed. (A LISP instance ID is configured on the map server using the eid-prefix command within LISP site configuration mode.)

Note	When the eid-table vrf vrf-name command is used, the referenced VRF must already be created using the vrf definition command and at least one address family must be enabled within that VRF.

Usage Guidelines

When LISP database parameters are configured on an Egress Tunnel Router (ETR) for specified IPv4 or IPv6 EID-prefix blocks using the database-mapping command, the locator (or locators) associated with these IPv4 or IPv6 EID-prefix blocks is considered as reachable (up) by default, assuming that: (1) it corresponds to a local interface on the box that is not shut, or (2) it corresponds to a locator addresses on another xTR of the same site that and that locator is up and reachable via local site routing. The locator-down command can be used to configure a locator associated with the EID-prefix database mapping, to be administratively down.

When this command is configured, the locator status bits (LSBs) for the configured locator are cleared when packets are encapsulated and sent to remote sites. The egress tunnel routers (ETRs) at remote sites look for changes in the LSBs when decapsulating LISP packets. When the LSBs indicate that a specific locator is down, the ETR does not encapsulate packets using this locator to reach the local site.

Note	If this command is configured on an ETR to indicate that a locator is unreachable (down) and the LISP site includes multiple ETRs, this command must be configured on all ETRs at the site to ensure that the site consistently tells remote sites that the configured locator is not reachable.

Usage Guidelines

Use the locator-scope command to specify the locator scope name and to define the disjointed routing locator (RLOC) scopes. The map server will consider disjointed RLOCs in its map-request message only if the locator scopes are configured.

Usage Guidelines

When a LISP device is deployed in a multitenant (virtualized) network environment with segmented routing locator (RLOC) address space, separate router LISP instantiations are required for each locator address space. Separate instantiations are created by including the optional id entry with the router lisp command. Each router LISP instantiation is considered to be standalone and must be associated with an RLOC address space. The locator-table command is used to associate a VRF table through which the routing locator address space is reachable to a router LISP instantiation. All necessary LISP components used in the operation of that particular router LISP instantiation, (for example, map server, map resolver, proxy ingress tunnel router (PITR), proxy egress tunnel router (PETR), and other routers that function as both egress and ingress tunnel routers, also known as xTRs) must be reachable via the routing locator address space referred to by the locator-table command.

Note

Most multitenant deployments will not require separate locator forwarding tables. As with most current virtualization schemes, LISP endpoint ID (EID) virtualization (configured using the eid-table instance-id keywords) does not require locators and map-resolver/map-server (MR/MS) devices to exist in a VRF.

The following guidelines may be helpful in understanding the use of the locator-table command when RLOC address space virtualization is configured.

Router LISP instantiations are configured:

• When a router LISP instantiation is created without using the optional ID entry or when using the optional ID entry with a value of 0 (that is, router lisp 0 ), and no locator table is specified using the locator-table command. That particular router LISP instantiation then automatically uses the default (global) routing table as its RLOC or locator table. All locators, map resolvers, map servers, PETRs, PITRs, and other LISP devices must be reachable via the default routing table.

• When a router LISP instantiation is created using an optional ID entry other than 0, a locator table must be specified using the locator-table command. That particular router LISP instantiation then uses the routing table (default or VRF) referenced by the locator-table command and all locators, map resolvers, map servers, PETRs, PITRs, and other LISP devices must be reachable via a specified routing table.

• Only a single locator-table command can be configured per router LISP instantiation. Within each router LISP instantiation, multiple EID table instances may be configured, as necessary, to associate all EID address space with that routing locator addresses space.

• When a router LISP instantiation is created, it can only use a routing locator address space that has not already previously been assigned to another router LISP instantiation. That is, the default (global) routing table or any single VRF table referenced by a locator-table command can only be assigned within a single router LISP instantiation. Likewise, endpoint identifier (EID) address space referenced by the eid-table command can only be associated with a single router LISP instantiation.

Note	When the locator-table vrf vrf-name command is used, the referenced VRF must already have been created using the vrf definition command, and at least one address family must be enabled within that VRF.

Usage Guidelines

Use the loc-reach-algorithm command to enable LISP locator reachability algorithms. RLOC-probing is the only locator reachability algorithm available in Cisco IOS and Cisco IOS XE versions of LISP and it is disabled by default. To disable RLOC probing, use the no form of this command.

The RLOC-probing algorithm is a method used by a LISP to determine the reachability status of locators cached in its map cache. It involves the periodic exchange of special map-request and map-reply messages between an Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR) to validate locator reachability. The advantage of using RLOC probing is that it can handle a variety of failure scenarios, allowing the ITR to determine when the path to a specific locator is reachable or has become unreachable. This provides a robust mechanism for switching to using another locator from the cached locator.

At the router lisp level,

• loc-reach-algorithm enables the configuration for all the eid-tables defined under router lisp.

• no loc-reach-algorithm disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• no loc-reach-algorithm negates the inherited configuration.

• default loc-reach-algorithm reinherits the configuration from the router lisp level.

Usage Guidelines

The first use of this command is to configure an Ingress Tunnel Router (ITR) with a static IPv4 or IPv6 EID-to-RLOC mapping relationship and its associated traffic policy. For each entry, a destination EID-prefix block and its associated locator, priority, and weight are entered. The value in the EID-prefix/prefix-length argument is the LISP EID-prefix block at the destination site. The locator is an IPv4 or IPv6 address of the remote site where the IPv4 or IPv6 EID-prefix can be reached. Associated with the locator address is a priority and weight that are used to define traffic policies when multiple RLOCs are defined for the same EID-prefix block. This command can be entered up to eight times for a given EID-prefix. Static IPv4 or IPv6 EID-to-RLOC mapping entries configured using this command take precedence over dynamic mappings learned through map-request and map-reply exchanges.

The second, optional use of this command is to statically configure the packet handling behavior associated with a specified destination IPv4 or IPv6 EID prefix. For each entry, a destination IPv4 or IPv6 EID-prefix block is associated with a configured forwarding behavior. When a packet’s destination address matches the EID prefix, one of the following packet handling options can be configured:

• drop - Packets matching the destination IPv4 or IPv6 EID prefix are dropped. For example, this action may be useful when administrative policies define that packets should be prevented from reaching a site.

• map-request - Packets matching the destination IPv4 or IPv6 EID prefix cause a map request to be sent. It is implied that the map reply returned by this request will allow subsequent packets matching this EID prefix to be LISP-encapsulated. This action may be useful for troubleshooting map-request activities and other diagnostic actions.

• native-forward - Packets matching the destination IPv4 or IPv6 EID prefix are natively forwarded without LISP encapsulation. This action may be useful when the destination site is known to always be reachable natively and LISP encapsulation should never be used.

Usage Guidelines

Usage Guidelines

When a LISP site contains more than one xTR, all xTRs that are part of the same LISP site must be configured with consistent EID-to-RLOC mapping information using the database-mapping command. From the perspective of any xTR within the LISP site, one or more RLOCs will be local to that xTR (referred to as site-self in show command outputs), and one or more RLOCs will be local the other xTRs that are part of the same LISP site (and referred to as site-other in show command outputs). For a LISP site to maintain an accurate status of all locators within the site, each xTR sends RLOC probes to all site-other RLOCs.

Use the other-xtr-probe command to change the probe interval for sending RLOC probes to all site-other RLOCs.

Note

This functionality is enabled by default and cannot be disabled. The default interval is 30 seconds. Use the show run | include other-xtr-probe command to display the configured interval. When an output value is displayed, the value is configured for something other than the default value. When no output is displayed, it is configured for the default.

At the router lisp level,

• other-xtr-probe period enables the configuration for all the eid-tables defined under router lisp.

• no other-xtr-probe period resets the configuration to the system default value and the system default value is inherited by all the eid-tables defined under router lisp.

At the eid-table level,

• other-xtr-probe period overrides the configuration inherited from the router lisp level.

• no other-xtr-probe period resets the configuration to the system default value.

• default other-xtr-probe period reinherits the configuration from the router lisp level.

Usage Guidelines

Use the rloc-prefix command to specify a RLOC prefix to define locator scopes on a LISP map server. The map server uses these defined locator scopes to determine how to process the LISP map-request message that it receives.

Usage Guidelines

Use the rtr-locator-set command on a LISP map server to specify a locator set that includes the RLOCs of an RTR that are associated with a particular locator scope.

You must define a locator set before referring to it by using the locator-set command.

Usage Guidelines

Virtualization support is currently is available in LISP xTRs and MS/MRs. The instance-id has been added to LISP to support virtualization.

Use the xtr instance-id command to configure the instance-id associated with this xTR. Only one instance-id can be configured on an xTR. When an instance-id is configured, this instance-id will be included with the EID-prefixes when they are registered with the Map-Server. The Map-Server must also include the same instance-id within the EID-prefix configurations for this LISP site. Instance-id’s are configured on the Map-Server using the eid-prefix command in LISP Site configuration mode.

Note	Virtualization support is not currently available for the LISP ALT, which means that it is also not supported on LISP PITRs. To configure an xTR that is configured with an instance-id to communicate with non-LISP sites, you must use NAT techniques instead of a PITR for this functionality.