The Unicast RPF feature reduces problems that are caused by the introduction of malformed or forged (spoofed) IPv4 source addresses into a network by discarding IPv4 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) attacks, can take advantage of forged or rapidly changing source IPv4 or IPv6 addresses to allow attackers to thwart efforts to locate or filter the attacks. Unicast RPF deflects attacks by forwarding only the packets that have source addresses that are valid and consistent with the IP routing table.

When you enable Unicast RPF on an interface, the examines all ingress packets received on that interface to ensure that the source address and source interface appear in the routing table and match the interface on which the packet was received. This examination of source addresses relies on the Forwarding Information Base (FIB).

Unicast RPF verifies that any packet received at a interface arrives on the best return path (return route) to the source of the packet by doing a reverse lookup in the FIB. 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, the source address might have been modified by the attacker. If Unicast RPF does not find a reverse path for the packet, the packet is dropped.

Note

With Unicast RPF, all equal-cost “best” return paths are considered valid, which means that Unicast RPF works where multiple return paths exist, if 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 Interior Gateway Routing Protocol (EIGRP) variants are being used and unequal candidate paths back to the source IP address exist.

Unicast RPF (uRPF) has the following configuration guidelines and limitations:

• You must apply uRPF at the interface downstream from the larger portion of the network, preferably at the edges of your network.

• The further downstream that you apply uRPF, the finer the granularity you have in mitigating address spoofing and in identifying the sources of spoofed addresses. For example, applying uRPF on an aggregation device helps to mitigate attacks from many downstream networks or clients and is simple to administer, but it does not help identify the source of the attack. Applying uRPF at the network access server helps limit the scope of the attack and trace the source of the attack; however, deploying uRPF across many sites does add to the administration cost of operating the network.

• The more entities that deploy uRPF across Internet, intranet, and extranet resources, means that the better the chances are of mitigating large-scale network disruptions throughout the Internet community, and the better the chances are of tracing the source of an attack.

• uRPF will not inspect IP packets that are encapsulated in tunnels, such as generic routing encapsulation (GRE) tunnels. You must configure uRPF at a home gateway so that uRPF processes network traffic only after the tunneling and encryption layers have been stripped off the packets.

• You can use uRPF in any “single-homed” environment where there is only one access point out of the network or one upstream connection. Networks that have one access point provide 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.

• Do not use uRPF on interfaces that are internal to the network. Internal interfaces are likely to have routing asymmetry, which means that multiple routes to the source of a packet exist. You should configure uRPF only where there is natural or configured symmetry. Do not configure strict uRPF.

• uRPF allows packets with 0.0.0.0 source and 255.255.255.255 destination to pass so that the Bootstrap Protocol (BOOTP) and the Dynamic Host Configuration Protocol (DHCP) can operate correctly.

• When uRPF is enabled, loose mode is applied for both IPv4 and IPv6. However, strict mode can be applied per protocol.

• For strict uRPF to work, you must enable it on both the ingress interface and the interface where the source IP address is learned.

• The switch hardware does not implement strict uRPF per the configured routing interface.

• Strict uRPF is implemented per learned route on strict uRPF-enabled interfaces.

• If a route is resolved as ECMP, strict uRPF will fall back to loose mode.

• Because of the hardware limitation on the trap resolution, uRPF might not be applied on supervisor-bound packets via inband.

• For IP traffic, both IPv4 and IPv6 configurations should be enabled simultaneously.

• Due to hardware limitations, the Cisco Nexus 3600 Series switches support only the following combinations:

  uRPF Configuration		Applied Traffic Check on Source IP Address
  IPv4	IPv6	IP Unipath	IP ECMP	MPLS Encap/VPN/ECMP
  Disable	Disable	Allow	Allow	Allow
  Loose	Loose	uRPF loose	uRPF loose	uRPF loose
  Strict	Strict	uRPF strict	uRPF loose	uRPF loose

This table lists the default settings for Unicast RPF parameters.

The following examples show how to configure loose Unicast RPF for IPv4/IPv6 packets:

• 
  interface Ethernet2/3
  ip address 172.23.231.240/23
  ip verify unicast source reachable-via any 

• interface Ethernet2/3
  ipv6 address 2001:0DB8:c18:1::3/64
  ipv6 verify unicast source reachable-via any 

The following examples show how to configure strict Unicast RPF for IPv4/IPv6 packets:

• 
  interface Ethernet2/2
  ip address 172.23.231.240/23
  ip verify unicast source reachable-via rx

• 
  interface Ethernet2/2
  ipv6 address 2001:0DB8:c18:1::3/64
  ipv6 verify unicast source reachable-via rx

To display Unicast RPF configuration information, perform one of the following tasks: