Welcome to the Unicast RPF module. By the end of this module, you should be able to describe the operation and configuration of Unicast RPF. The Unicast Reverse Path Forwarding, or RPF, automates anti spoofing filters based on routing tables, also known as Routing Information Base or RIB. These checks validate packet receipt or interfaces where Junos OS would expect to receive such traffic. By default, the system expects to receive traffic on a given interface if it has an active route to the packet source address, and if it received the packet on the interface, that is the next hop for the active route to the packet's source address. For example, if a device running Junos OS receives a packet with a source address of 10.10.10.10 on interface GE0/0/1.0 and you configure the device to perform the unicast RPF check on that interface, It examines its routing table for the best route to 10.10.10.10. If this route lookup returns a route for 10.10.10.0/24 with the next hop of GE0/0/1.0, The packet passes the unicast RPF check and is accepted. You can combine both unicast RPF and firewall filters on the same interface. Junos OS accomplishes the unicast RPF checks by downloading additional information to the packet forwarding Engine. Therefore, activating this feature increases packet forwarding Engine memory usage. By default, devices running Junos OS use the strict mode RPF check. You can instead configure it to use the loose mode RPF check, which checks only to ensure a valid route to the source address exists in the routing table. However, in networks with a default route, a valid route to every IP address always exists, so using a loose mode check does not make sense in this environment. In general, using the default strict mode provides the best results. By default, when a Junos device performs its RPF check, it considers only the active routes to a given destination. In networks where perfectly symmetric routing exists. The default behavior of considering only active routes should work. However, in cases where the possibility of asymmetric routing or different forward and reverse paths exists, this design can cause legitimate traffic to be dropped. To ease this issue, you can require that the system consider all feasible routes to a destination when it performs the RPF check. In this mode, the system considers all routes it receives to a given prefix. Even if they are not the act of route to the destination. In networks where the possibility of asymmetric routing exists, you should activate this option. You do not need to implement RPF checking on all devices within your network. Typically, you can figure only the Edge device to perform RPF checking because all inbound and outbound spoofing passes through that device. In the sample network shown, R1 should be configured to perform RPF checks on all three interfaces. Note that the unicast RPF configuration options vary between Juno's devices. Refer to the product specific documentation for detailed support information. When a device running Junos OS finds that a packet has failed the RPF check, it discards it by default. However, if you specify an optional fail filter, the device processes packets that fail the RPF check through that filter prior to discarding them. In the fail filter, you can perform all the actions and action modifiers that you could in any other firewall filter, including accepting the traffic despite the packet failing the RPF check. Note that if you choose to log packets in an input firewall filter, but the packets then fail the RPF check the software does not log them. To log these packets, you must log them in an RPF fail filter. On most devices running Junos OS, Dynamic Host Configuration Protocol or DHCP and Bootstrap Protocol or Boot P requests fail the RPF checks. To enable these requests, you must configure a fail filter that permits traffic with a source address of default and a destination address of 255.255.255.255. This code shows a sample fail filter to include DHCP and Boot P requests. In the example, RPF is enabled in strict mode on GCE0/0/1. A Junos device considers only the active paths to any prefix. If RPF is enabled in loose mode on GCE0/0/2. A Junos device considers a valid route to the source address in the routing table. The fail filter named RPF, DHCP applies to the GE0/0/3 interfaces. As you can see, the configuration defines the RPF DHCP fail filter, and permits DHCP and Boot P requests. Now that you have enabled RPF on all interfaces, you do not need to include anti spoofing terms within the firewall filters. You show interfaces, interface name commands with either the extensive or detail options to verify that Unicast RPF is enabled and working on Junos device. The flags output field near the bottom of the display Reports the Unicast RPF status. If unicast RPF has not been enabled, the URPF flag is not displayed.
