Network administrators can use Unicast Reverse Path Forwarding (Unicast RPF) to help limit the malicious traffic on an enterprise network. This security feature works by enabling a router to verify the reachability of the source address in packets being forwarded. This capability can limit the appearance of spoofed addresses on a network. If the source IP address is not valid, the packet is discarded. Unicast RPF works in one of three different modes: strict mode, loose mode, or VRF mode. Note that not all network devices support all three modes of operation. Unicast RPF in VRF mode will not be covered in this document.
When administrators use Unicast RPF in strict mode, the packet must be received on the interface that the router would use to forward the return packet. Unicast RPF configured in strict mode may drop legitimate traffic that is received on an interface that was not the router's choice for sending return traffic. Dropping this legitimate traffic could occur when asymmetric routing paths are present in the network.
When administrators use Unicast RPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior using the allow-default option, which allows the use of the default route in the source verification process. Additionally, a packet that contains a source address for which the return route points to the Null 0 interface will be dropped. An access list may also be specified that permits or denies certain source addresses in Unicast RPF loose mode.
Care must be taken to ensure that the appropriate Unicast RPF mode (loose or strict) is configured during the deployment of this feature because it can drop legitimate traffic. Although asymmetric traffic flows may be of concern when deploying this feature, Unicast RPF loose mode is a scalable option for networks that contain asymmetric routing paths.
Unicast RPF in an Enterprise Network
In many enterprise environments, it is necessary to use a combination of strict mode and loose mode Unicast RPF. The choice of the Unicast RPF mode that will be used will depend on the design of the network segment connected to the interface on which Unicast RPF is deployed.
Administrators should use Unicast RPF in strict mode on network interfaces for which all packets received on an interface are guaranteed to originate from the subnet assigned to the interface. A subnet composed of end stations or network resources fulfills this requirement. Such a design would be in place for an access layer network or a branch office where there is only one path into and out of the branch network. No other traffic originating from the subnet is allowed and no other routes are available past the subnet.
Unicast RPF loose mode can be used on an uplink network interface that has a default route associated with it.
Unicast RPF Examples
Cisco IOS Devices
An important consideration for deployment is that Cisco Express Forwarding switching must be enabled for Unicast RPF to function. This command has been enabled by default as of IOS version 12.2. If it is not enabled, administrators can enable it with the following global configuration command: ip cef
Unicast RPF is enabled on a per-interface basis. The ip verify unicast source reachable-via rx command enables Unicast RPF in strict mode. To enable loose mode, administrators can use the any option to enforce the requirement that the source IP address for a packet must appear in the routing table. The allow-default option may be used with either the rx or any option to include IP addresses not specifically contained in the routing table. The allow-self-ping option should not be used because it could create a denial of service condition. An access list such as the one that follows may also be configured to specifically permit or deny a list of addresses through Unicast RPF:
Addresses that should never appear on a network can be dropped by entering a route to a null interface. The following command will cause all traffic received from the 10.0.0.0/8 network to be dropped even if Unicast RPF is enabled in loose mode with the allow-default option: ip route 10.0.0.0 255.0.0.0 Null0
Unicast RPF can be configured on the PIX Security Appliance, the ASA Security Appliance, the Catalyst 6500 switch, or the Cisco 7600 router Firewall Services Module on a per-interface basis with the following global command: ip verify reverse-path interfaceinterface_name
Troubleshooting Unicast RPF
Cisco IOS Devices
The show cef interfaceinterface_name command can be used to show that Cisco Express Forwarding and Unicast RPF have been enabled on an interface. The following response is an example of output for this command.
router#show cef interface FastEthernet 0/0
FastEthernet0/0 is up (if_number 3)
Corresponding hwidb fast_if_number 3
Corresponding hwidb firstsw->if_number 3
Internet address is 10.81.7.118/28
ICMP redirects are always sent
Per packet load-sharing is disabled
IP unicast RPF check is enabled
Inbound access list is not set
Outbound access list is not set
Hardware idb is FastEthernet0/0
Fast switching type 1, interface type 18
IP CEF switching enabled
IP CEF Fast switching turbo vector
Input fast flags 0x0, Input fast flags2 0x0, Output fast flags 0x0, Output fast flags2 0x0
Slot 0 Slot unit 0 Unit 0 VC -1
Transmit limit accumulator 0x0 (0x0)
IP MTU 1500
The show ip verify statistics command can provide information about Unicast RPF statistics on a PIX/ASA/FWSM firewall. The following example shows 21 drops by Unicast RPF on the outside interface and 2738 packets dropped by Unicast RPF on the inside interface. Dropped packets should be investigated to determine their source and administrators should consider whether the packets indicate attempts to circumvent network security.
Unallocated IP addresses, IP addresses for private internets as mentioned in RFC 1918, and special use IP addresses as mentioned in RFC 3330 can be a problem when they are used to route packets on the Internet. These addresses can be used to source attacks that could make it difficult or impossible to trace back to the source. Filtering these addresses at your network boundary will provide another layer of security. The official list of unallocated "bogon" Internet addresses is maintained by Team Cymru. They also maintain a page dedicated to filtering these bogon addresses at The Bogon Reference Page.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.