Configuring Unicast Reverse Path Forwarding

This chapter describes the Unicast Reverse Path Forwarding (Unicast RPF) feature. The Unicast RPF feature helps to mitigate problems that are caused by malformed or forged IP source addresses that are passing through a router.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Prerequisites to Configuring Unicast Reverse Path Forwarding

Prior to configuring Unicast RPF, configure ACLs:

  • Configure standard or extended ACLs to mitigate transmission of invalid IP addresses (perform egress filtering). Permit only valid source addresses to leave your network and get onto the Internet. Prevent all other source addresses from leaving your network for the Internet.

  • Configure standard or extended ACLs entries to drop (deny) packets that have invalid source IP addresses (perform ingress filtering). Invalid source IP addresses include the following types:
    • Reserved addresses
    • Loopback addresses
    • Private addresses (RFC 1918, Address Allocation for Private Internets)
    • Broadcast addresses (including multicast addresses)
    • Source addresses that fall outside the range of valid addresses associated with the protected network

  • Configure standard or extended ACL entries to forward (permit) packets that fail the Unicast RPF checks to allow specific traffic from known asymmetric routed sources.

Configure ACLs to track Unicast RPF events by adding the logging option into the ACL command. During network attacks, judicious logging of dropped or forwarded packets (suppressed drops) can provide additional information about network attacks.

Restrictions to Configuring Unicast Reverse Path Forwarding

There are some basic restrictions to applying Unicast RPF to multihomed clients:

  • Clients should not be multihomed to the same router because multihoming defeats the purpose of building a redundant service for the client.

  • Customers must ensure that the packets flowing up the link (out to the Internet) match the route advertised out the link. Otherwise, Unicast RPF filters those packets as malformed packets.

  • Unicast RPF is available only for platform images that support CEF. Unicast RPF is supported in Cisco IOS Releases 11.1(17)CC and 12.0 and later. It is not available in Cisco IOS Release 11.2 or 11.3.

Information About Unicast Reverse Path Forwarding

The Unicast RPF feature helps to mitigate problems that are caused by the introduction of malformed or forged (spoofed) IP source addresses into a network by discarding IP packets that lack a verifiable IP source address. For example, a number of common types of denial-of-service (DoS) attacks, including Smurf and Tribal Flood Network (TFN), can take advantage of forged or rapidly changing source IP addresses to allow attackers to thwart efforts to locate or filter the attacks. For Internet service providers (ISPs) that provide public access, Unicast RPF deflects such attacks by forwarding only packets that have source addresses that are valid and consistent with the IP routing table. This action protects the network of the ISP, its customer, and the rest of the Internet.

This section covers the following information:

How Unicast RPF Works

When Unicast RPF is enabled on an interface, the router examines all packets received as input on that interface to make sure that the source address and source interface appear in the routing table and match the interface on which the packet was received. This “look backwards” ability is available only when Cisco express forwarding (CEF) is enabled on the router, because the lookup relies on the presence of the Forwarding Information Base (FIB). CEF generates the FIB as part of its operation.

Note
Unicast RPF is an input function and is applied only on the input interface of a router at the upstream end of a connection.

Unicast RPF checks to see if any packet received at a router interface arrives on the best return path (return route) to the source of the packet. Unicast RPF does this by doing a reverse lookup in the CEF table. If the packet was received from one of the best reverse path routes, the packet is forwarded as normal. If there is no reverse path route on the same interface from which the packet was received, it might mean that the source address was modified. If Unicast RPF does not find a reverse path for the packet, the packet is dropped or forwarded, depending on whether an access control list (ACL) is specified in the ip verify unicast reverse-path interface configuration command.


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 EIGRP variants are being used and unequal candidate paths back to the source IP address exist.

When a packet is received at the interface where Unicast RPF and ACLs have been configured, the following actions occur:

