Cisco IOS IP Switching Command Reference

 

Syntax Description

 

Command Default

The invalidation rate of the IP route cache is not controlled.

 

Command History

 

Usage Guidelines

After you enter the ip cache-invalidate-delay command all cache invalidation requests are honored immediately.

Caution This command should only be used under the guidance of technical support personnel. Incorrect settings can seriously degrade network performance. The command-line-interface (CLI) will not allow you to enter the ip cache-invalidate-delay command until you configure the service internal command in global configuration mode.

---

The IP fast-switching and autonomous-switching features maintain a cache of IP routes for rapid access. When a packet is to be forwarded and the corresponding route is not present in the cache, the packet is process switched and a new cache entry is built. However, when routing table changes occur (such as when a link or an interface goes down), the route cache must be flushed so that it can be rebuilt with up-to-date routing information.

This command controls how the route cache is flushed. The intent is to delay invalidation of the cache until after routing has settled down. Because route table changes tend to be clustered in a short period of time, and the cache may be flushed repeatedly, a high CPU load might be placed on the router.

When this feature is enabled, and the system requests that the route cache be flushed, the request is held for at least minimum seconds. Then the system determines whether the cache has been “quiet” (that is, less than threshold invalidation requests in the last quiet seconds). If the cache has been quiet, the cache is then flushed. If the cache does not become quiet within maximum seconds after the first request, it is flushed unconditionally.

Manipulation of these parameters trades off CPU utilization versus route convergence time. Timing of the routing protocols is not affected, but removal of stale cache entries is affected.

Examples

The following example shows how to set a minimum delay of 5 seconds, a maximum delay of 30 seconds, and a quiet threshold of no more than 5 invalidation requests in the previous 10 seconds:

 

Related Commands

 

Syntax Description

 

Command Default

Cisco Express Forwarding is enabled by default on most platforms. To find out if Cisco Express Forwarding is enabled by default on your platform, enter the show ip cef command.

 

Command History

 

Usage Guidelines

The ip cef command is not available on the Cisco 12000 series because that router series operates only in distributed Cisco Express Forwarding mode. Distributed Cisco Express Forwarding is enabled also on the Cisco 6500 series router.

Cisco Express Forwarding is advanced Layer 3 IP switching technology. Cisco Express Forwarding optimizes network performance and scalability for networks with dynamic, topologically dispersed traffic patterns, such as those associated with web-based applications and interactive sessions.

If you enable Cisco Express Forwarding and then create an access list that uses the log keyword, the packets that match the access list are not Cisco Express Forwarding switched. They are fast switched. Logging disables Cisco Express Forwarding.

The following example shows how to enable standard Cisco Express Forwarding operation:

The following example shows how to enable distributed Cisco Express Forwarding operation:

 

Related Commands

 

Syntax Description

 

Command Default

Accounting is disabled by default.

 

Command History

 

Usage Guidelines

Collecting statistics can help you better understand Cisco Express Forwarding patterns in your network.

When you enable network accounting for Cisco Express Forwarding from global configuration mode, accounting information is collected at the Route Processor (RP) when Cisco Express Forwarding mode is enabled and at the line cards when distributed Cisco Express Forwarding mode is enabled. You can then display the collected accounting information using the show ip cef privileged EXEC command.

For prefixes with directly connected next hops, the non-recursive keyword enables express forwarding of the collection of packets and bytes through a prefix. This keyword is optional when this command is used in global configuration mode.

This command in interface configuration mode must be used in conjunction with the global configuration command. The interface configuration command allows a user to specify two different bins (internal or external) for the accumulation of statistics. The internal bin is used by default. The statistics are displayed through the show ip cef detail command.

Per-destination load balancing uses a series of 16 hash buckets into which the set of available paths are distributed. A hash function operating on certain properties of the packet is applied to select a bucket that contains a path to use. The source and destination IP addresses are the properties used to select the bucket for per-destination load balancing. Use the load-balance-hash keyword with the ip cef accounting command to enable per-hash-bucket counters. Enter the show ip cef prefix internal command to display the per-hash-bucket counters.

Note The ip cef accounting command is not supported on the Cisco 7600 series router.

Examples

The following example shows how to enable the collection of Cisco Express Forwarding accounting information for prefixes directly connected to the next hops:

 

Related Commands

 

Syntax Description

 

Command Default

If you do not configure a line card memory pool for the Cisco Express Forwarding queuing messages, the default is the IPC memory allocation for the switching platform.

 

Command History

 

Usage Guidelines

This command is available only on distributed switching platforms.

If you are expecting large routing updates to the Route Processor (RP), use this command to allocate a larger memory pool on the line cards for queuing Cisco Express Forwarding routing update messages. The memory pool reduces the transient memory requirements on the RP.

To display and monitor the current size of the Cisco Express Forwarding message queues, use the show cef linecar d command. Also, the peak size is recorded and displayed when you use the detail keyword.

Examples

The following example shows how to configure the Cisco Express Forwarding line card memory queue to 128000 kilobytes per second:

 

Related Commands

 

Syntax Description

original	Sets the load-balancing algorithm to the original algorithm based on a source and destination hash.
tunnel	Sets the load-balancing algorithm for use in tunnel environments or in environments where there are only a few IP source and destination address pairs.
id	(Optional) Fixed identifier.
universal	Sets the load-balancing algorithm to the universal algorithm that a src ip, a dest ip, a source port, a dest port, an L4 protocol and an ID hash. Note Any changes in these fields can result in the load balance based on the available links. Fragmented packets will be forwarded to two different links by this algorithm.
include-ports source	Sets the load-balancing algorithm to the include-ports algorithm that uses a Layer 4 source port.
include-ports destination	Sets the load-balancing algorithm to the include-ports algorithm that uses a Layer 4 destination port.
include-ports source destination	Sets the load balancing algorithm to the include-ports algorithm that uses Layer 4 source and destination ports.

 

Command Default

The universal load-balancing algorithm is selected. If you do not configure the fixed identifier for a load-balancing algorithm, the router automatically generates a unique ID.

 

Command History

 

Usage Guidelines

The original Cisco Express Forwarding load-balancing algorithm produced distortions in load sharing across multiple routers because of the use of the same algorithm on every router. When the load-balancing algorithm is set to universal mode, each router on the network can make a different load sharing decision for each source-destination address pair, and that resolves load-balancing distortions.

The tunnel algorithm is designed to share the load more fairly when only a few source-destination pairs are involved.

The include-ports algorithm allows you to use the Layer 4 source and destination ports as part of the load-balancing decision. This method benefits traffic streams running over equal-cost paths that are not loadshared because the majority of the traffic is between peer addresses that use different port numbers, such as Real-Time Protocol (RTP) streams. The include-ports algorithm is available in Cisco IOS Release 12.4(11)T and later releases.

