Usage Guidelines

The ipv4 alt-vrf command is required for all LISP devices that are connected to the ALT for exchange of LISP control plane messages for IPv4 EID mapping resolution. The VRF instance specified using the ipv4 alt-vrf command is used to segment EID prefixes from the global table and must be configured to enable the IPv4 address family (use the ipv6 alt-vrf command to enable the IPv6 address family).

Additionally, you must use the ipv4 alt-vrf command (or ipv6 alt-vrf command for IPv6 EID mapping resolution) when configuring any LISP device as a map resolver (MR), map server (MS), or proxy ingress tunnel router (PITR). For these LISP devices, configuring the ipv4 alt-vrf or ipv6 alt-vrf command is required regardless whether the device is connected to an ALT for the exchange of map requests or is configured as a standalone MR, MS, PITR, or any combination of the three (such as when a LISP MS/MR device has full knowledge of the LISP mapping system for a private LISP deployment and is not connected to any ALT).

When configuring a device as a LISP ingress tunnel router (ITR) to resolve IPv4 EID-to-RLOC mappings for destination EIDs, you can configure the device to use one of the following two options:

When using the ALT, you must configure the correct address family (IPv4 or IPv6) for resolving EID-to-RLOC mappings. If an IPv4 EID mapping is required, configure the ipv4 alt-vrf command and specify a VRF that enables the IPv4 address-family and connects to an IPv4-capable ALT.

Note

Before this command is used, the referenced VRF must already have been created using the vrf definition command. In addition, the corresponding configurations for connecting the LISP device to the ALT, including the GRE tunnel interfaces and any routing associated with the VRF (static or dynamic) must also have been created.

Usage Guidelines

Use this command to enable IPv4 LISP ETR functionality on the router. A router configured as an IPv4 ETR is also typically configured with database-mapping commands so that the ETR knows what endpoint identifier (EID)-prefix blocks and corresponding locators are used for the LISP site. In addition, the ETR should be configured to register with a map server with the ipv4 etr map-server command, or to use static LISP EID-to-routing locator (EID-to-RLOC) mappings with the map-cache command to participate in LISP networking.

Note	A device configured as an ETR should also be configured as an Ingress Tunnel Router (ITR). However, the LISP architecture does not require this and ETR and ITR functionality can occur in different devices.

At the router lisp level,

• ipv4 etr enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 etr disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• no ipv4 etr negates the inherited configuration.

• default ipv4 etr reinherits the configuration from the router lisp level.

Usage Guidelines

When an ETR receives a map request message, the message may contain mapping data for the invoking IPv4 source-EID's packet. By default, the ETR ignores mapping data included in map-request messages. However, if you configure the ipv4 etr accept-map-request-mapping command, the ETR caches the mapping data in its map cache and immediately uses it for forwarding packets.

If you configure the optional verify keyword, the ETR caches the mapping data but does not use it for forwarding packets until the ETR can send its own map request to one of the locators from the mapping data record (and receives the same data in a map reply message).

If this command is enabled and then later disabled, issuing the command clear ip lisp map-cache is required to clear any map-cache entries currently in the "tentative" state. Map-cache entries can remain in the “tentative” state for up to one minute and thus it may be desirable to clear these entries manually when this command is removed.

At the router lisp level,

• ipv4 etr accept-map-request-mapping enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 etr accept-map-request-mapping disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• no ipv4 etr accept-map-request-mapping negates the inherited configuration.

• default ipv4 etr accept-map-request-mapping reinherits the configuration from the router lisp level.

Usage Guidelines

Use this command to change the default value associated with the TTL field in IPv4 map-reply messages. You can use this command to change the default TTL that remote ITRs will cache and use for your site’s IPv4 EID prefix. The default value is 1440 minutes (24 hours), and the minimum value is 60 minutes.

At the router lisp level,

• ipv4 etr map-cache-ttl enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 etr map-cache-ttl 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,

• ipv4 etr map-cache-ttl overrides the configuration inherited from the router lisp level.

• no ipv4 etr map-cache-ttl resets the configuration to the system default value.

• default ipv4 etr map-cache-ttl reinherits the configuration from the router lisp level.

Usage Guidelines

