Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring Unicast Reverse-Path-Forwarding Check

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

Large amounts of unauthorized traffic such as attempts to flood a network with fake (bogus) service requests in a DoS attack can consume network resources and deny service to legitimate users. One way to help prevent DoS and DDoS attacks is to verify that incoming traffic originates from legitimate network sources.

Unicast RPF helps ensure that a traffic source is legitimate (authorized) by comparing the source address of each packet that arrives on an interface to the forwarding table entry for its source address. If the device uses the same interface that the packet arrived on to reply to the packet's source, this verifies that the packet originated from an authorized source, and the device forwards the packet. If the device does not use the same interface that the packet arrived on to reply to the packet's source, the packet might have originated from an unauthorized source, and the device discards the packet.

In this example, Device B has unicast RPF configured. Device A is using OSPF to advertise a prefix for the link that connects to Device D. OSPF is enabled on the links between Device B and Device C and the links between Device A and Device C, but not on the links between Device A and Device B. Therefore, Device B learns about the route to Device D through Device C.

This example also includes a fail filter. When a packet fails the unicast RPF check, the fail filter is evaluated to determine if the packet should be accepted anyway. The fail filter in this example allows Device B’s interfaces to accept Dynamic Host Configuration Protocol (DHCP) packets. The filter accepts all packets with a source address of 0.0.0.0 and a destination address of 255.255.255.255.

Figure 1 shows the sample network.

Figure 1: Unicast RPF Sample Topoolgy

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configuring Device A

Step-by-Step Procedure

1. Configure the interfaces.
   [edit interfaces]user@A# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30
   user@A# set fe-0/0/2 unit 5 family inet address 10.0.0.5/30
   user@A# set fe-0/0/1 unit 17 family inet address 10.0.0.17/30
   user@A# set fe-0/1/1 unit 25 family inet address 10.0.0.25/30
   user@A# set fe-1/1/1 unit 29 family inet address 10.0.0.29/30
2. Configure OSPF.
   [edit protocols ospf]user@A# set export send-directuser@A# set area 0.0.0.0 interface fe-0/1/1.25user@A# set area 0.0.0.0 interface fe-1/1/1.29
3. Configure the routing policy.
   [edit policy-options policy-statement send-direct]user@A# set from protocol directuser@A# set from route-filter 10.0.0.16/30 exactuser@A# set then accept
4. If you are done configuring Device A, commit the configuration.
   [edit]user@A# commit

Configuring Device B

Step-by-Step Procedure

1. Configure the interfaces.
   [edit interfaces]user@B# set fe-1/2/0 unit 2 family inet address 10.0.0.2/30
   user@B# set fe-1/1/1 unit 6 family inet address 10.0.0.6/30
   user@B# set fe-0/1/1 unit 9 family inet address 10.0.0.9/30
   user@B# set fe-0/1/0 unit 13 family inet address 10.0.0.13/30
2. Configure OSPF.
   [edit protocols ospf area 0.0.0.0]user@B# set interface fe-0/1/1.9user@B# set interface fe-0/1/0.13
3. Configure unicast RPF, and apply the optional fail filter.
   [edit interfaces]user@B# set fe-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp
   user@B# set fe-1/1/1 unit 6 family inet rpf-check fail-filter rpf-special-case-dhcp
   user@B# set fe-0/1/1 unit 9 family inet rpf-check fail-filter rpf-special-case-dhcp
   user@B# set fe-0/1/0 unit 13 family inet rpf-check fail-filter rpf-special-case-dhcp
4. (Optional) Configure the fail filter that gets evaluated if a packet fails the RPF check.
   [edit firewall filter rpf-special-case-dhcp]user@B# set term allow-dhcp from source-address 0.0.0.0/32 user@B# set term allow-dhcp from destination-address 255.255.255.255/32 user@B# set term allow-dhcp then count rpf-dhcp-traffic user@B# set term allow-dhcp then accept user@B# set term default then log user@B# set term default then reject
5. (Optional) Configure only active paths to be considered in the RPF check.

   This is the default behavior.

   [edit routing-options forwarding-table]user@B# set unicast-reverse-path active-paths
6. If you are done configuring Device B, commit the configuration.
   [edit]user@B# commit

Results

Confirm your configuration by issuing the show firewall, show interfaces, show protocols, show routing-options, and show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Enter the configurations on Device C, Device D, and Device E, as shown in CLI Quick Configuration.

Verification

Confirm that the configuration is working properly.

• Confirm That Unicast RPF Is Enabled
• Confirm That the Source Addresses Are Blocked
• Confirm That the Source Addresses Are Unblocked

Confirm That Unicast RPF Is Enabled

Purpose

Make sure that the interfaces on Device B have unicast RPF enabled.

Action

 Logical interface fe-0/1/0.13 (Index 73) (SNMP ifIndex 553) (Generation 208)
    Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
    Traffic statistics:
     Input  bytes  :               999390
     Output bytes  :              1230122
     Input  packets:                12563
     Output packets:                12613
    Local statistics:
     Input  bytes  :               998994
     Output bytes  :              1230122
     Input  packets:                12563
     Output packets:                12613
    Transit statistics:
     Input  bytes  :                  396                    0 bps
     Output bytes  :                    0                    0 bps
     Input  packets:                    0                    0 pps
     Output packets:                    0                    0 pps
    Protocol inet, MTU: 1500, Generation: 289, Route table: 22
      Flags: Sendbcast-pkt-to-re, uRPF
      RPF Failures: Packets: 0, Bytes: 0
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 10.0.0.12/30, Local: 10.0.0.13, Broadcast: 10.0.0.15, Generation: 241

Meaning

The uRPF flag confirms that unicast RPF is enabled on this interface.

Confirm That the Source Addresses Are Blocked

Purpose

Use the ping command to make sure that Device B blocks traffic from unexpected source addresses.

Action

PING 10.0.0.6 (10.0.0.6): 56 data bytes
^C
--- 10.0.0.6 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Meaning

As expected, the ping operation fails.

Confirm That the Source Addresses Are Unblocked

Purpose

Use the ping command to make sure that Device B does not block traffic when the RPF check is deactivated.

Action

1. Deactivate the RPF check on one of the interfaces.
2. Rerun the ping operation.

PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=63 time=1.316 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=1.263 ms
^C
--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.263/1.289/1.316/0.027 ms

Meaning

As expected, the ping operation succeeds.