SUMMARY STEPS

    1.    Input ACLs configured on the inbound interface are checked.

    2.    Unicast RPF checks to see if the packet has arrived on the best return path to the source, which it does by doing a reverse lookup in the FIB table.

    3.    CEF table (FIB) lookup is carried out for packet forwarding.

    4.    Output ACLs are checked on the outbound interface.

    5.    The packet is forwarded.


DETAILED STEPS
    Step 1   Input ACLs configured on the inbound interface are checked.
    Step 2   Unicast RPF checks to see if the packet has arrived on the best return path to the source, which it does by doing a reverse lookup in the FIB table.
    Step 3   CEF table (FIB) lookup is carried out for packet forwarding.
    Step 4   Output ACLs are checked on the outbound interface.
    Step 5   The packet is forwarded.
    What to Do Next

    This section provides information about Unicast RPF enhancements:

    Access Control Lists and Logging

    When you configure an access control list (ACL) and a packet fails the Unicast RPF check, the Unicast RPF checks the ACL to see if the packet should be dropped (by using a deny statement in the ACL) or forwarded (by using a permit statement in the ACL). Regardless of whether the 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 configured, the device drops the forged or malformed packet immediately, and no ACL logging occurs. The device and the interface Unicast RPF logging counters are updated.

    To log Unicast RPF events, specify the logging option for ACL entries. Using the log information, administrators can view source addresses that are used in an attack, the time at which packets arrived at an interface, and so on.

    Note

    ACL-based unicast RPF check is not supported in the hardware on Supervisor Engine 720. If you configure ACL-based uRPF check on an interface, all packets denied in the ACL are redirected to the MSFC3 CPU for the uRPF check, while packets permitted by the ACL are forwarded in hardware without a uRPF check. Redirected packets are subject to the global ACL bridged input hardware-to-CPU rate limiter (that limits the amount of such traffic that reaches the MSFC3 CPU) and may be dropped in hardware. Configure this rate limiter with themls rate-limit unicast acl input global configuration command.

    Beginning in Cisco IOS release 12.2(18)SXF6, you can change this behavior using the mls ip cef rpf hw-enable-rpf-acl global configuration command. When you add this command, packets permitted by the exception ACL are redirected to the MSFC3 CPU for the uRPF check, while packets denied by the ACL are forwarded in hardware with uRPF check. If the packets fail the hardware RPF check, they are punted to CPU. RPF-fail packets are subject to the global RPF fail hardware-to-CPU rate limiter. Configure this rate limiter with the mls rate-limit unicast ip rpf-failure global configuration command.


    Caution
    Logging requires CPU and memory resources. Logging Unicast RPF events for attacks that have a high rate of forged packets can degrade the performance of a device.

    Per-Interface Statistics

    Each time a packet is dropped or forwarded at an interface, that information is counted two ways: globally on the router and at each interface where you have applied Unicast RPF. Global statistics on dropped packets provide information about potential attacks on the network; however, these global statistics do not help to specify which interface is the source of the attack.

    Per-interface statistics allow network administrators to track two types of information about malformed packets: Unicast RPF drops and Unicast RPF suppressed drops. Statistics on the number of packets that Unicast RPF drops help to identify the interface that is the entry point of the attack. The Unicast RPF drop count tracks the number of drops at the interface. The Unicast RPF suppressed drop count tracks the number of packets that failed the Unicast RPF check but were forwarded because of the permit permission set up in the ACL. Using the drop count and suppressed drop count statistics, a network administrator can takes steps to isolate the attack at a specific interface.


    Note
    Judicious use of ACL logging can further identify the address or addresses that are being dropped by Unicast RPF.

    The figure below illustrates how Unicast RPF and CEF work together to validate IP source addresses by verifying packet return paths. In this example, a customer has sent a packet having a source address of 192.168.1.1 from interface FDDI 2/0/0. Unicast RPF checks the FIB to see if 192.168.1.1 has a path to FDDI 2/0/0. If there is a matching path, the packet is forwarded. If there is no matching path, the packet is dropped.

    Figure 1. Unicast RPF Validating IP Source Addresses

    The figure below illustrates how Unicast RPF drops packets that fail validation. In this example, a customer has sent a packet having a source address of 209.165.200.225, which is received at interface FDDI 2/0/0. Unicast RPF checks the FIB to see if 209.165.200.225 has a return path to FDDI 2/0/0. If there is a matching path, the packet is forwarded. In this case, there is no reverse entry in the routing table that routes the customer packet back to source address 209.165.200.225 on interface FDDI 2/0/0, and so the packet is dropped.

    Figure 2. Unicast RPF Dropping Packets That Fail Verification

    Implementing Unicast RPF

    Unicast RPF has several key implementation principles:

    • The packet must be received at an interface that has the best return path (route) to the packet source (a process called symmetric routing). There must be a route in the FIB matching the route to the receiving interface. Adding a route in the FIB can be done via static route, network statement, or dynamic routing. (ACLs permit Unicast RPF to be used when packets are known to be arriving by specific, less optimal asymmetric input paths.)

    • IP source addresses at the receiving interface must match the routing entry for the interface.

    • Unicast RPF is an input function and is applied only on the input interface of a router at the upstream end of a connection.

    Given these implementation principles, Unicast RPF becomes a tool that network administrators can use not only for their customers but also for their downstream network or ISP, even if the downstream network or ISP has other connections to the Internet.

    Caution
    Using optional BGP attributes such as weight and local preference, the best path back to the source address can be modified. Modification would affect the operation of Unicast RPF.

    This section provides information about the implementation of Unicast RPF:

    Security Policy and Unicast RPF

    When determining how to deploy Unicast Reverse Path Forwarding (RPF), consider the following points:

    • Apply Unicast RPF at the downstream interface, away from the larger portion of the network, preferably at the edges of your network. The further you apply Unicast RPF, the finer the granularity you have in mitigating address spoofing and in identifying sources of spoofed addresses. For example, applying Unicast RPF on an aggregation device helps to mitigate attacks from many downstream networks or clients and is simple to administer, but Unicast RPF does not help in identifying the source of the attack. Applying Unicast RPF at the network access server helps to limit the scope of the attack and trace the source of the attack. However, deploying Unicast RPF across many sites adds to the administration cost of operating a network.

    • When you deploy Unicast RPF on many entities on a network (for example, across the Internet, intranet, and extranet resources), you have better chances of mitigating large-scale network disruptions throughout the Internet community, and of tracing the source of an attack.

    • Unicast RPF does not inspect IP packets that are encapsulated in tunnels, such as the generic routing encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), or Point-to-Point Tunneling Protocol (PPTP). Configure Unicast RPF on a home gateway so that Unicast RPF processes network traffic only after tunneling and encryption layers are stripped off from the packets.

    Where to Use Unicast RPF

    Unicast RPF can be used in any “single-homed” environment where there is essentially only one access point out of the network; that is, one upstream connection. Networks having one access point offer the best example of symmetric routing, which means that the interface where a packet enters the network is also the best return path to the source of the IP packet. Unicast RPF is best used at the network perimeter for Internet, intranet, or extranet environments, or in ISP environments for customer network terminations.

    The following sections provide a look at implementing Unicast RPF in two network environments:

    Enterprise Networks with a Single Connection to an ISP

    In enterprise networks, one objective of using Unicast RPF for filtering traffic at the input interface (a process called ingress filtering) is for protection from malformed packets arriving from the Internet. Traditionally, local networks that have one connection to the Internet would use ACLs at the receiving interface to prevent spoofed packets from the Internet from entering their local network.

    ACLs work well for many single-homed customers; however, there are trade-offs when ACLs are used as ingress filters, including two commonly referenced limitations:

    • Packet per second (PPS) performance at very high packet rates

    • Maintenance of the ACL (whenever there are new addresses added to the network)

    Unicast RPF is one tool that addresses both of these limitations. With Unicast RPF, ingress filtering is done at CEF PPS rates. This processing speed makes a difference when the link is more than 1 Mbps. Additionally, since Unicast RPF uses the FIB, no ACL maintenance is necessary, and thus the administration overhead of traditional ACLs is reduced. The following figure and example demonstrate how Unicast RPF is configured for ingress filtering.

    The figure below illustrates an enterprise network that has a single link to an upstream ISP. In this example, Unicast RPF is applied at interface S0 on the enterprise router for protection from malformed packets arriving from the Internet. Unicast RPF is also applied at interface S5/0 on the ISP router for protection from malformed packets arriving from the enterprise network.

    Figure 3. Enterprise Network Using Unicast RPF for Ingress Filtering

    Using the topography in the figure above, a typical configuration (assuming that Cisco Express Forwarding is turned on) on the ISP router would be as follows: 

    ip cef