Use the ipv4 etr map-server command to configure the IPv4 or IPv6 locator of the map server to which the ETR will register for its IPv4 EIDs. The authentication key argument in the command syntax is a password that is used for a SHA-1 HMAC hash (included in the header of the map-register message).

You can configure the ETR to register with up to two map servers. After the ETR registers with the map servers, the map servers begin to advertise the EID-prefix blocks and RLOCs for the LISP site.

The password used for the SHA-1 HMAC may be entered in unencrypted (cleartext) form or encrypted form. To enter an unencrypted password, specify 0. To enter an AES encrypted password, specify 6.

Caution

Map server authentication keys entered in cleartext form will remain in cleartext form and be displayed in the configuration in cleartext form unless the Cisco IOS Encrypted Preshared Key feature is enabled. The Encrypted Preshared Key feature allows you to securely store plain text passwords in type 6 (AES) encryption format in NVRAM. To enable this feature, use the key config-key password-encryption and password encryption aes commands. For additional information on the Encrypted Preshared Key feature and its usage see: http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801f2336.shtml .

Caution

If you enable the Encrypted Preshared Key feature and then remove it, all type 6 encrypted keys immediately become unusable because the primary key is deleted—type 6 passwords cannot be unencrypted and used by the router. A warning message displays that details this and confirms the primary key deletion.

Note	The map server must be preconfigured with IPv4 EID prefixes that match the IPv4 EID-prefixes configured on this ETR using the database-mapping command, and a password matching the one provided with the key keyword on this ETR.

At the router lisp level,

• ipv4 etr map-server enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 etr map-server disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• ipv4 etr map-server overrides the configuration inherited from the router lisp level.

• no ipv4 etr map-server disables the configuration.

• default ipv4 etr map-server reinherits the configuration from the router lisp level.

Usage Guidelines

Use this command to enable the router to perform IPv4 LISP ITR functionality.

If a router configured as an ITR receives a packet for which no IPv4 destination address prefix match exists in the routing table and for which the source address of the packet matches an IPv4 EID-prefix block configured using the database-mapping command or map-cache command, then the packet is a candidate for LISP routing. In this case, the ITR sends a LISP map request to the map resolver configured using the ipv4 itr map-resolver command. Next, the ITR caches the IPv4 endpoint identifier-to-routing locator (EID-to-RLOC) mapping information returned by the associated map reply in its map cache. Subsequent packets destined to the same IPv4 EID-prefix block are then LISP-encapsulated according to this IPv4 EID-to-RLOC mapping entry.

Note	Devices are often configured as an ITR and as an Egress Tunnel Router (ETR). However, the LISP architecture does not require this and the functionality can occur in a different device.

At the router lisp level,

• ipv4 itr enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 itr disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• no ipv4 itr negates the inherited configuration.

• default ipv4 itr reinherits the configuration from the router lisp level.

Usage Guidelines

This command configures the locator to be used by a LISP ITR to reach the configured map resolver when sending a map request for IPv4 EID-to-RLOC mapping resolution.

A LISP ITR that needs to resolve an IPv4 EID-to-RLOC mapping for a destination EID can be configured to send a map request message either to a map resolver configured using the ipv4 itr map-resolver command, or directly over the LISP Alternative Logical Topology (ALT) using the ipv4 alt-vrf command. If a map resolver is used, map requests are sent to the map resolver with the additional LISP Encapsulated Control Message (ECM) header that includes the map resolver RLOC as its destination address. When the ALT is used, map requests are sent directly over the ALT without the additional LISP ECM header (the destination of the map request is the EID being queried).

At the router lisp level,

• ipv4 itr map-resolver enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 itr map-resolver disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• ipv4 ipv4 itr map-resolver overrides the configuration inherited from the router lisp level.

• no ipv4 itr map-resolver disables the configuration.

• default ipv4 itr map-resolver reinherits the configuration from the router lisp level.

Usage Guidelines

Use this command to control the maximum number of IPv4 LISP map-cache entries allowed to be stored on the router. The optional reserve-list keyword can be configured to guarantee that the referenced IPv4 EID-prefixes are always stored by the router.

