- play_arrow Configuring Firewall Filters
- play_arrow Understanding How Firewall Filters Protect Your Network
- Firewall Filters Overview
- Router Data Flow Overview
- Stateless Firewall Filter Overview
- Understanding How to Use Standard Firewall Filters
- Understanding How Firewall Filters Control Packet Flows
- Stateless Firewall Filter Components
- Stateless Firewall Filter Application Points
- How Standard Firewall Filters Evaluate Packets
- Understanding Firewall Filter Fast Lookup Filter
- Understanding Egress Firewall Filters with PVLANs
- Selective Class-based Filtering on PTX Routers
- Guidelines for Configuring Firewall Filters
- Guidelines for Applying Standard Firewall Filters
- Supported Standards for Filtering
- Monitoring Firewall Filter Traffic
- Troubleshooting Firewall Filters
- play_arrow Firewall Filter Match Conditions and Actions
- Overview of Firewall Filters (OCX Series)
- Overview of Firewall Filter Profiles on ACX Series Routers (Junos OS Evolved)
- Understanding Firewall Filter Match Conditions
- Understanding Firewall Filter Planning
- Understanding How Firewall Filters Are Evaluated
- Understanding Firewall Filter Match Conditions
- Firewall Filter Flexible Match Conditions
- Firewall Filter Nonterminating Actions
- Firewall Filter Terminating Actions
- Firewall Filter Match Conditions and Actions (ACX Series Routers)
- Firewall Filter Match Conditions and Actions in ACX Series Routers (Junos OS Evolved)
- Firewall Filter Match Conditions for Protocol-Independent Traffic
- Firewall Filter Match Conditions for IPv4 Traffic
- Firewall Filter Match Conditions for IPv6 Traffic
- Firewall Filter Match Conditions Based on Numbers or Text Aliases
- Firewall Filter Match Conditions Based on Bit-Field Values
- Firewall Filter Match Conditions Based on Address Fields
- Firewall Filter Match Conditions Based on Address Classes
- Understanding IP-Based Filtering and Selective Port Mirroring of MPLS Traffic
- Firewall Filter Match Conditions for MPLS Traffic
- Firewall Filter Match Conditions for MPLS-Tagged IPv4 or IPv6 Traffic
- Firewall Filter Match Conditions for VPLS Traffic
- Firewall Filter Match Conditions for Layer 2 CCC Traffic
- Firewall Filter Match Conditions for Layer 2 Bridging Traffic
- Firewall Filter Support on Loopback Interface
- play_arrow Applying Firewall Filters to Routing Engine Traffic
- Configuring Logical Units on the Loopback Interface for Routing Instances in Layer 3 VPNs
- Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List
- Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources
- Example: Configure a Filter to Block Telnet and SSH Access
- Example: Configuring a Filter to Block TFTP Access
- Example: Configuring a Filter to Accept Packets Based on IPv6 TCP Flags
- Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers
- Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods
- Example: Protecting the Routing Engine with a Packets-Per-Second Rate Limiting Filter
- Example: Configuring a Filter to Exclude DHCPv6 and ICMPv6 Control Traffic for LAC Subscriber
- Port Number Requirements for DHCP Firewall Filters
- Example: Configuring a DHCP Firewall Filter to Protect the Routing Engine
- play_arrow Applying Firewall Filters to Transit Traffic
- Example: Configuring a Filter for Use as an Ingress Queuing Filter
- Example: Configuring a Filter to Match on IPv6 Flags
- Example: Configuring a Filter to Match on Port and Protocol Fields
- Example: Configuring a Filter to Count Accepted and Rejected Packets
- Example: Configuring a Filter to Count and Discard IP Options Packets
- Example: Configuring a Filter to Count IP Options Packets
- Example: Configuring a Filter to Count and Sample Accepted Packets
- Example: Configuring a Filter to Set the DSCP Bit to Zero
- Example: Configuring a Filter to Set the DSCP Bit to Zero
- Example: Configuring a Filter to Match on Two Unrelated Criteria
- Example: Configuring a Filter to Accept DHCP Packets Based on Address
- Example: Configuring a Filter to Accept OSPF Packets from a Prefix
- Example: Configuring a Stateless Firewall Filter to Handle Fragments
- Configuring a Firewall Filter to Prevent or Allow IPv4 Packet Fragmentation
- Configuring a Firewall Filter to Discard Ingress IPv6 Packets with a Mobility Extension Header
- Example: Configuring an Egress Filter Based on IPv6 Source or Destination IP Addresses
- Example: Configuring a Rate-Limiting Filter Based on Destination Class
- play_arrow Configuring Firewall Filters in Logical Systems
- Firewall Filters in Logical Systems Overview
- Guidelines for Configuring and Applying Firewall Filters in Logical Systems
- References from a Firewall Filter in a Logical System to Subordinate Objects
- References from a Firewall Filter in a Logical System to Nonfirewall Objects
- References from a Nonfirewall Object in a Logical System to a Firewall Filter
- Example: Configuring Filter-Based Forwarding
- Example: Configuring Filter-Based Forwarding on Logical Systems
- Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods
- Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods
- Unsupported Firewall Filter Statements for Logical Systems
- Unsupported Actions for Firewall Filters in Logical Systems
- Filter-Based Forwarding for Routing Instances
- Forwarding Table Filters for Routing Instances on ACX Series Routers
- Configuring Forwarding Table Filters
- play_arrow Configuring Firewall Filter Accounting and Logging
- play_arrow Attaching Multiple Firewall Filters to a Single Interface
- Applying Firewall Filters to Interfaces
- Configuring Firewall Filters
- Multifield Classifier Example: Configuring Multifield Classification
- Multifield Classifier for Ingress Queuing on MX Series Routers with MPC
- Assigning Multifield Classifiers in Firewall Filters to Specify Packet-Forwarding Behavior (CLI Procedure)
- Understanding Multiple Firewall Filters in a Nested Configuration
- Guidelines for Nesting References to Multiple Firewall Filters
- Understanding Multiple Firewall Filters Applied as a List
- Guidelines for Applying Multiple Firewall Filters as a List
- Example: Applying Lists of Multiple Firewall Filters
- Example: Nesting References to Multiple Firewall Filters
- Example: Filtering Packets Received on an Interface Set
- play_arrow Attaching a Single Firewall Filter to Multiple Interfaces
- Interface-Specific Firewall Filter Instances Overview
- Interface-Specific Firewall Filter Instances Overview
- Filtering Packets Received on a Set of Interface Groups Overview
- Filtering Packets Received on an Interface Set Overview
- Example: Configuring Interface-Specific Firewall Filter Counters
- Example: Configuring a Stateless Firewall Filter on an Interface Group
- play_arrow Configuring Filter-Based Tunneling Across IP Networks
- Understanding Filter-Based Tunneling Across IPv4 Networks
- Firewall Filter-Based L2TP Tunneling in IPv4 Networks Overview
- Interfaces That Support Filter-Based Tunneling Across IPv4 Networks
- Components of Filter-Based Tunneling Across IPv4 Networks
- Example: Transporting IPv6 Traffic Across IPv4 Using Filter-Based Tunneling
- play_arrow Configuring Service Filters
- Service Filter Overview
- How Service Filters Evaluate Packets
- Guidelines for Configuring Service Filters
- Guidelines for Applying Service Filters
- Example: Configuring and Applying Service Filters
- Service Filter Match Conditions for IPv4 or IPv6 Traffic
- Service Filter Nonterminating Actions
- Service Filter Terminating Actions
- play_arrow Configuring Simple Filters
- play_arrow Configuring Layer 2 Firewall Filters
- Understanding Firewall Filters Used to Control Traffic Within Bridge Domains and VPLS Instances
- Example: Configuring Filtering of Frames by MAC Address
- Example: Configuring Filtering of Frames by IEEE 802.1p Bits
- Example: Configuring Filtering of Frames by Packet Loss Priority
- Example: Configuring Policing and Marking of Traffic Entering a VPLS Core
- Understanding Firewall Filters on OVSDB-Managed Interfaces
- Example: Applying a Firewall Filter to OVSDB-Managed Interfaces
- play_arrow Configuring Firewall Filters for Forwarding, Fragments, and Policing
- Filter-Based Forwarding Overview
- Firewall Filters That Handle Fragmented Packets Overview
- Stateless Firewall Filters That Reference Policers Overview
- Example: Configuring Filter-Based Forwarding on the Source Address
- Example: Configuring Filter-Based Forwarding to a Specific Outgoing Interface or Destination IP Address
- play_arrow Configuring Firewall Filters (EX Series Switches)
- Firewall Filters for EX Series Switches Overview
- Understanding Planning of Firewall Filters
- Understanding Firewall Filter Match Conditions
- Understanding How Firewall Filters Control Packet Flows
- Understanding How Firewall Filters Are Evaluated
- Understanding Firewall Filter Processing Points for Bridged and Routed Packets on EX Series Switches
- Firewall Filter Match Conditions, Actions, and Action Modifiers for EX Series Switches
- Platform Support for Firewall Filter Match Conditions, Actions, and Action Modifiers on EX Series Switches
- Support for Match Conditions and Actions for Loopback Firewall Filters on Switches
- Configuring Firewall Filters (CLI Procedure)
- Understanding How Firewall Filters Test a Packet's Protocol
- Understanding Filter-Based Forwarding for EX Series Switches
- Example: Configuring Firewall Filters for Port, VLAN, and Router Traffic on EX Series Switches
- Example: Configuring a Firewall Filter on a Management Interface on an EX Series Switch
- Example: Using Filter-Based Forwarding to Route Application Traffic to a Security Device
- Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for 802.1X or MAC RADIUS Authentication
- Verifying That Policers Are Operational
- Troubleshooting Firewall Filters
- play_arrow Configuring Firewall Filters (QFX Series Switches, EX4600 Switches, PTX Series Routers)
- Overview of Firewall Filters (QFX Series)
- Understanding Firewall Filter Planning
- Planning the Number of Firewall Filters to Create
- Firewall Filter Match Conditions and Actions (QFX and EX Series Switches)
- Firewall Filter Match Conditions and Actions (QFX10000 Switches)
- Firewall Filter Match Conditions and Actions (PTX Series Routers)
- Firewall and Policing Differences Between PTX Series Packet Transport Routers and T Series Matrix Routers
- Configuring Firewall Filters
- Applying Firewall Filters to Interfaces
- Overview of MPLS Firewall Filters on Loopback Interface
- Configuring MPLS Firewall Filters and Policers on Switches
- Configuring MPLS Firewall Filters and Policers on Routers
- Configuring MPLS Firewall Filters and Policers
- Understanding How a Firewall Filter Tests a Protocol
- Understanding Firewall Filter Processing Points for Bridged and Routed Packets
- Understanding Filter-Based Forwarding
- Example: Using Filter-Based Forwarding to Route Application Traffic to a Security Device
- Configuring a Firewall Filter to De-Encapsulate GRE or IPIP Traffic
- Verifying That Firewall Filters Are Operational
- Monitoring Firewall Filter Traffic
- Troubleshooting Firewall Filter Configuration
- play_arrow Configuring Firewall Filter Accounting and Logging (EX9200 Switches)
-
- play_arrow Configuring Traffic Policers
- play_arrow Understanding Traffic Policers
- Policer Implementation Overview
- ARP Policer Overview
- Example: Configuring ARP Policer
- Understanding the Benefits of Policers and Token Bucket Algorithms
- Determining Proper Burst Size for Traffic Policers
- Controlling Network Access Using Traffic Policing Overview
- Traffic Policer Types
- Order of Policer and Firewall Filter Operations
- Understanding the Frame Length for Policing Packets
- Supported Standards for Policing
- Hierarchical Policer Configuration Overview
- Understanding Enhanced Hierarchical Policers
- Packets-Per-Second (pps)-Based Policer Overview
- Guidelines for Applying Traffic Policers
- Policer Support for Aggregated Ethernet Interfaces Overview
- Example: Configuring a Physical Interface Policer for Aggregate Traffic at a Physical Interface
- Firewall and Policing Differences Between PTX Series Packet Transport Routers and T Series Matrix Routers
- Hierarchical Policers on ACX Series Routers Overview
- Guidelines for Configuring Hierarchical Policers on ACX Series Routers
- Hierarchical Policer Modes on ACX Series Routers
- Processing of Hierarchical Policers on ACX Series Routers
- Actions Performed for Hierarchical Policers on ACX Series Routers
- Configuring Aggregate Parent and Child Policers on ACX Series Routers
- play_arrow Configuring Policer Rate Limits and Actions
- play_arrow Configuring Layer 2 Policers
- Hierarchical Policers
- Configuring a Policer Overhead
- Two-Color and Three-Color Policers at Layer 2
- Layer 2 Traffic Policing at the Pseudowire Overview
- Configuring a Two-Color Layer 2 Policer for the Pseudowire
- Configuring a Three-Color Layer 2 Policer for the Pseudowire
- Applying the Policers to Dynamic Profile Interfaces
- Attaching Dynamic Profiles to Routing Instances
- Using Variables for Layer 2 Traffic Policing at the Pseudowire Overview
- Configuring a Policer for the Complex Configuration
- Creating a Dynamic Profile for the Complex Configuration
- Attaching Dynamic Profiles to Routing Instances for the Complex Configuration
- Verifying Layer 2 Traffic Policers on VPLS Connections
- Understanding Policers on OVSDB-Managed Interfaces
- Example: Applying a Policer to OVSDB-Managed Interfaces
- play_arrow Configuring Two-Color and Three-Color Traffic Policers at Layer 3
- Two-Color Policer Configuration Overview
- Basic Single-Rate Two-Color Policers
- Bandwidth Policers
- Prefix-Specific Counting and Policing Actions
- Policer Overhead to Account for Rate Shaping in the Traffic Manager
- Three-Color Policer Configuration Overview
- Applying Policers
- Three-Color Policer Configuration Guidelines
- Basic Single-Rate Three-Color Policers
- Basic Two-Rate Three-Color Policers
- Example: Configuring a Two-Rate Three-Color Policer
- play_arrow Configuring Logical and Physical Interface Traffic Policers at Layer 3
- play_arrow Configuring Policers on Switches
- Overview of Policers
- Traffic Policer Types
- Understanding the Use of Policers in Firewall Filters
- Understanding Tricolor Marking Architecture
- Configuring Policers to Control Traffic Rates (CLI Procedure)
- Configuring Tricolor Marking Policers
- Understanding Policers with Link Aggregation Groups
- Understanding Color-Blind Mode for Single-Rate Tricolor Marking
- Understanding Color-Aware Mode for Single-Rate Tricolor Marking
- Understanding Color-Blind Mode for Two-Rate Tricolor Marking
- Understanding Color-Aware Mode for Two-Rate Tricolor Marking
- Example: Using Two-Color Policers and Prefix Lists
- Example: Using Policers to Manage Oversubscription
- Assigning Forwarding Classes and Loss Priority
- Configuring Color-Blind Egress Policers for Medium-Low PLP
- Configuring Two-Color and Three-Color Policers to Control Traffic Rates
- Verifying That Two-Color Policers Are Operational
- Verifying That Three-Color Policers Are Operational
- Troubleshooting Policer Configuration
- Troubleshooting Policer Configuration
-
- play_arrow Configuration Statements and Operational Commands
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
ON THIS PAGE
Example: Forwarding Packets to the Discard Interface
This example shows how to use discard routing to mitigate denial of service (DoS) attacks, protect vital network resources from outside attack, provide protection services for customers so that each customer can initiate its own protection, and log and track DoS attempts.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
In discard routing, routers are configured with rules that disallow millions of requests in a short period of time from being sent to the same address. If too many requests are received in a short period of time, the router simply discards the requests without forwarding them. The requests are sent to a router that does not forward the packets. The problematic routes are sometimes referred to as discard routes or black-holed routes. The types of routes that should be discarded are identified as attacks to customers from peers or other customers, attacks from customers to peers or other customers, attack controllers, which are hosts providing attack instructions, and unallocated address spaces, known as bogons or invalid IP addresses.
After the attack attempt is identified, operators can put a configuration in place to
mitigate the attack. One way to configure discard routing in Junos OS is to create a discard
static route for each next hop used for discard routes. A discard static route uses the discard option.
For example:
user@host# show routing-options
static {
route 192.0.2.101/32 discard;
route 192.0.2.103/32 discard;
route 192.0.2.105/32 discard;
}
user@host> show route protocol static terse inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A V Destination P Prf Metric 1 Metric 2 Next hop AS path * ? 192.0.2.101/32 S 5 Discard * ? 192.0.2.103/32 S 5 Discard * ? 192.0.2.105/32 S 5 Discard
Another strategy, which is the main focus of this example, is to use routing policy and the discard interface. In this approach, the discard interface contains the next hop you are assigning to the null route routes. A discard interface can have only one logical unit (unit 0), but you can configure multiple IP addresses on unit 0.
For example:
user@host# show interfaces dsc
unit 0 {
family inet {
address 192.0.2.102/32 {
destination 192.0.2.101;
}
address 192.0.2.104/32 {
destination 192.0.2.103;
}
address 192.0.2.106/32 {
destination 192.0.2.105;
}
}
}
user@host> show interfaces terse dsc
b
Interface Admin Link Proto Local Remote
dsc up up
dsc.0 up up inet 192.0.2.102 --> 192.0.2.101
192.0.2.104 --> 192.0.2.103
192.0.2.106 --> 192.0.2.105The advantage of using a discard interface instead of using discard static routes is that the discard interface allows you to configure and assign filters to the interface for counting, logging, and sampling the traffic. This is demonstrated in this example.
To actually discard packets requires a routing policy attached to the BGP sessions. To locate discard-eligible routes, you can use a route filter, an access list, or a BGP community value.
For example, here is how you would use a route filter:
Route Filter
protocols {
bgp {
import blackhole-by-route;
}
}
policy-options {
policy-statement blackhole-by-route {
term specific-routes {
from {
route-filter 10.10.10.1/32 exact;
route-filter 10.20.20.2/32 exact;
route-filter 10.30.30.3/32 exact;
route-filter 10.40.40.4/32 exact;
}
then {
next-hop 192.0.2.101
}
}
}
}
Figure 1 shows the sample network.
The example includes three routers with external BGP (EBGP) sessions established.
Device R1 represents the attacking device. Device R3 represents the router closest to the device that is being attacked. Device R2 mitigates the attack by forwarding packets to the discard interface.
The example shows an outbound filter applied to the discard interface.
An issue with using a single null route filter is visibility. All discard packets increment the same counter. To see which categories of packets are being discarded, use destination class usage (DCU), and associate a user-defined class with each null route community. Then reference the DCU classes in a firewall filter. For related examples, see Example: Grouping Source and Destination Prefixes into a Forwarding Class and Example: Configuring a Rate-Limiting Filter Based on Destination Class.
Compared to using route filters and access lists, using a community value is the least administratively difficult and the most scalable approach. Therefore, this is the approach shown in this example.
By default, the next hop must be equal the external BGP (EBGP) peer address. Altering the next hop for null route services requires the multihop feature to be configured on the EBGP sessions.
CLI Quick Configuration shows the configuration for all of the devices in Figure 1.
The section #configuration756__policy-discard-st describes the steps on Device R2.
Configuration
Procedure
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 R1
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.2 set routing-options autonomous-system 100
Device R2
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 family inet address 10.1.0.1/30 set interfaces dsc unit 0 family inet filter output log-discard set interfaces dsc unit 0 family inet address 192.0.2.102/32 destination 192.0.2.101 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp import blackhole-policy set protocols bgp group ext type external set protocols bgp group ext multihop set protocols bgp group ext export dsc-export set protocols bgp group ext neighbor 10.0.0.1 peer-as 100 set protocols bgp group ext neighbor 10.1.0.2 peer-as 300 set policy-options policy-statement blackhole-policy term blackhole-communities from community blackhole-all-routers set policy-options policy-statement blackhole-policy term blackhole-communities then next-hop 192.0.2.101 set policy-options policy-statement dsc-export from route-filter 192.0.2.101/32 exact set policy-options policy-statement dsc-export from route-filter 192.0.2.102/32 exact set policy-options policy-statement dsc-export then community set blackhole-all-routers set policy-options policy-statement dsc-export then accept set policy-options community blackhole-all-routers members 100:5555 set routing-options static route 192.0.2.102/32 next-hop 192.0.2.101 set routing-options autonomous-system 200 set firewall filter log-discard term one then count counter set firewall filter log-discard term one then log
Device R3
set interfaces fe-1/2/1 unit 0 family inet address 10.1.0.2/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set interfaces lo0 unit 0 family inet address 192.0.2.102/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.1.0.1 set routing-options autonomous-system 300
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Use the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device R2:
Create the router interfaces.
content_copy zoom_out_map[edit interfaces] user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R2# set fe-1/2/1 unit 0 family inet address 10.1.0.1/30 user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
Configure a firewall filter that matches all packets and counts and logs the packets.
content_copy zoom_out_map[edit firewall filter log-discard term one] user@R2# set then count counter user@R2# set then log
Create a discard interface and apply the output firewall filter.
Input firewall filters have no impact in this context.
content_copy zoom_out_map[edit interfaces dsc unit 0 family inet] user@R2# set filter output log-discard user@R2# set address 192.0.2.102/32 destination 192.0.2.101
Configure a static route that sends the next hop to the destination address that is specified in the discard interface.
content_copy zoom_out_map[edit routing-options static] user@R2# set route 192.0.2.102/32 next-hop 192.0.2.101
Configure BGP peering.
content_copy zoom_out_map[edit protocols bgp ] user@R2# set group ext type external user@R2# set group ext multihop user@R2# set group ext neighbor 10.0.0.1 peer-as 100 user@R2# set group ext neighbor 10.1.0.2 peer-as 300
Configure the routing policies.
content_copy zoom_out_map[edit policy-options policy-statement blackhole-policy term blackhole-communities] user@R2# set from community blackhole-all-routers user@R2# set then next-hop 192.0.2.101 [edit policy-options policy-statement dsc-export] user@R2# set from route-filter 192.0.2.101/32 exact user@R2# set from route-filter 192.0.2.102/32 exact user@R2# set then community set blackhole-all-routers user@R2# set then accept [edit policy-options community blackhole-all-routers] user@R2# set members 100:5555
Apply the routing policies.
content_copy zoom_out_map[edit protocols bgp ] user@R2# set import blackhole-policy user@R2# set group ext export dsc-export
Configure the autonomous system (AS) number.
content_copy zoom_out_map[edit routing-options] user@R2# set autonomous-system 200
Results
From configuration mode, confirm your configuration by issuing the show
interfaces, show protocols , show policy-options, show routing-options, and show firewall commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
[edit]
user@R2# show interfaces
fe-1/2/0 {
unit 0 {
family inet {
address 10.0.0.2/30;
}
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 10.1.0.1/30;
}
}
}
dsc {
unit 0 {
family inet {
filter {
output log-discard;
}
address 192.0.2.102/32 {
destination 192.0.2.101;
}
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
import blackhole-policy;
group ext {
type external;
multihop;
export dsc-export;
neighbor 10.0.0.1 {
peer-as 100;
}
neighbor 10.1.0.2 {
peer-as 300;
}
}
}
user@R2# show policy-options
policy-statement blackhole-policy {
term blackhole-communities {
from community blackhole-all-routers;
then {
next-hop 192.0.2.101;
}
}
}
policy-statement dsc-export {
from {
route-filter 192.0.2.101/32 exact;
route-filter 192.0.2.102/32 exact;
}
then {
community set blackhole-all-routers;
accept;
}
}
community blackhole-all-routers members 100:5555;
user@R2# show routing-options
static {
route 192.0.2.102/32 next-hop 192.0.2.101;
}
autonomous-system 200;
user@R2# show firewall
filter log-discard {
term one {
then {
count counter;
log;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Clearing the Firewall Counters
- Pinging the 192.0.2.101 Address
- Checking the Output Filter
- Checking the Community Attribute
Clearing the Firewall Counters
Purpose
Clear the counters to make sure you are starting from a known zero (0) state.
Action
From Device R2, run the
clear firewallcommand.content_copy zoom_out_mapuser@R2> clear firewall filter log-discard
From Device R2, run the
show firewallcommand.content_copy zoom_out_mapuser@R2> show firewall filter log-discard Filter: /log-discard Counters: Name Bytes Packets counter 0 0
Pinging the 192.0.2.101 Address
Purpose
Send packets to the destination address.
Action
From Device R1, run the ping command.
user@R1> ping 192.0.2.101 PING 192.0.2.101 (192.0.2.101): 56 data bytes ^C --- 192.0.2.101 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss
Meaning
As expected, the ping request fails, and no response is sent. The packets are being discarded.
Checking the Output Filter
Purpose
Verify that Device R2’s firewall filter is functioning properly.
Action
From Device R2, enter the show firewall filter log-discard command.
user@R2> show firewall filter log-discard Filter: log-discard Counters: Name Bytes Packets counter 336 4
Meaning
As expected, the counter is being incremented.
The ping packet carries an additional 20 bytes of IP overhead as well as 8 bytes of ICMP header.
Checking the Community Attribute
Purpose
Verify that the route is being tagged with the community attribute.
Action
From Device R1, enter the show route extensive command, using the
neighbor address for Device R2, 192.0.2.101.
user@R1> show route 192.0.2.101 extensive
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
192.0.2.101/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 192.0.2.101/32 -> {10.0.0.2}
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 684
Address: 0x94141d8
Next-hop reference count: 2
Source: 10.0.0.2
Next hop: 10.0.0.2 via fe-1/2/0.0, selected
Session Id: 0x8000a
State: <Active Ext>
Local AS: 100 Peer AS: 200
Age: 53:03
Validation State: unverified
Task: BGP_200.10.0.0.2+63097
Announcement bits (1): 2-KRT
AS path: 200 I
Communities: 100:5555
Accepted
Localpref: 100
Router ID: 192.168.0.2
Meaning
As expected, when Device R2 advertises the 192.0.2.101 route to Device R1, Device R2 adds the 100:5555 community tag.