interface loopback 0
  description Loopback interface on Gateway Router 2
  ip address 192.168.3.1 255.255.255.255
  no ip redirects
  no ip directed-broadcast
  no ip proxy-arp
interface Serial 5/0
  description 128K HDLC link to ExampleCorp WT50314E  R5-0
  bandwidth 128
  ip unnumbered loopback 0
  ip verify unicast reverse-path
  no ip redirects
  no ip directed-broadcast
  no ip proxy-arp
ip route 192.168.10.0 255.255.252.0 Serial 5/0

    The gateway router configuration of the enterprise network (assuming that Cisco Express Forwarding is turned on) would look similar to the following: 

    ip cef
interface Ethernet 0
 description ExampleCorp LAN
 ip address 192.168.10.1 255.255.252.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
interface Serial 0
 description 128K HDLC link to ExampleCorp Internet Inc WT50314E  C0
 bandwidth 128
 ip unnumbered ethernet 0
 ip verify unicast reverse-path
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
ip route 0.0.0.0 0.0.0.0 Serial 0

    Notice that Unicast RPF works with a single default route. There are no additional routes or routing protocols. Network 192.168.10.0/22 is a connected network. Hence, packets coming from the Internet with a source address in the range 192.168.10.0/22 will be dropped by Unicast RPF.

    Network Access Server Application (Applying Unicast RPF in PSTN ISDN PoP Aggregation Routers)

    Aggregation routers are ideal places to use Unicast RPF with single-homed clients. Unicast RPF works equally well on leased-line or PSTN/ISDN/xDSL customer connections into the Internet. In fact, dialup connections are reputed to be the greatest source of DoS attacks using forged IP addresses. As long as the network access server supports Cisco Express Forwarding, Unicast RPF will work. In this topology, the customer aggregation routers need not have the full Internet routing table. Aggregation routers need the routing prefixes information (IP address block); hence, information configured or redistributed in the Interior Gateway Protocol (IGP) or Internal Border Gateway Protocol (IBGP) (depending on the way that you add customer routes into your network) would be enough for Unicast RPF to do its job.

    The figure below illustrates the application of Unicast RPF to the aggregation and access routers for an Internet service provider (ISP) point of presence (POP), with the ISP routers providing dialup customer connections. In this example, Unicast RPF is applied upstream from the customer dialup connection router on the receiving (input) interfaces of the ISP aggregation routers.

    Figure 4. Unicast RPF Applied to PSTN/ISDN Customer Connections

    Routing Table Requirements

    To work correctly, Unicast RPF needs proper information in the CEF tables. This requirement does not mean that the router must have the entire Internet routing table. The amount of routing information needed in the CEF tables depends on where Unicast RPF is configured and what functions the router performs in the network. For example, in an ISP environment, a router that is a leased-line aggregation router for customers needs only the information based on the static routes redistributed into the IGP or IBGP (depending on which technique is used in the network). Unicast RPF would be configured on the customer interfaces--hence the requirement for minimal routing information. In another scenario, a single-homed ISP could place Unicast RPF on the gateway link to the Internet. The full Internet routing table would be required. Requiring the full routing table would help protect the ISP from external DoS attacks that use addresses that are not in the Internet routing table.

    Where Not to Use Unicast RPF

    Unicast RPF should not be used on interfaces that are internal to the network. Internal interfaces are likely to have routing asymmetry (see the figure below), meaning multiple routes to the source of a packet. Unicast RPF should be applied only where there is natural or configured symmetry. As long as administrators carefully plan which interfaces they activate Unicast RPF on, routing asymmetry is not a serious problem.

    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. Hence, it is not recommended that you apply Unicast RPF where there is a chance of asymmetric routing, unless you use ACLs to allow the router to accept incoming packets. ACLs permit Unicast RPF to be used when packets are known to be arriving by specific, less optimal asymmetric input paths. However, 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.

    The figure below illustrates how Unicast RPF can block legitimate traffic in an asymmetrical routing environment.

    Figure 5. Unicast RPF Blocking Traffic in an Asymmetrical Routing Environment

    Unicast RPF with BOOTP and DHCP

    Unicast RPF will allow packets with 0.0.0.0 source and 255.255.255.255 destination to pass so that Bootstrap Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) functions work properly. This enhancement was added in Cisco IOS Release 12.0 and later, but it is not in Cisco IOS Release 11.1CC.

    Related Features and Technologies

    For more information about Unicast RPF-related features and technologies, review the following:

    • Unicast RPF requires Cisco express forwarding (CEF) to function properly on the router.

    • Unicast RPF can be more effective at mitigating spoofing attacks when combined with a policy of ingress and egress filtering using Cisco IOS access control lists (ACLs).
      • Ingress filtering applies filters to traffic received at a network interface from either internal or external networks. With ingress filtering, packets that arrive from other networks or the Internet and that have a source address that matches a local network, private, or broadcast address are dropped. In ISP environments, for example, ingress filtering can apply to traffic received at the router from either the client (customer) or the Internet.
      • Egress filtering applies filters to traffic exiting a network interface (the sending interface). By filtering packets on routers that connect your network to the Internet or to other networks, you can permit only packets with valid source IP addresses to leave your network.

    For more information on network filtering, refer to RFC 2267.

    • Cisco IOS software provides additional features that can help mitigate DoS attacks:
      • Committed Access Rate (CAR). CAR allows you to enforce a bandwidth policy against network traffic that matches an access list. For example, CAR allows you to rate-limit what should be low-volume traffic, such as ICMP traffic. To find out more about CAR, refer to the Cisco IOS Quality of Service Solutions Configuration Guide .
      • Context-based Access Control (CBAC). CBAC selectively blocks any network traffic not originated by a protected network. CBAC uses timeout and threshold values to manage session state information, helping to determine when to drop sessions that do not become fully established. Setting timeout values for network sessions helps mitigate DoS attacks by freeing up system resources, dropping sessions after a specified amount of time. For more information on CBAC, refer to the Cisco IOS Security Configuration Guide .
      • TCP Intercept. The TCP Intercept feature implements software to protect TCP servers from TCP SYN-flooding attacks, which are a type of DoS attack. A SYN-flooding attack occurs when a hacker floods a server with a barrage of requests for connection. Like CBAC, the TCP Intercept feature also uses timeout and threshold values to manage session state information, helping to determine when to drop sessions that do not become fully established. For more information on TCP Intercept, refer to the Cisco IOS Security Configuration Guide

    How to Configure Unicast Reverse Path Forwarding

    Configuring Unicast RPF

    To use Unicast RPF, you must configure the router for CEF switching or CEF distributed switching. There is no need to configure the input interface for CEF switching because Unicast RPF has been implemented as a search through the FIB using the source IP address. As long as CEF is running on the router, individual interfaces can be configured with other switching modes. Unicast RPF is an input-side function that is enabled on an interface or subinterface that supports any type of encapsulation and operates on IP packets received by the router. It is very important that CEF be turned on globally in the router--Unicast RPF will not work without CEF.

    To configure Unicast RPF, use the following commands beginning in global configuration mode:

    SUMMARY STEPS

      1.    Router(config)# ip cef

      2.    Router(config-if)# interface type

      3.    Router(config-if)# ip verify unicast reverse-path list

      4.    Router(config-if)# exit


    DETAILED STEPS
       Command or ActionPurpose
      Step 1 Router(config)# ip cef

      Example:
      

        
      
 

      Example:
      
          
      or 
      

        
      
 

      Example:
      
          
      Router(config)# ip cef distributed
      

        
      
 
            		 
          
      
