To configure an IPv4 or IPv6 endpoint identifier-to-routing locator (EID-to-RLOC) mapping relationship and an associated traffic policy for Locator/ID Separation Protocol (LISP), use the database-mapping command in LISP EID-table or LISP EID-table dynamic-EID configuration mode. To remove the configured database mapping, use the no form of this command.

Syntax Description

Command Default

No LISP database entries are defined.

Command Modes

LISP EID-table configuration (config-router-lisp-eid-table)

LISP EID-table dynamic-EID (config-router-lisp-eid-table-dynamic-eid)

Note	The EID-table dynamic-EID command mode only supports the locator-set option for configuring RLOCs and its associated policies.

Command History

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 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).

Related Commands

To specify an authentication key to validate the endpoint identifier (EID)-notify messages received from a device, use the eid-notify authentication-key command in Locator/ID Separation Protocol (LISP) EID-table dynamic-EID configuration mode. To remove the specified authentication key, use the no form of the command.

Command Default

No authentication key is specified to validate the EID-notify messages received from a device.

Command Modes

LISP EID-table dynamic-EID (config-router-lisp-eid-table-dynamic-eid)

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.

Related Commands

To enable sending of dynamic endpoint identifier (EID) presence notifications to a gateway xTR with the specified IPv4/IPv6 address along with the authentication key used with the gateway xTR, use the eid-notify key command in Locator/ID Separation Protocol (LISP) EID-table dynamic-EID configuration mode. To disable the configured options, use the no form of the command.

Command Default

No dynamic EID presence notifications are sent to the gateway xTR.

Command Modes

LISP EID-table dynamic-EID (config-router-lisp-eid-table-dynamic-eid)

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.

Related Commands

To configure a Locator ID Separation Protocol (LISP) instance ID for association with a virtual routing and forwarding (VRF) table or default table through which the endpoint identifier (EID) address space is reachable, use the eid-table command in LISP configuration mode. To remove this association, use the no form of this command.

Syntax Description

Command Default

A router configured for LISP associates the default table with instance ID 0.

Command Modes

LISP configuration (config-router-lisp)

Command History

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.

Related Commands

To configure a locator from a locator set associated with an IPv4 or IPv6 EID-prefix database-mapping to be unreachable (down), use the locator-down command in Locator/ID Separation Protocol (LISP) configuration mode. To return the locator to reachable (up) status, use the no form of this command.

Syntax Description

Command Default

An IPv4 or IPv6 locator associated with a configured IPv4 or IPv6 EID-prefix block is considered reachable (up) unless an Interior Gateway Protocol (IGP) routing protocol indicates it is down.

Command Modes

LISP configuration (config-router-lisp)

Command History

Usage Guidelines

When LISP database parameters are configured on an Ingress Tunnel Router (ITR) for specified IPv4 or IPv6 EID-prefix blocks using the database-mapping command or map-cache command, the locators associated with these IPv4 or IPv6 EID-prefix blocks are considered as reachable (up) by default. The locator-down command can be used to configure a locator from a locator-set associated with the EID-prefix database mapping to be down.

When this command is configured, the locator status bits (LSBs) for the configured locator will be cleared when packets are encapsulated and sent to remote sites. 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 egress tunnel router (ETR) will not encapsulate packets using this locator to reach the local site.

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

Related Commands

To specify a locator scope and enter Locator/ID Separation Protocol (LISP) locator scope configuration mode, use the locator-scope command in LISP configuration mode. To remove the specified locator scope, use the no form of the command.

Command Default

No locator-scope is specified.

Command Modes

LISP configuration (config-router-lisp)

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.

Related Commands

To associate a virtual routing and forwarding (VRF) table through which the routing locator address space is reachable to a router Locator ID Separation Protocol (LISP) instantiation, use the locator-table command in LISP configuration mode. To remove this association, use the no form of this command.

Syntax Description

Command Default

A router LISP instantiation is associated with the default (global) routing table.

Command Modes

LISP configuration (config-router-lisp)

Command History

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.

Related Commands

To configure a Locator/ID Separation Protocol (LISP) locator reachability algorithm, use the loc-reach-algorithm command in LISP configuration mode. To disable this functionality, use the no form of this command.

Syntax Description

Command Default

The locator reachability algorithm rloc-probing is disabled by LISP.

Command Modes

LISP configuration (config-router-lisp)

Command History

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.

Related Commands

To configure a static IPv4 or IPv6 endpoint identifier-to-routing locator (EID-to-RLOC) mapping relationship and its associated traffic policy, or to statically configure the packet handling behavior associated with a specified destination IPv4 or IPv6 EID prefix, use the map-cache command in Locator/ID Separation Protocol (LISP) configuration mode. To remove the configuration, use the no form of this command.

Syntax Description

Command Default

No static destination EID-to-RLOC mapping relationships are configured by default.

Command Modes

LISP configuration (config-router-lisp)

Command History

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.

Related Commands

To configure the interval, in seconds, that an xTR probes site-local routing locators (RLOCs), use the other-xtr-probe command in Locator/ID Separation Protocol (LISP) configuration mode. To return to the default setting, use the no form of this command.

Syntax Description

Command Default

Probing of site-local RLOCs is enabled by default and cannot be disabled. The default interval is 30 seconds.

Command Modes

LISP configuration (config-router-lisp)

Command History

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.

Related Commands

To specify a routing locator (RLOC) prefix to check against the ingress tunnel router (ITR) RLOC and the egress tunnel router (ETR) RLOC, use the rloc-prefix command in Locator/ID Separation Protocol (LISP) locator scope confuguration mode. To remove the RLOC prefix, use the no form of the command.

Command Default

No RLOC prefixes are defined.

Command Modes

LISP locator scope (config-router-lisp-locator-scope)

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.

Related Commands

To specify a locator set of the re-encapsulating tunnel router (RTR) routing locators (RLOCs), use the rtr-locator-set command in Locator/ID Separation Protocol (LISP) locator scope configuration mode. To remove the specified locator set, use the no form of the command.

Command Default

No RTR locator sets are defined.

Command Modes

LISP locator scope (config-router-lisp-locator-scope)

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.

Related Commands

To configure an instance-id to be associated with EID-prefixes for a LISP xTR, use the xtr instance-id command in LISP configuration mode. To disable this functionality, use the no form of this command.

Syntax Description

Command Default

By default, an xTR is not configured to use an instance-id.

Command Modes

LISP configuration

Command History

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.

Related Commands