- play_arrow Port Security
- play_arrow Port Security Overview
-
- play_arrow IPSec
- play_arrow Understanding IPsec and Security Associations
- play_arrow IPsec Configurations and Examples
- play_arrow Configuring IPsec Security Associations
- play_arrow Using Digital Certificates for IPsec
- play_arrow Additional IPsec Options
- play_arrow Configuring IPsec Dynamic Endpoints
- play_arrow Additional ES and AS PIC Configuration Examples
- Example: ES PIC Manual SA Configuration
- Example: AS PIC Manual SA Configuration
- Example: ES PIC IKE Dynamic SA Configuration
- Example: AS PIC IKE Dynamic SA Configuration
- Example: IKE Dynamic SA Between an AS PIC and an ES PIC Configuration
- Example: AS PIC IKE Dynamic SA with Digital Certificates Configuration
- Example: Dynamic Endpoint Tunneling Configuration
-
- play_arrow Digital Certificates
- play_arrow Configuring Digital Certificates
- Public Key Cryptography
- Configuring Digital Certificates
- Configuring Digital Certificates for an ES PIC
- IKE Policy for Digital Certificates on an ES PIC
- Configuring Digital Certificates for Adaptive Services Interfaces
- Configuring Auto-Reenrollment of a Router Certificate
- IPsec Tunnel Traffic Configuration
- Tracing Operations for Security Services
- play_arrow Configuring SSH and SSL Router Access
-
- play_arrow Trusted Platform Module
- play_arrow MACsec
- play_arrow Understanding MACsec
- play_arrow MACsec Examples
-
- play_arrow MAC Limiting and Move Limiting
- play_arrow MAC Limiting and Move Limiting Configurations and Examples
- Understanding MAC Limiting and MAC Move Limiting
- Understanding MAC Limiting on Layer 3 Routing Interfaces
- Understanding and Using Persistent MAC Learning
- Configuring MAC Limiting
- Example: Configuring MAC Limiting
- Verifying That MAC Limiting Is Working Correctly
- Override a MAC Limit Applied to All Interfaces
- Configuring MAC Move Limiting (ELS)
- Verifying That MAC Move Limiting Is Working Correctly
- Verifying That the Port Error Disable Setting Is Working Correctly
-
- play_arrow DHCP Protection
- play_arrow DHCPv4 and DHCPv6
- play_arrow DHCP Snooping
- Understanding DHCP Snooping (ELS)
- Understanding DHCP Snooping (non-ELS)
- Understanding DHCP Snooping Trust-All Configuration
- Enabling DHCP Snooping (non-ELS)
- Configuring Static DHCP IP Addresses
- Example: Protecting Against Address Spoofing and Layer 2 DoS Attacks
- Example: Protecting Against DHCP Snooping Database Attacks
- Example: Protecting Against ARP Spoofing Attacks
- Example: Prioritizing Snooped and Inspected Packet
- Configuring DHCP Security with Q-in-Q Tunneling in Service Provider Style
- play_arrow DHCP Option 82
- play_arrow Dynamic ARP Inspection (DAI)
-
- play_arrow IP Source Guard
- play_arrow Understanding IP Source Guard
- play_arrow IP Source Guard Examples
- Example: Configuring IP Source Guard on a Data VLAN That Shares an Interface with a Voice VLAN
- Example: Configuring IP Source Guard with Other EX Series Switch Features to Mitigate Address-Spoofing Attacks on Untrusted Access Interfaces
- Example: Configuring IP Source Guard and Dynamic ARP Inspection to Protect the Switch from IP Spoofing and ARP Spoofing
- Example: Configuring IPv6 Source Guard and Neighbor Discovery Inspection to Protect a Switch from IPv6 Address Spoofing
- Configuring IP Source Guard to Mitigate the Effects of Source IP Address Spoofing and Source MAC Address Spoofing
- Example: Configuring IP Source Guard and Dynamic ARP Inspection on a Specified Bridge Domain to Protect the Devices Against Attacks
- Example: Configuring IPv6 Source Guard and Neighbor Discovery Inspection to Protect a Switch from IPv6 Address Spoofing
-
- play_arrow IPv6 Access Security
- play_arrow Neighbor Discovery Protocol
- play_arrow SLAAC Snooping
- play_arrow Router Advertisement Guard
-
- play_arrow Control Plane Distributed Denial-of-Service (DDoS) Protection and Flow Detection
- play_arrow Control Plane DDoS Protection
- play_arrow Flow Detection and Culprit Flows
-
- play_arrow Storm Control
- play_arrow Malware Protection
- play_arrow Juniper Malware Removal Tool
-
- play_arrow Configuration Statements and Operational Commands
Example: Configuring Unicast RPF (On a Switch)
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 (uRPF) to filter incoming traffic.
Requirements
This example uses two EX switches, referred to in this topic as Switch A and Switch B. Certain EX switch models allow you to configure uRPF on individual interfaces. Whereas on certain EX switch models you cannot configure individual interfaces for uRPF – the switch applies uRPF globally to all interfaces on the switch.
Any Junos OS release for EX switches but not earlier than Junos OS Release 10.1
Two EX switches that support uRPF configuration on individual interfaces.
Before you begin, ensure you have:
Connected the two switches by symmetrically routed interfaces.
Ensured that the interface on which you will configure unicast RPF is symmetrically routed. A symmetrically routed interface is an interface that uses the same route in both directions between the source and the destination. Do not enable unicast RPF on asymmetrically routed interfaces. An asymmetrically routed interface uses different paths to send and receive packets between the source and the destination.
In this example, if you are using EX switches that apply uRPF globally to all interfaces, then ensure that all switch interfaces are symmetrically routed before you enable unicast RPF on an interface. When you enable unicast RPF on any interface, it is enabled globally on all switch interfaces. Do not enable unicast RPF on asymmetrically routed interfaces. An asymmetrically routed interface uses different paths to send and receive packets between the source and the destination.
Overview and Topology
In this example, an enterprise network's system administrator wants to protect Switch A against potential DoS and DDoS attacks from the Internet. The administrator configures unicast RPF on interface xe-0/0/4 on Switch A. Packets arriving on interface xe-0/0/4 on Switch A from the Switch B source also use incoming interface xe-0/0/4 as the best return path to send packets back to the source. In this topology, Switch A and Switch B are both connected by symmetrically routed interfaces.
Switch A is on the edge of an enterprise network. The interface xe-0/0/4 on Switch A connects to the interface xe-0/0/5 on Switch B.
Switch B is on the edge of the service provider network that connects the enterprise network to the Internet.
Topology
Configuration
To enable unicast RPF, perform these tasks:
Procedure
CLI Quick Configuration
To quickly configure unicast RPF on Switch A, copy the following command and paste it into the switch terminal window:
[edit interfaces] set xe-0/0/4 unit 0 family inet rpf-check
Step-by-Step Procedure
To configure unicast RPF on Switch A:
Enable unicast RPF on interface xe-0/0/4:
content_copy zoom_out_map[edit interfaces] user@switch# set xe-0/0/4 unit 0 family inet rpf-check
Results
Check the results:
[edit interfaces] user@switch# show xe-0/0/4 { unit 0 { family inet { rpf-check; } } }
Verification
Unicast reverse-path forwarding (RPF) can help protect your LAN from denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks on untrusted interfaces. Unicast RPF filters traffic with source addresses that do not use the incoming interface as the best return path back to the source. If the network configuration changes so that an interface that has unicast RPF enabled becomes a trusted interface or becomes asymmetrically routed (the interface that receives a packet is not the best return path to the packet’s source), disable unicast RPF.
To disable uRPF on EX switches that apply uRPF globally to all interfaces, you must
delete it from every interface on which you explicitly configured it. If you do not
disable unicast RPF on every interface on which you explicitly enabled it, it remains
implicitly enabled on all interfaces. If you attempt to delete unicast RPF from an
interface on which it was not explicitly enabled, the warning: statement not
found
message appears. If you do not disable unicast RPF on every interface on
which you explicitly enabled it, unicast RPF remains implicitly enabled on all
interfaces.
On EX switch models that allow you to configure uRPF on individual interfaces, the switch does not apply unicast RPF to an interface unless you explicitly enable that interface for unicast RPF.
To disable unicast RPF, delete its configuration from the interface:
[edit interfaces]user@switch# delete xe-0/0/4 unit 0 family inet rpf-check
Verifying That Unicast RPF Is Enabled on the Switch
Purpose
Verify that unicast RPF is enabled and working on the interface.
Action
Use one of the show interfaces interface-name
commands with either the extensive or
detail options to verify that unicast RPF is enabled and
working on the switch. The example below displays output from the show
interfaces ge- extensive
command.
user@switch> show interfaces xe-0/0/4.0 extensive Physical interface: xe-0/0/4, Enabled, Physical link is Up Interface index: 147, SNMP ifIndex: 659 Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None, Ethernet-Switching Error: None, MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled, Flow control: Enabled, Speed Configuration: Auto Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Current address: 84:c1:c1:7b:a8:04, Hardware address: 84:c1:c1:7b:a8:04 Last flapped : 2023-04-04 10:34:13 PDT (00:01:29 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Active alarms : None Active defects : None PCS statistics Seconds Bit errors 2 Errored blocks 2 Link Degrade : Link Monitoring : Disable Interface transmit statistics: Disabled Logical interface xe-0/0/4.0 (Index 335) (SNMP ifIndex 696) Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2 Input packets : 0 Output packets: 1 Protocol inet, MTU: 1500 Max nh cache: 100000, New hold nh limit: 100000, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re, uRPF Addresses, Flags: Is-Preferred Is-Primary Destination: 10.0.1/24, Local: 10.0.1.1, Broadcast: 10.0.1.255 Protocol multiservice, MTU: Unlimited Flags: Is-Primary
Meaning
The show interfaces xe-0/0/4 extensive
command (and the show
interfaces xe-0/0/4 detail
command) displays in-depth information about the
interface. 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.
On EX switches that apply uRPF globally to all interfaces, uRPF is implicitly enabled on all switch interfaces, including aggregated Ethernet interfaces (also referred to as link aggregation groups or LAGs) and routed VLAN interfaces (RVIs) when you enable uRPF on a single interface. However, the uRPF status is shown as enabled only on interfaces for which you have explicitly configured uRPF. Thus, the uRPF flag is not displayed on interfaces for which you have not explicitly configured uRPF even though uRPF is implicitly enabled on all interfaces.
Troubleshooting Unicast RPF
Legitimate Packets Are Discarded
Problem
The switch filters valid packets from legitimate sources, which results in the switch's discarding packets that should be forwarded.
Solution
The interface or interfaces on which legitimate packets are discarded are asymmetrically routed interfaces. An asymmetrically routed interface uses different paths to send and receive packets between the source and the destination, so the interface that receives a packet is not the same interface the switch uses to reply to the packet's source.
Unicast RPF works properly only on symmetrically routed interfaces. A symmetrically routed interface is an interface that uses the same route in both directions between the source and the destination. Unicast RPF filters packets by checking the forwarding table for the best return path to the source of an incoming packet. If the best return path uses the same interface as the interface that received the packet, the switch forwards the packet. If the best return path uses a different interface than the interface that received the packet, the switch discards the packet.
On EX switches that apply uRPF globally to all interfaces, uRPF works properly only if all switch interfaces—including aggregated Ethernet interfaces (also referred to as link aggregation groups or LAGs), integrated routing and bridging (IRB) interfaces, and routed VLAN interfaces (RVIs)—are symmetrically routed, because unicast RPF is enabled globally on all switch interfaces.