Enables CEF or distributed CEF on the router. Distributed CEF is required for routers that use a Route Switch Processor (RSP) and Versatile Interface Processor (VIP), which includes Unicast RPF.
      

          
      
You might want to disable CEF or distributed CEF (dCEF) on a particular interface if that interface is configured with a feature that CEF or dCEF does not support. In this case, you would enable CEF globally, but disable CEF on a specific interface using the no ip route-cache cef interface command, which enables all but that specific interface to use express forwarding. If you have disabled CEF or dCEF operation on an interface and want to reenable it, you can do so by using the ip route-cache cef command in interface configuration mode.
      

         
      
      

      Step 2
Router(config-if)# interface type 
       
          
      
Selects the input interface on which you want to apply Unicast RPF. This is the receiving interface, which allows Unicast RPF to verify the best return path before forwarding the packet on to the next destination.
      

          
      
The interface type is specific to your router and the types of interface cards installed on the router. To display a list of available interface types, enter the interface ? command.
      

         
      
      

      Step 3
Router(config-if)#
 ip verify unicast reverse-path list 
       
          
      
Enables Unicast RPF on the interface. 
      

          
      • 
Use the list option to identify an access list. If the access list denies network access, spoofed packets are dropped at the interface. If the access list permits network access, spoofed packets are forwarded to the destination address. Forwarded packets are counted in the interface statistics. If the access list includes the logging option, information about the spoofed packets is logged to the log server.
        

        • 

      • 
