- 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: Configuring Policy Chains and Route Filters
A policy chain is the application of multiple policies within a specific section of the configuration. A route filter is a collection of match prefixes.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
An example of a policy chain applied to BGP is as follows:
user@R1# show protocols bgp group int { type internal; local-address 192.168.0.1; export [ adv-statics adv-large-aggregates adv-small-aggregates ]; neighbor 192.168.0.2; neighbor 192.168.0.3; }
The adv-statics
, adv-large-aggregates
,
and adv-small-aggregates
policies, in addition to the default
BGP policy, make up the policy chain applied to the BGP peers of Device
R1. Two of the policies demonstrate route filters with different match
types. The other policy matches all static routes, so no route filter
is needed.
user@R1# show policy-options policy-statement adv-large-aggregates { term between-16-and-18 { from { protocol aggregate; route-filter 172.16.0.0/16 upto /18; } then accept; } } policy-statement adv-small-aggregates { term between-19-and-24 { from { protocol aggregate; route-filter 172.16.0.0/16 prefix-length-range /19-/24; } then accept; } } policy-statement adv-statics { term statics { from protocol static; then accept; } }
Optionally, you can convert this policy chain into a single multiterm policy for the internal BGP (IBGP) peers. If you do this, one of the advantages of a policy chain is lost—the ability to reuse policies for different purposes.
Figure 1 displays Device R1
in AS 64510 with its IBGP peers, Device R2 and Device R3. Device R1
also has external BGP (EBGP) connections to Device R4 in AS 64511
and Device R5 in AS 64512. The current administrative policy within
AS 64510 is to send the customer static routes only to other IBGP
peers. Any EBGP peer providing transit service only receives aggregate
routes with mask lengths smaller than 18 bits. Any EBGP peer providing
peering services receives all customer routes and all aggregates whose
mask length is larger than 19 bits. Each portion of these administrative
policies is configured in a separate routing policy within the [edit policy-opitons]
configuration hierarchy. These policies
provide the administrators of AS 64510 with multiple configuration
options for advertising routes to peers.
Device R4 is providing transit service to AS 64510, which allows the AS to advertise its assigned routing space to the Internet. On the other hand, the peering service provided by Device R5 allows AS 64510 to route traffic directly between the autonomous systems (ASs) for all customer routes.
Topology
Figure 1 shows the sample network.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.
The section Procedure describes the steps on Device R1.
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 R1
set interfaces fe-1/2/0 unit 0 description to_R2 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces fe-1/2/2 unit 0 description to_R3 set interfaces fe-1/2/2 unit 0 family inet address 10.0.0.5/30 set interfaces fe-1/2/3 unit 0 description to_R4 set interfaces fe-1/2/3 unit 0 family inet address 10.1.0.5/30 set interfaces fe-1/2/1 unit 0 description to_R5 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.10/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.1 set protocols bgp group int export adv-statics set protocols bgp group int export adv-large-aggregates set protocols bgp group int export adv-small-aggregates set protocols bgp group int neighbor 192.168.0.2 set protocols bgp group int neighbor 192.168.0.3 set protocols bgp group to_64511 type external set protocols bgp group to_64511 export adv-large-aggregates set protocols bgp group to_64511 neighbor 10.1.0.6 peer-as 64511 set protocols bgp group to_64512 type external set protocols bgp group to_64512 export adv-small-aggregates set protocols bgp group to_64512 export adv-statics set protocols bgp group to_64512 neighbor 10.0.0.9 peer-as 64512 set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement adv-large-aggregates term between-16-and-18 from protocol aggregate set policy-options policy-statement adv-large-aggregates term between-16-and-18 from route-filter 172.16.0.0/16 upto /18 set policy-options policy-statement adv-large-aggregates term between-16-and-18 then accept set policy-options policy-statement adv-small-aggregates term between-19-and-24 from protocol aggregate set policy-options policy-statement adv-small-aggregates term between-19-and-24 from route-filter 172.16.0.0/16 prefix-length-range /19-/24 set policy-options policy-statement adv-small-aggregates term between-19-and-24 then accept set policy-options policy-statement adv-statics term statics from protocol static set policy-options policy-statement adv-statics term statics then accept set routing-options static route 172.16.1.16/28 discard set routing-options static route 172.16.1.32/28 discard set routing-options static route 172.16.1.48/28 discard set routing-options static route 172.16.1.64/28 discard set routing-options aggregate route 172.16.0.0/16 set routing-options aggregate route 172.16.1.0/24 set routing-options router-id 192.168.0.1 set routing-options autonomous-system 64510
Device R2
set interfaces fe-1/2/0 unit 0 description to_R1 set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 description to_R3 set interfaces fe-1/2/1 unit 0 family inet address 10.1.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.2 set protocols bgp group int neighbor 192.168.0.1 export send-static-aggregate set protocols bgp group int neighbor 192.168.0.3 set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static-aggregate term 1 from protocol static set policy-options policy-statement send-static-aggregate term 1 from protocol aggregate set policy-options policy-statement send-static-aggregate term 1 then accept set routing-options static route 172.16.2.16/28 discard set routing-options static route 172.16.2.32/28 discard set routing-options static route 172.16.2.48/28 discard set routing-options static route 172.16.2.64/28 discard set routing-options aggregate route 172.16.2.0/24 set routing-options aggregate route 172.16.0.0/16 set routing-options router-id 192.168.0.2 set routing-options autonomous-system 64510
Device R3
set interfaces fe-1/2/1 unit 0 description to_R2 set interfaces fe-1/2/1 unit 0 family inet address 10.1.0.2/30 set interfaces fe-1/2/2 unit 0 description to_R1 set interfaces fe-1/2/2 unit 0 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group int type internal set protocols bgp group int local-address 192.168.0.3 set protocols bgp group int neighbor 192.168.0.1 export send-static-aggregate set protocols bgp group int neighbor 192.168.0.2 set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-static-aggregate from protocol static set policy-options policy-statement send-static-aggregate from protocol aggregate set policy-options policy-statement send-static-aggregate then accept set routing-options static route 172.16.3.16/28 discard set routing-options static route 172.16.3.32/28 discard set routing-options static route 172.16.3.48/28 discard set routing-options static route 172.16.3.64/28 discard set routing-options aggregate route 172.16.0.0/16 set routing-options aggregate route 172.16.3.0/24 set routing-options router-id 192.168.0.3 set routing-options autonomous-system 64510
Device R4
set interfaces fe-1/2/3 unit 0 description to_R1 set interfaces fe-1/2/3 unit 0 family inet address 10.1.0.6/30 set interfaces lo0 unit 0 family inet address 192.168.0.4/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 64510 set protocols bgp group ext neighbor 10.1.0.5 set routing-options autonomous-system 64511
Device R5
set interfaces fe-1/2/1 unit 0 description to_R1 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.9/30 set interfaces lo0 unit 0 family inet address 192.168.0.5/32 set protocols bgp group ext type external set protocols bgp group ext neighbor 10.0.0.10 peer-as 64510 set routing-options autonomous-system 64512
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Use the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device R1:
Configure the device interfaces.
content_copy zoom_out_map[edit interfaces] user@R1# set fe-1/2/0 unit 0 description to_R2 user@R1# set fe-1/2/0 unit 0 family inet address 10.0.0.1/30 user@R1# set fe-1/2/2 unit 0 description to_R3 user@R1# set fe-1/2/2 unit 0 family inet address 10.0.0.5/30 user@R1# set fe-1/2/3 unit 0 description to_R4 user@R1# set fe-1/2/3 unit 0 family inet address 10.1.0.5/30 user@R1# set fe-1/2/1 unit 0 description to_R5 user@R1# set fe-1/2/1 unit 0 family inet address 10.0.0.10/30 user@R1# set lo0 unit 0 family inet address 192.168.0.1/32
Configure the IBGP connections to Device R2 and Device R3.
content_copy zoom_out_map[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 192.168.0.1 user@R1# set neighbor 192.168.0.2 user@R1# set neighbor 192.168.0.3
Apply the export policies for the internal peers.
content_copy zoom_out_map[edit protocols bgp group int] user@R1# set export adv-statics user@R1# set export adv-large-aggregates user@R1# set export adv-small-aggregates
Configure the EBGP connection to Device R4.
content_copy zoom_out_map[edit protocols bgp group to_64511] user@R1# set type external user@R1# set neighbor 10.1.0.6 peer-as 64511
Apply the export policy for Device R4.
content_copy zoom_out_map[edit protocols bgp group to_64511] user@R1# set export adv-large-aggregates
Configure the EBGP connection to Device R5.
content_copy zoom_out_map[edit protocols bgp group to_64512] user@R1# set type external user@R1# set neighbor 10.0.0.9 peer-as 64512
Apply the export policies for Device R5.
content_copy zoom_out_map[edit protocols bgp group to_64512] user@R1# set export adv-small-aggregates user@R1# set export adv-statics
Configure OSPF connections to Device R2 and Device R3.
content_copy zoom_out_map[edit protocols ospf area 0.0.0.0] user@R1# set interface fe-1/2/0.0 user@R1# set interface fe-1/2/2.0 user@R1# set interface lo0.0 passive
Configure the routing policies.
content_copy zoom_out_map[edit policy-options policy-statement adv-large-aggregates term between-16-and-18] user@R1# set from protocol aggregate user@R1# set from route-filter 172.16.0.0/16 upto /18 user@R1# set then accept [edit policy-options policy-statement adv-small-aggregates term between-19-and-24] user@R1# set from protocol aggregate user@R1# set from route-filter 172.16.0.0/16 prefix-length-range /19-/24 user@R1# set then accept [edit policy-options policy-statement adv-statics term statics] user@R1# set from protocol static user@R1# set then accept
Configure the static and aggregate routes.
content_copy zoom_out_map[edit routing-options static] user@R1# set route 172.16.1.16/28 discard user@R1# set route 172.16.1.32/28 discard user@R1# set route 172.16.1.48/28 discard user@R1# set route 172.16.1.64/28 discard [edit routing-options aggregate] user@R1# set route 172.16.0.0/16 user@R1# set route 172.16.1.0/24
Configure the autonomous system (AS) number and router ID.
content_copy zoom_out_map[edit routing-options] user@R1# set router-id 192.168.0.1 user@R1# set autonomous-system 64510
Results
From configuration mode, confirm your configuration
by entering the show interfaces
, show protocols
, show policy-options
, and show routing-options
commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@R1# show interfaces fe-1/2/0 { unit 0 { description to_R2; family inet { address 10.0.0.1/30; } } } fe-1/2/2 { unit 0 { description to_R3; family inet { address 10.0.0.5/30; } } } fe-1/2/3 { unit 0 { description to_R4; family inet { address 10.1.0.5/30; } } } fe-1/2/1 { unit 0 { description to_R5; family inet { address 10.0.0.10/30; } } } lo0 { unit 0 { family inet { address 192.168.0.1/32; } } }
user@R1# show protocols bgp { group int { type internal; local-address 192.168.0.1; export [ adv-statics adv-large-aggregates adv-small-aggregates ]; neighbor 192.168.0.2; neighbor 192.168.0.3; } group to_64511 { type external; export adv-large-aggregates; neighbor 10.1.0.6 { peer-as 64511; } } group to_64512 { type external; export [ adv-small-aggregates adv-statics ]; neighbor 10.0.0.9 { peer-as 64512; } } } ospf { area 0.0.0.0 { interface fe-1/2/0.0; interface fe-1/2/2.0; interface lo0.0 { passive; } } }
user@R1# show policy-options policy-statement adv-large-aggregates { term between-16-and-18 { from { protocol aggregate; route-filter 172.16.0.0/16 upto /18; } then accept; } } policy-statement adv-small-aggregates { term between-19-and-24 { from { protocol aggregate; route-filter 172.16.0.0/16 prefix-length-range /19-/24; } then accept; } } policy-statement adv-statics { term statics { from protocol static; then accept; } }
user@R1# show routing-options static { route 172.16.1.16/28 discard; route 172.16.1.32/28 discard; route 172.16.1.48/28 discard; route 172.16.1.64/28 discard; } aggregate { route 172.16.0.0/16; route 172.16.1.0/24; } router-id 192.168.0.1; autonomous-system 64510;
If you are done configuring the device, enter commit
from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying the Route Advertisement to Device R4
- Checking Where the Longer Routes Are Originating
- Blocking the More Specific Routes
- Verifying the Route Advertisement to Device R5
Verifying the Route Advertisement to Device R4
Purpose
On Device R1, make sure that the customer routes are advertised to Device R4.
Action
user@R1> show route advertising-protocol bgp 10.1.0.6 inet.0: 29 destinations, 31 routes (29 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.0.0/16 Self I * 172.16.2.0/24 Self I * 172.16.2.16/28 Self I * 172.16.2.32/28 Self I * 172.16.2.48/28 Self I * 172.16.2.64/28 Self I * 172.16.3.0/24 Self I * 172.16.3.16/28 Self I * 172.16.3.32/28 Self I * 172.16.3.48/28 Self I * 172.16.3.64/28 Self I
Meaning
The adv-large-aggregates
policy is applied
to the peering session with Device R4 to advertise the aggregate routes
with a subnet mask length between 16 and 18 bits. The 172.16.0.0/16
aggregate route is being sent as defined by the administrative policy,
but a number of other routes with larger subnet masks are also being
sent to Device R4.
Checking Where the Longer Routes Are Originating
Purpose
On Device R1, find where the other routes are coming from.
Action
user@R1> show route 172.16.3.16/28 inet.0: 29 destinations, 31 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.3.16/28 *[BGP/170] 20:16:00, localpref 100, from 192.168.0.3 AS path: I, validation-state: unverified > to 10.0.0.6 via fe-1/2/2.0
Meaning
Device R1 has learned this route through its BGP session with Device R3. Because it is an active BGP route, it is automatically advertised by the BGP default policy. Remember that the default policy is always applied to the end of every policy chain. What is needed is a policy to block the more specific routes from being advertised.
Blocking the More Specific Routes
Purpose
Create a policy called not-larger-than-18
that rejects all routes within the 172.16.0.0 /16 address space
that have a subnet mask length greater than or equal to 19 bits. This
ensures that all aggregates with a mask between 16 and 18 bits are
advertised, thus accomplishing the goal of the administrative policy.
Action
On Device R1, configure the
not-larger-than-18
policy.content_copy zoom_out_map[edit policy-options policy-statement not-larger-than-18 term reject-greater-than-18-bits] user@R1# set from route-filter 172.16.0.0/16 prefix-length-range /19-/32 user@R1# set then reject
On Device R1, apply the policy to the peering session with Device R4.
content_copy zoom_out_map[edit protocols bgp group to_64511] user@R1# set export not-larger-than-18 user@R1# commit
On Device R1, check which routes are advertised to Device R4.
content_copy zoom_out_mapuser@R1> show route advertising-protocol bgp 10.1.0.6 inet.0: 29 destinations, 31 routes (29 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.0.0/16 Self I
Meaning
The policy chain is working correctly. Only the 172.16.0.0 /16 route is advertised to Device R4.
Verifying the Route Advertisement to Device R5
Purpose
On Device R1, make sure that the customer routes are advertised to Device R5.
Device R5 is Device R1’s EBGP peer in AS 64512. The administrative
policy states that this peer receives only aggregate routes larger
than 18 bits in length and all customer routes. In anticipation of
encountering a problem similar to the problem on Device R4, you can
create a policy called not-smaller- than-18
that rejects
all aggregates with mask lengths between 16 and 18 bits.
Action
On Device R2, configure an aggregate route for 172.16.128.0/17.
content_copy zoom_out_map[edit routing-options aggregate] user@R2# set route 172.16.128.0/17 discard user@R2# commit
On Device R1, check which routes are advertised to Device R5.
content_copy zoom_out_mapuser@R1> show route advertising-protocol bgp 10.0.0.9 inet.0: 30 destinations, 32 routes (30 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/24 Self I * 172.16.1.16/28 Self I * 172.16.1.32/28 Self I * 172.16.1.48/28 Self I * 172.16.1.64/28 Self I * 172.16.2.0/24 Self I * 172.16.2.16/28 Self I * 172.16.2.32/28 Self I * 172.16.2.48/28 Self I * 172.16.2.64/28 Self I * 172.16.3.0/24 Self I * 172.16.3.16/28 Self I * 172.16.3.32/28 Self I * 172.16.3.48/28 Self I * 172.16.3.64/28 Self I * 172.16.128.0/17 Self I
The aggregate route 172.16.128.0/17 is advertised, in violation of the administrative policy
On Device R1, configure the
not-smaller-than-18
policy.content_copy zoom_out_map[edit policy-options policy-statement not-smaller-than-18 term reject-less-than-18-bits] user@R1# set from protocol aggregate user@R1# set from route-filter 172.16.0.0/16 upto /18 user@R1# set then reject
On Device R1, apply the policy to the peering session with Device R5.
content_copy zoom_out_map[edit protocols bgp group to_64512] user@R1# set export not-smaller-than-18 user@R1# commit
On Device R1, check which routes are advertised to Device R5.
content_copy zoom_out_mapuser@R1> show route advertising-protocol bgp 10.0.0.9 inet.0: 29 destinations, 31 routes (29 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/24 Self I * 172.16.1.16/28 Self I * 172.16.1.32/28 Self I * 172.16.1.48/28 Self I * 172.16.1.64/28 Self I * 172.16.2.0/24 Self I * 172.16.2.16/28 Self I * 172.16.2.32/28 Self I * 172.16.2.48/28 Self I * 172.16.2.64/28 Self I * 172.16.3.0/24 Self I * 172.16.3.16/28 Self I * 172.16.3.32/28 Self I * 172.16.3.48/28 Self I * 172.16.3.64/28 Self I
Meaning
The policy chain is working correctly. Only aggregate routes larger than 18 bits in length and all customer routes are advertised to Device R5.