Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring Unicast RPF (On a Router)

 

This example shows how to help defend ingress interfaces against denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks by configuring unicast RPF on a customer-edge interface to filter incoming traffic.

Requirements

No special configuration beyond device initialization is required.

Overview

In this example, Device A is using OSPF to advertise a prefix for the link that connects to Device D. Device B has unicast RPF configured. 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.

If ingress filtering is used in an environment where DHCP or BOOTP is used, it should be ensured that the packets with a source address of 0.0.0.0 and a destination address of 255.255.255.255 are allowed to reach the relay agent in routers when appropriate.

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
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.

Device A

Device B

Device C

Device D

Device E

Configuring Device A

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device A:

  1. Configure the interfaces.
  2. Configure OSPF.
  3. Configure the routing policy.
  4. If you are done configuring Device A, commit the configuration.

Configuring Device B

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device B:

  1. Configure the interfaces.
  2. Configure OSPF.
  3. Configure unicast RPF, and apply the optional fail filter.
  4. (Optional) Configure the fail filter that gets evaluated if a packet fails the RPF check.
  5. (Optional) Configure only active paths to be considered in the RPF check.

    This is the default behavior.

  6. If you are done configuring Device B, commit the configuration.

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.

Device A

Device B

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

Purpose

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

Action

user@B> show interfaces fe-0/1/0.13 extensive

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

From Device A, ping Device B’s interfaces, using 10.0.0.17 as the source address.

user@A> ping 10.0.0.6 source 10.0.0.17

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.

user@B> deactivate interfaces fe-1/1/1.6 family inet rpf-check
user@A> ping 10.0.0.6 source 10.0.0.17

Meaning

As expected, the ping operation succeeds.