Repeat this step for each access list that you want specify.
        

        • 

      

         
      
      

      Step 4
Router(config-if)#
 exit 
       
          
      
Exits interface configuration mode. Repeat Steps 2 and 3 for each interface on which you want to apply Unicast RPF. 
      

         
      
      

      

      

      

      Verifying Unicast RPF
      

      
To verify that Unicast RPF is operational, use the show cef interface command. The following example shows that Unicast RPF is enabled at interface serial2/0/0.
      

      Router-3# show cef interface serial 2/0/0
Serial2/0/0 is up (if_number 8)
 Internet address is 192.168.10.2/30
 ICMP redirects are never sent
 Per packet loadbalancing is disabled
!The next line displays Unicast RPF packet dropping information.
 IP unicast RPF check is enabled
 Inbound access list is not set
 Outbound access list is not set
 Interface is marked as point to point interface
 Packets switched to this interface on linecard are dropped to next slow path
 Hardware idb is Serial2/0/0
 Fast switching type 4, interface type 6
!The next line displays Unicast RPF packet dropping information.
 IP Distributed CEF switching enabled
 IP LES Feature Fast switching turbo vector
 IP Feature CEF switching turbo vector
 Input fast flags 0x40, Output fast flags 0x0, ifindex 7(7)
 Slot 2 Slot unit 0 VC -1
 Transmit limit accumulator 0x48001A02 (0x48001A02)
 IP MTU 1500
      

      

      

      Troubleshooting Tips
      

      