Examples

The following example shows how to enable the Cisco Express Forwarding load-balancing algorithm for tunnel environments:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

If this command is not configured, Cisco Express Forwarding does not optimize the address resolution of directly connected neighbors for IPv4.

 

Command History

 

Usage Guidelines

The ip cef optimize neighbor resolution command is very similar to the ipv6 cef optimize neighbor resolution command, except that it is IPv4-specific.

Use this command to trigger Layer 2 address resolution of neighbors directly from Cisco Express Forwarding for IPv4.

Examples

The following example shows how to optimize address resolution from Cisco Express Forwarding for directly connected neighbors:

 

Related Commands

 

Syntax Description

 

Defaults

All Cisco Express Forwarding adjacency prefix management is disabled by default.

 

Command History

 

Usage Guidelines

When Cisco Express Forwarding is configured, the forwarding information base (FIB) table may conflict with static host routes that are specified in terms of an output interface or created by a Layer 2 address resolution protocols such as Address Resolution Protocol (ARP), map lists, and so on.

The Layer 2 address resolution protocol adds adjacencies to Cisco Express Forwarding, which in turn creates a corresponding host route entry in the FIB table. This entry is called an adjacency prefix.

override

If the Cisco Express Forwarding adjacency prefix entries are also configured by a static host route, a conflict occurs.

This command ensures that adjacency prefixes can override static host glean routes, and correctly restore routes when the adjacency prefix is deleted.

validate

When you add a /31 netmask route, the new netmask does not overwrite an existing /32 Cisco Express Forwarding entry. This problem is resolved by configuring the validate keyword to periodically validate prefixes derived from adjacencies in the FIB against prefixes originating from the RIB.

Examples

override

The following example shows how to enable Cisco Express Forwarding table adjacency prefix override:

validate

The following example shows how to enable Cisco Express Forwarding table adjacency prefix validation:

 

Syntax Description

 

Command Default

All consistency checkers are disabled by default.

 

Command History

 

Usage Guidelines

This command configures Cisco Express Forwarding table consistency checkers and parameters for the detection mechanism types that are listed in Table 2 .

Examples

The following example shows how to enable the Cisco Express Forwarding consistency checkers:

 

Related Commands,

 

Syntax Description

 

Defaults

Default size for event log is 10000 entries.

 

Command History

 

Usage Guidelines

This command is used to troubleshoot inconsistencies that occur in the Cisco Express Forwarding event log between the routes in the Routing Information Base (RIB), Route Processor (RP) Cisco Express Forwarding tables, and line card Cisco Express Forwarding tables.

The Cisco Express Forwarding event log collects Cisco Express Forwarding events as they occur without debugging enabled. This process allows the tracing of an event immediately after it occurs. Cisco technical personnel may ask for information from this event log to aid in resolving problems with the Cisco Express Forwarding feature.

When the Cisco Express Forwarding table event log has reached its capacity, the oldest event is written over by the newest event until the event log size is reset using this command or cleared using the clear ip cef event-log command.

Examples

The following example shows how to set the Cisco Express Forwarding table event log size to 5000 entries:

 

Related Commands

 

Syntax Description

 

Defaults

The default configuration value is 0 seconds for automatic exponential backoff.

 

Command History

 

Usage Guidelines

The Cisco Express Forwarding background resolution timer can use either a fixed time interval or an exponential backoff timer that reacts to the amount of resolution work required. The exponential backoff timer starts at 1 second, increasing to 16 seconds when a network flap is in progress. When the network recovers, the timer returns to 1 second.

The default is used for the exponential backoff timer. During normal operation, the default configuration value set to 0 results in re-resolution occurring much sooner than when the timer is set at a higher fixed interval.

Examples

The following example show how to set the Cisco Express Forwarding background resolution timer to 3 seconds:

 

Syntax Description

 

Defaults

Load interval: 30 seconds
Update rate: 10 seconds

 

Command History

 

Usage Guidelines

The ip nhrp trigger-svc command sets the threshold by which NHRP sets up and tears down a connection. The threshold is the Cisco Express Forwarding traffic load statistics. The thresholds in the ip nhrp trigger-svc command are measured during a sampling interval of 30 seconds, by default. To change that interval over which that threshold is determined, use the load-interval seconds option of the ip cef traffic-statistics command.

When NHRP is configured on a Cisco Express Forwarding switching node with a Versatile Interface Processor (VIP2) adapter, you must make sure the update-rate keyword is set to 5 seconds.

Other Cisco IOS features could also use the ip cef traffic-statistics command; this NHRP feature relies on it.

Examples

In the following example, the triggering and teardown thresholds are calculated based on an average over 120 seconds:

 

Related Commands

 

Syntax Description

 

Command Default

Per-destination load balancing is enabled by default when you enable Cisco Express Forwarding.

 

Command History

 

Usage Guidelines

Per-packet load balancing allows the router to send data packets over successive equal-cost paths without regard to individual destination hosts or user sessions. Path utilization is good, but packets destined for a given destination host might take different paths and might arrive out of order.

Note Per-packet load balancing via Cisco Express Forwarding is not supported on Engine 2 Cisco 12000 series Internet router line cards (LCs).

Per-destination load balancing allows the router to use multiple, equal-cost paths to achieve load sharing. Packets for a given source-destination host pair are guaranteed to take the same path, even if multiple, equal-cost paths are available. Traffic for different source-destination host pairs tends to take different paths.

Note If you want to enable per-packet load sharing to a particular destination, then all interfaces that can forward traffic to the destination must be enabled for per-packet load sharing.

Note Per-packet load balancing can result in out-of-sequence (OOS) packet delivery errors on some routers, which can cause applications such as VoIP to malfunction. Therefore, per-packet load balancing is not recommended. For more information, see the release notes and caveats for your platform and software release.

Cisco ASR 1000 Series Aggregation Services Routers

The ip load-sharing command is not supported on the Cisco ASR 1000 Series Aggregation Services Router. Per-packet load balancing is not supported. On the Cisco ASR 1000 Series Aggregation Services Router, per-destination load balancing is enabled by default and cannot be disabled.

Examples

The following example shows how to enable per-packet load balancing:

The following example shows how to enable per-destination load balancing:

 

Related Commands

 

Syntax Description

 

Command Default

The switching method is not controlled.

 

Command History

 

Usage Guidelines

IP Route Cache

Note The Cisco 10000 series routers do not support the ip route-cache command.

Using the route cache is often called fast switching. The route cache allows outgoing packets to be load-balanced on a per-destination basis rather than on a per-packet basis. The ip route-cache command with no additional keywords enables fast switching.

