Unicast Reverse Path Forwarding

Unicast Reverse Path Forwarding (uRPF, RFC 3704) helps prevent source IP address spoofing. uRPF ensures packets take the correct path through TNSR by comparing the source address to the routing table.

uRPF is a dynamic alternative to restricting source addresses based on VPF rules or ACL entries. uRPF is a better fit for use with dynamic routing since TNSR consults the routing table instead of using manually configured source addresses and interface lists.

Configuring uRPF

To configure uRPF, start in config mode and use the following command to create a uRPF filter and enter config-urpf-filter mode:

tnsr(config)# urpf-filter interface <if-name> address-family (ipv4|ipv6) direction (in|out)
tnsr(config-urpf-filter)#

The parameters when creating a uRPF filter are:

interface <if-name>:

The name of the interface where TNSR will perform uRPF.

address-family (ipv4|ipv6):

The address family of incoming packets subject to uRPF.

direction (in|out):

The direction in which TNSR will perform uRPF.

in:

TNSR performs uRPF when a packet arrives on this interface (ingress). If the route back to the source address does not match the interface upon which the inbound packet arrived, TNSR drops the packet.

out:

TNSR performs uRPF when a packet exits this interface (egress). If TNSR would route the source address out the same interface it is sending the packet through, it drops the packet.

Once in config-urpf-filter mode there are additional commands:

mode (loose|strict):

Configures the type of uRPF TNSR will perform on packets.

strict:

This is the default mode which behaves as described earlier in this document, ensuring the routes to source addresses match interfaces.

loose:

Relaxes uRPF so TNSR only validates that the source address has a route available through any interface.

vrf <vrf>:

Configures a specific VRF TNSR will consult for uRPF validation.

Compatibility

The ingress checks performed by uRPF on an interface are not compatible with TNSR acting as a DHCP client on that interface. The initial DHCP request would egress but uRPF would drop the response from the server because the local routing table would not yet have an entry associating the server address with the interface.

If the IP address of the DHCP server is a known and static IP address, this limitation can be worked around by adding a static route for that address:

tnsr(config)# route table default
tnsr(config-route-table)# route <dhcp-server-address>/32
tnsr(config-rttbl4-next-hop)# next-hop 0 via 0.0.0.0 <interface-name>
tnsr(config-rttbl4-next-hop)# exit
tnsr(config-route-table)# exit