If you experience problems while using Unicast RPF, check the following items.
      

      

      HSRP Failure
      

       Failure to disable Unicast RPF before disabling CEF can cause Hot Standby Router Protocol (HSRP) failure. If you want to disable CEF on the router, you must first disable Unicast RPF. To disable Unicast RPF, see the section “Monitoring and Maintaining Unicast RPF.” 
	 
      

      

      

      Dropped Boot Requests
      

      
In Cisco IOS Release 11.1(17)CC, Unicast RPF can drop BOOTP request packets that have a source address of 0.0.0.0 due to source address verification at the interface. To enable boot requests to work on the interface, you must use ACLs instead of Unicast RPF.
      

      

      

      

      Monitoring and Maintaining
	 Unicast RPF
      

       This section
		describes commands used to monitor and maintain Unicast RPF.
	 
      


       
				  
       Command
				  
      
 
				      		
 
				  
       Purpose
				  
      
 
				      		

      
      

      
				  
       
					 
      Device# show ip traffic
      
 
				  
      

				      		
 
				  
       Displays
					 global router statistics about Unicast RPF drops and suppressed drops.
				  
      
 
				      		

      

      
				  
       
					 
      Device# show ip interface type
      
 
				  
      

				      		
 
				  
       Displays
					 per-interface statistics about Unicast RPF drops and suppressed drops.
				  
      
 
				      		

      

      
				  
       
					 
      Device# show access-lists
      
 
				  
      

				      		
 
				  
       Displays
					 the number of matches to a specific ACL.
				  
      
 
				      		

      

      
				  
       
					 
      Device(config-if)# no ip verify unicast reverse-path list
      
 
				  
      

				      		
 
				  
       Disables
					 Unicast RPF at the interface. Use the 
					 list option to
					 disable Unicast RPF for a specific ACL at the interface.
				  
      
 
				      		

      
      

      

      


      Caution
      To disable CEF, you must first disable Unicast RPF.
		Failure to disable Unicast RPF before disabling CEF can cause HSRP failure. If
		you want to disable CEF on the router, you must first disable Unicast RPF. 
	 
      

       Unicast RPF counts
		the number of packets dropped or suppressed because of malformed or forged
		source addresses. Unicast RPF counts dropped or forwarded packets that include
		the following global and per-interface information:
	 
      

      • 
		  
         Global Unicast
			 RPF drops 
		  
        

		
        • 

      • 
		  
         Per-interface
			 Unicast RPF drops 
		  
        

		
        • 

      • 
		  
         Per-interface
			 Unicast RPF suppressed drops 
		  
        

		
        • 

      

       The 
		show 
		  ip 
		  traffic command shows the total number (global
		count) of dropped or suppressed packets for all interfaces on the router. The
		Unicast RPF drop count is included in the IP statistics section.
	 
      

      Device# show ip traffic

