Introduction

This lab is focused on demonstrating how to implement uRPF within the ASN.

 

Lab Topology

The diagram below is a reminder of the lab topology:

 

Introduction

This simple exercise shows how to configure unicast reverse path forwarding (uRPF) on the access ports of the access router in the AS.

Unicast RPF is designed to help mitigate attacks based on source address spoofing.  Configuring Unicast RPF on an interface drops the packets with spoofed IP source address as they enter the device on that interface.

The router’s forwarding table contains a list of all destinations and which interface is used to get to those destinations - here is an example of the forwarding table (FIB) on the Access Router of Group 6 in this lab:

A6>show ip cef
Prefix               Next Hop             Interface
0.0.0.0/0            100.68.6.20          FastEthernet0/0
0.0.0.0/8            drop
0.0.0.0/32           receive
100.68.6.0/24        100.68.6.20          FastEthernet0/0
100.68.6.1/32        100.68.6.20          FastEthernet0/0
100.68.6.2/32        100.68.6.20          FastEthernet0/0
100.68.6.3/32        100.68.6.20          FastEthernet0/0
100.68.6.4/32        receive              Loopback0
100.68.6.5/32        100.68.6.20          FastEthernet0/0
100.68.6.16/31       100.68.6.20          FastEthernet0/0
100.68.6.18/31       100.68.6.20          FastEthernet0/0
100.68.6.20/31       attached             FastEthernet0/0
100.68.6.20/32       attached             FastEthernet0/0
100.68.6.21/32       receive              FastEthernet0/0
100.68.6.22/31       100.68.6.20          FastEthernet0/0
100.68.6.28/30       100.68.6.20          FastEthernet0/0
100.68.6.34/31       attached             FastEthernet0/1
100.68.6.34/32       receive              FastEthernet0/1
100.68.6.35/32       attached             FastEthernet0/1
100.68.6.64/26       100.68.6.35          FastEthernet0/1
100.68.6.64/32       192.0.2.1            Null0
100.68.106.0/24      100.68.6.35          FastEthernet0/1
100.127.1.0/24       100.68.6.20          FastEthernet0/0
127.0.0.0/8          drop
192.0.2.1/32         attached             Null0
224.0.0.0/4          drop
224.0.0.0/24         receive
240.0.0.0/4          drop
255.255.255.255/32   receive

When uRPF is turned on for any interface, the router will compare the source address and inbound interface for any packet entering any interface. If the source address and inbound interface match the FIB entry, the packet is forwarded. If they do not match what is in the FIB, the packet is silently discarded.

Spoofed source addresses are caused either by denial-of-service (DoS) attacks or mis-configured end-user devices.  Turning on uRPF ensures that only packets with valid source addresses are permitted in through the interface.

uRPF is one of the recommendations in the IETF’s BCP38 document (May 2000), and an essential part of the global MANRS initiative to help secure the global Internet infrastructure.

 

Implementing uRPF on Access Router

The Access router has just one customer connected to it. We will now turn on uRPF on that customer interface for both IPv4 and IPv6, like this:

interface FastEthernet0/1
 description P2P Ethernet Link to CustX
 ip verify unicast source reachable-via rx allow-self-ping
 ipv6 verify unicast source reachable-via rx
!

Note we are using newer Cisco IOS syntax - some systems will still support the older ip verify unicast reverse-path syntax - the newer syntax is perhaps more intuitive as to what the command is doing.

The reachable-via rx option is what is called strict-mode of uRPF. As described in the introduction, if the source address and incoming interface do not match what is in the FIB, the packet is dropped1.

The allow-self-ping option allows the operator to ping the local interface and not have the packets dropped by uRPF.

Once uRPF is configured, check the status by doing:

show cef interface FastEthernet 0/1

If you look carefully in the output, you will see reference to uRPF being configured on the inbound interface. And if you run:

show ip interface FastEthernet 0/1

and

show ipv6 interface FastEthernet 0/1