LISP map-cache entries are added in one of two ways - dynamically or statically. Dynamic entries are added when a valid map-reply message is returned for a map-request message generated in response to a cache-miss lookup. Static IPV4 entries are added via the map-cache command. Whether a new map-cache entry is stored depends on the following conditions.

Dynamic map-cache entries are always added until the default or configured cache limit is reached. After the default or configured cache limit is reached, unless the optional reserve-list is configured, no further dynamic entries are added and no further map requests are generated in response to cache-miss lookups until a free position is available. Existing dynamic IPv4 map-cache entries can time-out due to inactivity or can be removed by the administrator via the clear ip lisp map-cache command to create a free position in the map-cache. When the optional reserve-list is configured, a map request will be generated and a new dynamic map-cache entry will be added for IPv4 EID prefixes found in the prefix-list referenced by the reserve-list keyword. In this case, a new entry will replace an existing dynamic entry so that the cache-limit is maintained. The dynamic entry deleted will be either a nonreserve idle map-cache entry, nonreserve active map-cache entry, reserve idle map-cache entry, or reserve active map-cache entry (in that order), whichever is available first for deletion. Idle map-cache entries are those that have seen no activity in the last 10 minutes.

Static map-cache entries are always added, even if the addition of the static entry exceeds the default or configured cache-limit. If the current map-cache contains dynamic entries, the addition of a new static entry will replace an existing dynamic entry such that the cache-limit is maintained. The dynamic entry deleted will be either a non-reserve idle map-cache entry, non-reserve active map-cache entry, reserve idle map-cache entry, or reserve active map-cache entry (in that order), whichever is available first for deletion. Idle map-cache entries are those that have seen no activity in the last 10 minutes.

Caution

Static map-cache entries count against the default or configured cache-limit. Since static entries are always added, static entries can be added beyond the default or configured cache limit. If the number of static entries configured exceeds the default or configured cache-limit, no dynamic entries can be added.

Note

If the reserve-list keyword is used, be sure that the prefix list includes entries that match all entries for which you expect to receive a map reply, including the “more-specifics”. This can be ensured by appending "le 32" to the end of all prefix-list entries for IPv4 prefixes. For example, if you want to match on any “more specifics” to 172.16.0.0/16, you specify ip prefix-list lisp-list seq 5 permit 172.16.0.0/16 le 32 in order to cover all replies within this range.

Note	The show ip lisp map-cache detail command provides additional details about the endpoint identifier-to-routing locator (EID-to-RLOC) mapping entries stored in the LISP map cache, including whether the prefix is covered by the reserve-list prefix list.

At the router lisp level,

• ipv4 map-cache-limit enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 map-cache-limit 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,

• ipv4 map-cache-limit overrides the configuration inherited from the router lisp level.

• no ipv4 map-cache-limit resets the configuration to the system default value.

• default ipv4 map-cache-limit reinherits the configuration from the router lisp level.

Usage Guidelines

An ITR forwards LISP packets based on endpoint identifier-to-routing locator (EID-to-RLOC) mapping policy data obtained from destination Egress Tunnel Routers (ETRs) and stored in its local map cache. When the map cache does not contain an entry for the destination prefix, the map resolution process is executed in order to build the map-cache entry. Even though this process takes a short amount of time, upon router reload it may be undesirable to wait for data-driven events to cause map-cache entries to be built.

The LISP map-cache persistence feature periodically stores dynamically learned remote EID map-cache entries to a file located in flash. When the router reloads, it checks for these files and uses the list of remote EIDs to prime the map cache after reboot. This ensures that packet loss after an xTR comes up is minimal because data-driven triggers are not required to repopulate the map cache for previously active EID prefixes.

Note	The remote EID prefixes listed in the stored file are used to trigger map requests. The map replies that return based on these map requests are what prime the map-cache. In this way, the map cache always contains fresh information upon reload.

Use the ipv4 map-cache-persistent command to control how often, in minutes, the ITR or PITR should save dynamically learned IPv4 map-cache entries to a file in flash. By default, map-cache persistence is set at 10 minutes. Use the no form of the command to disable LISP map-cache persistence. Alternatively, if the default value is changed, you can use the default form of this command to return the save interval setting to the default value.