IP statistics:
  Rcvd:  1471590 total, 887368 local destination
         0 format errors, 0 checksum errors, 301274 bad hop count
         0 unknown protocol, 0 not a gateway
         0 security failures, 0 bad options, 0 with options
  Opts:  0 end, 0 nop, 0 basic security, 0 loose source route
         0 timestamp, 0 extended security, 0 record route
         0 stream ID, 0 strict source route, 0 alert, 0 other
  Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
         0 fragmented, 0 couldn't fragment
  Bcast: 205233 received, 0 sent
  Mcast: 463292 received, 462118 sent
  Sent:  990158 generated, 282938 forwarded
  ! The second line below (“0 unicast RPF”) displays Unicast RPF packet dropping   information.
  Drop:  3 encapsulation failed, 0 unresolved, 0 no adjacency
         0 no route, 0 unicast RPF, 0 forced drop

      

       A nonzero value for
		the count of dropped or suppressed packets can mean one of two things: 
	 
      

      • 
		  
         Unicast RPF is
			 dropping or suppressing packets that have a bad source address (normal
			 operation).
		  
        

		
        • 

      • 
		  
         Unicast RPF is
			 dropping or suppressing legitimate packets because the route is misconfigured
			 to use Unicast RPF in environments where asymmetric routing exists; that is,
			 where multiple paths can exist as the best return path for a source address.
		  
        

		
        • 

      

       The 
		show 
		  ip 
		  interface command shows the total of dropped or
		suppressed packets at a specific interface. If Unicast RPF is configured to use
		a specific ACL, that ACL information is displayed along with the drop
		statistics. 
	 
      

      Device> show ip interface ethernet0/1/1

   Unicast RPF ACL 197
   1 unicast RPF drop
   1 unicast RPF suppressed drop

      

       The 
		show 
		  access-lists command displays the number of
		matches found for a specific entry in a specific access list.
	 
      

      Device> show access-lists

