## Introduction

This lab looks at 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 4 in this lab:

    A4>show ip cef
    Prefix               Next Hop             Interface
    0.0.0.0/0            100.68.4.20          GigabitEthernet1
    0.0.0.0/8            drop
    0.0.0.0/32           receive
    100.68.4.0/24        100.68.4.20          GigabitEthernet1
    100.68.4.1/32        100.68.4.20          GigabitEthernet1
    100.68.4.2/32        100.68.4.20          GigabitEthernet1
    100.68.4.3/32        100.68.4.20          GigabitEthernet1
    100.68.4.4/32        receive              Loopback0
    100.68.4.16/31       100.68.4.20          GigabitEthernet1
    100.68.4.18/31       100.68.4.20          GigabitEthernet1
    100.68.4.20/31       attached             GigabitEthernet1
    100.68.4.20/32       attached             GigabitEthernet1
    100.68.4.21/32       receive              GigabitEthernet1
    100.68.4.28/30       100.68.4.20          GigabitEthernet1
    100.68.4.34/31       attached             GigabitEthernet2
    100.68.4.34/32       receive              GigabitEthernet2
    100.68.4.35/32       attached             GigabitEthernet2
    100.68.4.64/26       100.68.4.35          GigabitEthernet2
    100.127.1.0/24       100.68.4.20          GigabitEthernet1
    127.0.0.0/8          drop
    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 is 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 GigabitEthernet2
     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 GigabitEthernet2

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 GigabitEthernet2

and

    show ipv6 interface GigabitEthernet2

you will see some of the uRPF stats displayed:

    AX#sh ip interface gig 2
    GigabitEthernet2 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 gig 2
    GigabitEthernet2 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 GigabitEthernet4
     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, check that your network actually is working. If you cannot find the issue, 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 exited the Customer Router. Let’s look on the Access Router now:

    AX#show ip interface gig 2
    GigabitEthernet2 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.↩︎