Note	Use theshow run | include persistent command to determine the current state of this feature. If this command returns nothing, then map-cache persistence is enabled and set to the default value. Other output results are self-explanatory.

At the router lisp level,

• ipv4 map-cache-persistent interval enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 map-cache-persistent interval 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,

• ipv4 map-cache-persistent interval overrides the configuration inherited from the router lisp level.

• no ipv4 map-cache-persistent interval resets the configuration to the system default value.

• default ipv4 map-cache-persistent interval reinherits the configuration from the router lisp level.

Usage Guidelines

Use this command to configure the IPv4 source address to be used by the Ingress Tunnel Router (ITR) for LISP IPv4 map-request messages. Typically, a locator address configured in the database-mapping command is used as the source address for LISP IPv4 map-request messages. There are cases, however, where it may be desirable to configure the specified source address for these map-request messages. For example, when the ITR is behind a network address translation (NAT) device, you may have to specify a source address that matches the NAT configuration to properly allow for return traffic.

At the router lisp level,

• ipv4 map-request-source enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 map-request-source disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• ipv4 map-request-source overrides the configuration inherited from the router lisp level.

• no ipv4 map-request-source disables the configuration.

• default ipv4 map-request-source reinherits the configuration from the router lisp level.

Usage Guidelines

Use this command to enable the router to perform IPv4 LISP map-resolver functionality. A LISP map resolver is deployed as a LISP Infrastructure component.

Map resolvers also send negative map replies directly back to an Ingress Tunnel Router (ITR) in response to queries for non-LISP addresses.

Note	For a router configured as an IPv4 map resolver, you must configure the ipv4 alt-vrf command regardless whether the device is connected to an ALT for the exchange of map requests or is configured as a standalone map resolver. Refer to the ipv4 alt-vrf for related configuration information.

Usage Guidelines

Use this command to enable the router to perform IPv4 LISP map-server functionality. A LISP map server is deployed as a LISP infrastructure component. LISP site commands are configured on the map server for a LISP Egress Tunnel Router (ETR) that registers to the map server. The authentication key on the map server must match the one configured on the ETR. A map server receives map-register control packets from ETRs. A map server configured with a service interface to the LISP Alternative Logical Topology (ALT) injects aggregates for the registered EID prefixes into the LISP ALT.

The map-server also receives map-request control packets from the LISP-ALT, which it then forwards as a LISP encapsulated control messages (ECMs) to the registered ETR that is authoritative for the EID prefix being queried. The ETR returns a map-reply message directly back to the Ingress Tunnel Router (ITR).

Note	For a router configured as a IPv4 map server, you must configure the ipv4 alt-vrf command regardless whether the device is connected to an ALT for the exchange of map requests or is configured as a standalone map server. Refer to the ipv4 alt-vrf command for related configuration information.

Usage Guidelines

By default, IPv4 PMTUD is enabled for LISP. When IPv4 PMTUD is enabled, all LISP packets are sent with DF=1 in the outer IP header, and incoming IPv4 Internet Control Message Protocol (ICMP) Type 3 Code 4 (“Destination Unreachable, Fragmentation Needed and Don’t Fragment was Set”) messages are processed and maintained by LISP on a per-destination locator basis. The MTU setting for a destination locator will be updated according to the ICMP message as long as the requested new MTU is lower than the existing MTU but is still within the configured min and max keywords MTU boundaries.

IPv4 PMTUD can be disabled for LISP using the no ipv4 path-mtu-discovery command in LISP configuration mode. When IPv4 PMTUD is disabled, all LISP packets are sent with DF=0 in the outer IP header and LISP does not process incoming ICMP Type 3 Code 4 messages. Disabling IPv4 PMTUD for LISP is not recommended. To re-enable IPv4 PMTUD, use the ipv4 path-mtu-discovery command in LISP configuration mode without any additional parameters.

Usage Guidelines

Use this command to enable IPv4 LISP PETR functionality on the router. PETR functionality is a special case of Egress Tunnel Router (ETR) functionality where the router accepts LISP-encapsulated packets from an Ingress Tunnel Router (ITR) or Proxy ITR (PITR) that are destined to non-LISP sites, decapsulates them, and then forwards them natively toward the non-LISP destination.