Extended IP access list 197
     deny ip 192.168.201.0 0.0.0.63 any log-input (1 match)
     permit ip 192.168.201.64 0.0.0.63 any log-input (1 match)
     deny ip 192.168.201.128 0.0.0.63 any log-input
     permit ip 192.168.201.192 0.0.0.63 any log-input
      

      

      

      

      Configuration Examples for Unicast Reverse Path Forwarding
      

      
    
      

      

      Example  Unicast RPF on a Leased-Line Aggregation Router
      

      
      
      
The following commands enable Unicast RPF on a serial interface:
      

      
      ip cef
! or “ip cef distributed” for RSP+VIP based routers
!
interface serial 5/0/0
 ip verify unicast reverse-path
      

    
      

      

      

      Example  Unicast RPF on the Cisco AS5800 Using Dialup Ports
      

      
      
      
The following example enables Unicast RPF on a Cisco AS5800. The interface Group-Async command makes it easy to apply Unicast RPF on all the dialup ports.
      

      
      ip cef
!
interface Group-Async1
 ip verify unicast reverse-path
      

    
      

      

      

      Example: Configuring Unicast
	 RPF
      

       
		 
		 
	 
      

      

      

      Example  Unicast RPF with ACLs and Logging
      

      
      
      
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 Ethernet0 to check packets arriving at that interface. 
      

      
      
For example, packets with a source address of 192.168.201.10 arriving at interface Ethernet0 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 Ethernet0 are forwarded because of the permit statement in ACL 197. ACL information about dropped or suppressed packets is logged (logging option turned on for the ACL entry) to the log server.
      

      
      ip cef distributed
!
int eth0/1/1
 ip address 192.168.200.1 255.255.255.0
 ip verify unicast reverse-path 197
!
int eth0/1/2
 ip address 192.168.201.1 255.255.255.0
!
access-list 197 deny   ip 192.168.201.0 0.0.0.63 any log-input
access-list 197 permit ip 192.168.201.64 0.0.0.63 any log-input
access-list 197 deny   ip 192.168.201.128 0.0.0.63 any log-input
access-list 197 permit ip 192.168.201.192 0.0.0.63 any log-input
access-list 197 deny ip host 0.0.0.0 any log

      

    
      

      

      

      

      Feature Information for Configuring Unicast Reverse Path Forwarding
      

      
			
      The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. 
      
 Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required. 
      

       
		

      Table 1 Feature Information for Configuring Unicast Reverse Path Forwarding
       
				  
       Feature Name
				  
      
 
				      		
 
				  
       Releases
				  
      
 
				      		
 
				  
       Feature Information
				  
      
 
				      		

      
      

       
				  
       Configuring Unicast Reverse Path Forwarding
				  
      
 
				      		
 
				  
       12.3(6) Cisco IOS XE 3.1.0SG
				  
      
 
				      		
 
				  
       The Unicast RPF feature helps to mitigate problems that are caused by malformed or forged IP source addresses that are passing through a router.
				  
      
 
				      		

      
      

      

      
 
		
       Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2010 Cisco Systems, Inc. All rights reserved.