Entering the ip route-cache command has no effect on a subinterface. Subinterfaces accept the no form of the command; however, this disables Cisco Express Forwarding or distributed Cisco Express Forwarding on the physical interface and all subinterfaces associated with the physical interface

The default behavior for Fast Switching varies by interface and media.

Note IPv4 fast switching is removed with the implementation of the Cisco Express Forwarding infrastructure enhancements for Cisco IOS 12.2(25)S-based releases and Cisco IOS Release 12.4(20)T. For these and later Cisco IOS releases, switching path are Cisco Express Forwarding switched or process switched.

IP Route Cache Same Interface

You can enable IP fast switching when the input and output interfaces are the same interface, using the ip route-cache same-interface command. This configuration normally is not recommended, although it is useful when you have partially meshed media, such as Frame Relay or you are running Web Cache Communication Protocol (WCCP) redirection. You could use this feature on other interfaces, although it is not recommended because it would interfere with redirection of packets to the optimal path.

IP Route Cache Flow

The flow caching option can be used in conjunction with Cisco Express Forwarding switching to enable NetFlow, which allows statistics to be gathered with a finer granularity. The statistics include IP subprotocols, well-known ports, total flows, average number of packets per flow, and average flow lifetime.

Note The ip route-cache flow command has the same functionality as the ip flow ingress command, which is the preferred command for enabling NetFlow. If either the ip route-cache flow command or the
ip flow ingress command is configured, both commands will appear in the output of the
show running-config command.

IP Route Cache Distributed

The distributed option is supported on Cisco routers with line cards and Versatile Interface Processors (VIPs) that support Cisco Express Forwarding switching.

On Cisco routers with Route/Switch Processor (RSP) and VIP controllers, the VIP hardware can be configured to switch packets received by the VIP with no per-packet intervention on the part of the RSP. When VIP distributed switching is enabled, the input VIP interface tries to switch IP packets instead of forwarding them to the RSP for switching. Distributed switching helps decrease the demand on the RSP.

If the ip route-cache distributed, ip cef distributed, and ip route-cache flow commands are configured, the VIP performs distributed Cisco Express Forwarding switching and collects a finer granularity of flow statistics.

IP Route-Cache Cisco Express Forwarding

In some instances, you might want to disable Cisco Express Forwarding or distributed Cisco Express Forwarding on a particular interface because that interface is configured with a feature that
Cisco Express Forwarding or distributed Cisco Express Forwarding does not support. Because all interfaces that support Cisco Express Forwarding or distributed Cisco Express Forwarding are enabled by default when you enable Cisco Express Forwarding or distributed Cisco Express Forwarding operation globally, you must use the no form of the ip route-cache distributed command in the interface configuration mode to turn Cisco Express Forwarding or distributed Cisco Express Forwarding operation off a particular interface.

Disabling Cisco Express Forwarding or distributed Cisco Express Forwarding on an interface disables Cisco Express Forwarding or distributed Cisco Express Forwarding switching for packets forwarded to the interface, but does not affect packets forwarded out of the interface.

Additionally, when you disable distributed Cisco Express Forwarding on the RSP, Cisco IOS software switches packets using the next-fastest switch path (Cisco Express Forwarding).

Enabling Cisco Express Forwarding globally disables distributed Cisco Express Forwarding on all interfaces. Disabling Cisco Express Forwarding or distributed Cisco Express Forwarding globally enables process switching on all interfaces.

Note On the Cisco 12000 series Internet router, you must not disable distributed Cisco Express Forwarding on an interface.

IP Route Cache Policy

If Cisco Express Forwarding is already enabled, the ip route-cache route command is not required because PBR packets are Cisco Express Forwarding-switched by default.

Before you can enable fast-switched PBR, you must first configure PBR.

FSPBR supports all of PBR’s match commands and most of PBR’s set commands, with the following restrictions:

• The set ip default next-hop and set default interface commands are not supported.
• The set interface command is supported only over point-to-point links, unless a route cache entry exists using the same interface specified in the set interface command in the route map.
  Also, at the process level, the routing table is consulted to determine if the interface is on a reasonable path to the destination. During fast switching, the software does not make this check. Instead, if the packet matches, the software blindly forwards the packet to the specified interface.

Note Not all switching methods are available on all platforms. Refer to the Cisco Product Catalog for information about features available on the platform you are using.

Examples

Configuring Fast Switching and Disabling Cisco Express Forwarding Switching

The following example shows how to enable fast switching and disable Cisco Express Forwarding switching:

The following example shows that fast switching is enabled:

The following example shows that Cisco Express Forwarding switching is disabled:

The following example shows the configuration information for FastEthernet interface 0/0/0:

The following example shows how to enable Cisco Express Forwarding (and to disable distributed
Cisco Express Forwarding if it is enabled):

The following example shows how to enable VIP distributed Cisco Express Forwarding and per-flow accounting on an interface (regardless of the previous switching type enabled on the interface):

The following example shows how to enable Cisco Express Forwarding on the router globally (which also disables distributed Cisco Express Forwarding on any interfaces that are running distributed
Cisco Express Forwarding), and disable Cisco Express Forwarding (which enables process switching) on Ethernet interface 0:

The following example shows how to enable distributed Cisco Express Forwarding operation on the router (globally), and disable Cisco Express Forwarding operation on Ethernet interface 0:

The following example shows how to reenable distributed Cisco Express Forwarding operation on Ethernet interface 0:

Configuring Fast Switching for Traffic That Is Received and Transmitted over the Same Interface

The following example shows how to enable fast switching and disable Cisco Express Forwarding switching:

The following example shows that fast switching on the same interface is enabled for interface fastethernet 0/0/0:

The following example shows the configuration information for FastEthernet interface 0/0/0:

Enabling NetFlow Accounting

The following example shows how to enable NetFlow switching:

The following example shows that NetFlow accounting is enabled for FastEthernet interface 0/0/0:

Configuring Distributed Switching

The following example shows how to enable distributed switching:

The following example shows that distributed Cisco Express Forwarding switching is for FastEthernet interface 0/0/0:

Configuring Fast Switching for PBR

The following example shows how to configure a simple policy-based routing scheme and to enable FSPBR:

The following example shows that FSPBR is enabled for FastEthernet interface 0/0/0:

 

Related Commands

 

Syntax Description

 

Command Default

No notifications are sent.

 

Command History

 

Usage Guidelines

This command configures the threshold Unicast RPF drop rate which, when exceeded, triggers a notification. Configuring a value of 0 means that any Unicast RPF packet drop triggers a notification.

Examples