PETR services may be necessary in several cases. For example, by default when a LISP site forwards packets to a non-LISP site natively (not LISP encapsulated), the source IP address of the packet is that of a site endpoint identifiers (EIDs). If the provider side of the access network is configured with strict unicast reverse path forwarding (uRPF), these packets are considered spoofed and dropped because EIDs are not advertised in the provider default free zone (DFZ). In this case, instead of natively forwarding packets intended for non-LISP sites, the ITR encapsulates the packets (using the site locator as the source address and the PETR as the destination address) so that packets destined for LISP sites will follow normal LISP forwarding processes and be sent directly to the destination ETR. As a second example, if a LISP IPv6 (EID) site wants to communicate with a non-LISP IPv6 site and some portion of the intermediate network does not support an IPv6 (it is IPv4 only). Assuming that the PETR has both IPv4 and IPv6 connectivity, the ITR can LISP-encapsulate the IPv6 EIDs with IPv4 locators destined for the PETR, which decapsulates the packets and forwards them natively to the non-LISP IPv6 site over its IPv6 connection. That is, the use of the PETR effectively allows the LISP sites packets to traverse (hop over) the IPv4 portion of the network using the LISP mixed protocol encapsulation support.

Note	A router that is configured as an ETR performs a check to verify that the LISP packet inner header destination address is within the address range of a local EID prefix, whereas a router configured as a PETR does not perform this check.

Note	When an ITR or PITR requires the use of IPv4 PETR services, the ITR or PITR must be configured to forward IPv4 EID packets to the PETR using the ipv4 use-petr command.

At the router lisp level,

• ipv4 proxy-etr enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 proxy-etr disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• no ipv4 proxy-etr negates the inherited configuration.

• default ipv4 proxy-etr reinherits the configuration from the router lisp level.

Usage Guidelines

Use this command to enable IPv4 LISP Proxy Ingress Tunnel Router (PITR) functionality on the router. PITR functionality is a special case of Ingress Tunnel Router (ITR) functionality where the router receives native packets from non-LISP sites that are destined for LISP sites, encapsulates them, and forwards them to the Egress Tunnel Router (ETR) that is authoritative for the destination LISP site endpoint identifier (EID).

PITR services are required to provide interconnectivity between non-LISP sites and LISP sites. For example, when connected to the Internet, a PITR acts as a gateway between the legacy Internet and the LISP-enabled network. To accomplish this, the PITR must advertise one or more highly aggregated EID prefixes on behalf of LISP sites into the underlying DFZ (that is, the Internet) and act as an ITR for traffic received from the public Internet.

If PITR services are enabled using the ipv4 proxy-itr command, the PITR creates LISP-encapsulated packets when it sends a data packet to a LISP site, sends a Data Probe, or sends a map-request message. The outer (LISP) header address-family and source address are determined as follows:

• When the locator-hash function returns a destination routing locator (RLOC) in the following ways:

  • A destination RLOC is returned within the IPv4 address-family, then the address ipv4-local-locator is used as the source address from the locator namespace.

  • A destination RLOC is returned within the IPv6 address-family (assuming the optional address ipv6-local-locator is entered), it will be used as a source locator for encapsulation.

• When configuring a router as a LISP PITR, you must configure the ipv4 alt-vrf command (or ipv6 alt-vrf command for IPv6 EID mapping) regardless whether the device is connected to an ALT for the exchange of map requests or is configured as a standalone PITR on the same device as a LISP MS/MR.

Note

A router cannot be configured to perform ITR and PITR functions at the same time. It must be configured for one or the other purpose. A router that is configured as an ITR performs a check to verify that the source of any packet intended for LISP encapsulation is within the address range of a local EID prefix, whereas a router configured as a PITR does not perform this check. If a router is configured as an ITR using the ipv4 itr command and an attempt is made to also configure PITR functionality, and an error indicating that ITR functionality must first be disabled is issued.

Note

When a device is configured as a non-ALT-connected PITR, it must also be configured with information defining the extent of the LISP EID space it is proxying for. This can be done using either static map-cache entries incorporating the map-request keyword, or by importing RIB routes using the ipv4 route-import map-cache command. The use of either method provides information to the non-ALT-connected PITR that allows it to send Map-Requests for destinations in order to determine their IPv4 EID-to-RLOC mappings, or negative-mapping results.