you will see some of the uRPF stats displayed:

AX#sh ip interface fast 0/1
FastEthernet0/1 is up, line protocol is up
...
  IP verify source reachable-via RX, allow self-ping
   0 verification drops
   0 suppressed verification drops
   0 verification drop-rate

AX#sh ipv6 int fast 0/1
FastEthernet0/1 is up, line protocol is up
...
 IPv6 verify source reachable-via rx
   0 verification drop(s) (process), 0 (CEF)
   0 suppressed verification drop(s) (process), 0 (CEF)
...

Counters are zero here as we haven’t tested it yet.

 

Implementing uRPF for Server subnet

The server appliance for each group is connected to the Core router. We will turn on uRPF there too. Compromised end-user devices are the biggest source of spoofed addresses on the Internet today.

As above, we turn on uRPF on the server subnet only:

interface FastEthernet0/1
 description Server Subnet
 ip verify unicast source reachable-via rx allow-self-ping
 ipv6 verify unicast source reachable-via rx
!

We don’t configure uRPF on the other interfaces - this router is in the core of the network, and uRPF really is only intended for access interfaces connecting to single-homed edge networks or end-user devices2.

 

Testing

To test that our uRPF is working, we are going to go to our Customer Router and set up a “fake” address on a Loopback interface.

First, try a traceroute to 8.8.8.8 from the Customer Router - use the Loopback 0 interface address as the source, like this (using Group 6 Customer Router as an example):

Cust6#trace 8.8.8.8 source loop 0
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1 100.68.6.34 [AS 60] 16 msec 16 msec 20 msec
  2 100.68.6.20 [AS 60] 20 msec 36 msec 36 msec
  3 100.68.6.17 [AS 60] 64 msec 52 msec 60 msec
  4 100.122.1.4 [AS 60] 88 msec 80 msec 80 msec
  5 10.10.0.241 [AS 60] 80 msec 96 msec 96 msec
...
 14 8.8.8.8 [AS 60] 116 msec 116 msec 124 msec

If the traceroute doesn’t work, did you remember to remove the trigger routes at the end of the uRPF lab? Check on the Trigger Router to make sure you did this. If you did, and it still doesn’t reach 8.8.8.8 then please check with your lab instructor.

Now create a second Loopback interface with the IPv4 address 10.255.255.1/32. Don’t worry about IPv6 for now - the effect is the same:

interface Loopback1
 ip address 10.255.255.1 255.255.255.255
!

Now try tracing to 8.8.8.8 again. You should see something like this:

Cust6#trace 8.8.8.8 source loop 1
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1  *  *  *
  2

which is what you’d expect - there is no route from the Access Router to the Customer Router for 10.255.255.1. However, the ICMP packets sent by the traceroute command will still have exit the Customer Router. Let’s look on the Core Router now:

AX#show ip interface fast0/1
FastEthernet0/1 is up, line protocol is up
...
  IP verify source reachable-via RX, allow self-ping
   6 verification drops
   0 suppressed verification drops
   0 verification drop-rate

The 6 verification drops in the example above are the ICMP packets from the traceroute which the uRPF configuration automatically dropped.

 

Wrapping Up

This lab has shown how to configure uRPF on access interfaces on routers. Once you have completed your testing, and the lab instructor has given the say so, remove the second Loopback interface from the Customer Router. Simply do:

no interface Loopback1

and you will then be ready to proceed to the next lab.

 


  1. There is another mode of uRPF called loose-mode. This allows the source address to come from any interface, and is configured by ip verify unicast source reachable-via any - there is an IPv6 equivalent as well. This option is used when the network operator is interested in dropping non-routed address space and is typically used on routers carrying the full BGP table or when customers are multi-homed on to the service provider network using BGP.

  2. uRPF can be configured in multihoming situations, but great care is required not to drop valid packets due to asymmetric traffic flows. This set up is beyond the scope of this workshop. Please refer to the BGP Attribute presentation where the Weight is discussed.