The following example shows how to configure a notification threshold value of 900 on Ethernet interface 3/0:

Router(config# interface ethernet 3/0

 

Related Commands

 

Syntax Description

 

Command Default

Unicast RPF is disabled.

 

Command History

 

Usage Guidelines

Use the ip verify unicast reverse-path interface command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that are received by a router. Malformed or forged source addresses can indicate denial of service (DoS) attacks on the basis of source IP address spoofing.

When Unicast RPF is enabled on an interface, the router examines all packets that are received on that interface. The router checks to ensure that the source address appears in the Forwarding Information Base (FIB) and that it matches the interface on which the packet was received. This “look backwards” ability is available only when Cisco Express Forwarding is enabled on the router because the lookup relies on the presence of the FIB. Cisco Express Forwarding generates the FIB as part of its operation.

To use Unicast RPF, enable Cisco Express Forwarding switching or distributed Cisco Express Forwarding switching in the router. There is no need to configure the input interface for Cisco Express Forwarding switching. As long as Cisco Express Forwarding is running on the router, individual interfaces can be configured with other switching modes.

Note It is very important for Cisco Express Forwarding to be configured globally in the router. Unicast RPF will not work without Cisco Express Forwarding.

Note Unicast RPF is an input function and is applied on the interface of a router only in the ingress direction.

The Unicast Reverse Path Forwarding feature checks to determine whether any packet that is received at a router interface arrives on one of the best return paths to the source of the packet. The feature does this by doing a reverse lookup in the Cisco Express Forwarding table. If Unicast RPF does not find a reverse path for the packet, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast Reverse Path Forwarding command. If an ACL is specified in the command, then when (and only when) a packet fails the Unicast RPF check, the ACL is checked to determine whether the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.

If no ACL is specified in the Unicast Reverse Path Forwarding command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.

Unicast RPF events can be logged by specifying the logging option for the ACL entries used by the Unicast Reverse Path Forwarding command. Log information can be used to gather information about the attack, such as source address, time, and so on.

Where to Use RPF in Your Network

Unicast RPF may be used on interfaces in which only one path allows packets from valid source networks (networks contained in the FIB). Unicast RPF may also be used in cases for which a router has multiple paths to a given network, as long as the valid networks are switched via the incoming interfaces. Packets for invalid networks will be dropped. For example, routers at the edge of the network of an Internet service provider (ISP) are likely to have symmetrical reverse paths. Unicast RPF may still be applicable in certain multi-homed situations, provided that optional Border Gateway Protocol (BGP) attributes such as weight and local preference are used to achieve symmetric routing.

With Unicast RPF, all equal-cost “best” return paths are considered valid. This means that Unicast RPF works in cases where multiple return paths exist, provided that each path is equal to the others in terms of the routing cost (number of hops, weights, and so on) and as long as the route is in the FIB. Unicast RPF also functions where Enhanced Internet Gateway Routing Protocol (EIGRP) variants are being used and unequal candidate paths back to the source IP address exist.

For example, routers at the edge of the network of an ISP are more likely to have symmetrical reverse paths than routers that are in the core of the ISP network. Routers that are in the core of the ISP network have no guarantee that the best forwarding path out of the router will be the path selected for packets returning to the router. In this scenario, you should use the new form of the command, ip verify unicast source reachable-via, if there is a chance of asymmetrical routing.

Examples

The following example shows that the Unicast Reverse Path Forwarding feature has been enabled on a serial interface:

The following example uses a very simple single-homed ISP to demonstrate the concepts of ingress and egress filters used in conjunction with Unicast RPF. The example illustrates an ISP-allocated classless interdomain routing (CIDR) block 192.168.202.128/28 that has both inbound and outbound filters on the upstream interface. Be aware that ISPs are usually not single-homed. Hence, provisions for asymmetrical flows (when outbound traffic goes out one link and returns via a different link) need to be designed into the filters on the border routers of the ISP.

The following example demonstrates the use of ACLs and logging with Unicast RPF. In this example, extended ACL 197 provides entries that deny or permit network traffic for specific address ranges. Unicast RPF is configured on Ethernet interface 0 to check packets arriving at that interface.

For example, packets with a source address of 192.168.201.10 arriving at Ethernet interface 0 are dropped because of the deny statement in ACL 197. In this case, the ACL information is logged (the logging option is turned on for the ACL entry) and dropped packets are counted per-interface and globally. Packets with a source address of 192.168.201.100 arriving at Ethernet interface 0 are forwarded because of the permit statement in ACL 197. ACL information about dropped or suppressed packets is logged (the logging option is turned on for the ACL entry) to the log server.

 

Related Commands

 

Syntax Description

any	Examines incoming packets to determine whether the source address is in the Forwarding Information Base (FIB) and permits the packet if the source is reachable through any interface (sometimes referred to as loose mode).
rx	Examines incoming packets to determine whether the source address is in the FIB and permits the packet only if the source is reachable through the interface on which the packet was received (sometimes referred to as strict mode).
l2-src	(Optional) Enables source IPv4 and source MAC address binding.
allow-default	(Optional) Allows the use of the default route for RPF verification.
allow-self-ping	(Optional) Allows a router to ping its own interface or interfaces. Caution Use caution when enabling the allow-self-ping keyword. This keyword opens a denial-of-service (DoS) hole.
access-list	(Optional) Specifies a numbered access control list (ACL) in the following ranges: 1 to 99 (IP standard access list) 100 to 199 (IP extended access list) 1300 to 1999 (IP standard access list, expanded range) 2000 to 2699 (IP extended access list, expanded range)

 

Command Default

Unicast RPF is disabled.

Source IPv4 and source MAC address binding is disabled.

 

Command History

 

Usage Guidelines

Use the ip verify unicast source reachable-via interface command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that pass through a router. Malformed or forged source addresses can indicate DoS attacks based on source IP address spoofing.

To use Unicast RPF, enable Cisco Express Forwarding or distributed Cisco Express Forwarding in the router. There is no need to configure the input interface for Cisco Express Forwarding. As long as Cisco Express Forwarding is running on the router, individual interfaces can be configured with other switching modes.

Note It is important for Cisco Express Forwarding to be configured globally on the router. Unicast RPF does not work without Cisco Express Forwarding.

Note Unicast RPF is an input function and is applied on the interface of a router only in the ingress direction.

When Unicast RPF is enabled on an interface, the router examines all packets that are received on that interface. The router checks to make sure that the source address appears in the FIB. If the rx keyword is selected, the source address must match the interface on which the packet was received. If the any keyword is selected, the source address must be present only in the FIB. This ability to “look backwards” is available only when Cisco Express Forwarding is enabled on the router because the lookup relies on the presence of the FIB. Cisco Express Forwarding generates the FIB as part of its operation.

Note If the source address of an incoming packet is resolved to a null adjacency, the packet will be dropped. The null interface is treated as an invalid interface by the new form of the Unicast RPF command. The older form of the command syntax did not exhibit this behavior.

Unicast RPF checks to determine whether any packet that is received at a router interface arrives on one of the best return paths to the source of the packet. If a reverse path for the packet is not found, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast RPF command. If an ACL is specified in the command, when (and only when) a packet fails the Unicast RPF check, the ACL is checked to determine whether the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.

If no ACL is specified in the ip verify unicast source reachable-via command, the router drops the forged or malformed packet immediately, and no ACL logging occurs. The router and interface Unicast RPF counters are updated.

Unicast RPF events can be logged by specifying the logging option for the ACL entries that are used by the ip verify unicast source reachable-via command. Log information can be used to gather information about the attack, such as source address, time, and so on.

Strict Mode RPF

If the source address is in the FIB and reachable only through the interface on which the packet was received, the packet is passed. The syntax for this method is ip verify unicast source reachable-via rx.

Exists-Only (or Loose Mode) RPF

If the source address is in the FIB and reachable through any interface on the router, the packet is passed. The syntax for this method is ip verify unicast source reachable-via any.

Because this Unicast RPF option passes packets regardless of which interface the packet enters, it is often used on Internet service provider (ISP) routers that are “peered” with other ISP routers (where asymmetrical routing typically occurs). Packets using source addresses that have not been allocated on the Internet, which are often used for spoofed source addresses, are dropped by this Unicast RPF option. All other packets that have an entry in the FIB are passed.

allow-default

Normally, sources found in the FIB but only by way of the default route will be dropped. Specifying the allow-default keyword option will override this behavior. You must specify the allow-default keyword in the command to permit Unicast RPF to successfully match on prefixes that are known through the default route to pass these packets.

allow-self-ping

This keyword allows the router to ping its own interface or interfaces. By default, when Unicast RPF is enabled, packets that are generated by the router and destined to the router are dropped, thereby, making certain troubleshooting and management tasks difficult to accomplish. Issue the allow-self-ping keyword to enable self-pinging.

Caution Caution should be used when enabling the allow-self-ping keyword because this option opens a potential DoS hole.

---

Using RPF in Your Network

Use Unicast RPF strict mode on interfaces where only one path allows packets from valid source networks (networks contained in the FIB). Also, use Unicast RPF strict mode when a router has multiple paths to a given network, as long as the valid networks are switched through the incoming interfaces. Packets for invalid networks will be dropped. For example, routers at the edge of the network of an ISP are likely to have symmetrical reverse paths. Unicast RPF strict mode is applicable in certain multihomed situations, provided that optional Border Gateway Protocol (BGP) attributes, such as weight and local preference, are used to achieve symmetric routing.

Note With Unicast RPF, all equal-cost “best” return paths are considered valid. This means that Unicast RPF works in cases where multiple return paths exist, provided that each path is equal to the others in terms of the routing cost (number of hops, weights, and so on) and as long as the route is in the FIB. Unicast RPF also functions where Enhanced Internet Gateway Routing Protocol (EIGRP) variants are being used and unequal candidate paths back to the source IP address exist.

Use Unicast RPF loose mode on interfaces where asymmetric paths allow packets from valid source networks (networks contained in the FIB). Routers that are in the core of the ISP network have no guarantee that the best forwarding path out of the router will be the path selected for packets returning to the router.

IP and MAC Address Spoof Prevention

In Release 15.0(1)M and later, you can use the l2-src keyword to enable source IPv4 and source MAC address binding. To disable source IPv4 and source MAC address binding, use the no form of the ip verify unicast source reachable-via command.

If an inbound packet fails this security check, it will be dropped and the Unicast RPF dropped-packet counter will be incremented. The only exception occurs if a numbered access control list has been specified as part of the Unicast RPF command in strict mode, and the ACL permits the packet. In this case the packet will be forwarded and the Unicast RPF suppressed-drops counter will be incremented.

Note The l2-src keyword cannot be used with the loose uRPF command, ip verify unicast source reachable-via any command.

Not all platforms support the l2-src keyword. Therefore, not all the possible keyword combinations for strict Unicast RPF in the following list will apply to your platform:

Possible keyword combinations for strict Unicast RPF include the following:

Examples

Single-Homed ISP Connection with Unicast RPF

The following example uses a very simple single-homed ISP connection to demonstrate the concept of Unicast RPF. In this example, an ISP peering router is connected through a single serial interface to one upstream ISP. Hence, traffic flows into and out of the ISP will be symmetric. Because traffic flows will be symmetric, a Unicast RPF strict-mode deployment can be configured.

ACLs and Logging with Unicast RPF

The following example demonstrates the use of ACLs and logging with Unicast RPF. In this example, extended ACL 197 provides entries that deny or permit network traffic for specific address ranges. Unicast RPF is configured on interface Ethernet 0/1/1 to check packets arriving at that interface.

For example, packets with a source address of 192.168.201.10 arriving at interface Ethernet 0/1/1 are dropped because of the deny statement in ACL 197. In this case, the ACL information is logged (the logging option is turned on for the ACL entry) and dropped packets are counted per-interface and globally. Packets with a source address of 192.168.201.100 arriving at interface Ethernet 0/1/2 are forwarded because of the permit statement in ACL 197. ACL information about dropped or suppressed packets is logged (the logging option is turned on for the ACL entry) to the log server.

MAC Address Binding on Software Switching Platforms Like the Cisco 7200 Series Routers

The following example shows how to enable source IPv4 and source MAC address binding on Ethernet 0/0:

 

Related Commands

 

Syntax Description

 

Command Default

Unicast RPF verification is disabled.

 

Command History

 

Usage Guidelines

Unicast RPF is configured to verify that the source address is in the Forwarding Information Base (FIB). The ip verify unicast vrf command is configured in interface configuration mode and is enabled for each VRF. This command has permit and deny keywords that are used to determine if traffic is forwarded or dropped after Unicast RPF verification.

Examples

The following example configures Unicast RPF verification for VRF1 and VRF2. VRF1 traffic is forwarded. VRF2 traffic is dropped.

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Cisco Express Forwarding for IPv6 is disabled by default.

 

Command History

 

Usage Guidelines

The ipv6 cef command is similar to the ip cef command, except that it is IPv6-specific.

The ipv6 cef command is not available on the Cisco 12000 series Internet routers because this distributed platform operates only in distributed Cisco Express Forwarding for IPv6 mode.

Note The ipv6 cef command is not supported in interface configuration mode.

Note Some distributed architecture platforms, such as the Cisco 7500 series routers, support both Cisco Express Forwarding for IPv6 and distributed Cisco Express Forwarding for IPv6. When Cisco Express Forwarding for IPv6 is configured on distributed platforms, Cisco Express Forwarding switching is performed by the Route Processor (RP).

Note You must enable Cisco Express Forwarding for IPv4 by using the ip cef global configuration command before enabling Cisco Express Forwarding for IPv6 by using the ipv6 cef global configuration command.

Cisco Express Forwarding for IPv6 is advanced Layer 3 IP switching technology that functions the same and offer the same benefits as Cisco Express Forwarding for IPv4. Cisco Express Forwarding for IPv6 optimizes network performance and scalability for networks with dynamic, topologically dispersed traffic patterns, such as those associated with web-based applications and interactive sessions.

Examples

The following example enables standard Cisco Express Forwarding for IPv4 operation and then standard Cisco Express Forwarding for IPv6 operation globally on the router.

 

Related Commands

 

Syntax Description

 

Command Default

Cisco Express Forwarding for IPv6 network accounting is disabled by default.

 

Command History

 

Usage Guidelines

The ipv6 cef accounting command is similar to the ip cef accounting command, except that it is IPv6-specific.

Configuring Cisco Express Forwarding for IPv6 network accounting enables you to collect statistics on Cisco Express Forwarding for IPv6 traffic patterns in your network.

When you enable network accounting for Cisco Express Forwarding for IPv6 by using the ipv6 cef accounting command in global configuration mode, accounting information is collected at the Route Processor (RP) when Cisco Express Forwarding for IPv6 mode is enabled and at the line cards when distributed Cisco Express Forwarding for IPv6 mode is enabled. You can then display the collected accounting information using the show ipv6 cef EXEC command.

For prefixes with directly connected next hops, the non-recursive keyword enables express forwarding of the collection of packets and bytes through a prefix. This keyword is optional when this command is used in global configuration mode after you enter another keyword on the ipv6 cef accounting command.

This command in interface configuration mode must be used in conjunction with the global configuration command. The interface configuration command allows a user to specify two different bins (internal or external) for the accumulation of statistics. The internal bin is used by default. The statistics are displayed through the show ipv6 cef detail command.

Per-destination load balancing uses a series of 16 hash buckets into which the set of available paths are distributed. A hash function operating on certain properties of the packet is applied to select a bucket that contains a path to use. The source and destination IP addresses are the properties used to select the bucket for per-destination load balancing. Use the load-balance-hash keyword with the ipv6 cef accounting command to enable per-hash-bucket counters. Enter the show ipv6 cef prefix internal command to display the per-hash-bucket counters.

Examples

The following example enables the collection of Cisco Express Forwarding for IPv6 accounting information for prefixes with directly connected next hops:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Distributed Cisco Express Forwarding for IPv6 is disabled on the Cisco 7500 series routers and enabled on the Cisco 12000 series Internet routers.

 

Command History

 

Usage Guidelines

The ipv6 cef distributed command is similar to the ip cef distributed command, except that it is IPv6-specific.

Enabling distributed Cisco Express Forwarding for IPv6 globally on the router by using the ipv6 cef distributed in global configuration mode distributes the Cisco Express Forwarding processing of IPv6 packets from the Route Processor (RP) to the line cards of distributed architecture platforms.

Note The ipv6 cef distributed command is not supported on the Cisco 12000 series Internet routers because distributed Cisco Express Forwarding for IPv6 is enabled by default on this platform.

Note To forward distributed Cisco Express Forwarding for IPv6 traffic on the router, configure the forwarding of IPv6 unicast datagrams globally on your router by using the ipv6 unicast-routing global configuration command, and configure an IPv6 address and IPv6 processing on an interface by using the ipv6 address interface configuration command.

Note You must enable distributed Cisco Express Forwarding for IPv4 by using the ip cef distributed global configuration command before enabling distributed Cisco Express Forwarding for IPv6 by using the ipv6 cef distributed global configuration command.

Cisco Express Forwarding is advanced Layer 3 IP switching technology. Cisco Express Forwarding optimizes network performance and scalability for networks with dynamic, topologically dispersed traffic patterns, such as those associated with web-based applications and interactive sessions.

Examples

The following example enables distributed Cisco Express Forwarding for IPv6 operation:

 

Related Commands

 

Syntax Description

 

Command Default

The universal load-balancing algorithm is selected. If you do not configure the fixed identifier for a load-balancing algorithm, the router automatically generates a unique ID.

 

Command History

 

Usage Guidelines

The ipv6 cef load-sharing algorithm command is similar to the ip cef load-sharing algorithm command, except that it is IPv6-specific.

When the Cisco Express Forwarding for IPv6 load-balancing algorithm is set to universal mode, each router on the network can make a different load-sharing decision for each source-destination address pair.

The include-ports algorithm allows you to use the Layer 4 source and destination ports as part of the load-balancing decision. This method benefits traffic streams running over equal-cost paths that are not load-shared because the majority of the traffic is between peer addresses that use different port numbers, such as Real-Time Protocol (RTP) streams.

Examples

The following example shows how to enable the Cisco Express Forwarding load-balancing algorithm for IPv6 for Layer-4 source and destination ports:

The router automatically generates fixed IDs for the algorithm.

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

If this command is not configured, Cisco Express Forwarding for IPv6 does not optimize the address resolution of directly connected neighbors.

 

Command History

 

Usage Guidelines

The ipv6 cef optimize neighbor resolution command is very similar to the ip cef optimize neighbor resolution command, except that it is IPv6-specific.

Use this command to trigger Layer 2 address resolution of neighbors directly from Cisco Express Forwarding for IPv6.

Examples

The following example shows how to optimize address resolution from Cisco Express Forwarding for IPv6 for directly connected neighbors:

 

Related Commands

 

Syntax Description

 

Command Default

Unicast RPF is disabled.

 

Command History

 

Usage Guidelines

The ipv6 verify unicast reverse-path command is used to enable Unicast RPF for IPv6 in strict checking mode. The Unicast RPF for IPv6 feature requires that Cisco Express Forwarding for IPv6 is enabled on the router.

Note Beginning in Cisco IOS Release 12.0(31)S, the Cisco 12000 series Internet router supports both the ipv6 verify unicast reverse-path and ipv6 verify unicast source reachable-via rx commands to enable Unicast RPF to be compatible with the Cisco IOS Release 12.3T and 12.2S software trains.

Use the ipv6 verify unicast reverse-path command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that pass through a router. Malformed or forged source addresses can indicate denial-of-service (DoS) attacks based on source IP address spoofing.

When Unicast RPF is enabled on an interface, the router examines all packets received on that interface. The router checks to make sure that the source IPv6 address appears in the routing table and that it is reachable by a path through the interface on which the packet was received. Unicast RPF is an input feature and is applied only on the input interface of a router at the upstream end of a connection.

The Unicast RPF feature performs a reverse lookup in the CEF table to check if any packet received at a router interface has arrived on a path identified as a best return path to the source of the packet. If a reverse path for the packet is not found, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast RPF command. If an ACL is specified in the command, then when (and only when) a packet fails the Unicast RPF check, the ACL is checked to determine whether the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.

If no ACL is specified in the Unicast RPF command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.

Unicast RPF events can be logged by specifying the logging option for the ACL entries used by the Unicast RPF command. Log information can be used to gather information about the attack, such as source address, time, and so on.

Note When you configure Unicast RPF for IPv6 on the Cisco 12000 series Internet router, the most recently configured checking mode is not automatically applied to all interfaces as on other platforms. You must enable Unicast RPF for IPv6 separately on each interface.

When you configure a SPA on the Cisco 12000 series Internet router, the interface address is in the format slot/subslot/port.

The optional access-list keyword for the ipv6 verify unicast reverse-path command is not supported on the Cisco 12000 series Internet router. For information about how Unicast RPF can be used with ACLs on other platforms to mitigate the transmission of invalid IPv4 addresses (perform egress filtering) and to prevent (deny) the reception of invalid IPv4 addresses (perform ingress filtering), refer to the “Configuring Unicast Reverse Path Forwarding” chapter in the “Other Security Features” section of the Cisco IOS Security Configuration Guide.

Note When using Unicast RPF, all equal-cost “best” return paths are considered valid. This means that Unicast RPF works in cases where multiple return paths exist, provided that each path is equal to the others in terms of the routing cost (number of hops, weights, and so on).

Do not use Unicast RPF on core-facing interfaces that are internal to the network. Internal interfaces are likely to have routing asymmetry, meaning that there are multiple routes to the source of a packet. Apply Unicast RPF only where there is natural or configured symmetry.

For example, routers at the edge of the network of an Internet service provider (ISP) are more likely to have symmetrical reverse paths than routers that are in the core of the ISP network. Routers that are in the core of the ISP network have no guarantee that the best forwarding path out of the router will be the path selected for packets returning to the router. Hence, it is not recommended that you apply Unicast RPF where there is a chance of asymmetric routing. It is simplest to place Unicast RPF only at the edge of a network or, for an ISP, at the customer edge of the network.

Examples

Unicast Reverse Path Forwarding on a Serial Interface

The following example shows how to enable the Unicast RPF feature on a serial interface:

Unicast Reverse Path Forwarding on a Cisco 12000 Series Internet Router

The following example shows how to enable Unicast RPF for IPv6 with strict checking on a 10G SIP Gigabit Ethernet interface 2/1/2:

Unicast Reverse Path Forwarding on a Single-Homed ISP

The following example uses a very simple single-homed ISP to demonstrate the concepts of ingress and egress filters used in conjunction with Unicast RPF. The example illustrates an ISP-allocated classless interdomain routing (CIDR) block 209.165.202.128/28 that has both inbound and outbound filters on the upstream interface. Be aware that ISPs are usually not single-homed. Hence, provisions for asymmetrical flows (when outbound traffic goes out one link and returns via a different link) need to be designed into the filters on the border routers of the ISP.

ACL Logging with Unicast RPF

The following example demonstrates the use of ACLs and logging with Unicast RPF. In this example, extended ACL abc provides entries that deny or permit network traffic for specific address ranges. Unicast RPF is configured on interface Ethernet 0/0 to check packets arriving at that interface.

For example, packets with a source address of 8765:4321::1 arriving at Ethernet interface 0 are dropped because of the deny statement in ACL “abc.” In this case, the ACL information is logged (the logging option is turned on for the ACL entry) and dropped packets are counted per-interface and globally. Packets with a source address of 1234:5678::1 arriving at Ethernet interface 0/0 are forwarded because of the permit statement in ACL abc. ACL information about dropped or suppressed packets is logged (the logging option is turned on for the ACL entry) to the log server.

 

Related Commands

 

Syntax Description

 

Command Default

Unicast RPF is disabled.

 

Command History

 

Usage Guidelines

The ipv6 verify unicast reverse-path command is used to enable Unicast RPF for IPv6 in loose checking mode.

Use the ipv6 verify unicast source reachable-via command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that pass through an IPv6 router. Malformed or forged source addresses can indicate denial-of-service (DoS) attacks based on source IPv6 address spoofing.

The URPF feature checks to see if any packet received at a router interface arrives on one of the best return paths to the source of the packet. The feature does this by doing a reverse lookup in the CEF table. If URPF does not find a reverse path for the packet, U RPF can drop or forward the packet, depending on whether an access control list (ACL) is specified in the ipv6 verify unicast source reachable-via command. If an ACL is specified in the command, then when (and only when) a packet fails the URPF check, the ACL is checked to see if the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for U RPF drops and in the interface statistics for Unicast RPF.

If no ACL is specified in the ipv6 verify unicast source reachable-via command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.

U RPF events can be logged by specifying the logging option for the ACL entries used by the ipv6 verify unicast source reachable-via command. Log information can be used to gather information about the attack, such as source address, time, and so on.

Examples

The following example enables Unicast RPF on any interface:

 

Related Commands

 

Syntax Description

 

Command Default

The defaults are as follows:

• For XL-mode systems:

– IPv4 unicast and MPLS—512,000 routes

– IPv6 unicast and IPv4 multicast—256,000 routes

• For non-XL mode systems:

– IPv4 unicast and MPLS—192,000 routes

– IPv6 unicast and IPv4 multicast—32,000 routes

Note See the “Usage Guidelines” section for information on XL and non-XL mode systems.

 

Command History

 

Usage Guidelines

Note If you copy a configuration file that contains the multilayer switching (MLS) Cisco Express Forwarding maximum routes into the startup-config file and reload the Cisco 7600 series router, the Cisco 7600 series router reloads after it reboots.

This command is not supported on Cisco 7600 series routers that are configured with a Supervisor Engine 2.

The mls cef maximum-routes command limits the maximum number of the routes that can be programmed in the hardware. If routes are detected that exceed the limit for that protocol, an exception condition is generated.

The determination of XL and non-XL mode is based on the type of Policy Feature Card (PFC) or Distributed Forwarding Card (DFC) modules that are installed in your system. For additional information on systems running Cisco IOS software release 12.2SXF and earlier releases see:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/release/notes/OL_4164.html#Policy_Feature_Card_Guidelines_and_Restrictions

For additional information on systems running Cisco IOS software release 12.2SXH and later releases see:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html#Policy_Feature_Card_Guidelines_and_Restrictions

The valid values for the maximum-routes argument depend on the system mode—XL mode or non-XL mode. The valid values are as follows:

• XL mode

– IP and MPLS—Up to 1,007,000 routes

– IP multicast and IPv6—Up to 503,000 routes

• Non-XL mode

– IP and MPLS—Up to 239,000 routes

– IP multicast and IPv6—Up to 119,000 routes

Note The maximum values that you are permitted to configure is not fixed but varies depending on the values that are allocated for other protocols.

An example of how to enter the maximum routes argument is as follows:

where 4 is 4096 IP routes (1024 x4 = 4096).

The new configurations are applied after a system reload only and do not take effect if a switchover occurs.

Note A switchover might lead to a crash when you have a VSS in a dual supervisor setup due to a lack of synchronization between the TCAM.

In RPR mode, if you change and save the maximum-routes configuration, the redundant supervisor engine reloads when it becomes active from either a switchover or a system reload. The reload occurs 5 minutes after the supervisor engine becomes active.

Use the show mls cef maximum-routes command to display the current maximum routes system configuration.

Examples

This example shows how to set the maximum number of routes that are allowed per protocol:

This example shows how to return to the default setting for a specific protocol:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Tunnel fragmentation is not enabled.

 

Command History

 

Usage Guidelines

When you enable tunnel fragmentation, if the size of the packets that are going into a tunnel interface exceed the MTU, the packet is fragmented. The packets that are fragmented are reassembled at the destination point.

Examples

This example shows how to allow tunnel fragmentation:

This example shows how to return to the default setting:

 

Related Commands

 

Syntax Description

 

Command Default

The default priority settings are used.

 

Command History

 

Usage Guidelines

This command is not supported on Cisco 7600 series routers that are configured with a Supervisor Engine 2.

A lower value indicates a higher priority.

When a protocol sees a Forwarding Information Base (FIB) table exception, the protocol notifies the FIB Embedded Resource Manager (ERM). The FIB ERM periodically polls the FIB table exception status and decides which protocol gets priority over another protocol when multiple protocols are running under the exception. Only one protocol can attempt to recover from an exception at any time.

If there is sufficient FIB space, the protocol with the highest priority tries to recover first. Other protocols under the exception do not start to recover until the previous protocol completes the recovery process by reloading the appropriate FIB table.

Examples

This example shows how to set the ERM exception-recovery priority:

This example shows how to return to the default setting:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Defaults

Multicast is disabled.

 

Command History

 

Usage Guidelines

This command is not supported on Cisco 7600 series routers that are configured with a Supervisor Engine 720.

Examples

This example shows how to enable MLS IP:

 

Related Commands

 

Syntax Description

 

Command Default

MLS per-prefix accounting is disabled by default.

 

Command History

 

Usage Guidelines

Per-prefix accounting collects the adjacency counters used by the prefix. When the prefix is used for accounting, the adjacency cannot be shared with other prefixes. You can use per-prefix accounting to account for the packets sent to a specific destination.

Examples

This example shows how to enable MLS per-prefix accounting:

This example shows how to disable MLS per-prefix accounting:

 

Related Commands

 

Syntax Description

 

Defaults

Source and destination IP address and universal identification

 

Command History

 

Usage Guidelines

The mls ip cef load-sharing command affects the IPv4, the IPv6, and the Multiprotocol Label Switching (MPLS) forwardings.

The mls ip cef load-sharing command is structured as follows:

• mls ip cef load-sharing full —Uses Layer 3 and Layer 4 information with multiple adjacencies.
• mls ip cef load-sharing full simple —Uses Layer 3 and Layer 4 information without multiple adjacencies.
• mls ip cef load-sharing simple —Uses Layer 3 information without multiple adjacencies.

For additional guidelines, refer to the Cisco 7600 Series Router Cisco IOS Software Configuration Guide .

Examples

This example shows how to set load balancing to include Layer 3 and Layer 4 ports with multiple adjacencies:

This example shows how to set load balancing to exclude the destination Layer 4 ports and source and destination IP addresses (Layer 3) from the load-balancing algorithm:

This example shows how to set load balancing to exclude the source Layer 4 ports and source and destination IP addresses (Layer 3) from the load-balancing algorithm:

This example shows how to return to the default setting:

 

Related Commands

 

Syntax Description

 

Defaults

No rate limit is configured.

 

Command History

 

Usage Guidelines

The valid values for the number of data packets per second are as follows:

• For Cisco 7600 series routers that are configured with a Supervisor Engine 2, the valid values are from 1 to 1000000.
• For Cisco 7600 series routers that are configured with a Supervisor Engine 720, the valid values are from 0 to 1000000.

Certain denial-of-service attacks target the route processing engines of routers. Certain packets that cannot be forwarded by the Policy Feature Card (PFC) are directed to the Multilayer Switch Feature Card (MSFC) for processing. Denial-of-service attacks can overload the route processing engine and cause routing instability when running dynamic routing protocols. You can use the mls ip cef rate-limit command to limit the amount of traffic that is sent to the MSFC to prevent denial-of-service attacks against the route processing engine.

This command rate limits all Cisco Express Forwarding-punted data packets including the following:

• Data packets going to the local interface IP address
• Data packets requiring Address Resolution Protocol (ARP)

Setting the rate to a low value could impact the packets that are destined to the IP addresses of the local interfaces and the packets that require ARP.

You should use this command to limit these packets to a normal rate and to avoid abnormal incoming rates.

For additional guidelines, see the Cisco 7600 Series Router Cisco IOS Software Configuration Guide .

Examples

This example shows how to enable and set rate limiting:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

uRPF is disabled.

 

Command History

 

Usage Guidelines

This command is supported on systems configured with a PFC3 (Supervisor Engine 720 and Supervisor Engine 32) only.

If you do not enter the mls ip cef rpf hw-enable-rpf-acl command, when the uRPF with ACL is specified, packets that are permitted by the uRPF ACL are forwarded in hardware and the denied packets are sent to the Multilayer Switching Feature Card (MSFC) for the uRPF check. This command enables hardware forwarding with the uRPF check for the packets that are denied by the uRPF ACL. However, in this case packets permitted by the uRPF ACL are sent to the MSFC for forwarding.

Examples

This example shows how to enable hardware uRPF when RPF and ACL are enabled:

This example shows how to disable hardware uRPF when RPF and ACL are enabled:

 

Related Commands

 

Syntax Description