At the router lisp level,

• ipv4 proxy-itr enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 proxy-itr disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• ipv4 proxy-itr overrides the configuration inherited from the router lisp level.

• no ipv4 proxy-itr disables the configuration.

• default ipv4 proxy-itr reinherits the configuration from the router lisp level.

Usage Guidelines

When the ipv4 route-import database command is used with the optional route-map map-name keyword and argument, imported IPv4 prefixes are filtered according to the specified route map name and are associated with the specified locator set.

When the ipv4 route-import database command is used without the optional route-map keyword, all imported IPv4 prefixes are filtered and associated with the specified locator set.

Usage Guidelines

When a device is configured as a PITR, it must be informed about the extent of the IPv4 LISP EID space for which it is proxying to provide a means for signaling the LISP control plane process (map request generation) for populating the PITR IPv4 LISP map cache when it receives traffic.

If the PITR is configured to connect to an ALT infrastructure (see the ipv4 alt-vrf command), it will have full knowledge of the LISP IPv4 EID address space for which it is proxying. However, when a PITR is configured to use a map resolver for map-cache resolution, the LISP EID space for which it is proxying must be defined for the PITR to send map requests for destinations needed to determine IPv4 EID-to-RLOC mappings or negative mapping results.

The ipv4 route-import map-cache command provides a simple mechanism to define the extent of IPv4 LISP EID space for the PITR by taking advantage of the existing static, connected, the Interior Gateway Protocol (IGP) dynamic routing protocols EIGRP, OSPF, OSPFv3, and RIP or the Border Gateway Protocol (BGP)-based routing infrastructure. (Prior to the ipv4 route-import map-cache command, static map-cache entries with the map-request keyword were required to drive the LISP control plane.)

The type of IPv4 LISP EID space can be configured using the ipv4 route-import map-cache command with the protocol argument to import all appropriate IPv4 EID prefixes. In all cases, an optional route-map keyword can be added to provide filtering to selective import-appropriate EID prefixes. The route-map keyword can match on any useful criteria such as community, tag, or local preference.

Note	If the ipv4 route-import map-cache command is configured to use BGP and then BGP is removed (using the no router bgp autonomous-system-number command), the corresponding ipv4 route-import map-cache bgp configuration is not automatically removed.

Note	See the clear ip lisp route-import command for information about reimporting prefixes.

Usage Guidelines

When the ipv4 route-import map-cache command is configured, it may also be desired to configure a limit on the number of EID prefixes that can be imported by the PITR. This can be accomplished by configuring the ipv4 route-import maximum-prefix command. When the optional threshold value is specified, expressed as a percentage of the maximum limit, a warning message is generated when the number of IPv4 prefixes exceeds the threshold percentage. The warning-only keyword permits all prefixes to be imported but alerts the user when the threshold is exceeded.

Usage Guidelines

When a change occurs on an Egress Tunnel Router (ETR) for some attribute of an IPv4 EID prefix configured using the database-mapping command such as an associated routing locator (RLOC), priority, or weight, the ETR will automatically attempt to inform all LISP sites with which it has recently been communicating of this change. The ETR informs the other xTRs (with which it has recently been communicating) by sending a map request with the SMR bit in the header set to on to the RLOC addresses of those other xTRs. The ETR obtains the RLOC addresses by reviewing its own IPv4 LISP map cache, which contains these entries for the most recent conversations.

When an xTR receives the SMR map-request message from the ETR, the default response of the xTRs is to send a new map-request message with the SMR bit cleared through the Mapping System (such as through the configured map resolver) to get an up-to-date mapping for the EID indicated in the SMR map-request.

Once the map reply is received by the ETR for the new map request, the xTR will have an updated cache entry representing the changed state of the ETR that initially sent the SMR map request (as will all other xTRs that completed the SMR map-request process).

By default, xTRs process and respond to any map-request message that has the SMR bit set to on. Use the ipv4 solicit-map-request ignore command to disable this behavior, causing xTRs to ignore all map-request messages that have the SMR bit set to on. To restore SMR map request handling capabilities, use the no form of this command.

Note	A LISP ITR will only respond to an SMR map request only when it has an existing IPv4 map-cache entry for the EID in the SMR map request. If it does not have an entry, the SMR map request is ignored.

At the router lisp level,

• ipv4 solicit-map-request ignore enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 solicit-map-request ignore disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• no ipv4 solicit-map-request ignore negates the inherited configuration.

• default ipv4 solicit-map-request ignore reinherits the configuration from the router lisp level.

Usage Guidelines

Use the ipv4 use-petr command to enable an Ingress Tunnel Router (ITR) or Proxy Ingress Tunnel Router (PITR) to use IPv4 Proxy Egress Tunnel Router (PETR) services. When the use of PETR services is enabled, instead of natively forwarding LISP endpoint identifier (EID) (source) packets destined to non-LISP sites, these packets are LISP-encapsulated and forwarded to the PETR. Upon receiving these packets, the PETR decapsulates them and then forwards them natively toward the non-LISP destination.

PETR services may be necessary in several cases:

1. By default when a LISP site forwards packets to a non-LISP site natively (not LISP encapsulated), the source IP address of the packet is that of an EID. When the provider side of the access network is configured with strict unicast reverse path forwarding (uRPF) or an anti-spoofing access list, it may consider these packets to be spoofed and drop them since EIDs are not advertised in the provider core network. In this case, instead of natively forwarding packets destined to non-LISP sites, the ITR encapsulates these packets using its site locator(s) as the source address and the PETR as the destination address.

   Note

   The use of the ipv4 use-petr command does not change LISP-to-LISP or non-LISP-to-non-LISP forwarding behavior. LISP EID packets destined for LISP sites will follow normal LISP forwarding processes and be sent directly to the destination ETR as normal. Non-LISP-to-non-LISP packets are never candidates for LISP encapsulation and are always forwarded natively according to normal processes.

2. When a LISP IPv6 (EID) site needs to connect to a non-LISP IPv6 site and the ITR locators or some portion of the intermediate network does not support IPv6 (it is IPv4 only), the PETR can be used to traverse (hop over) the address family incompatibility, assuming that the PETR has both IPv4 and IPv6 connectivity. The ITR in this case can LISP-encapsulate the IPv6 EIDs with IPv4 locators destined for the PETR, which de-encapsulates the packets and forwards them natively to the non-LISP IPv6 site over its IPv6 connection. In this case, the use of the PETR effectively allows the LISP site packets to traverse the IPv4 portion of network using the LISP mixed protocol encapsulation support.

   Note	Because LISP supports mixed protocol encapsulations, the locator specified for the PETR in this case can either be an IPv4 or IPv6 address.

Up to eight PETR locators can be entered per address family. When multiple entries are made, the packet forwarding behavior is as follows:

• When multiple PETRs are configured using the ipv4 use-petr command by itself (that is, without the optional priority and weight configurations), packets are sent to each PETR based on hash-based load sharing.

• When multiple PETRs are configured using the ipv4 use-petr command and including the optional priority and weight configurations, packets are sent to each PETR according the normal LISP priority and weight load sharing algorithms. The priority configuration is used to determine load-sharing among PETR resources when multiple PETRs are specified. The weight configuration is used to determine how to loadshare traffic between multiple PETRs of identical priority when multiple PETRs are specified. The value represents the percentage of traffic to be load-shared.

Note

The use of the ipv4 use-petr command by itself (that is, without the optional priority and weight configurations) and with the optional priority and weight configurations at the same time is not permitted. Only one method may be used. If the ipv4 use-petr command is already configured without priority and weight , adding an additional PETR entry that includes priority and weight is not permitted. All entries that do not include priority and weight must first be removed prior to adding any entries that include priority and weight .

At the router lisp level,

• ipv4 use-petr enables the configuration for all the eid-tables defined under router lisp.

• no ipv4 use-petr disables the configuration for all the eid-tables under router lisp.

At the eid-table level,

• ipv4 use-petr overrides the configuration inherited from the router lisp level.

• no ipv4 use-petr disables the configuration.

• default ipv4 use-petr reinherits the configuration from the router lisp level.