Junos® OS
Roung Policies, Firewall Filters, and
Trac Policers User Guide
Published
2024-06-13
Juniper Networks, Inc.
1133 Innovaon Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. All other trademarks, service marks, registered marks, or registered service
marks are the property of their respecve owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publicaon without noce.
Junos® OS Roung Policies, Firewall Filters, and Trac Policers User Guide
Copyright © 2024 Juniper Networks, Inc. All rights reserved.
The informaon in this document is current as of the date on the tle page.
YEAR 2000 NOTICE
Juniper Networks hardware and soware products are Year 2000 compliant. Junos OS has no known me-related
limitaons through the year 2038. However, the NTP applicaon is known to have some diculty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentaon consists of (or is intended for use
with) Juniper Networks soware. Use of such soware is subject to the terms and condions of the End User License
Agreement ("EULA") posted at hps://support.juniper.net/support/eula/. By downloading, installing or using such
soware, you agree to the terms and condions of that EULA.
ii
Table of Contents
About This Guide | xxxvi
1
Understanding and Conguring Junos Roung Policies
Overview | 2
Policy Framework Overview | 2
Comparison of Roung Policies and Firewall Filters | 9
Prex Priorizaon Overview | 15
FIB Prex Priorizaon | 16
Accounng of the Policer Overhead Aribute at the Interface Level | 17
Conguring the Accounng of Policer Overhead in Interface Stascs | 19
Understanding Roung Policies | 22
Protocol Support for Import and Export Policies | 26
Example: Applying Roung Policies at Dierent Levels of the BGP Hierarchy | 27
Requirements | 27
Overview | 28
Conguraon | 30
Vericaon | 36
Default Roung Policies | 40
Example: Conguring a Condional Default Route Policy | 44
Requirements | 44
Overview | 44
Conguraon | 45
Vericaon | 50
Evaluang Roung Policies Using Match Condions, Acons, Terms, and Expressions | 54
How a Roung Policy Is Evaluated | 54
Categories of Roung Policy Match Condions | 56
Roung Policy Match Condions | 58
iii
Route Filter Match Condions | 72
Acons in Roung Policy Terms | 75
Summary of Roung Policy Acons | 93
Example: Conguring a Roung Policy to Adverse the Best External Route to Internal Peers | 96
Requirements | 98
Overview | 98
Conguraon | 100
Vericaon | 104
Example: Conguring BGP to Adverse Inacve Routes | 108
Requirements | 110
Overview | 110
Conguraon | 111
Vericaon | 115
Example: Using Roung Policy to Set a Preference Value for BGP Routes | 119
Requirements | 119
Overview | 119
Conguraon | 121
Vericaon | 126
Example: Enabling BGP Route Adversements | 127
Requirements | 128
Overview | 128
Conguraon | 129
Vericaon | 135
Example: Rejecng Known Invalid Routes | 138
Requirements | 139
Overview | 139
Conguraon | 139
Vericaon | 141
Example: Using Roung Policy in an ISP Network | 142
Requirements | 142
Overview | 142
Set Commands for All Devices in the Topology | 145
iv
Conguring Device Customer-1 | 153
Conguring Device Customer-2 | 156
Conguring Devices ISP-1 and ISP-2 | 160
Conguring Device ISP-3 | 167
Conguring Device Exchange-2 | 174
Conguring Device Private-Peer-2 | 177
Vericaon | 183
Understanding Policy Expressions | 205
Understanding Backup Selecon Policy for OSPF Protocol | 211
Conguring Backup Selecon Policy for the OSPF Protocol | 212
Conguring Backup Selecon Policy for IS-IS Protocol | 220
Understanding Backup Selecon Policy for IS-IS Protocol | 220
Example: Conguring Backup Selecon Policy for the OSPF or OSPF3 Protocol | 222
Requirements | 222
Overview | 223
Conguraon | 224
Vericaon | 249
Evaluang Complex Cases Using Policy Chains and Subrounes | 257
Understanding How a Roung Policy Chain Is Evaluated | 257
Example: Conguring Policy Chains and Route Filters | 259
Requirements | 259
Overview | 259
Conguraon | 262
Vericaon | 271
Example: Using Firewall Filter Chains | 276
Requirements | 276
Overview | 277
Conguraon | 278
Vericaon | 283
Understanding Policy Subrounes in Roung Policy Match Condions | 284
How a Roung Policy Subroune Is Evaluated | 288
v
Example: Conguring a Policy Subroune | 291
Requirements | 291
Overview | 291
Conguraon | 293
Vericaon | 300
Conguring Route Filters and Prex Lists as Match Condions | 305
Understanding Route Filters for Use in Roung Policy Match Condions | 305
Understanding Route Filter and Source Address Filter Lists for Use in Roung Policy Match
Condions | 329
Understanding Load Balancing Using Source or Desnaon IP Only | 329
Conguring Load Balancing Using Source or Desnaon IP Only | 330
Walkup for Route Filters Overview | 332
Conguring Walkup for Route Filters to Improve Operaonal Eciency | 336
Example: Conguring Route Filter Lists | 342
Requirements | 342
Overview | 342
Conguraon | 343
Vericaon | 345
Example: Conguring Walkup for Route Filters Globally to Improve Operaonal Eciency | 348
Requirements | 348
Overview | 349
Conguring Route Filter Walkup Globally | 350
Vericaon | 354
Troubleshoong | 355
Example: Conguring Walkup for Route Filters Locally to Improve Operaonal Eciency | 356
Requirements | 357
Overview | 357
Conguring Route Filter Walkup Locally | 358
Vericaon | 362
Troubleshoong | 363
Example: Conguring a Route Filter Policy to Specify Priority for Prexes Learned Through OSPF | 364
vi
Requirements | 364
Overview | 365
Conguraon | 366
Vericaon | 370
Example: Conguring the MED Using Route Filters | 370
Requirements | 371
Overview | 371
Conguraon | 372
Vericaon | 387
Example: Conguring Layer 3 VPN Protocol Family Qualiers for Route Filters | 390
Requirements | 390
Overview | 390
Conguraon | 391
Vericaon | 394
Understanding Prex Lists for Use in Roung Policy Match Condions | 394
Example: Conguring Roung Policy Prex Lists | 398
Requirements | 399
Overview | 399
Conguraon | 402
Vericaon | 410
Example: Conguring the Priority for Route Prexes in the RPD Infrastructure | 414
Requirements | 414
Overview | 415
Conguraon | 416
Vericaon | 423
Conguring Priority for Route Prexes in RPD Infrastructure | 428
Conguring AS Paths as Match Condions | 435
Understanding AS Path Regular Expressions for Use as Roung Policy Match Condions | 435
Example: Using AS Path Regular Expressions | 444
Requirements | 444
Overview | 445
Conguraon | 447
vii
Vericaon | 455
Understanding Prepending AS Numbers to BGP AS Paths | 459
Example: Conguring a Roung Policy for AS Path Prepending | 460
Requirements | 460
Overview | 460
Conguraon | 461
Vericaon | 466
Appendix Full Conguraons | 469
Understanding Adding AS Numbers to BGP AS Paths | 470
Example: Adversing Mulple Paths in BGP | 471
Requirements | 472
Overview | 472
Conguraon | 474
Vericaon | 501
Improve the Performance of AS Path Lookup in BGP Policy | 508
AS Path Lookup in a BGP Policy Without Regular Expression Overview | 509
Congure AS Path Lookup Without Using Regular Expression | 510
Conguring Communies as Match Condions | 513
Understanding BGP Communies, Extended Communies, and Large Communies as Roung
Policy Match Condions | 513
Understanding How to Dene BGP Communies and Extended Communies | 515
How BGP Communies and Extended Communies Are Evaluated in Roung Policy Match
Condions | 523
Example: Conguring Communies in a Roung Policy | 530
Requirements | 530
Overview | 531
Conguraon | 533
Vericaon | 545
Example: Conguring Extended Communies in a Roung Policy | 550
Requirements | 550
Overview | 550
viii
Conguraon | 552
Vericaon | 557
Example: Conguring BGP Large Communies | 562
Requirements | 562
Overview | 562
Conguraon | 563
Vericaon | 569
Example: Conguring a Roung Policy Based on the Number of BGP Communies | 574
Requirements | 574
Overview | 574
Conguraon | 575
Vericaon | 582
Example: Conguring a Roung Policy That Removes BGP Communies | 585
Requirements | 585
Overview | 585
Conguraon | 587
Vericaon | 594
Increasing Network Stability with BGP Route Flapping Acons | 598
Understanding Damping Parameters | 598
Using Roung Policies to Damp BGP Route Flapping | 600
Example: Conguring BGP Route Flap Damping Parameters | 606
Requirements | 607
Overview | 607
Conguraon | 608
Vericaon | 614
Example: Conguring BGP Route Flap Damping Based on the MBGP MVPN Address Family | 621
Requirements | 621
Overview | 621
Conguraon | 622
Vericaon | 634
Tracking Trac Usage with Source Class Usage and Desnaon Class Usage Acons | 637
Understanding Source Class Usage and Desnaon Class Usage Opons | 637
ix
Source Class Usage Overview | 639
Guidelines for Conguring SCU | 640
System Requirements for SCU | 641
Terms and Acronyms for SCU | 642
desnaon class usage (DCU) | 642
source class usage (SCU) | 643
source address (SA) | 643
desnaon address (DA) | 643
Roadmap for Conguring SCU | 643
Roadmap for Conguring SCU with Layer 3 VPNs | 644
Conguring Route Filters and Source Classes in a Roung Policy | 644
Applying the Policy to the Forwarding Table | 646
Enabling Accounng on Inbound and Outbound Interfaces | 646
Conguring Input SCU on the vt Interface of the Egress PE Router | 647
Mapping the SCU-Enabled vt Interface to the VRF Instance | 648
Conguring SCU on the Output Interface | 649
Associang an Accounng Prole with SCU Classes | 650
Verifying Your SCU Accounng Prole | 651
SCU Conguraon | 652
SCU with Layer 3 VPNs Conguraon | 663
Example: Grouping Source and Desnaon Prexes into a Forwarding Class | 673
Requirements | 674
Overview | 674
Conguraon | 677
Vericaon | 684
Avoiding Trac Roung Threats with Condional Roung Policies | 688
Condional Adversement and Import Policy (Roung Table) with certain match condions | 688
Condional Adversement Enabling Condional Installaon of Prexes Use Cases | 691
x
Example: Conguring a Roung Policy for Condional Adversement Enabling Condional
Installaon of Prexes in a Roung Table | 693
Requirements | 693
Overview | 693
Conguraon | 697
Vericaon | 707
Protecng Against DoS Aacks by Forwarding Trac to the Discard Interface | 716
Assigning Forwarding Classes and Loss Priority | 716
Understanding Forwarding Packets to the Discard Interface | 718
Example: Forwarding Packets to the Discard Interface | 720
Requirements | 720
Overview | 720
Conguraon | 724
Vericaon | 729
Improving Commit Times with Dynamic Roung Policies | 734
Understanding Dynamic Roung Policies | 734
Example: Conguring Dynamic Roung Policies | 739
Requirements | 739
Overview | 739
Conguraon | 741
Vericaon | 752
Tesng Before Applying Roung Policies | 760
Understanding Roung Policy Tests | 760
Example: Tesng a Roung Policy with Complex Regular Expressions | 762
Requirements | 762
Overview | 762
Conguraon | 765
Vericaon | 771
2
Conguring
Firewall Filters
Understanding How Firewall Filters Protect Your Network | 774
Firewall Filters Overview | 774
xi
Router Data Flow Overview | 775
Stateless Firewall Filter Overview | 778
Understanding How to Use Standard Firewall Filters | 780
Understanding How Firewall Filters Control Packet Flows | 781
Stateless Firewall Filter Components | 783
Stateless Firewall Filter Applicaon Points | 790
How Standard Firewall Filters Evaluate Packets | 795
Understanding Firewall Filter Fast Lookup Filter | 800
Understanding Egress Firewall Filters with PVLANs | 801
Selecve Class-based Filtering on PTX Routers | 802
Selecve Class-based Filtering on PTX Routers | 802
Understanding Class-based Filtering on PTX Routers | 804
Example: Selecve Class Based Filtering (PTX Routers) | 805
Guidelines for Conguring Firewall Filters | 816
Guidelines for Applying Standard Firewall Filters | 823
Supported Standards for Filtering | 828
Monitoring Firewall Filter Trac | 829
Monitoring Trac for All Firewall Filters and Policers That Are Congured | 829
Monitoring Trac for a Specic Firewall Filter | 830
Monitoring Trac for a Specic Policer | 831
Troubleshoong Firewall Filters | 832
Troubleshoong QFX10000 Switches | 833
Do Not Combine Match Condions for Dierent Layers | 833
Layer 2 Packets Cannot be Discarded with Firewall Filters | 833
Protect-RE (loopback) Firewall Filter Does Not Filter Packets Applied to EM0 Interfaces | 834
Troubleshoong Other Switches | 834
Firewall Filter Conguraon Returns a No Space Available in TCAM Message | 835
Filter Counts Previously Dropped Packet | 838
Matching Packets Not Counted | 839
Counter Reset When Eding Filter | 840
xii
Cannot Include loss-priority and policer Acons in Same Term | 840
Cannot Egress Filter Certain Trac Originang on QFX Switch | 841
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling | 842
Egress Firewall Filters with Private VLANs | 842
Egress Filtering of L2PT Trac Not Supported | 844
Cannot Drop BGP Packets in Certain Circumstances | 844
Invalid Stascs for Policer | 845
Policers can Limit Egress Filters | 845
Firewall Filter Match Condions and Acons | 847
Overview of Firewall Filters (OCX Series) | 848
Understanding Firewall Filter Match Condions | 850
Understanding Firewall Filter Planning | 855
Understanding How Firewall Filters Are Evaluated | 856
Understanding Firewall Filter Match Condions | 858
Firewall Filter Flexible Match Condions | 864
Firewall Filter Nonterminang Acons | 873
Firewall Filter Terminang Acons | 886
Firewall Filter Match Condions and Acons (ACX Series Routers) | 911
Overview of Firewall Filter Match Condions and Acons on ACX Series Routers | 912
Match Condions for Bridge Family Firewall Filters (ACX Series Routers) | 914
Match Condions for CCC Firewall Family Filters (ACX Series Routers) | 918
Match Condions for IPv4 Trac (ACX Series Routers) | 919
Match Condions for IPv6 Trac (ACX Series Routers) | 925
Match Condions for MPLS Trac (ACX Series Routers) | 932
Nonterminang Acons (ACX Series Routers) | 933
Terminang Acons (ACX Series Routers) | 937
Firewall Filter Match Condions for Protocol-Independent Trac | 939
Firewall Filter Match Condions for IPv4 Trac | 942
Firewall Filter Match Condions for IPv6 Trac | 959
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
xiii
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Fields | 986
Firewall Filter Match Condions Based on Address Classes | 996
Understanding IP-Based Filtering and Selecve Port Mirroring of MPLS Trac | 998
Firewall Filter Match Condions for MPLS Trac | 1004
Firewall Filter Match Condions for MPLS-Tagged IPv4 or IPv6 Trac | 1013
Firewall Filter Match Condions for VPLS Trac | 1017
Firewall Filter Match Condions for Layer 2 CCC Trac | 1036
Firewall Filter Match Condions for Layer 2 Bridging Trac | 1042
Firewall Filter Support on Loopback Interface | 1059
Applying Firewall Filters to Roung Engine Trac | 1061
Conguring Logical Units on the Loopback Interface for Roung Instances in Layer 3 VPNs | 1061
Example: Conguring a Filter to Limit TCP Access to a Port Based On a Prex List | 1063
Requirements | 1063
Overview | 1064
Conguraon | 1064
Vericaon | 1067
Example: Conguring a Stateless Firewall Filter to Accept Trac from Trusted Sources | 1069
Requirements | 1069
Overview | 1069
Conguraon | 1070
Vericaon | 1073
Example: Congure a Filter to Block Telnet and SSH Access | 1077
Requirements | 1077
Overview and Topology | 1077
Conguraon | 1078
Verify the Stateless Firewall Filter | 1086
Example: Conguring a Filter to Block TFTP Access | 1090
Requirements | 1090
xiv
Overview | 1090
Conguraon | 1091
Vericaon | 1094
Example: Conguring a Filter to Accept Packets Based on IPv6 TCP Flags | 1095
Requirements | 1095
Overview | 1095
Conguraon | 1095
Vericaon | 1098
Example: Conguring a Filter to Block TCP Access to a Port Except from Specied BGP Peers | 1099
Requirements | 1099
Overview | 1099
Conguraon | 1100
Vericaon | 1105
Example: Conguring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods | 1107
Requirements | 1108
Overview | 1108
Conguraon | 1109
Vericaon | 1116
Example: Protecng the Roung Engine with a Packets-Per-Second Rate Liming Filter | 1123
Requirements | 1124
Overview | 1124
Conguraon | 1124
Vericaon | 1127
Example: Conguring a Filter to Exclude DHCPv6 and ICMPv6 Control Trac for LAC Subscriber | 1128
Requirements | 1129
Overview | 1129
Conguraon | 1129
Port Number Requirements for DHCP Firewall Filters | 1135
Example: Conguring a DHCP Firewall Filter to Protect the Roung Engine | 1136
Requirements | 1136
Overview | 1136
Conguraon | 1137
xv
Vericaon | 1140
Applying Firewall Filters to Transit Trac | 1142
Example: Conguring a Filter for Use as an Ingress Queuing Filter | 1142
Requirements | 1143
Overview | 1143
Conguraon | 1144
Example: Conguring a Filter to Match on IPv6 Flags | 1146
Requirements | 1146
Overview | 1146
Conguraon | 1146
Vericaon | 1148
Example: Conguring a Filter to Match on Port and Protocol Fields | 1148
Requirements | 1148
Overview | 1148
Conguraon | 1148
Vericaon | 1153
Example: Conguring a Filter to Count Accepted and Rejected Packets | 1153
Requirements | 1153
Overview | 1153
Conguraon | 1154
Vericaon | 1157
Example: Conguring a Filter to Count and Discard IP Opons Packets | 1158
Requirements | 1158
Overview | 1158
Conguraon | 1159
Vericaon | 1162
Example: Conguring a Filter to Count IP Opons Packets | 1162
Requirements | 1163
Overview | 1163
Conguraon | 1163
Vericaon | 1169
Example: Conguring a Filter to Count and Sample Accepted Packets | 1169
xvi
Requirements | 1170
Overview | 1170
Conguraon | 1171
Vericaon | 1174
Example: Conguring a Filter to Set the DSCP Bit to Zero | 1176
Requirements | 1177
Overview | 1177
Conguraon | 1177
Vericaon | 1180
Example: Conguring a Filter to Set the DSCP Bit to Zero | 1181
Requirements | 1181
Overview | 1181
Conguraon | 1181
Vericaon | 1184
Example: Conguring a Filter to Match on Two Unrelated Criteria | 1185
Requirements | 1185
Overview | 1185
Conguraon | 1185
Vericaon | 1188
Example: Conguring a Filter to Accept DHCP Packets Based on Address | 1189
Requirements | 1189
Overview | 1189
Conguraon | 1189
Vericaon | 1192
Example: Conguring a Filter to Accept OSPF Packets from a Prex | 1193
Requirements | 1193
Overview | 1193
Conguraon | 1193
Vericaon | 1197
Example: Conguring a Stateless Firewall Filter to Handle Fragments | 1197
Requirements | 1197
Overview | 1198
xvii
Conguraon | 1199
Vericaon | 1203
Conguring a Firewall Filter to Prevent or Allow IPv4 Packet Fragmentaon | 1205
Conguring a Firewall Filter to Discard Ingress IPv6 Packets with a Mobility Extension Header | 1206
Example: Conguring an Egress Filter Based on IPv6 Source or Desnaon IP Addresses | 1207
Requirements | 1207
Overview | 1207
Conguraon | 1208
Example: Conguring a Rate-Liming Filter Based on Desnaon Class | 1212
Requirements | 1212
Overview | 1212
Conguraon | 1212
Vericaon | 1216
Conguring Firewall Filters in Logical Systems | 1217
Firewall Filters in Logical Systems Overview | 1217
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
References from a Firewall Filter in a Logical System to Subordinate Objects | 1222
References from a Firewall Filter in a Logical System to Nonrewall Objects | 1224
References from a Nonrewall Object in a Logical System to a Firewall Filter | 1227
Example: Conguring Filter-Based Forwarding | 1234
Requirements | 1234
Overview | 1234
Conguraon | 1235
Example: Conguring Filter-Based Forwarding on Logical Systems | 1240
Requirements | 1240
Overview | 1241
Conguraon | 1244
Vericaon | 1251
Example: Conguring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods | 1254
Requirements | 1255
xviii
Overview | 1255
Conguraon | 1256
Vericaon | 1259
Example: Conguring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods | 1260
Requirements | 1261
Overview | 1261
Conguraon | 1262
Vericaon | 1265
Unsupported Firewall Filter Statements for Logical Systems | 1266
Unsupported Acons for Firewall Filters in Logical Systems | 1269
Filter-Based Forwarding for Roung Instances | 1276
Forwarding Table Filters for Roung Instances on ACX Series Routers | 1277
Conguring Forwarding Table Filters | 1278
Conguring Firewall Filter Accounng and Logging | 1281
Accounng for Firewall Filters Overview | 1281
System Logging Overview | 1282
System Logging of Events Generated for the Firewall Facility | 1283
Firewall Filter Logging Acons | 1286
Example: Conguring Stascs Collecon for a Firewall Filter | 1290
Requirements | 1290
Overview | 1290
Conguraon | 1291
Vericaon | 1297
Example: Conguring Logging for a Firewall Filter Term | 1297
Requirements | 1298
Overview | 1298
Conguraon | 1298
Vericaon | 1302
Aaching Mulple Firewall Filters to a Single Interface | 1304
Applying Firewall Filters to Interfaces | 1304
xix
Conguring Firewall Filters | 1305
Conguring a Firewall Filter | 1305
Applying a Firewall Filter to a Layer 3 (Routed) Interface | 1307
Muleld Classier Example: Conguring Muleld Classicaon | 1308
Muleld Classicaon Overview | 1308
Muleld Classicaon Requirements and Restricons | 1311
Muleld Classicaon Limitaons on M Series Routers | 1312
Example: Conguring Muleld Classicaon | 1315
Requirements | 1315
Overview | 1316
Conguraon | 1317
Vericaon | 1323
Example: Conguring and Applying a Firewall Filter for a Muleld Classier | 1325
Requirements | 1325
Overview | 1325
Conguraon | 1327
Vericaon | 1331
Muleld Classier for Ingress Queuing on MX Series Routers with MPC | 1334
Assigning Muleld Classiers in Firewall Filters to Specify Packet-Forwarding Behavior (CLI
Procedure) | 1335
Understanding Mulple Firewall Filters in a Nested Conguraon | 1338
Guidelines for Nesng References to Mulple Firewall Filters | 1340
Understanding Mulple Firewall Filters Applied as a List | 1342
Guidelines for Applying Mulple Firewall Filters as a List | 1346
Example: Applying Lists of Mulple Firewall Filters | 1348
Requirements | 1349
Overview | 1349
Conguraon | 1350
Vericaon | 1355
Example: Nesng References to Mulple Firewall Filters | 1356
Requirements | 1356
Overview | 1357
xx
Conguraon | 1357
Vericaon | 1361
Example: Filtering Packets Received on an Interface Set | 1362
Requirements | 1362
Overview | 1362
Conguraon | 1363
Vericaon | 1371
Aaching a Single Firewall Filter to Mulple Interfaces | 1372
Interface-Specic Firewall Filter Instances Overview | 1372
Interface-Specic Firewall Filter Instances Overview | 1375
Filtering Packets Received on a Set of Interface Groups Overview | 1377
Filtering Packets Received on an Interface Set Overview | 1378
Example: Conguring Interface-Specic Firewall Filter Counters | 1379
Requirements | 1379
Overview | 1379
Conguraon | 1380
Vericaon | 1384
Example: Conguring a Stateless Firewall Filter on an Interface Group | 1386
Requirements | 1386
Overview | 1386
Conguraon | 1387
Vericaon | 1392
Conguring Filter-Based Tunneling Across IP Networks | 1398
Understanding Filter-Based Tunneling Across IPv4 Networks | 1398
Firewall Filter-Based L2TP Tunneling in IPv4 Networks Overview | 1401
Interfaces That Support Filter-Based Tunneling Across IPv4 Networks | 1405
Components of Filter-Based Tunneling Across IPv4 Networks | 1407
Example: Transporng IPv6 Trac Across IPv4 Using Filter-Based Tunneling | 1413
Requirements | 1413
Overview | 1415
xxi
Conguraon | 1418
Vericaon | 1429
Conguring Service Filters | 1435
Service Filter Overview | 1435
How Service Filters Evaluate Packets | 1437
Guidelines for Conguring Service Filters | 1439
Guidelines for Applying Service Filters | 1442
Example: Conguring and Applying Service Filters | 1445
Requirements | 1445
Overview | 1446
Conguraon | 1447
Vericaon | 1451
Service Filter Match Condions for IPv4 or IPv6 Trac | 1453
Service Filter Nonterminang Acons | 1464
Service Filter Terminang Acons | 1465
Conguring Simple Filters | 1467
Simple Filter Overview | 1467
How Simple Filters Evaluate Packets | 1468
Guidelines for Conguring Simple Filters | 1469
Guidelines for Applying Simple Filters | 1474
Example: Conguring and Applying a Simple Filter | 1475
Requirements | 1475
Overview | 1476
Conguraon | 1476
Vericaon | 1480
Conguring Layer 2 Firewall Filters | 1483
Understanding Firewall Filters Used to Control Trac Within Bridge Domains and VPLS Instances | 1483
Example: Conguring Filtering of Frames by MAC Address | 1484
Example: Conguring Filtering of Frames by IEEE 802.1p Bits | 1486
xxii
Example: Conguring Filtering of Frames by Packet Loss Priority | 1487
Example: Conguring Policing and Marking of Trac Entering a VPLS Core | 1489
Understanding Firewall Filters on OVSDB-Managed Interfaces | 1492
Example: Applying a Firewall Filter to OVSDB-Managed Interfaces | 1493
Requirements | 1494
Overview | 1494
Conguraon | 1494
Conguring Firewall Filters for Forwarding, Fragments, and Policing | 1497
Filter-Based Forwarding Overview | 1497
Firewall Filters That Handle Fragmented Packets Overview | 1500
Stateless Firewall Filters That Reference Policers Overview | 1500
Example: Conguring Filter-Based Forwarding on the Source Address | 1501
Requirements | 1502
Overview | 1502
Conguraon | 1505
Vericaon | 1513
Example: Conguring Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP
Address | 1515
Understanding Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP
Address | 1515
Example: Conguring Filter-Based Forwarding to a Specic Outgoing Interface | 1517
Requirements | 1518
Overview | 1518
Conguraon | 1519
Vericaon | 1523
Example: Conguring Filter-Based Forwarding to a Specic Desnaon IP Address | 1524
Requirements | 1525
Overview | 1525
Conguraon | 1526
Vericaon | 1535
Conguring Firewall Filters (EX Series Switches) | 1538
Firewall Filters for EX Series Switches Overview | 1539
xxiii
Understanding Planning of Firewall Filters | 1543
Understanding Firewall Filter Match Condions | 1547
Understanding How Firewall Filters Control Packet Flows | 1553
Understanding How Firewall Filters Are Evaluated | 1554
Understanding Firewall Filter Processing Points for Bridged and Routed Packets on EX Series
Switches | 1556
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
Plaorm Support for Firewall Filter Match Condions, Acons, and Acon Modiers on EX Series
Switches | 1574
Support for Match Condions and Acons for Loopback Firewall Filters on Switches | 1637
Conguring Firewall Filters (CLI Procedure) | 1642
Conguring a Firewall Filter | 1642
Conguring a Term Specically for IPv4 or IPv6 Trac | 1647
Applying a Firewall Filter to a Port on a Switch | 1648
Applying a Firewall Filter to a Management Interface on a Switch | 1649
Applying a Firewall Filter to a VLAN on a Network | 1650
Applying a Firewall Filter to a Layer 3 (Routed) Interface | 1652
Understanding How Firewall Filters Test a Packet's Protocol | 1653
Understanding Filter-Based Forwarding for EX Series Switches | 1654
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches | 1654
Requirements | 1655
Overview | 1655
Conguring an Ingress Port Firewall Filter to Priorize Voice Trac and Rate-Limit TCP and
ICMP Trac | 1660
Conguring a VLAN Ingress Firewall Filter to Prevent Rogue Devices from Disrupng VoIP
Trac | 1668
Conguring a VLAN Firewall Filter to Count, Monitor, and Analyze Egress Trac on the
Employee VLAN | 1672
Conguring a VLAN Firewall Filter to Restrict Guest-to-Employee Trac and Peer-to-Peer
Applicaons on the Guest VLAN | 1675
Conguring a Router Firewall Filter to Give Priority to Egress Trac Desned for the Corporate
Subnet | 1678
Vericaon | 1680
xxiv
Example: Conguring a Firewall Filter on a Management Interface on an EX Series Switch | 1684
Requirements | 1684
Overview and Topology | 1684
Conguraon | 1685
Vericaon | 1688
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Requirements | 1690
Overview and Topology | 1690
Conguraon | 1690
Vericaon | 1694
Example: Applying Firewall Filters to Mulple Supplicants on Interfaces Enabled for 802.1X or MAC
RADIUS Authencaon | 1696
Requirements | 1696
Overview and Topology | 1697
Conguraon | 1699
Vericaon | 1702
Verifying That Policers Are Operaonal | 1703
Troubleshoong Firewall Filters | 1704
Troubleshoong QFX10000 Switches | 1705
Do Not Combine Match Condions for Dierent Layers | 1705
Layer 2 Packets Cannot be Discarded with Firewall Filters | 1705
Protect-RE (loopback) Firewall Filter Does Not Filter Packets Applied to EM0 Interfaces | 1706
Troubleshoong Other Switches | 1706
Firewall Filter Conguraon Returns a No Space Available in TCAM Message | 1707
Filter Counts Previously Dropped Packet | 1710
Matching Packets Not Counted | 1711
Counter Reset When Eding Filter | 1712
Cannot Include loss-priority and policer Acons in Same Term | 1712
Cannot Egress Filter Certain Trac Originang on QFX Switch | 1713
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling | 1714
Egress Firewall Filters with Private VLANs | 1714
Egress Filtering of L2PT Trac Not Supported | 1716
Cannot Drop BGP Packets in Certain Circumstances | 1716
Invalid Stascs for Policer | 1717
xxv
Policers can Limit Egress Filters | 1717
Conguring Firewall Filters (QFX Series Switches, EX4600 Switches, PTX Series
Routers) | 1719
Overview of Firewall Filters (QFX Series) | 1720
Understanding Firewall Filter Planning | 1723
Planning the Number of Firewall Filters to Create | 1725
How to Increase the Number of Firewall Filters | 1725
TCAM | 1726
Avoid Conguring too Many Filters | 1727
Conguring TCAM Error Messages | 1727
How to Increase the Scale of Firewall Filters Using Proles | 1728
How Policers can Limit Egress Filters | 1732
Planning for Filter-Specic Policers | 1733
Planning for Filter-Based Forwarding | 1733
Firewall Filter Match Condions and Acons (QFX and EX Series Switches) | 1734
Firewall Filter Match Condions and Acons (EX4100, EX4100-F, EX4400, EX4600, EX4650,
QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, QFX5700) | 1735
Firewall Filter Match Condions and Acons (QFX5220 and the QFX5130-32CD) | 1765
Firewall Filter Match Condions and Acons (QFX10000 Switches) | 1783
Firewall Filter Match Condions and Acons (PTX Series Routers) | 1801
Firewall Filter Match Condions and Acons (PTX Series Routers) | 1801
IPv6 Firewall Filter Match Condions and Acons (PTX10001-20C) | 1818
Firewall and Policing Dierences Between PTX Series Packet Transport Routers and T Series Matrix
Routers | 1826
Conguring Firewall Filters | 1829
Conguring a Firewall Filter | 1829
Conguring Enhanced Egress Firewall Filters (QFX5110 and QFX5220 Switches) | 1833
Applying a Firewall Filter to a Port | 1834
Applying a Firewall Filter to a VLAN | 1835
Applying a Firewall Filter to a Layer 3 (Routed) Interface | 1835
Applying a Firewall Filter to a Layer 2 CCC (QFX10000 Switches) | 1837
Applying Firewall Filters to Interfaces | 1838
xxvi
Overview of MPLS Firewall Filters on Loopback Interface | 1838
Conguring MPLS Firewall Filters and Policers on Switches | 1840
Conguring an MPLS Firewall Filter | 1840
Applying an MPLS Firewall Filter to an MPLS Interface | 1841
Applying an MPLS Firewall Filter to a Loopback Interface | 1841
Conguring Policers for LSPs | 1842
Conguring MPLS Firewall Filters and Policers on Routers | 1843
Conguring MPLS Firewall Filters and Policers | 1852
Understanding How a Firewall Filter Tests a Protocol | 1855
Understanding Firewall Filter Processing Points for Bridged and Routed Packets | 1856
Understanding Filter-Based Forwarding | 1857
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1858
Requirements | 1858
Overview and Topology | 1858
Conguraon | 1859
Vericaon | 1862
Conguring a Firewall Filter to De-Encapsulate GRE or IPIP Trac | 1865
Conguring a Filter to De-Encapsulate GRE Trac | 1865
Conguring a Filter to De-Encapsulate IPIP Trac | 1867
Applying the Filter to an Interface | 1868
Verifying That Firewall Filters Are Operaonal | 1869
Monitoring Firewall Filter Trac | 1870
Monitoring Trac for All Firewall Filters and Policers That Are Congured on the Switch | 1870
Monitoring Trac for a Specic Firewall Filter | 1872
Monitoring Trac for a Specic Policer | 1872
Troubleshoong Firewall Filter Conguraon | 1874
Firewall Filter Conguraon Returns a No Space Available in TCAM Message | 1874
Filter Counts Previously Dropped Packet | 1877
Matching Packets Not Counted | 1878
Counter Reset When Eding Filter | 1879
Cannot Include loss-priority and policer Acons in Same Term | 1879
xxvii
Cannot Egress Filter Certain Trac Originang on QFX Switch | 1880
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling | 1881
Egress Firewall Filters with Private VLANs | 1881
Egress Filtering of L2PT Trac Not Supported | 1882
Cannot Drop BGP Packets in Certain Circumstances | 1883
Invalid Stascs for Policer | 1884
Policers can Limit Egress Filters | 1884
Conguring Firewall Filter Accounng and Logging (EX9200 Switches) | 1886
Example: Conguring Logging for a Stateless Firewall Filter Term | 1886
Requirements | 1886
Overview | 1886
Conguraon | 1887
Vericaon | 1891
Use the CLI Editor in Conguraon Mode | 1892
3
Conguring Trac Policers
Understanding Trac Policers | 1898
Policer Implementaon Overview | 1899
ARP Policer Overview | 1903
Example: Conguring ARP Policer | 1905
Requirements | 1905
Overview | 1905
Conguraon | 1906
Vericaon | 1908
Understanding the Benets of Policers and Token Bucket Algorithms | 1910
Determining Proper Burst Size for Trac Policers | 1912
Controlling Network Access Using Trac Policing Overview | 1920
Trac Policer Types | 1926
Order of Policer and Firewall Filter Operaons | 1930
Understanding the Frame Length for Policing Packets | 1930
Supported Standards for Policing | 1931
xxviii
Hierarchical Policer Conguraon Overview | 1932
Understanding Enhanced Hierarchical Policers | 1934
Packets-Per-Second (pps)-Based Policer Overview | 1938
Guidelines for Applying Trac Policers | 1938
Policer Support for Aggregated Ethernet Interfaces Overview | 1939
Example: Conguring a Physical Interface Policer for Aggregate Trac at a Physical Interface | 1941
Requirements | 1941
Overview | 1941
Conguraon | 1942
Vericaon | 1948
Firewall and Policing Dierences Between PTX Series Packet Transport Routers and T Series Matrix
Routers | 1950
Hierarchical Policers on ACX Series Routers Overview | 1953
Guidelines for Conguring Hierarchical Policers on ACX Series Routers | 1955
Hierarchical Policer Modes on ACX Series Routers | 1957
Processing of Hierarchical Policers on ACX Series Routers | 1962
Acons Performed for Hierarchical Policers on ACX Series Routers | 1963
Conguring Aggregate Parent and Child Policers on ACX Series Routers | 1966
Conguring Policer Rate Limits and Acons | 1970
Policer Bandwidth and Burst-Size Limits | 1970
Policer Color-Marking and Acons | 1972
Single Token Bucket Algorithm | 1975
Dual Token Bucket Algorithms | 1978
Conguring Layer 2 Policers | 1980
Hierarchical Policers | 1980
Hierarchical Policer Overview | 1981
Example: Conguring a Hierarchical Policer | 1982
Requirements | 1983
Overview | 1983
xxix
Conguraon | 1984
Vericaon | 1990
Example: Conguring a Hierarchical Policer for Subscriber Services Firewall (ACX7100-48L
Devices) | 1991
Overview | 1991
Conguraon Scenarios | 1992
Conguring a Policer Overhead | 2005
Two-Color and Three-Color Policers at Layer 2 | 2007
Two-Color Policing at Layer 2 Overview | 2007
Three-Color Policing at Layer 2 Overview | 2009
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer | 2012
Requirements | 2012
Overview | 2012
Conguraon | 2013
Vericaon | 2019
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Conguring a Two-Color Layer 2 Policer for the Pseudowire | 2022
Conguring a Three-Color Layer 2 Policer for the Pseudowire | 2023
Applying the Policers to Dynamic Prole Interfaces | 2024
Aaching Dynamic Proles to Roung Instances | 2025
Using Variables for Layer 2 Trac Policing at the Pseudowire Overview | 2027
Conguring a Policer for the Complex Conguraon | 2027
Creang a Dynamic Prole for the Complex Conguraon | 2028
Aaching Dynamic Proles to Roung Instances for the Complex Conguraon | 2030
Verifying Layer 2 Trac Policers on VPLS Connecons | 2031
Understanding Policers on OVSDB-Managed Interfaces | 2032
Example: Applying a Policer to OVSDB-Managed Interfaces | 2033
Requirements | 2033
Overview | 2034
Conguraon | 2034
xxx
Conguring Two-Color and Three-Color Trac Policers at Layer 3 | 2038
Two-Color Policer Conguraon Overview | 2038
Basic Single-Rate Two-Color Policers | 2046
Single-Rate Two-Color Policer Overview | 2046
Example: Liming Inbound Trac at Your Network Border by Conguring an Ingress Single-Rate
Two-Color Policer | 2047
Requirements | 2048
Overview | 2048
Conguraon | 2051
Vericaon | 2057
Example: Conguring Interface and Firewall Filter Policers at the Same Interface | 2059
Requirements | 2059
Overview | 2060
Conguraon | 2061
Vericaon | 2071
Bandwidth Policers | 2074
Bandwidth Policer Overview | 2074
Example: Conguring a Logical Bandwidth Policer | 2076
Requirements | 2076
Overview | 2077
Conguraon | 2078
Vericaon | 2084
Prex-Specic Counng and Policing Acons | 2087
Prex-Specic Counng and Policing Overview | 2088
Filter-Specic Counter and Policer Set Overview | 2091
Filter-Specic Policer Overview | 2091
Example: Conguring Prex-Specic Counng and Policing | 2092
Requirements | 2092
Overview | 2092
Conguraon | 2094
Vericaon | 2100
Prex-Specic Counng and Policing Conguraon Scenarios | 2102
Policer Overhead to Account for Rate Shaping in the Trac Manager | 2110
Policer Overhead to Account for Rate Shaping Overview | 2110
xxxi
Example: Conguring Policer Overhead to Account for Rate Shaping | 2111
Requirements | 2111
Overview | 2111
Conguraon | 2112
Vericaon | 2120
Three-Color Policer Conguraon Overview | 2122
Applying Policers | 2126
Overview of Applying Policers | 2126
Applying Aggregate Policers | 2127
Applying Hierarchical Policers on Enhanced Intelligent Queuing PICs | 2130
Conguring Hierarchical Policers | 2133
Conguring a Single-Rate Two-Color Policer | 2134
Conguring a Single-Rate Color-Blind Policer | 2135
Conguring a Two-Rate Tricolor Marker Policer | 2136
Three-Color Policer Conguraon Guidelines | 2138
Plaorms Supported for Three-Color Policers | 2138
Color Modes for Three-Color Policers | 2139
Naming Convenons for Three-Color Policers | 2140
Basic Single-Rate Three-Color Policers | 2142
Single-Rate Three-Color Policer Overview | 2142
Example: Conguring a Single-Rate Three-Color Policer | 2143
Requirements | 2143
Overview | 2143
Conguraon | 2144
Vericaon | 2150
Basic Two-Rate Three-Color Policers | 2151
Two-Rate Three-Color Policer Overview | 2151
Example: Conguring a Two-Rate Three-Color Policer | 2153
Requirements | 2153
Overview | 2153
Conguraon | 2154
Vericaon | 2159
Example: Conguring a Two-Rate Three-Color Policer | 2161
xxxii
Requirements | 2161
Overview | 2161
Conguraon | 2162
Vericaon | 2167
Conguring Logical and Physical Interface Trac Policers at Layer 3 | 2170
Two-Color and Three-Color Logical Interface Policers | 2170
Logical Interface (Aggregate) Policer Overview | 2170
Example: Conguring a Two-Color Logical Interface (Aggregate) Policer | 2171
Requirements | 2172
Overview | 2172
Conguraon | 2173
Vericaon | 2178
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer | 2180
Requirements | 2180
Overview | 2180
Conguraon | 2181
Vericaon | 2187
Two-Color and Three-Color Physical Interface Policers | 2189
Physical Interface Policer Overview | 2189
Example: Conguring a Physical Interface Policer for Aggregate Trac at a Physical Interface | 2191
Requirements | 2191
Overview | 2191
Conguraon | 2192
Vericaon | 2198
Conguring Policers on Switches | 2201
Overview of Policers | 2202
Trac Policer Types | 2210
Understanding the Use of Policers in Firewall Filters | 2214
Understanding Tricolor Marking Architecture | 2219
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Conguring Policers | 2220
Specifying Policers in a Firewall Filter Conguraon | 2222
xxxiii
Applying a Firewall Filter That Is Congured with a Policer | 2222
Conguring Tricolor Marking Policers | 2222
Conguring a Tricolor Marking Policer | 2223
Applying Tricolor Marking Policers to Firewall Filters | 2224
Understanding Policers with Link Aggregaon Groups | 2225
Understanding Color-Blind Mode for Single-Rate Tricolor Marking | 2226
Understanding Color-Aware Mode for Single-Rate Tricolor Marking | 2226
Understanding Color-Blind Mode for Two-Rate Tricolor Marking | 2229
Understanding Color-Aware Mode for Two-Rate Tricolor Marking | 2229
Example: Using Two-Color Policers and Prex Lists | 2232
Example: Using Policers to Manage Oversubscripon | 2236
Assigning Forwarding Classes and Loss Priority | 2238
Conguring Color-Blind Egress Policers for Medium-Low PLP | 2241
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
Conguring Two-Color Policers | 2242
Conguring Three-Color Policers | 2243
Specifying Policers in a Firewall Filter Conguraon | 2244
Applying a Firewall Filter That Includes a Policer | 2244
Verifying That Two-Color Policers Are Operaonal | 2245
Verifying That Three-Color Policers Are Operaonal | 2246
Troubleshoong Policer Conguraon | 2247
Incomplete Count of Packet Drops | 2247
Counter Reset When Eding Filter | 2248
Invalid Stascs for Policer | 2249
Policers Can Limit Egress Filters | 2249
Troubleshoong Policer Conguraon | 2251
Incomplete Count of Packet Drops | 2251
Counter Reset When Eding Filter | 2252
Invalid Stascs for Policer | 2252
xxxiv
Egress Policers on QFX3500 Devices Might Allow More Throughput Than Is Congured | 2253
Filter-Specic Egress Policers on QFX3500 Devices Might Allow More Throughput Than Is
Congured | 2254
Policers Can Limit Egress Filters | 2255
4
Conguraon Statements and Operaonal Commands
Firewall Filter Conguraon Statements Supported by Junos OS for EX Series Switches | 2258
gtp-header | 2263
gtp-teid | 2265
per-logical-interface-rewall | 2267
Junos CLI Reference Overview | 2269
5
Troubleshoong
Knowledge Base | 2271
xxxv
About This Guide
Roung policies allow you to control the roung informaon between the roung protocols and the
roung tables and between the roung tables and the forwarding table. All roung protocols use the
Junos OS roung tables to store the routes that they learn and to determine which routes they should
adverse in their protocol packets. Roung policies also allow you to control which routes the roung
protocols store in and retrieve from the roung table.
Firewall lter policies allow you to control packets transing the router to a network desnaon and
packets desned for and sent by the router. They provide a means of protecng your router from
excessive trac transing the router to a network desnaon or desned for the Roung Engine.
Firewall lters that control local packets can also protect your router from external incidents such as
denial-of-service aacks.
RELATED DOCUMENTATION
Day One: Conguring Junos Policies and Firewall Filters
xxxvi
1
PART
Understanding and Conguring Junos
Roung Policies
Overview | 2
Evaluang Roung Policies Using Match Condions, Acons, Terms, and
Expressions | 54
Evaluang Complex Cases Using Policy Chains and Subrounes | 257
Conguring Route Filters and Prex Lists as Match Condions | 305
Conguring AS Paths as Match Condions | 435
Conguring Communies as Match Condions | 513
Increasing Network Stability with BGP Route Flapping Acons | 598
Tracking Trac Usage with Source Class Usage and Desnaon Class Usage
Acons | 637
Avoiding Trac Roung Threats with Condional Roung Policies | 688
Protecng Against DoS Aacks by Forwarding Trac to the Discard Interface |
716
Improving Commit Times with Dynamic Roung Policies | 734
Tesng Before Applying Roung Policies | 760
CHAPTER 1
Overview
IN THIS CHAPTER
Policy Framework Overview | 2
Comparison of Roung Policies and Firewall Filters | 9
Prex Priorizaon Overview | 15
FIB Prex Priorizaon | 16
Accounng of the Policer Overhead Aribute at the Interface Level | 17
Conguring the Accounng of Policer Overhead in Interface Stascs | 19
Understanding Roung Policies | 22
Protocol Support for Import and Export Policies | 26
Example: Applying Roung Policies at Dierent Levels of the BGP Hierarchy | 27
Default Roung Policies | 40
Example: Conguring a Condional Default Route Policy | 44
Policy Framework Overview
IN THIS SECTION
Roung Policy and Firewall Filters | 3
Reasons to Create a Roung Policy | 3
Router Flows Aected by Policies | 4
Control Points | 7
Policy Components | 8
2
The Junos
®
operang system (Junos OS) provides a
policy framework
, which is a collecon of Junos OS
policies that allows you to control ows of roung informaon and packets.
The Junos OS policy architecture is simple and straighorward. However, the actual implementaon of
each policy adds layers of complexity to the policy as well as adding power and exibility to your
router’s capabilies. Conguring a policy has a major impact on the ow of roung informaon or
packets within and through the router. For example, you can congure a roung policy that does not
allow routes associated with a parcular customer to be placed in the roung table. As a result of this
roung policy, the customer routes are not used to forward data packets to various desnaons and the
routes are not adversed by the roung protocol to neighbors.
Before conguring a policy, determine what you want to accomplish with it and thoroughly understand
how to achieve your goal using the various match condions and acons. Also, make certain that you
understand the default policies and acons for the policy you are conguring.
Roung Policy and Firewall Filters
The policy framework is composed of the following policies:
• Roung policy—Allows you to control the roung informaon between the roung protocols and the
roung tables and between the roung tables and the forwarding table. All roung protocols use the
Junos OS roung tables to store the routes that they learn and to determine which routes they
should adverse in their protocol packets. Roung policy allows you to control which routes the
roung protocols store in and retrieve from the roung table.
•
Firewall lter
policy—Allows you to control packets transing the router to a network desnaon and
packets desned for and sent by the router.
NOTE: The term
rewall lter policy
is used here to emphasize that a rewall lter is a policy
and shares some fundamental similaries with a roung policy. However, when referring to a
rewall lter policy in the rest of this manual, the term
rewall lter
is used.
Reasons to Create a Roung Policy
The following are typical circumstances under which you might want to preempt the default roung
policies in the roung policy framework by creang your own roung policies:
• You do not want a protocol to import all routes into the roung table. If the roung table does not
learn about certain routes, they can never be used to forward packets and they can never be
redistributed into other roung protocols.
• You do not want a roung protocol to export all the acve routes it learns.
3
• You want a roung protocol to announce acve routes learned from another roung protocol, which
is somemes called
route redistribuon
.
• You want to manipulate route characteriscs, such as the preference value, AS path, or community.
You can manipulate the route characteriscs to control which route is selected as the acve route to
reach a desnaon. In general, the acve route is also adversed to a router’s neighbors.
• You want to change the default BGP route ap-damping parameters.
• You want to perform per-packet load balancing.
• You want to enable
class of service
(CoS).
Router Flows Aected by Policies
The Junos OS policies aect the following router ows:
• Flow of roung informaon between the roung protocols and the roung tables and between the
roung tables and the forwarding table. The Roung Engine handles this ow.
Roung informaon
is
the informaon about routes learned by the roung protocols from a router’s neighbors. This
informaon is stored in roung tables and is subsequently adversed by the roung protocols to the
router’s neighbors. Roung policies allow you to control the ow of this informaon.
• Flow of data packets in and out of the router’s physical interfaces. The Packet Forwarding Engine
handles this ow.
Data packets
are chunks of data that transit the router as they are being forwarded
from a source to a desnaon. When a router receives a data packet on an interface, it determines
where to forward the packet by looking in the forwarding table for the best route to a desnaon.
The router then forwards the data packet toward its desnaon through the appropriate interface.
Firewall lters allow you to control the ow of these data packets.
• Flow of local packets from the router’s physical interfaces and to the Roung Engine. The Roung
Engine handles this ow.
Local packets
are chunks of data that are desned for or sent by the router.
Local packets usually contain roung protocol data, data for IP services such as Telnet or SSH, and
data for administrave protocols such as the Internet Control Message Protocol (ICMP). When the
Roung Engine receives a local packet, it forwards the packet to the appropriate process or to the
kernel, which are both part of the Roung Engine, or to the Packet Forwarding Engine. Firewall lters
allow you to control the ow of these local packets.
NOTE: In the rest of this chapter, the term
packets
refers to both data and local packets
unless explicitly stated otherwise.
Figure 1 on page 5 illustrates the ows through the router. Although the ows are very dierent from
each other, they are also interdependent. Roung policies determine which routes are placed in the
4
forwarding table. The forwarding table, in turn, has an integral role in determining the appropriate
physical interface through which to forward a packet.
Figure 1: Flows of Roung Informaon and Packets
You can congure roung policies to control which routes the roung protocols place in the roung
tables and to control which routes the roung protocols adverse from the roung tables (see Figure 2
on page 6). The roung protocols adverse acve routes only from the roung tables. (An
acve
route
is a route that is chosen from all routes in the roung table to reach a desnaon.)
You can also use roung policies to do the following:
• Change specic route characteriscs, which allow you to control which route is selected as the acve
route to reach a desnaon. In general, the acve route is also adversed to a router’s neighbors.
• Change to the default BGP route ap-damping values.
• Perform per-packet load balancing.
• Enable class of service (CoS).
5
Figure 2: Roung Policies to Control Roung Informaon Flow
You can congure rewall lters to control the following aspects of packet ow (see Figure 3 on page
7):
• Which data packets are accepted on and transmied from the physical interfaces. To control the ow
of data packets, you apply rewall lters to the physical interfaces.
• Which local packets are transmied from the physical interfaces and to the Roung Engine. To
control local packets, you apply rewall lters on the loopback interface, which is the interface to the
Roung Engine.
Firewall lters provide a means of protecng your router from excessive trac transing the router to a
network desnaon or desned for the Roung Engine. Firewall lters that control local packets can
also protect your router from external incidents such as denial-of-service aacks.
6
Figure 3: Firewall Filters to Control Packet Flow
Control Points
All policies provide two points at which you can control roung informaon or packets through the
router (see Figure 4 on page 8). These control points allow you to control the following:
• Roung informaon before and aer it is placed in the roung table.
• Data packets before and aer a forwarding table lookup.
• Local packets before and aer they are received by the Roung Engine. (Figure 4 on page 8
appears to depict only one control point but because of the bidireconal ow of the local packets,
two control points actually exist.)
7
Figure 4: Policy Control Points
Because there are two control points, you can congure policies that control the roung informaon or
data packets before and aer their interacon with their respecve tables, and policies that control local
packets before and aer their interacon with the Roung Engine.
Import roung policies
control the
roung informaon that is placed in the roung tables, whereas
export roung policies
control the
roung informaon that is adversed from the roung tables.
Input rewall lters
control packets that
are received on a router interface, whereas
output rewall lters
control packets that are transmied
from a router interface.
Policy Components
All policies are composed of the following components that you congure:
•
Match condions
—Criteria against which a route or packets are compared. You can congure one or
more criteria. If all criteria match, one or more acons are applied.
•
Acons
—What happens if all criteria match. You can congure one or more acons.
•
Terms
—Named structures in which match condions and acons are dened. You can dene one or
more terms.
The policy framework soware evaluates each incoming and outgoing route or packet against the match
condions in a term. If the criteria in the match condions are met, the dened acon is taken.
In general, the policy framework soware compares the route or packet against the match condions in
the rst term in the policy, then goes on to the next term, and so on. Therefore, the order in which you
arrange terms in a policy is relevant.
8
The order of match condions within a term is not relevant because a route or packet must match all
match condions in a term for an acon to be taken.
RELATED DOCUMENTATION
Comparison of Roung Policies and Firewall Filters | 9
Roung Policies, Firewall Filters, and Trac Policers User Guide
Comparison of Roung Policies and Firewall Filters
Although roung policies and rewall lters share an architecture, their purposes, implementaon, and
conguraon are dierent. Table 1 on page 9 describes their purposes. Table 2 on page 10 compares
the implementaon details for roung policies and rewall lters, highlighng the similaries and
dierences in their conguraon.
Table 1: Purpose of Roung Policies and Firewall Filters
Policies Source Policy Purpose
Roung policies Roung informaon is generated by internal
networking peers.
To control the size and content of the roung
tables, which routes are adversed, and which
routes are considered the best to reach various
desnaons.
Firewall lters Packets are generated by internal and external
devices through which hosle aacks can be
perpetrated.
To protect your router and network from
excessive incoming trac or hosle aacks
that can disrupt network service, and to
control which packets are forwarded from
which router interfaces.
9
Table 2: Implementaon Dierences Between Roung Policies and Firewall Filters
Policy
Architecture
Roung Policy Implementaon Firewall Filter Implementaon
Control points Control roung informaon that is placed in
the roung table with an import roung policy
and adversed from the roung table with an
export roung policy.
Control packets that are accepted on a router
interface with an input rewall lter and that
are forwarded from an interface with an output
rewall lter.
Conguraon
tasks:
• Dene
policy
• Apply
policy
Dene a policy that contains terms, match
condions, and acons.
Apply one or more export or import policies to
a roung protocol. You can also apply a
policy
expression
, which uses Boolean logical
operators with mulple import or export
policies.
You can also apply one or more export policies
to the forwarding table.
Dene a policy that contains terms, match
condions, and acons.
Apply one input or output rewall lter to a
physical interface or physical interface group to
lter data packets received by or forwarded to
a physical interface (on roung plaorms with
an Internet Processor II applicaon-specic
integrated circuit [ASIC] only).
You can also apply one input or output rewall
lter to the roung plaorm’s loopback
interface, which is the interface to the Roung
Engine (on all roung plaorms). This allows
you to lter local packets received by or
forwarded from the Roung Engine.
Terms Congure as many terms as desired. Dene a
name for each term.
Terms are evaluated in the order in which you
specify them.
Evaluaon of a policy ends aer a packet
matches the criteria in a term and the dened
or default policy acon of accept or reject is
taken. The route is not evaluated against
subsequent terms in the same policy or
subsequent policies.
Congure as many terms as desired. Dene a
name for each term.
Terms are evaluated in the order in which you
specify them.
Evaluaon of a rewall lter ends aer a
packet matches the criteria in a term and the
dened or default acon is taken. The packet is
not evaluated against subsequent terms in the
rewall lter.
10
Table 2: Implementaon Dierences Between Roung Policies and Firewall Filters
(Connued)
Policy
Architecture
Roung Policy Implementaon Firewall Filter Implementaon
Match
condions
Specify zero or more criteria that a route must
match. You can specify criteria based on
source, desnaon, or properes of a route.
You can also specify the following match
condions, which require more conguraon:
• Autonomous system (AS) path expression—
A combinaon of AS numbers and regular
expression operators.
•
Community—A group of desnaons that
share a common property.
•
Prex list—A named list of prexes.
•
Route list—A list of desnaon prexes.
•
Subroune—A roung policy that is called
repeatedly from other roung policies.
Specify zero or more criteria that a packet must
match. You must match various elds in the
packet’s header. The elds are grouped into the
following categories:
• Numeric values, such as port and protocol
numbers.
• Prex values, such as IP source and
desnaon prexes.
•
Bit-eld values—Whether parcular bits in
the elds are set, such as IP opons,
Transmission Control Protocol (TCP) ags,
and IP fragmentaon elds. You can specify
the elds using Boolean logical operators.
11
Table 2: Implementaon Dierences Between Roung Policies and Firewall Filters
(Connued)
Policy
Architecture
Roung Policy Implementaon Firewall Filter Implementaon
Acons Specify zero or one acon to take if a route
matches all criteria. You can specify the
following acons:
• Accept—Accept the route into the roung
table, and propagate it. Aer this acon is
taken, the evaluaon of subsequent terms
and policies ends.
• Reject—Do not accept the route into the
roung table, and do not propagate it. Aer
this acon is taken, the evaluaon of
subsequent terms and policies ends.
In addion to the preceding acons, you can
also specify zero or more of the following types
of acons:
•
Next term—Evaluate the next term in the
roung policy.
• Next policy—Evaluate the next roung
policy.
• Acons that manipulate characteriscs
associated with a route as the roung
protocol places it in the roung table or
adverses it from the roung table.
• Trace acon, which logs route matches.
Specify zero or one acon to take if a packet
matches all criteria. (We recommend that you
always explicitly congure an acon.) You can
specify the following acons:
• Accept—Accept a packet.
• Discard—Discard a packet silently, without
sending an ICMP message.
•
Reject—Discard a packet, and send an
ICMP desnaon unreachable message.
•
Roung instance—Specify a roung table to
which packets are forwarded.
•
Next term—Evaluate the next term in the
rewall lter.
NOTE: On Junos OS Evolved, next term
cannot appear as the last term of the
acon. A lter term where next term is
specied as an acon but without any
match condions congured is not
supported.
In addion to zero or the preceding acons,
you can also specify zero or more acon
modiers. You can specify the following acon
modiers:
• Count—Add packet to a count total.
• Forwarding class—Set the packet
forwarding class to a specied value from 0
through 3.
• IPsec security associaon—Used with the
source and desnaon address match
condions, specify an IP Security (IPsec)
security associaon (SA) for the packet.
12
Table 2: Implementaon Dierences Between Roung Policies and Firewall Filters
(Connued)
Policy
Architecture
Roung Policy Implementaon Firewall Filter Implementaon
• Log—Store the header informaon of a
packet on the Roung Engine.
• Loss priority—Set the packet loss priority
(PLP) bit to a specied value, 0 or 1.
• Policer—Apply rate-liming procedures to
the trac.
• Sample—Sample the packet trac.
•
Syslog—Log an alert for the packet.
13
Table 2: Implementaon Dierences Between Roung Policies and Firewall Filters
(Connued)
Policy
Architecture
Roung Policy Implementaon Firewall Filter Implementaon
Default
policies and
acons
If an incoming or outgoing route arrives and a
policy related to the route is not explicitly
congured, the acon specied by the default
policy for the associated roung protocol is
taken.
The following default acons exist for roung
policies:
• If a policy does not specify a match
condion, all routes evaluated against the
policy match.
•
If a match occurs but the policy does not
specify an accept, reject, next term, or next
policy acon, one of the following occurs:
•
The next term, if present, is evaluated.
•
If no other terms are present, the next
policy is evaluated.
• If no other policies are present, the
acon specied by the default policy is
taken.
• If a match does not occur with a term in a
policy and subsequent terms in the same
policy exist, the next term is evaluated.
• If a match does not occur with any terms in
a policy and subsequent policies exist, the
next policy is evaluated.
• If a match does not occur by the end of a
policy and no other policies exist, the
accept or reject acon specied by the
default policy is taken.
If an incoming or outgoing packet arrives on an
interface and a rewall lter is not congured
for the interface, the default policy is taken (the
packet is accepted).
The following default acons exist for rewall
lters:
• If a rewall lter does not specify a match
condion, all packets are considered to
match.
•
If a match occurs but the rewall lter does
not specify an acon, the packet is
accepted.
•
If a match occurs, the dened or default
acon is taken and the evaluaon ends.
Subsequent terms in the rewall lter are
not evaluated, unless the next term acon is
specied.
NOTE: On Junos OS Evolved, next term
cannot appear as the last term of the
acon. A lter term where next term is
specied as an acon but without any
match condions congured is not
supported.
• If a match does not occur with a term in a
rewall lter and subsequent terms in the
same lter exist, the next term is evaluated.
• If a match does not occur by the end of a
rewall lter, the packet is discarded.
14
RELATED DOCUMENTATION
Policy Framework Overview | 2
Roung Policies, Firewall Filters, and Trac Policers User Guide
Understanding the Algorithm Used to Load Balance Trac on MX Series Routers
Prex Priorizaon Overview
Junos OS routes have a predetermined order for route installaon. This is no longer sucient as it is
somemes required to priorize certain routes or prexes over others for beer convergence or to
provide dierenated services. In a network with a large number of routes, it is somemes important to
control the order in which routes get updated due to a change in the network topology. For example, it
would be useful to rst update OSPF routes that correspond to an IBGP neighbor, and only then update
the rest of the OSPF routes. At a system level, Junos OS implements reasonable defaults based on
heuriscs to determine the order in which routes get updated. However, the default behavior is not
always opmal. Prex priorizaon allows the user to control the order in which the routes get updated
from LDP or OSPF to rpd, and from rpd to kernel. In Junos OS Release 16.1 and later, you can control
the order in which the routes get updated from LDP or OSPF to rpd, and from rpd to kernel.
In Junos OS Release 16.1 and later, the Junos OS policy language is extended to let the user set the
relave priority high and low for prexes via the exisng protocol import policy. Based on the tagged
priority, the routes are placed in dierent priority queues. Routes that are not explicitly assigned a
priority are treated as medium priority. Within the same priority level, routes will connue to be updated
in lexicographic order. Prex priorizaon would need each supporng protocol to priorize its routes
internally. Prex priorizaon ensures that high priority IGP and LDP routes get updated to the FIB
(forwarding table) before medium and low priority routes.
NOTE: There is an upper limit on how many high priority prexes are allowed in the kernel. Not
more than 10,000 high priority prexes can coexist in the kernel. If this threshold is crossed in
the kernel, then any new high priority prex addion request will be considered as normal
priority. This is a “best eort” priorizaon scheme and will not be handled if the kernel is highly
loaded.
RELATED DOCUMENTATION
Example: Conguring the Priority for Route Prexes in the RPD Infrastructure | 414
Conguring Priority for Route Prexes in RPD Infrastructure | 428
15
FIB Prex Priorizaon
IN THIS SECTION
FIB prex priorizaon | 16
FIB prex priories | 16
Supported route types for FIB prex priorizaon in order of install preference | 16
FIB prex priorizaon workow | 17
FIB prex priorizaon
FIB prex priorizaon allows user-dened priories to be assigned to routes when they are exported
to the forwarding plane from the roung plane. Route priories can be assigned in the roung plane, by
way of IGP protocol import policies that assign priories to routes. The user sets the relave priority
high and low for prexes via the exisng protocol import policy – see Prex Priorizaon Overview.
These route priories are exported into the forwarding table.
However, there could be situaons when there is a need to override the roung plane route
priorizaon, with user-dened route priorizaon at the forwarding plane. FIB (forwarding informaon
base) prex priorizaon allows this. In the forwarding table export policy, on matching routes, a route
priority can be assigned.
FIB prex priories
• High – Prexes assigned this priority have the highest install priority. These routes are always given
importance over others.
• Medium – Prexes assigned this priority have the second highest install priority.
NOTE: Prexes that are not assigned high or medium priories are unpriorized.
Supported route types for FIB prex priorizaon in order of install preference
16
• Interface/local routes – Given highest priority uncondionally and will bypass forwarding table
export policy evaluaon.
• Host routes
• IPv4 and IPv6 routes
• MPLS – routes prozaon will be PROTO-based and not prex-based.
FIB prex priorizaon workow
The forward table reserves memory buers for high and medium priority routes, based on user
conguraon – see
b-priorizaon
. Once this conguraon is set, the number of lower priority routes
that can be installed in the forwarding table is limited to the remaining space for these routes.
Aer seng the percentages for high and medium priority routes, the next step is to congure the
forwarding table export policy. See
b-install-priority
.
Once routes are installed in the forwarding table and have their route priories assigned by the FIB
prex priorizaon process, the routes can transion to other priories as well. Because iteraons of a
forwarding table export policy might mark a previously unpriorized route as high priority for example,
such transions are managed in the forwarding table by the packet forwarding engine.
Accounng of the Policer Overhead Aribute at the Interface Level
IN THIS SECTION
Need for Policer Overhead adjustment | 18
Policer Overhead Adjustment Applicability for Policers | 18
A bandwidth prole (BWP) enforces limits on bandwidth ulizaon according to the service level
specicaon (SLS) that has been agreed upon by the subscriber and the service provider as part of the
service level agreement (SLA).There are two types of bandwidth proles:
• Ingress Bandwidth Prole
• Egress Bandwidth Prole
17
Need for Policer Overhead adjustment
The Metro Ethernet Forum (MEF) Carrier Ethernet (CE) 2.0 set of standards has stringent requirements
for the bandwidth prole enforcement at the user network interface (UNI). MEF CE 2.0 cercaon
compliance allows only a 2 percent deviaon from UNI commited or peak rate across all frame sizes.
This means that the policers should take into account the frame size at the UNI interface, including
frame checksum and excluding all addional overheads that might be added inside the service provider
network (such as S-VLANs). Therefore, this translates into two customer requirements:
• Junos OS egress policers use frame length before output VLAN manipulaon. If VLANs are added on
output, those extra bytes will not be counted. In order to address MEF CE 2.0 requirements, adjust
the length of the packet that is used for policing purposes for Junos egress policers that use frame
length before output VLAN manipulaon. Therefore, if VLANs are added on output, the extra bytes
will not be counted.
• In some network designs, bandwidth prole enforcement is implemented at the Layer 2 (L2) VPN
Provider Edge Router and not at the Ethernet access device (EAD) terminang the physical UNI
interface. The EAD typically adds an S-VLAN that idenes the port in the access network. The S-
VLAN that is added is considered internal to the service provider network and typically should not be
taken into account for bandwidth prole enforcement purposes at the Provider Edge device in both
ingress and egress direcons. This also translates into a requirement to allow adjusng the packet
length used for policing purposes on ingress and egress.
In order to address these requirements, policer-overhead adjustment is dened on a per logical interface
(IFL)/direcon granularity, which is the range of -64 bytes to +64 bytes. The policer-overhead adjustment
is applied for all the policers that take into account Layer 1 (L1) or L2 packet length that are exercised in
the specied IFL/direcon, including corresponding logical interface family (IFF) feature policers, and is
applied only to interface or lter-based policers.
Policer Overhead Adjustment Applicability for Policers
The ingress or egress policer overhead adjustment conguraon is applicable for the following types of
policers on ingress or egress IFL and IFF, respecvely:
• L2 two-color and three-color policers.
• IFL-level policers (congured at the IFL or in a lter aached to IFL).
• Family-level policers that use L2 packet length, or policers in lters aached to L2 IFF (family bridge,
vpls, ccc).
18
NOTE: The list is applicable for all types of policers, including regular two-color policers, three-
color policers, and hierarchical policers, provided that the policer operates on an L1 or L2 packet
length.
Ingress policer overhead adjustment conguraon is applied to any policers aached to ingress L2
roung instances.
NOTE: Note that any IFF policer on the L3 family (inet inet6), which considers only L3 packet
length, will not consider this adjustment. The policer overhead adjustment value (+ve or -ve) is
added to the actual L2 packet length to obtain the number of bytes to charge the policer.
Therefore, this is used only as an intermediate value, and does not aect actual L2 packet length.
This feature is applied before VLAN normalizaon, and is independent of the egress-shaping-
overhead or ingress-shaping-overhead conguraon under class of service.
RELATED DOCUMENTATION
policer-overhead-adjustment
Conguring the Accounng of Policer Overhead in Interface Stascs | 19
Conguring the Accounng of Policer Overhead in Interface Stascs
The Metro Ethernet Forum (MEF) Carrier Ethernet (CE) 2.0 set of standards has stringent requirements
to the bandwidth prole enforcement at the user-to-network interfaces (UNI). MEF CE 2.0 cercaon
compliance allows only a 2 percent deviaon from UNI commied or peak rate across all frame sizes.
This means that the policers should take into account the frame size at the UNI interface, including
frame checksum and excluding all addional overheads that might be added inside the service provider
network (such as S-VLANs).
In order to address the MEF CE 2.0 stringent requirements to the bandwidth prole, policer-overhead
adjustment is dened on a per IFL or direcon granularity. The policer-overhead adjustment is in the range
of -16 bytes to +16 bytes and is applied for all the policers that take into account Layer 1/ Layer 2
(L1/L2) packet length in the specied IFL or direcon, including corresponding logical interface family
(IFF) feature policers.
To congure the policer-overhead:
19
1. At the [edit interfaces] hierarchy level in conguraon mode, create the interface on which to add
the policer-overhead to input or output trac.
[edit interfaces]
user@host# edit interfaces
interface name
For example:
[edit interfaces
interface name
]
user@host# edit xe-0/1/6
2. Create the unit on which to add the policer overhead.
[edit interfaces unit]
[edit interfaces
interface name
unit
unit-number
]
For example:
[edit interfaces unit]
user@host# edit xe-0/1/6 unit 0
3. Congure the policer-overhead for the ingress policer.
[edit interfaces
interface name
unit
unit-number
]
user@host# set policer-overhead ingress
value in bytes (-16..+16 bytes)
For example:
[edit xe-0/1/6 unit 0]
user@host# set policer-overhead ingress 10;
4. Congure the policer-overhead for the egress policer.
user@host# set policer-overhead egress
value in bytes (-16..+16 bytes)
20
[edit xe-0/1/6 unit 0]
user@host# set policer-overhead egress 10;
5. Verify the conguraon.
[edit interfaces]
user@host# show interfaces xe-0/1/6
xe-0/1/6 {
unit 0 {
policer-overhead {
ingress 10;
egress 10;
}
}
}
user@host>show interfaces xe-0/1/6
Physical interface: xe-0/1/6, Enabled, Physical link is Up
Interface index: 161, SNMP ifIndex: 544
Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode, Speed: 10Gbps, BPDU Error:
None, MAC-REWRITE Error: None,
Loopback: None, Source filtering: Disabled, Flow control: Enabled
Pad to minimum frame size: Disabled
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Schedulers : 0
Current address: 00:23:9c:fc:a8:58, Hardware address: 00:23:9c:fc:a8:58
Last flapped : 2015-09-13 20:12:36 PDT (14:21:57 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Active alarms : None
Active defects : None
PCS statistics Seconds
Bit errors 0
Errored blocks 0
Link Degrade :
Link Monitoring : Disable
Interface transmit statistics: Disabled
Logical interface xe-0/1/6.0 (Index 339) (SNMP ifIndex 571)
21
Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Policer overhead :
Ingress policer overhead : 10 bytes
Egress policer overhead : 10 bytes
Input packets : 0
Output packets: 0
Protocol multiservice, MTU: Unlimited
Flags: Is-Primary
user@host> show interfaces xe-0/1/6.0
Logical interface xe-0/1/6.0 (Index 339) (SNMP ifIndex 571)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Policer overhead :
Ingress policer overhead : 10 bytes
Egress policer overhead : 10 bytes
Input packets : 0
Output packets: 0
Protocol multiservice, MTU: Unlimited
Flags: Is-Primary
RELATED DOCUMENTATION
policer-overhead-adjustment
Accounng of the Policer Overhead Aribute at the Interface Level | 17
Understanding Roung Policies
IN THIS SECTION
Imporng and Exporng Routes | 23
Acve and Inacve Routes | 25
Explicitly Congured Routes | 25
Dynamic Database | 25
22
For some roung plaorm vendors, the ow of routes occurs between various protocols. If, for example,
you want to congure redistribuon from RIP to OSPF, the RIP process tells the OSPF process that it
has routes that might be included for redistribuon. In Junos OS, there is not much direct interacon
between the roung protocols. Instead, there are central gathering points where all protocols install
their roung informaon. These are the main unicast roung tables inet.0 and inet6.0.
From these tables, the roung protocols calculate the best route to each desnaon and place these
routes in a forwarding table. These routes are then used to forward roung protocol trac toward a
desnaon, and they can be adversed to neighbors.
Imporng and Exporng Routes
Two terms—
import
and
export
—explain how routes move between the roung protocols and the roung
table.
• When the Roung Engine places the routes of a roung protocol into the roung table, it is
imporng
routes into the roung table.
• When the Roung Engine uses acve routes from the roung table to send a protocol adversement,
it is
exporng
routes from the roung table.
NOTE: The process of moving routes between a roung protocol and the roung table is
described always
from the point of view of the roung table
. That is, routes are
imported into
a roung table from a roung protocol and they are
exported from
a roung table to a roung
protocol. Remember this disncon when working with roung policies.
As shown in Figure 5 on page 24, you use import roung policies to control which routes are placed in
the roung table, and export roung policies to control which routes are adversed from the roung
table to neighbors.
23
Figure 5: Imporng and Exporng Routes
In general, the roung protocols place all their routes in the roung table and adverse a limited set of
routes from the roung table. The general rules for handling the roung informaon between the
roung protocols and the roung table are known as the
roung policy framework
.
The roung policy framework is composed of default rules for each roung protocol that determine
which routes the protocol places in the roung table and adverses from the roung table. The default
rules for each roung protocol are known as
default roung policies
.
You can create roung policies to preempt the default policies, which are always present. A
roung
policy
allows you to modify the roung policy framework to suit your needs. You can create and
implement your own roung policies to do the following:
• Control which routes a roung protocol places in the roung table.
• Control which acve routes a roung protocol adverses from the roung table. An
acve route
is a
route that is chosen from all routes in the roung table to reach a desnaon.
• Manipulate the route characteriscs as a roung protocol places the route in the roung table or
adverses the route from the roung table.
You can manipulate the route characteriscs to control which route is selected as the acve route to
reach a desnaon. The acve route is placed in the forwarding table and is used to forward trac
toward the route’s desnaon. In general, the acve route is also adversed to a router’s neighbors.
24
Acve and Inacve Routes
When mulple routes for a desnaon exist in the roung table, the protocol selects an acve route and
that route is placed in the appropriate roung table. For equal-cost routes, the Junos OS places mulple
next hops in the appropriate roung table.
When a protocol is exporng routes from the roung table, it exports acve routes only. This applies to
acons specied by both default and user-dened export policies.
When evaluang routes for export, the Roung Engine uses only acve routes from the roung table.
For example, if a roung table contains mulple routes to the same desnaon and one route has a
preferable metric, only that route is evaluated. In other words, an export policy does not evaluate all
routes; it evaluates only those routes that a roung protocol is allowed to adverse to a neighbor.
NOTE: By default, BGP adverses acve routes. However, you can congure BGP to adverse
inacve routes
, which go to the same desnaon as other routes but have less preferable
metrics.
Explicitly Congured Routes
An
explicitly congured route
is a route that you have congured.
Direct routes
are not explicitly
congured. They are created as a result of IP addresses being congured on an interface. Explicitly
congured routes include aggregate, generated, local, and stac routes. (An
aggregate route
is a route
that dislls groups of routes with common addresses into one route. A
generated route
is a route used
when the roung table has no informaon about how to reach a parcular desnaon. A
local route
is
an IP address assigned to a router interface. A
stac route
is an unchanging route to a desnaon.)
The policy framework soware treats direct and explicitly congured routes as if they are learned
through roung protocols; therefore, they can be imported into the roung table. Routes cannot be
exported from the roung table to the pseudoprotocol, because this protocol is not a real roung
protocol. However, aggregate, direct, generated, and stac routes can be exported from the roung
table to roung protocols, whereas local routes cannot.
Dynamic Database
In Junos OS Release 9.5 and later, you can congure roung policies and certain roung policy objects in
a dynamic database that is not subject to the same vericaon required by the standard conguraon
database. As a result, you can quickly commit these roung policies and policy objects, which can be
referenced and applied in the standard conguraon as needed. BGP is the only protocol to which you
can apply roung policies that reference policies congured in the dynamic database. Aer a roung
policy based on the dynamic database is congured and commied in the standard conguraon, you
can quickly make changes to exisng roung policies by modifying policy objects in the dynamic
25
database. Because Junos OS does not validate conguraon changes to the dynamic database, when
you use this feature, you should test and verify all conguraon changes before comming them.
RELATED DOCUMENTATION
Example: Conguring Dynamic Roung Policies
Protocol Support for Import and Export Policies
Table 3: Protocol Support for Import and Export Policies
Protocol Import Policy Export Policy Supported Levels
BGP Yes Yes Import: global, group, peer
Export: global, group, peer
DVMRP Yes Yes Global
IS-IS Yes Yes Export: global
LDP Yes Yes Global
MPLS No No –
OSPF Yes Yes Export: global
Import: external routes
only
PIM dense mode Yes Yes Global
PIM sparse mode Yes Yes Global
26
Table 3: Protocol Support for Import and Export Policies
(Connued)
Protocol Import Policy Export Policy Supported Levels
Pseudoprotocol—Explicitly congured
routes, which include the following:
• Aggregate routes
• Generated routes
Yes No Import: global
RIP and RIPng Yes Yes Import: global, neighbor
Export: group
Example: Applying Roung Policies at Dierent Levels of the BGP
Hierarchy
IN THIS SECTION
Requirements | 27
Overview | 28
Conguraon | 30
Vericaon | 36
This example shows BGP congured in a simple network topology and explains how roung polices take
eect when they are applied at dierent levels of the BGP conguraon.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
27
Overview
IN THIS SECTION
Topology | 29
For BGP, you can apply policies as follows:
• BGP global import and export statements—Include these statements at the [edit protocols bgp]
hierarchy level (for roung instances, include these statements at the [edit routing-instances
routing-
instance-name
protocols bgp] hierarchy level).
• Group import and export statements—Include these statements at the [edit protocols bgp group
group-
name
] hierarchy level (for roung instances, include these statements at the [edit routing-instances
routing-instance-name
protocols bgp group
group-name
] hierarchy level).
• Peer import and export statements—Include these statements at the [edit protocols bgp group
group-name
neighbor
address
] hierarchy level (for roung instances, include these statements at the [edit routing-
instances
routing-instance-name
protocols bgp group
group-name
neighbor
address
] hierarchy level).
A peer-level import or export statement overrides a group import or export statement. A group-level import
or export statement overrides a global BGP import or export statement.
In this example, a policy named send-direct is applied at the global level, another policy named
send-192.168.0.1 is applied at the group level, and a third policy named send-192.168.20.1 is applied at the
neighbor level.
user@host# show protocols
bgp {
local-address 172.16.1.1;
export send-direct;
group internal-peers {
type internal;
export send-192.168.0.1;
neighbor 172.16.2.2 {
export send-192.168.20.1;
}
neighbor 172.16.3.3;
}
group other-group {
28
type internal;
neighbor 172.16.4.4;
}
}
A key point, and one that is oen misunderstood and that can lead to problems, is that in such a
conguraon, only the most explicit policy is applied. A neighbor-level policy is more explicit than a
group-level policy, which in turn is more explicit than a global policy.
The neighbor 172.16.2.2 is subjected only to the send-192.168.20.1 policy. The neighbor 172.16.3.3,
lacking anything more specic, is subjected only to the send-192.168.0.1 policy. Meanwhile, neighbor
172.16.4.4 in group other-group has no group or neighbor-level policy, so it uses the send-direct policy.
If you need to have neighbor 172.16.2.2 perform the funcon of all three policies, you can write and
apply a new neighbor-level policy that encompasses the funcons of the other three, or you can apply
all three exisng policies, as a chain, to neighbor 172.16.2.2.
Topology
Figure 6 on page 29 shows the sample network.
Figure 6: Applying Roung Policies to BGP
"CLI Quick Conguraon" on page 30 shows the conguraon for all of the devices in Figure 6 on page
29.
The secon "No Link Title" on page 32 describes the steps on Device R1.
29
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 30
Procedure | 32
Results | 34
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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.10.10.1/30
set interfaces lo0 unit 0 family inet address 172.16.1.1/32
set protocols bgp local-address 172.16.1.1
set protocols bgp export send-direct
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers export send-static-192.168.0
set protocols bgp group internal-peers neighbor 172.16.2.2 export send-static-192.168.20
set protocols bgp group internal-peers neighbor 172.16.3.3
set protocols bgp group other-group type internal
set protocols bgp group other-group neighbor 172.16.4.4
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set policy-options policy-statement send-static-192.168.0 term 1 from protocol static
set policy-options policy-statement send-static-192.168.0 term 1 from route-filter
192.168.0.0/24 orlonger
set policy-options policy-statement send-static-192.168.0 term 1 then accept
set policy-options policy-statement send-static-192.168.20 term 1 from protocol static
set policy-options policy-statement send-static-192.168.20 term 1 from route-filter
192.168.20.0/24 orlonger
set policy-options policy-statement send-static-192.168.20 term 1 then accept
30
set routing-options static route 192.168.0.1/32 discard
set routing-options static route 192.168.20.1/32 discard
set routing-options router-id 172.16.1.1
set routing-options autonomous-system 17
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.10.10.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.10.10.5/30
set interfaces lo0 unit 0 family inet address 172.16.2.2/32
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 172.16.2.2
set protocols bgp group internal-peers neighbor 172.16.3.3
set protocols bgp group internal-peers neighbor 172.16.1.1
set protocols bgp group internal-peers neighbor 172.16.4.4
set protocols ospf area 0.0.0.0 interface lo0.0 passive
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 routing-options router-id 172.16.2.2
set routing-options autonomous-system 17
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.10.10.6/30
set interfaces fe-1/2/2 unit 0 description to-R4
set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.9/30
set interfaces lo0 unit 0 family inet address 172.16.3.3/32
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 172.16.3.3
set protocols bgp group internal-peers neighbor 172.16.2.2
set protocols bgp group internal-peers neighbor 172.16.1.1
set protocols bgp group internal-peers neighbor 172.16.4.4
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/1.0
set protocols ospf area 0.0.0.0 interface fe-1/2/2.0
set routing-options router-id 172.16.3.3
set routing-options autonomous-system 17
31
Device R4
set interfaces fe-1/2/2 unit 0 description to-R3
set interfaces fe-1/2/2 unit 0 family inet address 10.10.10.10/30
set interfaces lo0 unit 0 family inet address 172.16.4.4/32
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 172.16.4.4
set protocols bgp group internal-peers neighbor 172.16.2.2
set protocols bgp group internal-peers neighbor 172.16.1.1
set protocols bgp group internal-peers neighbor 172.16.3.3
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/2.0
set routing-options router-id 172.16.4.4
set routing-options autonomous-system 17
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure an IS-IS default route policy:
1. Congure the device interfaces.
[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.10.10.1/30
user@R1# set lo0 unit 0 family inet address 172.16.1.1/32
2. Enable OSPF, or another interior gateway protocols (IGP), on the interfaces.
[edit protocols OSPF area 0.0.0.0]
user@R1# set interface lo0.0 passive
user@R1# set interface fe-1/2/0.0
32
3. Congure stac routes.
[edit routing-options]
user@R1# set static route 192.168.0.1/32 discard
user@R1# set static route 192.168.20.1/32 discard
4. Enable the roung policies.
[edit protocols policy-options]
user@R1# set policy-statement send-direct term 1 from protocol direct
user@R1# set policy-statement send-direct term 1 then accept
user@R1# set policy-statement send-static-192.168.0 term 1 from protocol static
user@R1# set policy-statement send-static-192.168.0 term 1 from route-filter 192.168.0.0/24
orlonger
user@R1# set policy-statement send-static-192.168.0 term 1 then accept
user@R1# set policy-statement send-static-192.168.20 term 1 from protocol static
user@R1# set policy-statement send-static-192.168.20 term 1 from route-filter 192.168.20.0/24
orlonger
user@R1# set policy-statement send-static-192.168.20 term 1 then accept
5. Congure BGP and apply the export policies.
[edit protocols bgp]
user@R1# set local-address 172.16.1.1
user@R1# set protocols bgp export send-direct
user@R1# set group internal-peers type internal
user@R1# set group internal-peers export send-static-192.168.0
user@R1# set group internal-peers neighbor 172.16.2.2 export send-static-192.168.20
user@R1# set group internal-peers neighbor 172.16.3.3
user@R1# set group other-group type internal
user@R1# set group other-group neighbor 172.16.4.4
6. Congure the router ID and autonomous system (AS) number.
[edit routing-options]
user@R1# set router-id 172.16.1.1
user@R1# set autonomous-system 17
33
7. If you are done conguring the device, commit the conguraon.
[edit]
user@R1# commit
Results
From conguraon mode, conrm your conguraon by issuing the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R1# show interfaces
fe-1/2/0 {
unit 0 {
description to-R2;
family inet {
address 10.10.10.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.1.1/32;
}
}
}
user@R1# show protocols
bgp {
local-address 172.16.1.1;
export send-direct;
group internal-peers {
type internal;
export send-static-192.168.0;
neighbor 172.16.2.2 {
export send-static-192.168.20;
}
neighbor 172.16.3.3;
34
}
group other-group {
type internal;
neighbor 172.16.4.4;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fe-1/2/0.0;
}
}
user@R1# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
policy-statement send-static-192.168.0 {
term 1 {
from {
protocol static;
route-filter 192.168.0.0/24 orlonger;
}
then accept;
}
}
policy-statement send-static-192.168.20 {
term 1 {
from {
protocol static;
route-filter 192.168.20.0/24 orlonger;
}
then accept;
35
}
}
user@R1# show routing-options
static {
route 192.168.0.1/32 discard;
route 192.168.20.1/32 discard;
}
router-id 172.16.1.1;
autonomous-system 17;
Vericaon
IN THIS SECTION
Verifying BGP Route Learning | 36
Verifying BGP Route Receiving | 38
Conrm that the conguraon is working properly.
Verifying BGP Route Learning
Purpose
Make sure that the BGP export policies are working as expected by checking the roung tables.
Acon
user@R1> show route protocol direct
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 *[Direct/0] 1d 22:19:47
> via lo0.0
36
10.10.10.0/30 *[Direct/0] 1d 22:19:47
> via fe-1/2/0.0
user@R1> show route protocol static
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.1/32 *[Static/5] 02:20:03
Discard
192.168.20.1/32 *[Static/5] 02:20:03
Discard
user@R2> show route protocol bgp
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.20.1/32 *[BGP/170] 02:02:40, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 10.10.10.1 via fe-1/2/0.0
user@R3> show route protocol bgp
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.1/32 *[BGP/170] 02:02:51, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 10.10.10.5 via fe-1/2/1.0
user@R4> show route protocol bgp
inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 10.10.10.9 via fe-1/2/2.0
10.10.10.0/30 [BGP/170] 1d 20:38:54, localpref 100, from 172.16.1.1
37
AS path: I, validation-state: unverified
> to 10.10.10.9 via fe-1/2/2.0
Meaning
On Device R1, the show route protocol direct command displays two direct routes: 172.16.1.1/32 and
10.10.10.0/30. The show route protocol static command displays two stac routes: 192.168.0.1/32 and
192.168.20.1/32.
On Device R2, the show route protocol bgp command shows that the only route that Device R2 has learned
through BGP is the 192.168.20.1/32 route.
On Device R3, the show route protocol bgp command shows that the only route that Device R3 has learned
through BGP is the 192.168.0.1/32 route.
On Device R4, the show route protocol bgp command shows that the only routes that Device R4 has
learned through BGP are the 172.16.1.1/32 and 10.10.10.0/30 routes.
Verifying BGP Route Receiving
Purpose
Make sure that the BGP export policies are working as expected by checking the BGP routes received
from Device R1.
Acon
user@R2> show route receive-protocol bgp 172.16.1.1
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.168.20.1/32 172.16.1.1 100 I
user@R3> show route receive-protocol bgp 172.16.1.1
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
38
Prefix Nexthop MED Lclpref AS path
* 192.168.0.1/32 172.16.1.1 100 I
user@R4> show route receive-protocol bgp 172.16.1.1
inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
172.16.1.1/32 172.16.1.1 100 I
10.10.10.0/30 172.16.1.1 100 I
Meaning
On Device R2, the route receive-protocol bgp 172.16.1.1 command shows that Device R2 received only one
BGP route, 192.168.20.1/32, from Device R1.
On Device R3, the route receive-protocol bgp 172.16.1.1 command shows that Device R3 received only one
BGP route, 192.168.0.1/32, from Device R1.
On Device R4, the route receive-protocol bgp 172.16.1.1 command shows that Device R4 received two BGP
routes, 172.16.1.1/32 and 10.10.10.0/30, from Device R1.
In summary, when mulple policies are applied at dierent CLI hierarchies in BGP, only the most specic
applicaon is evaluated, to the exclusion of other, less specic policy applicaons. Although this point
might seem to make sense, it is easily forgoen during router conguraon, when you mistakenly
believe that a neighbor-level policy is combined with a global or group-level policy, only to nd that your
policy behavior is not as ancipated.
RELATED DOCUMENTATION
Example: Conguring Policy Chains and Route Filters | 259
Example: Conguring a Policy Subroune | 291
Example: Conguring Roung Policy Prex Lists | 398
export
import
39
Default Roung Policies
IN THIS SECTION
OSPF and IS-IS Import Policies | 42
Automac Export | 43
If an incoming or outgoing route or packet arrives and there is no explicitly congured policy related to
the route or to the interface upon which the packet arrives, the acon specied by the default policy is
taken. A
default policy
is a rule or a set of rules that determine whether the route is placed in or
adversed from the roung table, or whether the packet is accepted into or transmied from the router
interface.
You must be familiar with the default roung policies to know when you need to modify them to suit
your needs. Table 4 on page 40 summarizes the default roung policies for each roung protocol that
imports and exports routes. The acons in the default roung policies are taken if you have not explicitly
congured a roung policy. This table also shows direct and explicitly congured routes, which for the
purposes of this table are considered a pseudoprotocol. Explicitly congured routes include aggregate,
generated, and stac routes.
NOTE: On PTX Series Packet Transport Routers, the default BGP roung policy diers from that
of other Junos OS roung devices. See Understanding the Default BGP Roung Policy on Packet
Transport Routers (PTX Series).
Table 4: Default Import and Export Policies for Protocols
Imporng or Exporng
Protocol
Default Import Policy Default Export Policy
BGP Accept all received BGP IPv4 routes
learned from congured neighbors and
import into the inet.0 roung table.
Accept all received BGP IPv6 routes
learned from congured neighbors and
import into the inet6.0 roung table.
Readverse all acve BGP routes to all
BGP speakers, while following protocol-
specic rules that prohibit one IBGP
speaker from readversing routes
learned from another IBGP speaker,
unless it is funconing as a route
reector.
40
Table 4: Default Import and Export Policies for Protocols
(Connued)
Imporng or Exporng
Protocol
Default Import Policy Default Export Policy
DVMRP Accept all DVMRP routes and import
into the inet.1 roung table.
Accept and export acve DVMRP
routes.
IGMP Import: accept all groups (regardless of
being aached to an interface). In
IGMP, there is no "export" from the
roung table into IGMP.
IS-IS Accept all IS-IS routes and import into
the inet.0 and inet6.0 roung tables.
More informaon is available here:
import (Protocols IS-IS)
Reject everything. (The protocol uses
ooding to announce local routes and
any learned routes.)
LDP Accept all LDP routes and import into
the inet.3 roung table.
Reject everything.
MPLS Accept all MPLS routes and import into
the inet.3 roung table.
Accept and export acve MPLS routes.
OSPF Accept all OSPF routes and import into
the inet.0 roung table. (You cannot
override or change this default policy.)
Reject everything. (The protocol uses
ooding to announce local routes and
any learned routes.)
PIM dense mode Accept all PIM dense mode routes and
import into the inet.1 roung table.
Accept acve PIM dense mode routes.
PIM sparse mode Accept all PIM sparse mode routes and
import into the inet.1 roung table.
Accept and export acve PIM sparse
mode routes.
41
Table 4: Default Import and Export Policies for Protocols
(Connued)
Imporng or Exporng
Protocol
Default Import Policy Default Export Policy
Pseudoprotocol:
• Direct routes
• Explicitly congured
routes:
• Aggregate routes
• Generated routes
•
Stac routes
Accept all direct and explicitly
congured routes and import into the
inet.0 roung table.
The pseudoprotocol cannot export any
routes from the roung table because it
is not a roung protocol.
Roung protocols can export these or
any routes from the roung table.
RIP Accept all RIP routes learned from
congured neighbors and import into
the inet.0 roung table.
Reject everything. To export RIP routes,
you must congure an export policy for
RIP.
RIPng Accept all RIPng routes learned from
congured neighbors and import into
the inet6.0 roung table.
Reject everything. To export RIPng
routes, you must congure an export
policy for RIPng.
Test policy Accept all routes. For addional informaon about test policy, see "Example:
Tesng a Roung Policy with Complex Regular Expressions" on page 762.
OSPF and IS-IS Import Policies
For OSPF, import policies apply to external routes only. An external route is a route that is outside the
OSPF autonomous system (AS). For internal routes (routes learned from OSPF), you cannot change the
default import policy for OSPF. As link-state protocols, IS-IS and OSPF exchange routes between
systems within an autonomous system (AS). All routers and systems within an AS must share the same
link-state database, which includes routes to reachable prexes and the metrics associated with the
prexes. If an import policy is congured and applied to IS-IS or OSPF, some routes might not be learned
or adversed or the metrics for learned routes might be altered, which would make a consistent link-
state database impossible.
The default export policy for IS-IS and OSPF protocols is to reject everything. These protocols do not
actually export their internally learned routes (the directly connected routes on interfaces that are
42
running the protocol). Both IS-IS and OSPF protocols use a procedure called ooding to announce local
routes and any routes learned by the protocol. The ooding procedure is internal to the protocol, and is
unaected by the policy framework. Exporng can be used only to announce informaon from other
protocols, and the default is not to do so.
Automac Export
For Layer 3 VPNs, the automac export feature can be congured to overcome the limitaon of local
prex leaking and automacally export routes between local VPN roung and forwarding (VRF) roung
instances.
In Layer 3 VPNs, mulple CE routers can belong to a single VRF roung instance on a PE router. A PE
router can have mulple VRF roung instances. In some cases, shared services might require routes to
be wrien to mulple VRF roung tables, both at the local and remote PE router. This requires the PE
router to share route informaon among each congured VRF roung instance. This exchange of route
informaon is accomplished with custom vrf-export and vrf-import policies that ulize BGP extended
community aributes to create hub-and-spoke topologies. This exchange of roung informaon, such as
route prexes, is known as prex leaking.
The automac export feature leaks prexes between VRF roung instances that are locally congured
on a given PE router. The automac export feature is enabled by using the auto-export statement.
Automac export is always applied on the local PE router, because it takes care of only local prex
leaking by evaluang the export policy of each VRF and determining which route targets can be leaked
locally. The standard VRF import and export policies sll aect only the remote PE prex leaking.
If the vrf-export policy examined by the automac export does not have an explicit then accept acon, the
automac export essenally ignores the policy and, therefore, does not leak the route targets specied
within it.
RELATED DOCUMENTATION
Protocol Support for Import and Export Policies | 26
Technology Overview: Understanding the Auto Export Feature
43
Example: Conguring a Condional Default Route Policy
IN THIS SECTION
Requirements | 44
Overview | 44
Conguraon | 45
Vericaon | 50
This example shows how to congure a condional default route on one roung device and redistribute
the default route into OSPF.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 45
In this example, OSPF area 0 contains three roung devices. Device R3 has a BGP session with an
external peer, for example, an Internet Service Provider (ISP).
To propagate a stac route into BGP, this example includes the discard statement when dening the
route. The ISP injects a default stac route into BGP, which provides the customer network with a
default stac route to reach external networks. The stac route has a discard next hop. This means that
if a packet does not match a more specic route, the packet is rejected and a reject route for this
desnaon is installed in the roung table, but Internet Control Message Protocol (ICMP) unreachable
messages are not sent. The discard next hop allows you to originate a summary route, which can be
adversed through dynamic roung protocols.
Device R3 exports the default route into OSPF. The route policy on Device R3 is condional such that if
the connecon to the ISP goes down, the default route is no longer exported into OSPF because it is no
44
longer acve in the roung table. This policy prevents packets from being silently dropped without
nocaon (also known as null-route ltering).
This example shows the conguraon for all of the devices and the step-by-step conguraon on
Device R3.
Topology
Figure 7 on page 45 shows the sample network.
Figure 7: OSPF with a Condional Default Route to an ISP
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 46
Procedure | 47
Results | 49
45
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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 R1->R3
set interfaces fe-1/2/0 unit 0 family inet address 10.0.1.2/30
set interfaces fe-1/2/1 unit 2 description R1->R2
set interfaces fe-1/2/1 unit 2 family inet address 10.0.0.1/30
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.2
Device R2
set interfaces fe-1/2/0 unit 1 description R2->R1
set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.2/30
set interfaces fe-1/2/1 unit 4 description R2->R3
set interfaces fe-1/2/1 unit 4 family inet address 10.0.2.2/30
set protocols ospf area 0.0.0.0 interface fe-1/2/0.1
set protocols ospf area 0.0.0.0 interface fe-1/2/1.4
Device R3
set interfaces fe-1/2/0 unit 3 description R3->R2
set interfaces fe-1/2/0 unit 3 family inet address 10.0.2.1/30
set interfaces fe-1/2/1 unit 5 description R3->R1
set interfaces fe-1/2/1 unit 5 family inet address 10.0.1.1/30
set interfaces ge-0/0/2 unit 0 description R3->ISP
set interfaces ge-0/0/2 unit 0 family inet address 10.0.45.2/30
set protocols bgp group ext type external
set protocols bgp group ext peer-as 64500
set protocols bgp group ext neighbor 10.0.45.1
set protocols ospf export gendefault
set protocols ospf area 0.0.0.0 interface fe-1/2/1.4
set protocols ospf area 0.0.0.0 interface fe-1/2/0.3
set policy-options policy-statement gendefault term upstreamroutes from protocol bgp
set policy-options policy-statement gendefault term upstreamroutes from as-path upstream
set policy-options policy-statement gendefault term upstreamroutes from route-filter 0.0.0.0/0
46
upto /16
set policy-options policy-statement gendefault term upstreamroutes then next-hop 10.0.45.1
set policy-options policy-statement gendefault term upstreamroutes then accept
set policy-options policy-statement gendefault term end then reject
set policy-options as-path upstream "^64500 "
set routing-options autonomous-system 64501
Device ISP
set interfaces ge-0/0/2 unit 0 family inet address 10.0.45.1/30
set protocols bgp group ext type external
set protocols bgp group ext export advertise-default
set protocols bgp group ext peer-as 64501
set protocols bgp group ext neighbor 10.0.45.2
set policy-options policy-statement advertise-default term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement advertise-default term 1 then accept
set routing-options static route 0.0.0.0/0 discard
set routing-options autonomous-system 64500
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R3:
1. Congure the interfaces.
[edit interfaces]
user@R3# set fe-1/2/0 unit 3 description R3->R2
user@R3# set fe-1/2/0 unit 3 family inet address 10.0.2.1/30
user@R3# set fe-1/2/1 unit 5 description R3->R1
user@R3# set fe-1/2/1 unit 5 family inet address 10.0.1.1/30
user@R3# set ge-0/0/2 unit 0 description R3->ISP
user@R3# set ge-0/0/2 unit 0 family inet address 10.0.45.2/30
47
2. Congure the autonomous system (AS) number.
[edit routing-options]
user@R3# set autonomous-system 64501
3. Congure the BGP session with the ISP device.
[edit protocols bgp group ext]
user@R3# set type external
user@R3# set peer-as 64500
user@R3# set neighbor 10.0.45.1
4. Congure OSPF.
[edit protocols ospf area 0.0.0.0]
user@R3# set interface fe-1/2/1.4
user@R3# set interface fe-1/2/0.3
5. Congure the roung policy.
[edit policy-options policy-statement gendefault]
user@R3# set term upstreamroutes from protocol bgp
user@R3# set term upstreamroutes from as-path upstream
user@R3# set term upstreamroutes from route-filter 0.0.0.0/0 upto /16
user@R3# set term upstreamroutes then next-hop 10.0.45.1
user@R3# set term upstreamroutes then accept
user@R3# set term end then reject
[edit policy-options]
user@R3# set as-path upstream "^64500 "
6. Apply the export policy to OSPF.
[edit protocols ospf]
user@R3# set export gendefault
48
7. If you are done conguring the device, commit the conguraon.
[edit]
user@R3# commit
Results
Conrm your conguraon by issuing the show command. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R3# show
interfaces {
fe-1/2/0 {
unit 3 {
description R3->R2;
family inet {
address 10.0.2.1/30;
}
}
}
fe-1/2/1 {
unit 5 {
description R3->R1;
family inet {
address 10.0.1.1/30;
}
}
}
ge-1/2/0 {
unit 0 {
description R3->ISP;
family inet {
address 10.0.45.2/30;
}
}
}
}
protocols {
bgp {
group ext {
type external;
49
peer-as 64500;
neighbor 10.0.45.1;
}
}
ospf {
export gendefault;
area 0.0.0.0 {
interface fe-1/2/1.4;
interface fe-1/2/0.3;
}
}
}
policy-options {
policy-statement gendefault {
term upstreamroutes {
from {
protocol bgp;
as-path upstream;
route-filter 0.0.0.0/0 upto /16;
}
then {
next-hop 10.0.45.1;
accept;
}
}
term end {
then reject;
}
}
as-path upstream "^64500 ";
}
routing-options {
autonomous-system 64501;
}
Vericaon
IN THIS SECTION
Verifying That the Route to the ISP Is Working | 51
50
Verifying That the Stac Route Is Redistributed | 51
Tesng the Policy Condion | 53
Conrm that the conguraon is working properly.
Verifying That the Route to the ISP Is Working
Purpose
Make sure connecvity is established between Device R3 and the ISP’s router.
Acon
user@R3> ping 10.0.45.1
PING 10.0.45.1 (10.0.45.1): 56 data bytes
64 bytes from 10.0.45.1: icmp_seq=0 ttl=64 time=1.185 ms
64 bytes from 10.0.45.1: icmp_seq=1 ttl=64 time=1.199 ms
64 bytes from 10.0.45.1: icmp_seq=2 ttl=64 time=1.186 ms
Meaning
The ping command conrms reachability.
Verifying That the Stac Route Is Redistributed
Purpose
Make sure that the BGP policy is redistribung the stac route into Device R3’s roung table. Also make
sure that the OSPF policy is redistribung the stac route into the roung tables of Device R1 and
Device R2.
Acon
user@R3> show route protocol bgp
inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
51
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:00:25, localpref 100
AS path: 64500 I
> to 10.0.45.1 via ge-0/0/2.6
user@R1> show route protocol ospf
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 00:03:58, metric 0, tag 0
> to 10.0.1.1 via fe-1/2/0.0
10.0.2.0/30 *[OSPF/10] 03:37:45, metric 2
to 10.0.1.1 via fe-1/2/0.0
> to 10.0.0.2 via fe-1/2/1.2
172.16.233.5/32 *[OSPF/10] 03:38:41, metric 1
MultiRecv
user@R2> show route protocol ospf
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 00:04:04, metric 0, tag 0
> to 10.0.2.1 via fe-1/2/1.4
10.0.1.0/30 *[OSPF/10] 03:37:46, metric 2
to 10.0.0.1 via fe-1/2/0.1
> to 10.0.2.1 via fe-1/2/1.4
172.16.233.5/32 *[OSPF/10] 03:38:47, metric 1
MultiRecv
Meaning
The roung tables contain the default 0.0.0.0/0 route. If Device R1 and Device R2 receive packets
desned for networks not specied in their roung tables, those packets will be sent to Device R3 for
further processing. If Device R3 receives packets desned for networks not specied in its roung table,
those packets will be sent to the ISP for further processing.
52
Tesng the Policy Condion
Purpose
Deacvate the interface to make sure that the route is removed from the roung tables if the external
network becomes unreachable.
Acon
user@R3> deactivate interfaces ge-0/0/2 unit 0 family inet address 10.0.45.2/30
user@R3> commit
user@R1> show route protocol ospf
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.2.0/30 *[OSPF/10] 03:41:48, metric 2
to 10.0.1.1 via fe-1/2/0.0
> to 10.0.0.2 via fe-1/2/1.2
172.16.233.5/32 *[OSPF/10] 03:42:44, metric 1
MultiRecv
user@R2> show route protocol ospf
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/30 *[OSPF/10] 03:42:10, metric 2
to 10.0.0.1 via fe-1/2/0.1
> to 10.0.2.1 via fe-1/2/1.4
172.16.233.5/32 *[OSPF/10] 03:43:11, metric 1
MultiRecv
Meaning
The roung tables on Device R1 and Device R2 do not contain the default 0.0.0.0/0 route. This veries
that the default route is no longer present in the OSPF domain. To reacvate the ge-0/0/2.6 interface,
issue the activate interfaces ge-0/0/2 unit 0 family inet address 10.0.45.2/30 conguraon mode command.
53
CHAPTER 2
Evaluang Roung Policies Using Match Condions,
Acons, Terms, and Expressions
IN THIS CHAPTER
How a Roung Policy Is Evaluated | 54
Categories of Roung Policy Match Condions | 56
Roung Policy Match Condions | 58
Route Filter Match Condions | 72
Acons in Roung Policy Terms | 75
Summary of Roung Policy Acons | 93
Example: Conguring a Roung Policy to Adverse the Best External Route to Internal Peers | 96
Example: Conguring BGP to Adverse Inacve Routes | 108
Example: Using Roung Policy to Set a Preference Value for BGP Routes | 119
Example: Enabling BGP Route Adversements | 127
Example: Rejecng Known Invalid Routes | 138
Example: Using Roung Policy in an ISP Network | 142
Understanding Policy Expressions | 205
Understanding Backup Selecon Policy for OSPF Protocol | 211
Conguring Backup Selecon Policy for the OSPF Protocol | 212
Conguring Backup Selecon Policy for IS-IS Protocol | 220
Example: Conguring Backup Selecon Policy for the OSPF or OSPF3 Protocol | 222
How a Roung Policy Is Evaluated
Figure 8 on page 55 shows how a single roung policy is evaluated. This roung policy consists of
mulple terms. Each term consists of match condions and acons to apply to matching routes. Each
route is evaluated against the policy as follows:
54
1. The route is evaluated against the rst term. If it matches, the specied acon is taken. If the acon
is to accept or reject the route, that acon is taken and the evaluaon of the route ends. If the next
term acon is specied, if no acon is specied, or if the route does not match, the evaluaon
connues as described in Step 2. If the next policy acon is specied, any accept or reject acon
specied in this term is skipped, all remaining terms in this policy are skipped, all other acons are
taken, and the evaluaon connues as described in Step 3.
2. The route is evaluated against the second term. If it matches, the specied acon is taken. If the
acon is to accept or reject the route, that acon is taken and the evaluaon of the route ends. If the
next term acon is specied, if no acon is specied, or if the route does not match, the evaluaon
connues in a similar manner against the last term. If the next policy acon is specied, any accept or
reject acon specied in this term is skipped, all remaining terms in this policy are skipped, all other
acons are taken, and the evaluaon connues as described in Step 3.
3. If the route matches no terms in the roung policy or the next policy acon is specied, the accept or
reject acon specied by the default policy is taken. For more informaon about the default roung
policies, see "Default Roung Policies" on page 40.
Figure 8: Roung Policy Evaluaon
Each term can consist of two statements, from and to, that dene match condions:
In the from statement, you dene the criteria that an incoming route must match. You can specify one or
more match condions. If you specify more than one, all condions must match the route for a match to
occur.
In the to statement, you dene the criteria that an outgoing route must match. You can specify one or
more match condions. If you specify more than one, all condions must match the route for a match to
occur.
55
The order of match condions in a term is not important, because a route must match all match
condions in a term for an acon to be taken.
Categories of Roung Policy Match Condions
A
match condion
denes the criteria that a route must match. You can dene one or more match
condions. If a route matches all match condions, one or more acons are applied to the route.
Match condions fall into two categories: standard and extended. In general, the extended match
condions are more complex than standard match condions. The extended match condions provide
many powerful capabilies. The standard match condions include criteria that are dened within a
roung policy and are less complex than the extended match condions, also called named match
condions.
Extended match condions are dened separately from the roung policy and are given names. You
then reference the name of the match condion in the denion of the roung policy itself.
Named match condions allow you to do the following:
• Reuse match condions in other roung policies.
• Read conguraons that include complex match condions more easily.
Named match condions include communies, prex lists, and AS path regular expressions.
Table 5 on page 56 describes each match condion, including its category, when you typically use it,
and any relevant notes about it. For more informaon about match condions, see "Roung Policy
Match Condions" on page 58.
Table 5: Match
Condion Concepts
Match Condion Category When to Use Notes
AS path regular expression—
A combinaon of AS
numbers and regular
expression operators.
Extended (BGP only) Match a route based on its AS
path. (An AS path consists of the AS
numbers of all routers a packet must go
through to reach a desnaon.) You can
specify an exact match with a parcular
AS path or a less precise match.
You use regular
expressions to match
the AS path.
56
Table 5: Match Condion Concepts
(Connued)
Match Condion Category When to Use Notes
Community—A group of
desnaons that share a
property. (Community
informaon is included as a
path aribute in BGP update
messages.)
Extended Match a group of desnaons that share a
property. Use a roung policy to dene a
community that species a group of
desnaons you want to match and one
or more acons that you want taken on
this community.
Acons can be
performed on the enre
group.
You can create mulple
communies associated
with a parcular
desnaon.
You can create match
condions using regular
expressions.
Prex list—A named list of IP
addresses.
Extended Match a route based on prex
informaon. You can specify an exact
match of a parcular route only.
You can specify a
common acon only for
all prexes in the list.
Route list—A list of
desnaon prexes.
Extended Match a route based on prex
informaon. You can specify an exact
match of a parcular route or a less
precise match.
You can specify an
acon for each prex in
the route list or a
common acon for all
prexes in the route list.
Standard—A collecon of
criteria that can match a
route.
Standard Match a route based on one of the
following criteria: area ID, color, external
route, family, instance (roung), interface
name, level number, local preference,
metric, neighbor address, next-hop
address, origin, preference, protocol,
roung table name, or tag.
You can specify a match condion for
policies based on protocols by naming a
protocol from which the route is learned
or to which the route is being adversed.
None.
57
Table 5: Match Condion Concepts
(Connued)
Match Condion Category When to Use Notes
Subroune—A roung policy
that is called repeatedly from
another roung policy.
Extended Use an eecve roung policy in other
roung policies. You can create a
subroune that you can call over and over
from other roung policies.
The subroune acon
inuences but does not
necessarily determine
the nal acon. For
more informaon, see
"How a Roung Policy
Subroune Is Evaluated"
on page 288.
Each term can consist of two statements, from and to, that dene match condions:
• In the from statement, you dene the criteria that an
incoming
route must match. You can specify one
or more match condions. If you specify more than one, all condions must match the route for a
match to occur.
• In the to statement, you dene the criteria that an
outgoing
route must match. You can specify one or
more match condions. If you specify more than one, all condions must match the route for a match
to occur.
The order of match condions in a term is not important, because a route must match all match
condions in a term for an acon to be taken.
RELATED DOCUMENTATION
Roung Policy Match Condions | 58
Roung Policy Match Condions
Each term in a roung policy can include two statements, from and to, to dene the condions that a
route must match for the policy to apply:
from {
family
family-name
;
match-conditions
;
policy
subroutine-policy-name
;
prefix-list
name
;
58
route-filter
destination-prefix
match-type
<
actions
>;
source-address-filter
source-prefix
match-type
<
actions
>;
}
to {
match-conditions
;
policy
subroutine-policy-name
;
}
In the from statement, you dene the criteria that an incoming route must match. You can specify one or
more match condions. If you specify more than one, they all must match the route for a match to
occur.
The from statement is oponal. If you omit the from, all routes are considered to match. All routes then
take the congured acons of the policy term.
In the to statement, you dene the criteria that an outgoing route must match. You can specify one or
more match condions. If you specify more than one, they all must match the route for a match to
occur. You can specify most of the same match condions in the to statement that you can in the from
statement. In most cases, specifying a match condion in the to statement produces the same result as
specifying the same match condion in the from statement.
The to statement is oponal. If you omit both the to and the from statements, all routes are considered to
match.
Table 6 on page 59 summarizes key roung policy match condions.
Table 6: Summary of Key
Roung Policy Match Condions
Match Condion Descripon
aggregate-contributor
Matches routes that are contribung to a congured aggregate. This match
condion can be used to suppress a contributor in an aggregate route.
area
area-id
Matches a route learned from the specied OSPF area during the exporng of
OSPF routes into other protocols.
as-path
name
Matches the name of the path regular expression of an autonomous systems
(AS). BGP routes whose AS path matches the regular expression are processed.
59
Table 6: Summary of Key Roung Policy Match Condions
(Connued)
Match Condion Descripon
color
preference
Matches a color value. You can specify preference values that are ner-grained
than those specied in the
preference
match condions. The color value can be
a number from 0 through 4,294,967,295 (2
32
– 1). A lower number indicates a
more preferred route.
community
Matches the name of one or more communies. If you list more than one name,
only one name needs to match for a match to occur. (The matching is
eecvely a logical OR operaon.)
external [type
metric-type
]
Matches external OSPF routes, including routes exported from one level to
another. In this match condion, type is an oponal keyword. The metric-type
value can be either 1 or 2. When you do not specify type, this condion
matches all external routes.
interface
interface-name
Matches the name or IP address of one or more router interfaces. Use this
condion with protocols that are interface-specic. For example, do not use
this condion with internal BGP (IBGP).
Depending on where the policy is applied, this match condion matches routes
learned from or adversed through the specied interface.
internal
Matches a roung policy against the internal ag for simplied next-hop self
policies.
level
level
Matches the IS-IS level. Routes that are from the specied level or are being
adversed to the specied level are processed.
local-preference
value
Matches a BGP local preference aribute. The preference value can be from 0
through 4,294,967,295 (2
32
– 1).
metric
metric
metric2
metric
Matches a metric value. The metric value corresponds to the mulple exit
discriminator (MED), and metric2 corresponds to the IGP metric if the BGP next
hop runs back through another route.
60
Table 6: Summary of Key Roung Policy Match Condions
(Connued)
Match Condion Descripon
neighbor
address
Matches the address of one or more neighbors (peers).
For BGP export policies, the address can be for a directly connected or
indirectly connected peer. For all other protocols, the address is for the
neighbor from which the adversement is received.
next-hop
address
Matches the next-hop address or addresses specied in the roung informaon
for a parcular route. For BGP routes, matches are performed against each
protocol next hop.
origin
value
Matches the BGP origin aribute, which is the origin of the AS path
informaon. The value can be one of the following:
• egp—Path informaon originated from another AS.
• igp—Path informaon originated from within the local AS.
• incomplete—Path informaon was learned by some other means.
preference
preference
preference2
preference
Matches the preference value. You can specify a primary preference value
(preference) and a secondary preference value (preference2). The preference
value can be a number from 0 through 4,294,967,295 (2
32
– 1). A lower
number indicates a more preferred route.
NOTE: Do not set preference2 for BGP route-policy.
protocol
protocol
Matches the name of the protocol from which the route was learned or to
which the route is being adversed. It can be one of the following: aggregate,
bgp, direct, dvmrp, isis, local, ospf, pim-dense, pim-sparse, rip, ripng, or static.
route-type
value
Matches the type of route. The value can be either external or internal.
All condions in the from and to statements must match for the acon to be taken. The match condions
dened in Table 7 on page 62 are eecvely a logical AND operaon. Matching in prex lists and route
lists is handled dierently. They are eecvely a logical OR operaon. If you congure a policy that
includes some combinaon of route lters, prex lists, and source address lters, they are evaluated
according to a logical OR operaon or a longest-route match lookup.
61
Table 7 on page 62 describes the match condions available for matching an incoming or outgoing
route. The table indicates whether you can use the match condion in both from and to statements and
whether the match condion funcons the same or dierently when used with both statements. If a
match condion funcons dierently in a from statement than in a to statement, or if the condion
cannot be used in one type of statement, there is a separate descripon for each type of statement.
Otherwise, the same descripon applies to both types of statements.
Table 7 on page 62 also indicates whether the match condion is standard or extended. In general, the
extended match condions include criteria that are dened separately from the roung policy
(autonomous system [AS] path regular expressions, communies, and prex lists) and are more complex
than standard match condions. The extended match condions provide many powerful capabilies.
The standard match condions include criteria that are dened within a roung policy and are less
complex than the extended match condions.
Table 7: Complete List of Roung Policy Match Condions
Match Condion Match
Condion
Category
Statement Descripon
aggregate-
contributor
Standard Match routes that are contribung to a congured aggregate. This match
condion can be used to suppress a contributor in an aggregate route.
area
area-id
Standard (Open Shortest Path First [OSPF] only) Area idener.
In a from statement used with an export policy, match a route learned from the
specied OSPF area when exporng OSPF routes into other protocols.
as-path
name
Extended (Border Gateway Protocol [BGP] only) Name of an AS path regular expression.
For more informaon, see "Understanding AS Path Regular Expressions for
Use as Roung Policy Match Condions" on page 435.
as-path-group
group-name
Extended (BGP only) Name of an AS path group regular expression. For more
informaon, see "Understanding AS Path Regular Expressions for Use as
Roung Policy Match Condions" on page 435.
bridge-domain-id
bridge-domain-
number
Extended Bridge domain ID, VLAN ID, or (with VXLAN encapsulaon) a VXLAN virtual
network idener (VNI).
62
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
color
preference
color2
preference
Standard
Color value. You can specify preference values (color and color2) that are
ner-grained than those specied in the preference and preference2 match
condions. The color value can be a number in the range from 0
through 4,294,967,295 (2
32
– 1). A lower number indicates a more preferred
route.
community-count
value
(equal |
orhigher |
orlower)
Standard (BGP only) Number of community entries required for a route to match. The
count value can be a number in the range of 0 through 1,024. Specify one of
the following opons:
• equal—The number of communies must equal this value to be considered
a match.
• orhigher —The number of communies must be greater than or equal to
this value to be considered a match.
• orlower—The number of communies must be less than or equal to this
value to be considered a match.
NOTE: If you congure mulple community-count statements, the matching is
eecvely a logical AND operaon.
NOTE: The community-count aribute only works with standard communies. It
does not work with extended communies.
This match condion is not supported for use with the To statement.
63
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
community
[
names
]
Extended Name of one or more communies. If you list more than one name, only one
name needs to match for a match to occur (the matching is eecvely a
logical OR operaon). For more informaon, see
Understanding BGP
Communies, Extended Communies, and Large Communies as Roung
Policy Match Condions
.
BGP EVPN routes have a set of extended communies carried in the BGP
update message path aribute, and as such, you can use extended
communies for ltering BGP EVPN routes. The informaon available
includes encapsulaon type, mac-mobility informaon, EVPN split-horizon
label informaon, ESI mode, and etree leaf label.
Use the following syntax to specify BGP EVPN extended communies:
• community (type, in decimal format)
val1
:
val2
val1
and
val2
can be specied as [2 + 4] octets, or as [4 + 2] octets.
external [ type
metric-type
]
Standard
(OSPF and IS-IS only) Match IGP external routes. For IS-IS routes, the external
condion also matches routes that are exported from one IS-IS level to
another. The type keyword is oponal and is applicable only to OSPF external
routes. When you do not specify type, the external condion matches all IGP
external (OSPF and IS-IS) routes. When you specify type, the external
condion matches only OSPF external routes with the specied OSPF metric
type. The metric type can either be 1 or 2.
To match BGP external routes, use the route-type match condion.
evpn-esi
Standard You can lter BGP EVPN routes on the basis of Ethernet Segment Ideners
(ESIs) informaon for routes types 1, 2, 4, 7, and 8, which are the only types
to include the ESI aribute in their prex. (ESI values are encoded as 10-byte
integers and are used to idenfy a mulhomed segment.)
evpn-etag
Standard You can lter BGP EVPN routes on the basis of EVPN tag informaon, which
is available from the prex of the EVPN route. Requires EVPN be set in the
following CLI hierarchy:
• filter policy-options policy-statement
name
term
name
family
64
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
evpn-mac-route
Standard Filtering BGP EVPN type-2 routes based on if it has any IP address.
EVPN type-2 MAC routes can have IP address in the prex along with MAC
address. The IP address carried in the MAC-IP route can be either IPv4 or
IPv6 address. It is possible to lter out type-2 routes based on only if it has
only mac address or mac+ipv4 address or mac+ipv6 address.
interface
interface-name
Standard Name or IP address of one or more roung device interfaces. Do not use this
qualier with protocols that are not interface-specic, such as IBGP.
Match a route learned from, or to be adversed to, one of the specied
interfaces. Direct routes match routes congured on the specied interface.
level
level
Standard (Intermediate System-to-Intermediate System [IS-IS] only) IS-IS level.
Match a route learned from, or to be adversed to, a specied level.
local-preference
value
Standard
(BGP only) BGP local preference (LOCAL_PREFlocal-preference (add |
subtract)
number
) aribute. The preference value can be a number in the
range 0 through 4,294,967,295 (2
32
– 1).
mac-filter-list
Standard (BGP only) Named mac lter list. EVPN type-2 routes have mac address as
part of the prex, which you can use to create a list of MAC addresses.
65
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
multicast-scoping
(
scoping-name
|
number
) <
(orhigher |
orlower) >
Standard Mulcast scope value of IPv4 or IPv6 mulcast group address. The mulcast-
scoping name corresponds to an IPv4 prex. You can match on a specic
mulcast-scoping prex or on a range of prexes. Specify orhigher to match
on a scope and numerically higher scopes, or orlower to match on a scope and
numerically lower scopes. For more informaon, see the Junos OS Mulcast
Protocols User Guide.
You can apply this scoping policy to the roung table by including the scope-
policy statement at the [edit routing-options] hierarchy level.
The
number
value can be any hexadecimal number from 0 through F. The
mulcast-scope value is a number from 0 through 15, or one of the following
keywords with the associated meanings:
• node-local (value=1)—No corresponding prex
• link-local (value=2)—Corresponding prex 224.0.0.0/24
• site-local (value=5)—No corresponding prex
• global (value=14)—Corresponding prex 224.0.1.0 through
238.255.255.255
• organization-local (value=8)—Corresponding prex 239.192.0.0/14
neighbor
address
Standard Address of one or more neighbors (peers).
For BGP, the address can be a directly connected or indirectly connected peer.
For BGP
import
policies, specifying to neighbor produces the same result as
specifying from neighbor.
For BGP
export
policies, specifying the neighbor match condion has no eect
and is ignored.
For all other protocols, the address is the neighbor from which the
adversement is received, or for to statements, it matches the neighbor to
which the adversement is sent.
NOTE: The neighbor
address
match condion is not valid for the Roung
Informaon Protocol (RIP).
66
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
next-hop
[
addresses
]
Standard One or more next-hop addresses specied in the roung informaon for a
parcular route. A next-hop address cannot include a netmask. For BGP
routes, matches are performed against each protocol next hop.
next-hop-type
merged
Standard LDP generates a next hop based on RSVP and IP next hops available to use,
combined with forwarding-class mapping.
This match condion is not supported for use with the To statement.
nlri-route-type
Standard Route type from NLRI 1 through NLRI 10. Mulple route types can be
specied in a single policy.
For EVPN, NLRI route types range from 1 to 8 (the rst octet of the route
prex in the BGP update message is the EVPN route type).
In addion to ltering on EVPN NLRI route types, you can also lter on IP
address or MAC address (mac-ip) that is embedded in the EVPN route prex
for route types 2 and 5. To do so, use a prefix-list or route-filter for the
address.
When a type-5 route is created from a type 2 mac-ip adversement that was
learned remotely, then the community that was learned from the type-2 route
adversement is included in the new type-5 route. You can prevent this by
enabling the donot-advertise-community statement at the protocols evpn ip-
prefix-routes hierarchy.
origin
value
Standard (BGP only) BGP origin aribute, which is the origin of the AS path
informaon. The value can be one of the following:
• egp—Path informaon originated in another AS.
• igp—Path informaon originated within the local AS.
• incomplete—Path informaon was learned by some other means.
67
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
policy [
policy-
name
]
Extended Name of a policy to evaluate as a subroune.
For informaon about this extended match condion, see "Understanding
Policy Subrounes in Roung Policy Match Condions" on page 284.
preference
preference
preference2
preference
Standard
Preference value. You can specify a primary preference value (preference) and
a secondary preference value (preference2). The preference value can be a
number from 0 through 4,294,967,295 (2
32
– 1). A lower number indicates a
more preferred route.
To specify even ner-grained preference values, see the color and color2
match condions in this table.
prefix-list
prefix-list-name
ip-addresses
Extended Named list of IP addresses. You can specify an exact match with incoming
routes.
For informaon about this extended match condion, see "Understanding
Prex Lists for Use in Roung Policy Match Condions" on page 394.
This match condion is not supported for use with the To statement.
This match condion is not supported for use with the To statement.
prefix-list-filter
prefix-list-name
match-type
Extended Named prex list. You can specify prex length qualiers for the list of
prexes in the prex list.
When used with EVPN NRLI route types 2 and 5, the following are supported:
• from prefix-list-filter [ exact | longer | orlonger ]
For informaon about this extended match condion, see "Understanding
Prex Lists for Use in Roung Policy Match Condions" on page 394.
This match condion is not supported for use with the To statement.
68
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
protocol
protocol
Standard Name of the protocol from which the route was learned or to which the route
is being adversed. It can be one of the following: access, access-internal,
aggregate, anchor, arp, bgp, bgp-ls-epe,bgp-static, direct, dvmrp, esis, evpn, frr,
isis, l-isis, isis, l2-learned-host-routing, l2circuit, l2vpn, ldp, local, mpls,
msdp, ospf (matches both OSPFv2 and OSPFv3 routes), ospf2 (matches OSPFv2
routes only), ospf3 (matches OSPFv3 routes only), pim, rift, rip, ripng, route-
target, rsvp, spring-te, static, or vpls.
rib
routing-table
Standard
Name of a roung table. The value of
routing-table
can be one of the
following:
• inet.0—Unicast IPv4 routes
•
instance-name
inet.0—Unicast IPv4 routes for a parcular roung instance
• inet.1—Mulcast IPv4 routes
• inet.2—Unicast IPv4 routes for mulcast reverse-path forwarding (RPF)
lookup
•
inet.3—MPLS routes
•
mpls.0—MPLS routes for label-switched path (LSP) next hops
•
inet6.0—Unicast IPv6 routes
route-
distinguisher
Standard Name of the route-disnguisher (RD).
RD supports ltering BGP EVPN routes. The RD informaon is carried in the
prex of the EVPN route.
69
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
route-filter
route-filter-list
Standard Named route lter or route lter list. You can specify prex length qualiers
for the list of routes in the route lter list.
When used with EVPN NRLI route types 2 and 5, the following are supported:
• from route-filter [ address-mask | exact | longer | orlonger | prefix-
length-range | through | upto ]
This match condion is not supported for use with the To statement.
rtf-prefix-list
name
route-targets
Extended (BGP only) Named list of route target prexes for BGP route target ltering
and proxy BGP route target ltering.
For informaon about this extended match condion, see
Example:
Conguring an Export Policy for BGP Route Target Filtering for VPNs
.
This match condion is not supported for use with the To statement.
source-address-
filter
destination-prefix
match-type
<
actions
>
Extended List of mulcast source addresses. When specifying a source address, you can
specify an exact match with a specic route or a less precise match using
match types. You can congure either a common acon that applies to the
enre list or an acon associated with each prex. For more informaon, see
"Understanding Route Filters for Use in Roung Policy Match Condions" on
page 305.
This match condion is not supported for use with the To statement.
state (active |
inactive)
Standard (BGP export only) Match on the following types of adversed routes:
• active—An acve BGP route
• inactive—A route adversed to internal BGP peers as the best external
path even if the best path is an internal route
• inactive—A route adversed by BGP as the best route even if the roung
table did not select it to be an acve route
70
Table 7: Complete List of Roung Policy Match Condions
(Connued)
Match Condion Match
Condion
Category
Statement Descripon
tag
string
tag2
string
Standard
Tag value. You can specify two tag strings: tag (for the rst string) and tag2.
These values are local to the router and can be set on congured routes or by
using an import roung policy.
You can specify mulple tags under one match condion by including the tags
within a bracketed list. For example: from tag [ tag1 tag2 tag3 ];
For OSPF routes, thetag acon sets the 32-bit tag eld in OSPF external link-
state adversement (LSA) packets.
For IS-IS routes, the tag acon sets the 32-bit ag in the IS-IS IP prex type
length values. (TLV).
OSPF stores the INTERNAL route's OSPF area ID in thetag2 aribute.
However, for EXTERNAL routes, OSPF does not store anything in the
tag2aribute.
You can congure a policy term to set the tag2 value for a route. If the route,
already has a tag2 value (for example, an OSPF route that stores area id in
tag2), then the original tag2 value is overwrien by the new value.
When the policy contains the "from area" match condion, for internal OSPF
routes, where tag2 is set, based on the OSPF area- ID, the evaluaon is
conducted to compare the tag2 aribute with the area ID. For external OSPF
routes that do not have the tag2 aribute set, the match condion fails.
validation-
database
Standard When BGP origin validaon is congured, triggers a lookup in the route
validaon database to determine if the route prex is valid, invalid, or
unknown. The route validaon database contains route origin authorizaon
(ROA) records that map route prexes to expected originang autonomous
systems (ASs). This prevents the accidental adversement of invalid routes.
See Conguring Origin Validaon for BGP.
RELATED DOCUMENTATION
Understanding Prex Lists for Use in Roung Policy Match Condions | 394
Understanding Route Filters for Use in Roung Policy Match Condions | 305
71
Route Filter Match Condions
When specifying a desnaon prex, you can specify an exact match with a specic route, or a less
precise match by using match types. You can congure either a common reject acon that applies to the
enre list, or an acon associated with each prex.
You can specify known invalid (“bad”) routes to ignore by specifying matches on desnaon prexes.
Addionally, you can specify that “good” routes be processed in a parcular way. For instance, you can
group trac from specic source or desnaon addresses into forwarding classes to be processed using
the
class of service
(CoS) feature.
Table 8 on page 73 lists route list match types.
72
Table 8: Route List Match Types
Match Type Match Condions
address-mask
netmask-value
All of the following are true:
• The bit-wise logical AND of the
netmask-value
paern and
the incoming IPv4 or IPv6 route address and the bit-wise
logical AND of the
netmask-value
paern and the
destination-prefix
address are the same. The bits set in the
netmask-value
paern do not need to be conguous.
• The
prefix-length
component of the incoming IPv4 or IPv6
route address and the
prefix-length
component of the
destination-prefix
address are the same.
NOTE: The address-mask roung policy match type is valid only
for matching an incoming IPv4 (family inet) or IPv6 (family
inet6) route address to a list of desnaon match prexes
specied in a route-filter statement.
The address-mask roung policy match type enables you to
match an incoming IPv4 or IPv6 route address on a congured
netmask address in addion to the length of a congured
desnaon match prex. The length of the route address must
match exactly with the length of the congured desnaon
match prex, as the address-mask match type does not support
prex length variaons for a range of prex lengths.
When the longest-match lookup is performed on a route lter,
the lookup evaluates an address-mask match type dierently
from other roung policy match types. The lookup does not
consider the length of the desnaon match prex. Instead, the
lookup considers the number of conguous high-order bits set
in the netmask value.
exact
The route shares the same most-signicant bits (described by
prefix-length
), and
prefix-length
is equal to the route's prex
length.
longer
The route shares the same most-signicant bits (described by
prefix-length
), and
prefix-length
is greater than the route's
prex length.
73
Table 8: Route List Match Types
(Connued)
Match Type Match Condions
orlonger
The route shares the same most-signicant bits (described by
prefix-length
), and
prefix-length
is equal to or greater than the
route's prex length.
prefix-length-range
prefix-length2
-
prefix-
length3
The route shares the same most-signicant bits (described by
prefix-length
), and the route's prex length falls between
prefix-
length2
and
prefix-length3
, inclusive.
through
destination-prefix
All the following are true:
• The route shares the same most-signicant bits (described by
prefix-length
) of the rst desnaon prex.
• The route shares the same most-signicant bits (described by
prefix-length
) of the second desnaon prex for the
number of bits in the prex length.
• The number of bits in the route's prex length is less than or
equal to the number of bits in the second prex.
You do not use the through match type in most roung policy
conguraons.
upto
prefix-length2
The route shares the same most-signicant bits (described by
prefix-length
) and the route's prex length falls between
prefix-
length
and
prefix-length2
.
RELATED DOCUMENTATION
Categories of Roung Policy Match Condions | 56
Summary of Roung Policy Acons | 93
Example: Rejecng Known Invalid Routes | 138
Example: Grouping Source and Desnaon Prexes into a Forwarding Class | 673
74
Acons in Roung Policy Terms
IN THIS SECTION
Conguring Flow Control Acons | 76
Conguring Acons That Manipulate Route Characteriscs | 77
Conguring the Default Acon in Roung Policies | 89
Conguring a Final Acon in Roung Policies | 91
Logging Matches to a Roung Policy Term | 92
Conguring Separate Acons for Routes in Route Lists | 92
Each term in a roung policy can include a then statement, which denes the acons to take if a route
matches all the condions in the from and to statements in the term:
then {
actions
;
}
You can include this statement at the following hierarchy levels:
• [edit policy-options policy-statement
policy-name
term
term-name
]
• [edit logical-systems
logical-system-name
policy-options policy-statement
policy-name
term
term-name
]
If a term does not have from and to statements, all routes are considered to match, and the acons apply
to them all. For informaon about the from and to statements, see "Roung Policy Match Condions" on
page 58.
You can specify one or more acons in the then statement. There are three types of acons:
• Flow control acons, which aect whether to accept or reject the route and whether to evaluate the
next term or roung policy.
• Acons that manipulate route characteriscs.
• Trace acon, which logs route matches.
75
NOTE: When you specify an acon that manipulates the route characteriscs, the changes
occur in a copy of the source route. The source route itself does not change. The eect of the
acon is visible only aer the route is imported into or exported from the roung table. To
view the source route before the roung policy has been applied, use the show route receive-
protocol command. To view a route aer an export policy has been applied, use the show route
advertised-protocol command.
During policy evaluaon, the characteriscs in the copy of the source route always change
immediately aer the acon is evaluated. However, the route is not copied to the roung
table or a roung protocol unl the policy evaluaon is complete.
The then statement is oponal. If you omit it, one of the following occurs:
• The next term in the roung policy, if one is present, is evaluated.
• If there are no more terms in the roung policy, the next roung policy, if one is present, is evaluated.
• If there are no more terms or roung policies, the accept or reject acon specied by the default
policy is taken. For more informaon, see "Default Roung Policies" on page 40.
The following secons discuss these acons:
Conguring Flow Control Acons
Table 9 on page 76 lists the ow control acons. You can specify one of these acons along with the
trace acon or one or more of the acons that manipulate route characteriscs (see "Conguring
Acons That Manipulate Route Characteriscs" on page 77).
Table 9: Flow Control
Acons
Flow Control
Acon
Descripon
accept
Accept the route and propagate it. Aer a route is accepted, no other terms in the roung
policy and no other roung policies are evaluated.
default-action
accept
Accept and override any acon intrinsic to the protocol. This is a nonterminang policy acon.
reject
Reject the route and do not propagate it. Aer a route is rejected, no other terms in the roung
policy and no other roung policies are evaluated.
76
Table 9: Flow Control Acons
(Connued)
Flow Control
Acon
Descripon
default-action
reject
Reject and override any acon intrinsic to the protocol. This is a nonterminang policy acon.
next term
Skip to and evaluate the next term in the same roung policy. Any accept or reject acon
specied in the then statement is skipped. Any acons in the then statement that manipulate
route characteriscs are applied to the route.
next term is the default control acon if a match occurs and you do not specify a ow control
acon.
NOTE: On Junos OS Evolved, next term cannot appear as the last term of the acon. A lter
term where next term is specied as an acon but without any match condions congured is
not supported.
next policy Skip to and evaluate the next roung policy. Any accept or reject acon specied in the then
statement is skipped. Any acons in the then statement that manipulate route characteriscs
are applied to the route.
next policy is the default control acon if a match occurs, you do not specify a ow control
acon, and there are no further terms in the current roung policy.
sr-te-template
Segment roung-trac engineered (SR-TE) template to apply for PCE-iniated LSPs.
Conguring Acons That Manipulate Route Characteriscs
You can specify one or more of the acons listed in Table 10 on page 77 to manipulate route
characteriscs.
Table 10:
Acons That Manipulate Route Characteriscs
Acon Descripon
add-path send-count
path-
count
(BGP only) Enable sending up to 20 BGP paths to a desnaon for a subset of add-
path adversed prexes.
77
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
as-path-prepend
as-path
(BGP only) Ax one or more AS numbers at the beginning of the AS path. If
specifying more than one AS number, enclose the numbers in quotaon marks
(“ ”). The AS numbers are added aer the local AS number has been added to the
path. This acon adds AS numbers to AS sequences only, not to AS sets. If the
exisng AS path begins with a confederaon sequence or set, the axed AS
numbers are placed within a confederaon sequence. Otherwise, the axed AS
numbers are placed within a nonconfederaon sequence. For more informaon,
see "Understanding Prepending AS Numbers to BGP AS Paths" on page 459.
In Junos OS Release 9.1 and later, you can specify 4-byte AS numbers as dened
in RFC 4893,
BGP Support for Four-octet AS Number Space
, as well as the 2-byte
AS numbers that are supported in earlier releases of the Junos OS.
as-path-expand last-as count
n
(BGP only) Extract the last AS number in the exisng AS path and ax that AS
number to the beginning of the AS path
n
mes, where
n
is a number from
1 through 32.
The AS number is added before the local AS number has been added to the path.
This acon adds AS numbers to AS sequences only, not to AS sets. If the exisng
AS path begins with a confederaon sequence or set, the axed AS numbers are
placed within a confederaon sequence. Otherwise, the axed AS numbers are
placed within a non-confederaon sequence. This opon is typically used in non-
IBGP export policies.
NOTE: Starng in Junos OS Release 17.3, it is possible to commit a null
conguraon for the count value, and if so, Junos will convert the null to a 1 count
rather than a 0 count, or disallowing the commit. The eect of having your as-
path-expand count equal one is that such an
as-path
is longer, and therefore less
preferable. We recommend that you either explicitly set the as-path-expand count,
or delete the unused seng to avoid any unexpected behavior.
assisted-replication
replicator-ip
replicator-ip
(strict | fallback-
replicator-ip
fallback-
replicator-ip
)
(Assisted replicaon [AR] with opmized intersubnet mulcast [OISM] only)
Enable an AR leaf device in an EVPN network running OISM to determiniscally
steer mulcast ows to specic AR replicator devices. Oponally include the
strict opon to strictly forward matching ows only to the preferred specied AR
replicator. Or, you can include a fallback AR replicator address to use in case the
preferred AR replicator goes down. See
assisted-replicaon (Determinisc AR
Replicator Policy Acons)
for details.
78
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
bgp-output-queue-priority
(BGP only) Set the output priority queue used for this route. There are 17
priorized output queues: an expedited queue that is the highest priority, and 16
numbered queues where 1 is the lowest priority and 16 is the highest.
class
class-name
(Class of service [CoS] only) Apply the specied class-of-service parameters to
routes installed into the roung table. For more informaon, see the Junos OS
Class of Service User Guide for Roung Devices.
color
preference
color2
preference
Set the preference value to the specied value. The color and color2 preference
values are even more ne-grained than those specied in the preference and
preference2 acons. The color value can be a number in the range from 0
through 4,294,967,295 (2
32
– 1). A lower number indicates a more preferred
route.
If you set the preference with the color acon, the value is internal to Junos OS
and is not transive.
color (add | subtract)
number
color2 (add | subtract)
number
Change the color preference value by the specied amount. If an addion
operaon results in a value that is greater than 4,294,967,295 (2
32
– 1), the value
is set to 2
32
– 1. If a subtracon operaon results in a value less than 0, the value
is set to 0. If an aribute value is not already set at the me of the addion or
subtracon operaon, the aribute value defaults to a value of 0 regardless of the
amount specied. If you perform an addion to an aribute with a value of 0, the
number you add becomes the resulng aribute value.
community (+ | add) [
names
]
(BGP only) Add the specied communies to the set of communies in the route.
For more informaon, see
Understanding BGP Communies, Extended
Communies, and Large Communies as Roung Policy Match Condions
.
community (– | delete)
[
names
]
(BGP only) Delete the specied communies from the set of communies in the
route. For more informaon, see
Understanding BGP Communies, Extended
Communies, and Large Communies as Roung Policy Match Condions
.
community (= | set) [
names
]
(BGP only) Replace any communies that were in the route in with the specied
communies. For more informaon, see
Understanding BGP Communies,
Extended Communies, and Large Communies as Roung Policy Match
Condions
.
79
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
cos-next-hop-map
map-name
Set CoS-based next-hop map in forwarding table.
damping
name
(BGP only) Apply the specied route-damping parameters to the route. These
parameters override the default damping parameters. This acon is useful only in
an import policy, because the damping parameters aect the state of routes in the
roung table.
To apply damping parameters, you must enable BGP ap damping as described in
the Junos OS Roung Protocols Library for Roung Devices, and you must create
a named list of parameters as described in "Using Roung Policies to Damp BGP
Route Flapping" on page 600.
destination-class
destination-class-name
Maintain packet counts for a route passing through your network, based on the
desnaon address in the packet. You can do the following:
• Congure group desnaon prexes by conguring a roung policy.
• Apply that roung policy to the forwarding table with the corresponding
desnaon class.
• Enable packet counng on one or more interfaces by including the
destination-class-usage statement at the [edit interfaces
interface-name
unit
logical-unit-number
family inet accounting] hierarchy level (see the Junos OS
Class of Service User Guide for Roung Devices).
• View the output by using one of the following commands: show interfaces
destination-class (all |
destination-class-name
logical-interface-name
), show
interfaces
interface-name
extensive, or show interfaces
interface-name
statistics (see the CLI Explorer).
• To congure a packet count based on the source address, use the source-class
statement described in this table.
external type
metric
Set the external metric type for routes exported by OSPF. You must specify the
keyword type.
80
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
forwarding-class
forwarding-
class-name
Create the forwarding class that includes packets based on both the desnaon
address and the source address in the packet. You can do the following:
• Congure group prexes by conguring a roung policy.
• Apply that roung policy to the forwarding table with the corresponding
forwarding class.
• Enable packet counng on one or more interfaces by using the procedure
described in either the destination-class or source-class acons dened in this
table.
install-nexthop <strict> lsp
lsp-name
Choose which next hops, among a set of equal LSP next hops, are installed in the
forwarding table. Use the export policy for the forwarding table to specify the LSP
next hop to be used for the desired routes. Specify the strict opon to enable
strict mode, which checks to see if any of the LSP next hops specied in the policy
are up. If none of the specied LSP next hops are up, the policy installs the discard
next hop.
install-to-fib
For PTX Series routers only, override the default BGP roung policy. For more
informaon, see Example: Overriding the Default BGP Roung Policy on PTX
Series Packet Transport Routers.
load-balance consistent-hash
(BGP only) For MX Series routers with modular port concentrators (MPCs) and for
QFX10000 switches only, specify consistent load balancing for one or more IP
addresses. This feature preserves the anity of a ow to a path in an equal-cost
mulpath (ECMP) group when one or more next-hop paths fail. Only ows for
paths that are inacve are redirected. Flows mapped to servers that remain acve
are maintained.
81
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
load-balance
symmetric-
consistent-hash
(MX Series Routers - AFT-based) Enable symmetric consistent hashing to support
consistent hashing with stac routes and achieve symmetric load-balancing with
correlated source IP and desnaon IP load-balancing hash-key in forward and
reverse direcon.
This acon is used in a scenario where consistent hash is to be applied on anycast
IPs used for load-balancing the trac learnt via stac route towards ECMP server
group in upstream and downstream direcon. Because the expectaon is that all
ows from a customer should reach the same ECMP server, only the source-IP is
used for creang the load-balancing hash in one direcon and desnaon-IP is
used for creang the load-balancing hash in the reverse direcon.
load-balance destination-ip-
only
Calculate load balancing hash based solely on desnaon IP address. This allows a
service provider to direct trac toward a specic content server in per-subscriber
aware environments.
load-balance per-packet
(For export to the forwarding table only) Install all next-hop addresses in the
forwarding table and have the forwarding table perform per-packet load
balancing. This policy acon allows you to opmize VPLS trac ows across
mulple paths. For more informaon, see
Conguring Per-Packet Load Balancing
.
load-balance per-prefix
For PTX Series routers only, override the default per-packet load balancing roung
policy for BGP. For more informaon, see Example: Overriding the Default BGP
Roung Policy on PTX Series Packet Transport Routers.
load-balance source-ip-only
Calculate load balancing hash based solely on source IP address. This allows a
service provider to direct trac toward a specic content server in per-subscriber
aware environments.
local-preference
value
(BGP only) Set the BGP local preference (LOCAL_PREF) aribute. The preference
value can be a number in the range from 0 through 4,294,967,295 (2
32
– 1).
82
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
local-preference (add |
subtract)
number
Change the local preference value by the specied amount. If an addion
operaon results in a value that is greater than 4,294,967,295 (2
32
– 1), the value
is set to 2
32
– 1. If a subtracon operaon results in a value less than 0, the value
is set to 0. If an aribute value is not already set at the me of the addion or
subtracon operaon, the aribute value defaults to a value of 0 regardless of the
amount specied. If you perform an addion to an aribute with a value of 0, the
number you add becomes the resulng aribute value.
For BGP, if the aribute value is not known, it is inialized to 100 before the
roung policy is applied.
map-to-interface (
interface-
name
| self)
Sets the map-to-interface value which is similar to exisng metric or tag acons.
The map-to-interface acon requires you to specify one of the following:
• A logical interface (for example, ge-0/0/0.0). The logical interface can be any
interface that mulcast currently supports, including VLAN and aggregated
Ethernet interfaces.
NOTE: If you specify a physical interface as the map-to-interface (for example,
ge-0/0/0), a value of .0 is appended to physical interface to create a logical
interface.
• The keyword self. The self keyword species that mulcast data packets are
sent on the same interface as the control packets and no mapping occurs.
If no term matches, then no mulcast data packets are sent.
metric
metric
metric2
metric
metric3
metric
metric4
metric
Set the metric. You can specify up to four metric values, starng with metric (for
the rst metric value) and connuing with metric2, metric3, and metric4.
(BGP only) metric corresponds to the MED, and metric2 corresponds to the IGP
metric if the BGP next hop loops through another router.
metric (add | subtract)
number
metric2 (add |
subtract)
number
metric3 (add
| subtract)
number
metric4
(add | subtract)
number
Change the metric value by the specied amount. If an addion operaon results
in a value that is greater than 4,294,967,295 (2
32
– 1), the value is set to 2
32
– 1. If
a subtracon operaon results in a value less than 0, the value is set to 0. If an
aribute value is not already set at the me of the addion or subtracon
operaon, the aribute value defaults to a value of 0 regardless of the amount
specied. If you perform an addion to an aribute with a value of 0, the number
you add becomes the resulng aribute value.
83
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
metric expression (metric
multiplier
x
offset
a
|
metric2 multiplier
y
offset
b
)
Calculate a metric based on the current values of metric and metric2.
This policy acon overrides the current value of the metric aribute with the
result of the expression
((x * metric) + a) + ((y * metric2) + b)
where metric and metric2 are the current input values. Metric mulpliers are
limited in range to eight signicant digits.
metric (igp | minimum-igp)
site-offset
(BGP only) Change the metric (MED) value by the specied negave or posive
oset. This acon is useful only in an external BGP (EBGP) export policy.
84
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
next-hop (
address
| discard |
next-table
table-name
| peer-
address | reject | self)
Set the next-hop address. When the adversing protocol is BGP, you can set the
next hop only when any third-party next hop can be adversed; that is, when you
are using IBGP or EBGP confederaons.
If you specify self, the next-hop address is replaced by one of the local roung
device’s addresses. The adversing protocol determines which address to use.
When the adversing protocol is BGP, this address is set to the local IP address
used for the BGP adjacency. A roung device cannot install routes with itself as
the next hop.
If you specify peer-address, the next-hop address is replaced by the peer’s IP
address. This opon is valid only in import policies. Primarily used by BGP to
enforce using the peer’s IP address for adversed routes, this opon is meaningful
only when the next hop is the adversing roung device or another directly
connected roung device.
If you specify discard, the next-hop address is replaced by a discard next hop.
If you specify next-table, the roung device performs a forwarding lookup in the
specied table.
If you use the next-table acon, the conguraon must include a term qualier
that species a dierent table than the one specied in the next-table acon. In
other words, the term qualier in the from statement must exclude the table in the
next-table acon. In the following example, the rst term contains rib vrf-
customer2.inet.0 as a matching condion. The acon species a next-hop in a
dierent roung table, vrf-customer1.inet.0. The second term does the opposite
by using rib vrf-customer1.inet.0 in the match condion and vrf-customer2.inet.0
In the next-table acon.
term 1 {
from {
protocol bgp;
rib vrf-customer2.inet.0;
community customer;
}
then {
next-hop next-table vrf-customer1.inet.0;
}
}
term 2 {
from {
85
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
protocol bgp;
rib vrf-customer1.inet.0;
community customer;
}
then {
next-hop next-table vrf-customer2.inet.0;
}
}
If you specify reject, the next-hop address is replaced by a reject next hop.
origin
value
(BGP only) Set the BGP origin aribute to one of the following values:
• igp—Path informaon originated within the local AS.
• egp—Path informaon originated in another AS.
• incomplete—Path informaon learned by some other means.
p2mp-lsp-root
Set the ingress root node for a mulpoint LDP (M-LDP)-based point-to-mulpoint
label-switched path (LSP). For more informaon, see Example: Conguring
Mulpoint LDP In-Band Signaling for Point-to-Mulpoint LSPs.
preference
preference
preference2
preference
Set the preference value. You can specify a primary preference value (preference)
and a secondary preference value (preference2). The preference value can be a
number in the range from 0 through 4,294,967,295 (2
32
– 1). A lower number
indicates a more preferred route. When you use an import policy to set the value
of preference2 to the highest allowed value of 4,294,967,295, Junos OS resets this
value to -1. If you set preference2 to a number greater than (2
31
– 1), it is reset to a
negave value.
To specify even ner-grained preference values, see the color and color2 acons in
this table.
If you set the preference with the preference acon, the new preference remains
associated with the route. The new preference is internal to the Junos OS and is
not transive.
86
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
preference (add | subtract)
number
preference2 (add |
subtract)
number
Change the preference value by the specied amount. If an addion operaon
results in a value that is greater than 4,294,967,295 (2
32
– 1), the value is set
to 2
32
– 1. If a subtracon operaon results in a value less than 0, the value is set
to 0. If an aribute value is not already set at the me of the addion or
subtracon operaon, the aribute value defaults to a value of 0 regardless of the
amount specied. If you perform an addion to an aribute with a value of 0, the
number you add becomes the resulng aribute value.
priority (low | medium |
high)
(OSPF import only) Specify a priority for prexes included in an OSPF import
policy. Prexes learned through OSPF are installed in the roung table based on
the priority assigned to the prexes. Prexes assigned a priority of high are
installed rst, while prexes assigned a priority of low are installed last.
NOTE: An OSPF import policy can only be used to set priority or to lter OSPF
external routes. If an OSPF import policy is applied that results in a reject
terminang acon for a nonexternal route, then the reject acon is ignored and
the route is accepted anyway.
87
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
source-class
source-class-
name
Maintain packet counts for a route passing through your network, based on the
source address. You can do the following:
• Congure group source prexes by conguring a roung policy.
• Apply that roung policy to the forwarding table with the corresponding
source class.
• Enable packet counng on one or more interfaces by including the source-
class-usage
interface-name
statement at the [edit interfaces
logical-unit-
number
unit family inet accounting] hierarchy level. Also, follow the source-
class-usage statement with the input or output statement to dene the
inbound and outbound interfaces on which trac monitored for source-class
usage (SCU) is arriving and deparng (or dene one interface for both). The
complete syntax is [edit interfaces
interface-name
unit family inet
accounting source-class-usage (input | output | input output)
unit-number
].
• View the output by using one of the following commands: show interfaces
interface-name
source-class
source-class-name
, show interfaces
interface-name
extensive, or show interfaces
interface-name
statistics (see the CLI Explorer).
• To congure a packet count based on the desnaon address, use the
destination-class statement described in this table.
• For a detailed source-class usage example conguraon, see the "Example:
Grouping Source and Desnaon Prexes into a Forwarding Class" on page
673.
NOTE: When conguring policy acon statements, you can congure only one
source class for each matching route. In other words, more than one source class
cannot be applied to the same route.
ssm-source [
addresses
];
Specify one or more IPv4 or IPv6 source addresses for the source-specic
mulcast (SSM) policy
ssm-source [
addresses
];
Specify one or more IPv4 or IPv6 source addresses for the source-specic
mulcast (SSM) policy.
88
Table 10: Acons That Manipulate Route Characteriscs
(Connued)
Acon Descripon
tag
tag
tag2
tag
Set the tag value. You can specify two tag strings: tag (for the rst string) and tag2
(a second string). These values are local to the router.
• For OSPF routes the tag acon sets the 32-bit tag eld in OSPF external link-
state adversement (LSA) packets.
• For IS-IS routes, the tag acon sets the 32-bit ag in the IS-IS IP prex type
length values (TLV).
• For RIPv2 routes, the tag acon sets the route-tag community. The tag2 opon
is not supported.
tag (add | subtract)
number
tag2 (add | subtract)
number
Change the tag value by the specied amount. If an addion operaon results in a
value that is greater than 4,294,967,295 (2
32
– 1), the value is set to 2
32
– 1. If a
subtracon operaon results in a value less than 0, the value is set to 0. If an
aribute value is not already set at the me of the addion or subtracon
operaon, the aribute value defaults to a value of 0 regardless of the amount
specied. If you perform an addion to an aribute with a value of 0, the number
you add becomes the resulng aribute value.
validation-state
When BGP origin validaon is congured, set the validaon state of a route prex
to valid, invalid, or unknown.
The route validaon database contains route origin authorizaon (ROA) records
that map route prexes to expected originang autonomous systems (ASs). This
prevents the accidental adversement of invalid routes.
See Understanding Origin Validaon for BGP.
Conguring the Default Acon in Roung Policies
The default-action statement overrides any acon intrinsic to the protocol. This acon is also
nonterminang, so that various policy terms can be evaluated before the policy is terminated. You can
specify a default acon, either accept or reject, as follows:
[edit]
policy-options {
policy-statement
policy-name
{
89
term
term-name
{
from {
family
family-name
;
match-conditions
;
policy
subroutine-policy-name
;
prefix-list
name
;
route-filter
destination-prefix
match-type
<
actions
>;
source-address-filter
source-prefix
match-type
<
actions
>;
}
to {
match-conditions
;
policy
subroutine-policy-name
;
}
then {
actions
;
default-action (accept | reject);
}
}
}
}
The resulng acon is set either by the protocol or by the last policy term that is matched.
Example: Conguring the Default Acon in a Roung Policy
Congure a roung policy that matches routes based on three policy terms. If the route matches the
rst term, a certain community tag is aached. If the route matches two separate terms, then both
community tags are aached. If the route does not match any terms, it is rejected (protocol’s default
acon). Note that the terms hub and spoke are mutually exclusive.
[edit]
policy-options {
policy-statement test {
term set-default {
then default-action reject;
}
term hub {
from interface ge-2/1/0.5;
then {
community add test-01-hub;
default-action accept;
}
90
}
term spoke {
from interface [ ge-2/1/0.1 ge-2/1/0.2 ];
then {
community add test-01-spoke;
default-action accept;
}
}
term management {
from protocol direct;
then {
community add management;
default-action accept;
}
}
}
}
Conguring a Final Acon in Roung Policies
In addion to specifying an acon using the then statement in a named term, you can also specify an
acon using the then statement in an unnamed term, as follows:
[edit]
policy-options {
policy-statement
policy-name
{
term
term-name
{
from {
family
family-name
;
match-conditions
;
policy
subroutine-policy-name
;
prefix-list
name
;
route-filter
destination-prefix
match-type
<
actions
>;
source-address-filter
source-prefix
match-type
<
actions
>;
}
to {
match-conditions
;
policy
subroutine-policy-name
;
}
then {
actions
;
91
}
}
then
action
;
}
}
Logging Matches to a Roung Policy Term
If you specify the trace acon, the match is logged to a trace le. To set up a trace le, you must specify
the following elements in the global traceoptions statement:
• Trace lename
• policy opon in the flag statement
The following example uses the trace lename of policy-log:
[edit]
routing-options {
traceoptions {
file “policy-log";
flag policy;
}
}
This acon does not aect the ow control during roung policy evaluaon.
If a term that species a trace acon also species a ow control acon, the name of the term is logged
in the trace le. If a term species a trace acon only, the word <default> is logged.
Conguring Separate Acons for Routes in Route Lists
If you specify route lists in the from statement, for each route in the list, you can specify an acon to take
on that individual route directly, without including a then statement. For more informaon, see
"Understanding Route Filters for Use in Roung Policy Match Condions" on page 305.
RELATED DOCUMENTATION
Route Filter Match Condions | 72
Roung Policy Match Condions | 58
92
Summary of Roung Policy Acons
An
acon
is what the policy framework soware does if a route matches all criteria dened in a match
condion. You can congure one or more acons in a term.
The policy framework soware supports the following types of acons:
• Flow control acons, which aect whether to accept or reject the route or whether to evaluate the
next term or roung policy
• Acons that manipulate route characteriscs
• Trace acon, which logs route matches
Manipulang the route characteriscs allows you to control which route is selected as the acve route
to reach a desnaon. In general, the acve route is also adversed to a roung plaorm’s neighbors.
You can manipulate the following route characteriscs: AS path, class, color, community, damping
parameters, desnaon class, external type, next hop, load balance, local preference, metric, origin,
preference, and tag.
For the numeric informaon (color, local preference, metric, preference, and tag), you can set a specic
value or change the value by adding or subtracng a specied amount. The addion and subtracon
operaons do not allow the value to exceed a maximum value and drop below a minimum value.
All policies have default acons in case one of the following situaons arises during policy evaluaon:
• A policy does not specify a match condion.
• A match occurs, but a policy does not specify an acon.
• A match does not occur with a term in a policy and subsequent terms in the same policy exist.
• A match does not occur by the end of a policy.
An acon denes what the router does with the route when the route matches all the match condions
in the from and to statements for a parcular term. If a term does not have from and to statements, all
routes are considered to match and the acons apply to all routes.
Each term can have one or more of the following types of acons. The acons are congured under the
then statement.
• Flow control acons, which aect whether to accept or reject the route and whether to evaluate the
next term or roung policy
• Acons that manipulate route characteriscs
• Trace acon, which logs route matches
93
If you do not specify an acon, one of the following results occurs:
• The next term in the roung policy, if one exists, is evaluated.
• If the roung policy has no more terms, the next roung policy, if one exists, is evaluated.
• If there are no more terms or roung policies, the accept or reject acon specied by the default
policy is executed.
Table 11 on page 94 summarizes the roung policy acons.
Table 11: Summary of Key Roung Policy Acons
Acon Descripon
Flow Control Acons These acons control the ow of roung informaon into and out of the
roung table.
accept
Accepts the route and propagates it. Aer a route is accepted, no other terms
in the roung policy and no other roung policies are evaluated.
reject
Rejects the route and does not propagate it. Aer a route is rejected, no other
terms in the roung policy and no other roung policies are evaluated.
next term Skips to and evaluates the next term in the same roung policy. Any accept or
reject acon specied in the then statement is ignored. Any acons specied in
the then statement that manipulate route characteriscs are applied to the
route.
next policy Skips to and evaluates the next roung policy. Any accept or reject acon
specied in the then statement is ignored. Any acons specied in the then
statement that manipulate route characteriscs are applied to the route.
Route Manipulaon Acons These acons manipulate the route characteriscs.
94
Table 11: Summary of Key Roung Policy Acons
(Connued)
Acon Descripon
as-path-prepend
as-path
Appends one or more AS numbers at the beginning of the AS path. If you are
specifying more than one AS number, include the numbers in quotaon marks.
The AS numbers are added aer the local AS number has been added to the
path. This acon adds AS numbers to AS sequences only, not to AS sets. If the
exisng AS path begins with a confederaon sequence or set, the appended AS
numbers are placed within a confederaon sequence. Otherwise, the appended
AS numbers are placed with a nonconfederaon sequence.
as-path-expand last-as count
n
Extracts the last AS number in the exisng AS path and appends that AS
number to the beginning of the AS path
n
mes. Replace
n
with a number from
1 through 32.
The AS numbers are added aer the local AS number has been added to the
path. This acon adds AS numbers to AS sequences only, not to AS sets. If the
exisng AS path begins with a confederaon sequence or set, the appended AS
numbers are placed within a confederaon sequence. Otherwise, the appended
AS numbers are placed with a nonconfederaon sequence.
class
class-name
Applies the specied class-of-service (CoS) parameters to routes installed into
the roung table.
color
preference
color2
preference
Sets the preference value to the specied value. The color and color2
preference values can be a number from 0 through 4,294,967,295 (2
32
– 1). A
lower number indicates a more preferred route.
damping
name
Applies the specied route-damping parameters to the route. These parameters
override BGP's default damping parameters.
This acon is useful only in import policies.
local-preference
value
Sets the BGP local preference aribute. The preference can be a number from 0
through 4,294,967,295 (2
32
– 1).
95
Table 11: Summary of Key Roung Policy Acons
(Connued)
Acon Descripon
metric
metric
metric2
metric
metric3
metric
metric4
metric
Sets the metric. You can specify up to four metric values, starng with metric
(for the rst metric value) and connuing with metric2, metric3, and metric4.
For BGP routes, metric corresponds to the MED, and metric2 corresponds to the
IGP metric if the BGP next hop loops through another router.
next-hop
address
Sets the next hop.
If you specify
address
as self, the next-hop address is replaced by one of the
local router's addresses. The adversing protocol determines which address to
use.
RELATED DOCUMENTATION
Roung Policies, Firewall Filters, and Trac Policers User Guide
Example: Conguring a Roung Policy to Adverse the Best External
Route to Internal Peers
IN THIS SECTION
Requirements | 98
Overview | 98
Conguraon | 100
Vericaon | 104
The BGP protocol specicaon, as dened in RFC 1771, species that a BGP peer shall adverse to its
internal peers the higher preference external path, even if this path is not the overall best (in other
96
words, even if the best path is an internal path). In pracce, deployed BGP implementaons do not
follow this rule. The reasons for deviang from the specicaon are as follows:
• Minimizing the amount of adversed informaon. BGP scales according to the number of available
paths.
• Avoiding roung and forwarding loops.
There are, however, several scenarios in which the behavior, specied in RFC 1771, of adversing the
best external route might be benecial. Liming path informaon is not always desirable as path
diversity might help reduce restoraon mes. Adversing the best external path can also address
internal BGP (IBGP) route oscillaon issues as described in RFC 3345,
Border Gateway Protocol (BGP)
Persistent Route Oscillaon Condion
.
The advertise-external statement modies the behavior of a BGP speaker to adverse the best external
path to IBGP peers, even when the best overall path is an internal path.
NOTE: The advertise-external statement is supported at both the group and neighbor level. If you
congure the statement at the neighbor level, you must congure it for all neighbors in a group.
Otherwise, the group is automacally split into dierent groups.
The conditional opon limits the behavior of the advertise-external seng, such that the external route is
adversed only if the route selecon process reaches the point where the mulple exit discriminator
(MED) metric is evaluated. Thus, an external route is not adversed if it has, for instance, an AS path
that is worse (longer) than that of the acve path. The conditional opon restricts external path
adversement to when the best external path and the acve path are equal unl the MED step of the
route selecon process. Note that the criteria used for selecng the best external path is the same
whether or not the conditional opon is congured.
Junos OS also provides support for conguring a BGP export policy that matches the state of an
adversed route. You can match either acve or inacve routes, as follows:
policy-options {
policy-statement
name
{
from state (active|inactive);
}
}
This qualier only matches when used in the context of an export policy. When a route is being
adversed by a protocol that can adverse inacve routes (such as BGP), state inactive matches routes
adversed as a result of the advertise-inactive and advertise-external statements.
97
For example, the following conguraon can be used as a BGP export policy toward internal peers to
mark routes adversed due to the advertise-external seng with a user-dened community. That
community can be later used by the receiving routers to lter out such routes from the forwarding table.
Such a mechanism can be used to address concerns that adversing paths not used for forwarding by
the sender might lead to forwarding loops.
user@host# show policy-options
policy-statement mark-inactive {
term inactive {
from state inactive;
then {
community set comm-inactive;
}
}
term default {
from protocol bgp;
then accept;
}
then reject;
}
community comm-inactive members 65536:65284;
Requirements
Junos OS 9.3 or later is required.
Overview
IN THIS SECTION
Topology | 99
This example shows three roung devices. Device R2 has an external BGP (EBGP) connecon to Device
R1. Device R2 has an IBGP connecon to Device R3.
Device R1 adverses 172.16.6.0/24. Device R2 does not set the local preference in an import policy for
Device R1’s routes, and thus 172.16.6.0/24 has the default local preference of 100.
Device R3 adverses 172.16.6.0/24 with a local preference of 200.
98
When the advertise-external statement is not congured on Device R2, 172.16.6.0/24 is not adversed
by Device R2 toward Device R3.
When the advertise-external statement is congured on Device R2 on the session toward Device R3,
172.16.6.0/24 is adversed by Device R2 toward Device R3.
When advertise-external conditional is congured on Device R2 on the session toward Device R3,
172.16.6.0/24 is not adversed by Device R2 toward Device R3. If you remove the then local-preference
200 seng on Device R3 and add the path-selection as-path-ignore seng on Device R2 (thus making the
path selecon criteria equal unl the MED step of the route selecon process), 172.16.6.0/24 is
adversed by Device R2 toward Device R3.
NOTE: To congure the advertise-external statement on a route reector, you must disable
intracluster reecon with the no-client-reflect statement, and the client cluster must be fully
meshed to prevent the sending of redundant route adversements.
When a roung device is congured as a route reector for a cluster, a route adversed by the
route reector is considered internal if it is received from an internal peer with the same cluster
idener or if both peers have no cluster idener congured. A route received from an internal
peer that belongs to another cluster, that is, with a dierent cluster idener, is considered
external.
Topology
Figure 9 on page 99 shows the sample network.
Figure 9: BGP Topology for adverse-external
99
"CLI Quick Conguraon" on page 100 shows the conguraon for all of the devices in Figure 9 on page
99.
The secon "No Link Title" on page 102 describes the steps on Device R2.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 100
Procedure | 101
CLI Quick
Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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 lo0 unit 0 family inet address 192.168.0.1/32
set protocols bgp group ext type external
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.0.0.2
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 from route-filter 172.16.6.0/24 exact
set policy-options policy-statement send-static term 1 then accept
set policy-options policy-statement send-static term 2 then reject
set routing-options static route 172.16.6.0/24 reject
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 100
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
100
set interfaces fe-1/2/1 unit 0 description to-R3
set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.5/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp group ext type external
set protocols bgp group ext peer-as 100
set protocols bgp group ext neighbor 10.0.0.1
set protocols bgp group int type internal
set protocols bgp group int local-address 192.168.0.2
set protocols bgp group int advertise-external
set protocols bgp group int neighbor 192.168.0.3
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 routing-options router-id 192.168.0.2
set routing-options autonomous-system 200
Device R3
set interfaces fe-1/2/0 unit 6 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 export send-static
set protocols bgp group int neighbor 192.168.0.2
set protocols ospf area 0.0.0.0 interface fe-1/2/0.6
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then local-preference 200
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 172.16.6.0/24 reject
set routing-options static route 0.0.0.0/0 next-hop 10.0.0.5
set routing-options autonomous-system 200
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R2:
101
1. Congure the device interfaces.
[edit interfaces]
user@R2# set fe-1/2/0 unit 0 description to-R1
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 description to-R3
user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.5/30
user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure OSPF or another interior gateway protocol (IGP).
[edit protocols ospf area 0.0.0.0]
user@R2# set interface fe-1/2/1.0
user@R2# set interface lo0.0 passive
3. Congure the EBGP connecon to Device R1.
[edit protocols bgp group ext]
user@R2# set type external
user@R2# set peer-as 100
user@R2# set neighbor 10.0.0.1
4. Congure the IBGP connecon to Device R3.
[edit protocols bgp group int]
user@R2# set type internal
user@R2# set local-address 192.168.0.2
user@R2# set neighbor 192.168.0.3
5. Add the advertise-external statement to the IBGP group peering session.
[edit protocols bgp group int]
user@R2# set advertise-external
102
6. Congure the autonomous system (AS) number and the router ID.
[edit routing-options ]
user@R2# set router-id 192.168.0.2
user@R2# set autonomous-system 200
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R2# show interfaces
fe-1/2/0 {
unit 0{
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
fe-1/2/1 {
unit 0 {
description to-R3;
family inet {
address 10.0.0.5/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
103
group ext {
type external;
peer-as 100;
neighbor 10.0.0.1;
}
group int {
type internal;
local-address 192.168.0.2;
advertise-external;
neighbor 192.168.0.3;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0;
interface lo0.0 {
passive;
}
}
}
user@R2# show routing-options
router-id 192.168.0.2;
autonomous-system 200;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the BGP Acve Path | 105
Verifying the External Route Adversement | 105
Verifying the Route on Device R3 | 106
Experimenng with the condional Opon | 106
Conrm that the conguraon is working properly.
104
Verifying the BGP Acve Path
Purpose
On Device R2, make sure that the 172.16.6.0/24 prex is in the roung table and has the expected
acve path.
Acon
user@R2> show route 172.16.6
inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[BGP/170] 00:00:07, localpref 200, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/1.0
[BGP/170] 03:23:03, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
Meaning
Device R2 receives the 172.16.6.0/24 route from both Device R1 and Device R3. The route from Device
R3 is the acve path, as designated by the asterisk (*). The acve path has the highest local preference.
Even if the local preferences of the two routes were equal, the route from Device R3 would remain
acve because it has the shortest AS path.
Verifying the External Route Adversement
Purpose
On Device R2, make sure that the 172.16.6.0/24 route is adversed toward Device R3.
Acon
user@R2> show route advertising-protocol bgp 192.168.0.3
inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden)
105
Prefix Nexthop MED Lclpref AS path
172.16.6.0/24 10.0.0.1 100 100 I
Meaning
Device R2 is adversing the 172.16.6.0/24 route toward Device R3.
Verifying the Route on Device R3
Purpose
Make sure that the 172.16.6.0/24 prex is in Device R3’s roung table.
Acon
user@R3> show route 172.16.6.0/24
inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[Static/5] 03:34:14
Reject
[BGP/170] 06:34:43, localpref 100, from 192.168.0.2
AS path: 100 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/0.6
Meaning
Device R3 has the stac route and the BGP route for 172.16.6.0/24.
Note that the BGP route is hidden on Device R3 if the route is not reachable or if the next hop cannot
be resolved. To fulll this requirement, this example includes a stac default route on Device R3 (static
route 0.0.0.0/0 next-hop 10.0.0.5).
Experimenng with the condional Opon
Purpose
See how the conditional opon works in the context of the BGP path selecon algorithm.
106
Acon
1. On Device R2, add the conditional opon.
[edit protocols bgp group int]
user@R2# set advertise-external conditional
user@R2# commit
2. On Device R2, check to see if the 172.16.6.0/24 route is adversed toward Device R3.
user@R2> show route advertising-protocol bgp 192.168.0.3
As expected, the route is no longer adversed. You might need to wait a few seconds to see this
result.
3. On Device R3, deacvate the then local-preference policy acon.
[edit policy-options policy-statement send-static term 1]
user@R3# deactivate logical-systems R3 then local-preference
user@R3# commit
4. On Device R2, ensure that the local preferences of the two paths are equal.
user@R2> show route 172.16.6.0/24
inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[BGP/170] 08:02:59, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
[BGP/170] 00:07:51, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/1.0
107
5. On Device R2, add the as-path-ignore statement.
[edit protocols bgp]
user@R2# set path-selection as-path-ignore
user@R2# commit
6. On Device R2, check to see if the 172.16.6.0/24 route is adversed toward Device R3.
user@R2> show route advertising-protocol bgp 192.168.0.3
inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.6.0/24 10.0.0.1 100 100 I
As expected, the route is now adversed because the AS path length is ignored and because the local
preferences are equal.
RELATED DOCUMENTATION
Example: Conguring BGP to Adverse Inacve Routes
Understanding BGP Path Selecon
Example: Conguring BGP to Adverse Inacve Routes
IN THIS SECTION
Requirements | 110
Overview | 110
Conguraon | 111
Vericaon | 115
108
By default, BGP readverses only acve routes. To have the roung table export to BGP the best route
learned by BGP even if Junos OS did not select it to be an acve route, include the advertise-inactive
statement:
advertise-inactive;
In Junos OS, BGP adverses BGP routes that are installed or acve, which are routes selected as the
best based on the BGP path selecon rules. The advertise-inactive statement allows nonacve BGP
routes to be adversed to other peers.
NOTE: If the roung table has two BGP routes where one is acve and the other is inacve, the
advertise-inactive statement does not adverse the inacve BGP prex. This statement does not
adverse an inacve BGP route in the presence of another acve BGP route. However, if the
acve route is a stac route, the advertise-inactive statement adverses the inacve BGP route.
NOTE: The advertise-inactive statement does not help to adverse the inacve route from the
VRF when the router is congured as a route reector.
Junos OS also provides support for conguring a BGP export policy that matches the state of an
adversed route. You can match either acve or inacve routes, as follows:
policy-options {
policy-statement
name
{
from state (active|inactive);
}
}
This qualier only matches when used in the context of an export policy. When a route is being
adversed by a protocol that can adverse inacve routes (such as BGP), state inactive matches routes
adversed as a result of the advertise-inactive (or advertise-external) statement.
For example, the following conguraon can be used as a BGP export policy to mark routes adversed
due to the advertise-inactive seng with a user-dened community. That community can be later used
by the receiving routers to lter out such routes from the forwarding table. Such a mechanism can be
109
used to address concerns that adversing paths not used for forwarding by the sender might lead to
forwarding loops.
user@host# show policy-options
policy-statement mark-inactive {
term inactive {
from state inactive;
then {
community set comm-inactive;
}
}
term default {
from protocol bgp;
then accept;
}
then reject;
}
community comm-inactive members 65536:65284;
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 111
In this example, Device R2 has two external BGP (EBGP) peers, Device R1 and Device R3.
Device R1 has a stac route to 172.16.5/24. Likewise, Device R2 also has a stac route to 172.16.5/24.
Through BGP, Device R1 sends informaon about its stac route to Device R2. Device R2 now has
informaon about 172.16.5/24 from two sources—its own stac route and the BGP-learned route
received from Device R1. Stac routes are preferred over BGP-learned routes, so the BGP route is
inacve on Device R2. Normally Device R2 would send the BGP-learned informaon to Device R3, but
Device R2 does not do this because the BGP route is inacve. Device R3, therefore, has no informaon
about 172.16.5/24 unless you enable the advertise-inactive command on Device R2, which causes
Device R2 to send the BGP-learned to Device R3.
110
Topology
Figure 10 on page 111 shows the sample network.
Figure 10: BGP Topology for adverse-inacve
"CLI Quick Conguraon" on page 111 shows the conguraon for all of the devices in Figure 10 on
page 111.
The secon "No Link Title" on page 113 describes the steps on Device R2.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 111
Procedure | 113
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
111
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 to_R2 type external
set protocols bgp group to_R2 export send-static
set protocols bgp group to_R2 neighbor 10.0.0.2 peer-as 200
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 172.16.5.0/24 discard
set routing-options static route 172.16.5.0/24 install
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.0.0.5/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp group to_R1 type external
set protocols bgp group to_R1 neighbor 10.0.0.1 peer-as 100
set protocols bgp group to_R3 type external
set protocols bgp group to_R3 advertise-inactive
set protocols bgp group to_R3 neighbor 10.0.0.6 peer-as 300
set routing-options static route 172.16.5.0/24 discard
set routing-options static route 172.16.5.0/24 install
set routing-options autonomous-system 200
Device R3
set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.6/30
set interfaces fe-1/2/0 unit 9 family inet address 10.0.0.9/30
set interfaces lo0 unit 0 family inet address 192.168.0.3/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.5
set routing-options autonomous-system 300
112
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R2:
1. Congure the device interfaces.
[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.0.0.5/30
user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure the EBGP connecon to Device R1.
[edit protocols bgp group to_R1]
user@R2# set type external
user@R2# set neighbor 10.0.0.1 peer-as 100
3. Congure the EBGP connecon to Device R3.
[edit protocols bgp group to_R3]
user@R2# set type external
user@R2# set neighbor 10.0.0.6 peer-as 300
4. Add the advertise-inactive statement to the EBGP group peering session with Device R3.
[edit protocols bgp group to_R3]
user@R2# set advertise-inactive
113
5. Congure the stac route to the 172.16.5.0/24 network.
[edit routing-options static]
user@R2# set route 172.16.5.0/24 discard
user@R2# set route 172.16.5.0/24 install
6. Congure the autonomous system (AS) number.
[edit routing-options]
user@R2# set autonomous-system 200
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
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.0.0.5/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
114
}
}
user@R2# show protocols
bgp {
group to_R1 {
type external;
neighbor 10.0.0.1 {
peer-as 100;
}
}
group to_R3 {
type external;
advertise-inactive;
neighbor 10.0.0.6 {
peer-as 300;
}
}
}
user@R2# show routing-options
static {
route 172.16.5.0/24 {
discard;
install;
}
}
autonomous-system 200;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the BGP Acve Path | 116
Verifying the External Route Adversement | 116
Verifying the Route on Device R3 | 117
115
Experimenng with the adverse-inacve Statement | 118
Conrm that the conguraon is working properly.
Verifying the BGP Acve Path
Purpose
On Device R2, make sure that the 172.16.5.0/24 prex is in the roung table and has the expected
acve path.
Acon
user@R2> show route 172.16.5
inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.5.0/24 *[Static/5] 21:24:38
Discard
[BGP/170] 21:21:41, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
Meaning
Device R2 receives the 172.16.5.0/24 route from both Device R1 and from its own stacally congured
route. The stac route is the acve path, as designated by the asterisk (*). The stac route path has the
lowest route preference (5) as compared to the BGP preference (170). Therefore, the stac route
becomes acve.
Verifying the External Route Adversement
Purpose
On Device R2, make sure that the 172.16.5.0/24 route is adversed toward Device R3.
116
Acon
user@R2> show route advertising-protocol bgp 10.0.0.6
inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
172.16.5.0/24 Self 100 I
Meaning
Device R2 is adversing the 172.16.5.0/24 route toward Device R3
Verifying the Route on Device R3
Purpose
Make sure that the 172.16.6.0/24 prex is in Device R3’s roung table.
Acon
user@R3> show route 172.16.5.0/24
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.5.0/24 *[BGP/170] 00:01:19, localpref 100
AS path: 200 100 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/1.0
Meaning
Device R3 has the BGP-learned route for 172.16.5.0/24.
117
Experimenng with the adverse-inacve Statement
Purpose
See what happens when the advertise-inactive statement is removed from the BGP conguraon on
Device R2.
Acon
1. On Device R2, deacvate the advertise-inactive statement.
[edit protocols bgp group to_R3]
user@R2# deactivate advertise-inactive
user@R2# commit
2. On Device R2, check to see if the 172.16.5.0/24 route is adversed toward Device R3.
user@R2> show route advertising-protocol bgp 10.0.0.6
As expected, the route is no longer adversed.
3. On Device R3, ensure that the 172.16.5/24 route is absent from the roung table.
user@R3> show route 172.16.5/24
Meaning
Device R1 adverses route 172.16.5/24 to Device R2, but Device R2 has a manually congured stac
route for this prex. Stac routes are preferred over BGP routes, so Device R2 installs the BGP route as
an inacve route. Because the BGP route is not acve, Device R2 does not readverse the BGP route to
Device R3. This is the default behavior in Junos OS. If you add the advertise-inactive statement to the
BGP conguraon on Device R2, Device R2 readverses nonacve routes.
RELATED DOCUMENTATION
Example: Conguring a Roung Policy to Adverse the Best External Route to Internal Peers
118
Understanding BGP Path Selecon
Example: Using Roung Policy to Set a Preference Value for BGP Routes
IN THIS SECTION
Requirements | 119
Overview | 119
Conguraon | 121
Vericaon | 126
This example shows how to use roung policy to set the preference for routes learned from BGP.
Roung informaon can be learned from mulple sources. To break es among equally specic routes
learned from mulple sources, each source has a preference value. Routes that are learned through
explicit administrave acon, such as stac routes, are preferred over routes learned from a roung
protocol, such as BGP or OSPF. This concept is called
administrave distance
by some vendors.
Requirements
No special conguraon beyond device inializaon is required before you congure this example.
Overview
IN THIS SECTION
Topology | 120
Roung informaon can be learned from mulple sources, such as through stac conguraon, BGP, or
an interior gateway protocol (IGP). When Junos OS determines a route’s preference to become the
acve route, it selects the route with the lowest preference as the acve route and installs this route
into the forwarding table. By default, the roung soware assigns a preference of 170 to routes that
originated from BGP. Of all the roung protocols, BGP has the highest default preference value, which
means that routes learned by BGP are the least likely to become the acve route.
119
Some vendors have a preference (distance) of 20 for external BGP (EBGP) and a distance of 200 for
internal BGP (IGBP). Junos OS uses the same value (170) for both EBGP and IBGP. However, this
dierence between vendors has no operaonal impact because Junos OS always prefers EBGP routes
over IBGP routes.
Another area in which vendors dier is in regard to IGP distance compared to BGP distance. For
example, some vendors assign a distance of 110 to OSPF routes. This is higher than the EBGP distance
of 20, and results in the selecon of an EBGP route over an equivalent OSPF route. In the same
scenario, Junos OS chooses the OSPF route, because of the default preference 10 for an internal OSPF
route and 150 for an external OSPF route, which are both lower than the 170 preference assigned to all
BGP routes.
This example shows a roung policy that matches routes from specic next hops and sets a preference.
If a route does not match the rst term, it is evaluated by the second term.
Topology
In the sample network, Device R1 and Device R3 have EBGP sessions with Device R2.
On Device R2, an import policy takes the following acons:
• For routes received through BGP from next-hop 10.0.0.1 (Device R1), set the route preference to 10.
• For routes received through BGP from next-hop 10.1.0.2 (Device R3), set the route preference to 15.
Figure 11 on page 120 shows the sample network.
Figure 11: BGP Preference Value Topology
"CLI Quick Conguraon" on page 121 shows the conguraon for all of the devices in Figure 11 on
page 120.
The secon "No Link Title" on page 122 describes the steps on Device R2.
120
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 121
Procedure | 122
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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 export send-direct
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.0.0.2
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
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 lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp group ext type external
set protocols bgp group ext import set-preference
set protocols bgp group ext export send-direct
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 send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set policy-options policy-statement set-preference term term1 from protocol bgp
121
set policy-options policy-statement set-preference term term1 from next-hop 10.0.0.1
set policy-options policy-statement set-preference term term1 then preference 10
set policy-options policy-statement set-preference term term2 from protocol bgp
set policy-options policy-statement set-preference term term2 from next-hop 10.1.0.2
set policy-options policy-statement set-preference term term2 then preference 15
set routing-options autonomous-system 200
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 protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.1.0.1
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 300
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R2:
1. Congure the device interfaces.
[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
122
2. Congure the local autonomous system.
[edit routing-options]
user@R2# set autonomous-system 200
3. Congure the roung policy that sends direct routes.
[edit policy-options policy-statement send-direct term 1]
user@R2# set from protocol direct
user@R2# set then accept
4. Congure the roung policy that changes the preference of received routes.
[edit policy-options policy-statement set-preference]
user@R2# set term term1 from protocol bgp
user@R2# set term term1 from next-hop 10.0.0.1
user@R2# set term term1 then preference 10
user@R2# set term term2 from protocol bgp
user@R2# set term term2 from next-hop 10.1.0.2
user@R2# set term term2 then preference 15
5. Congure the external peering with Device R2.
[edit protocols bgp group ext]
user@R2# set type external
user@R2# set export send-direct
user@R2# set neighbor 10.0.0.1 peer-as 100
user@R2# set neighbor 10.1.0.2 peer-as 300
6. Apply the set-preference policy as an import policy.
This aects Device R2’s roung table and has no impact on Device R1 and Device R3.
[edit protocols bgp group ext]
user@R2# set import set-preference
123
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
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;
}
}
}
lo0 {
unit 0{
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
type external;
import set-preference;
export send-direct;
neighbor 10.0.0.1 {
peer-as 100;
}
neighbor 10.1.0.2 {
peer-as 300;
}
124
}
}
user@R2# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
policy-statement set-preference {
term term1 {
from {
protocol bgp;
next-hop 10.0.0.1;
}
then {
preference 10;
}
}
term term2 {
from {
protocol bgp;
next-hop 10.1.0.2;
}
then {
preference 15;
}
}
}
user@R2# show routing-options
autonomous-system 200;
If you are done conguring the device, enter commit from conguraon mode.
125
Vericaon
IN THIS SECTION
Verifying the Preference | 126
Conrm that the conguraon is working properly.
Verifying the Preference
Purpose
Make sure that the roung tables on Device R1 and Device R2 reect the fact that Device R1 is using
the congured EBGP preference of 8, and Device R2 is using the default EBGP preference of 170.
Acon
From operaonal mode, enter the show route protocols bgp command.
user@R2> show route protocols bgp
inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/30 [BGP/10] 04:42:23, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
10.1.0.0/30 [BGP/15] 04:42:23, localpref 100
AS path: 300 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
192.168.0.1/32 *[BGP/10] 04:42:23, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
192.168.0.3/32 *[BGP/15] 04:42:23, localpref 100
AS path: 300 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
126
Meaning
The output shows that on Device R2, the preference values have been changed to 15 for routes learned
from Device R3, and the preference values have been changed to 10 for routes learned from Device R1.
RELATED DOCUMENTATION
Route Preferences Overview
Understanding External BGP Peering Sessions
Example: Enabling BGP Route Adversements
IN THIS SECTION
Requirements | 128
Overview | 128
Conguraon | 129
Vericaon | 135
Junos OS does not adverse the routes learned from one EBGP peer back to the same external BGP
(EBGP) peer. In addion, the soware does not adverse those routes back to any EBGP peers that are
in the same autonomous system (AS) as the originang peer, regardless of the roung instance. You can
modify this behavior by including the advertise-peer-as statement in the conguraon.
If you include the advertise-peer-as statement in the conguraon, BGP adverses the route regardless of
this check.
To restore the default behavior, include the no-advertise-peer-as statement in the conguraon:
no-advertise-peer-as;
The route suppression default behavior is disabled if the as-override statement is included in the
conguraon. If you include both the as-override and no-advertise-peer-as statements in the conguraon,
the no-advertise-peer-as statement is ignored.
127
Requirements
No special conguraon beyond device inializaon is required before you congure this example.
NOTE: This example was updated and re-validated on Junos release 21.2R1.
Overview
IN THIS SECTION
Topology | 128
This example shows three roung devices with external BGP (EBGP) connecons. Device R2 has an
EBGP connecon to Device R1 and another EBGP connecon to Device R3. Although separated by
Device R2 which is in AS 64511, Device R1 and Device R3 are in the same AS (AS 64512). Device R1
and Device R3 adverse into BGP direct routes to their own loopback interface addresses.
Device R2 receives these loopback interface routes, and the advertise peer-as statement allows Device R2
to adverse them. Specically, Device R1 sends the 192.168.0.1 route to Device R2, and because
Device R2 has the advertise peer-as congured, Device R2 can send the 192.168.0.1 route to Device R3.
Likewise, Device R3 sends the 192.168.0.3 route to Device R2, and advertise peer-as enables Device R2
to forward the route to Device R1.
To enable Device R1 and Device R3 to accept routes that contain their own AS number in the AS path,
the loops 2 statement is required on Device R1 and Device R3.
Topology
Figure 12: BGP Topology for adverse-peer-as
128
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 129
Procedure | 130
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces xe-0/2/0 description R1-to-R2
set interfaces xe-0/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 family inet unicast loops 2
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext peer-as 64511
set protocols bgp group ext neighbor 10.0.0.2
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 64512
Device R2
set interfaces xe-0/2/0 description R2-to-R1
set interfaces xe-0/2/0 unit 0 family inet address 10.0.0.2/30
set interfaces xe-0/2/1 description R2-to-R3
set interfaces xe-0/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 ext type external
set protocols bgp group ext advertise-peer-as
set protocols bgp group ext export send-direct
set protocols bgp group ext neighbor 10.0.0.1 peer-as 64512
129
set protocols bgp group ext neighbor 10.1.0.2 peer-as 64512
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 64511
Device R3
set interfaces xe-0/2/0 description R3-to-R2
set interfaces xe-0/2/0 unit 0 family inet address 10.1.0.2/30
set interfaces lo0 unit 0 family inet address 192.168.0.3/32
set protocols bgp family inet unicast loops 2
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext peer-as 64511
set protocols bgp group ext neighbor 10.1.0.1
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 64512
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R1:
1. Congure the device interfaces.
[edit interfaces]
user@R1# set xe-0/2/0 description R1-to-R2
user@R1# set xe-0/2/0 unit 0 family inet address 10.0.0.1/30
user@R1# set lo0 unit 0 family inet address 192.168.0.1/32
2. Congure BGP.
[edit protocols bgp group ext]
user@R1# set type external
130
user@R1# set peer-as 64511
user@R1# set neighbor 10.0.0.2
3. Prevent routes from Device R3 from being hidden on Device R1 by including the loops 2 statement.
The loops 2 statement means that the local device’s own AS number can appear in the AS path up to
one me without causing the route to be hidden. The route is hidden if the local device’s AS number
is detected in the path two or more mes.
[edit protocols bgp family inet unicast]
user@R1# set loops 2
4. Congure the roung policy that sends direct routes.
[edit policy-options policy-statement send-direct term 1]
user@R1# set from protocol direct
user@R1# set then accept
5. Apply the export policy to the BGP peering session with Device R2.
[edit protocols bgp group ext]
user@R1# set export send-direct
6. Congure the autonomous system (AS) number.
[edit routing-options ]
user@R1# set autonomous-system 64512
Step-by-Step Procedure
To congure Device R2:
1. Congure the device interfaces.
[edit interfaces]
user@R2# set xe-0/2/0 description R2-to-R1
user@R2# set xe-0/2/0 unit 0 family inet address 10.0.0.2/30
user@R2# set xe-0/2/1 description R2-to-R3
131
user@R2# set xe-0/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
2. Congure BGP.
[edit protocols bgp group ext]
user@R2# set type external
user@R2# set neighbor 10.0.0.1 peer-as 64512
user@R2# set neighbor 10.1.0.2 peer-as 64512
3. Congure Device R2 to adverse routes learned from one EBGP peer to another EBGP peer in the
same AS.
In other words, adverse to Device R1 routes learned from Device R3 (and the reverse), even though
Device R1 and Device R3 are in the same AS.
[edit protocols bgp group ext]
user@R2# set advertise-peer-as
4. Congure a roung policy that sends direct routes.
[edit policy-options policy-statement send-direct term 1]
user@R2# set from protocol direct
user@R2# set then accept
5. Apply the export policy.
[edit protocols bgp group ext]
user@R2# set export send-direct
6. Congure the AS number.
[edit routing-options]
user@R2# set autonomous-system 64511
132
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
Device R1
user@R1# show interfaces
xe-0/2/0 {
description R1-to-R2;
unit 0 {
family inet {
address 10.0.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
user@R1# show protocols
bgp {
family inet {
unicast {
loops 2;
}
}
group ext {
type external;
export send-direct;
peer-as 64511;
neighbor 10.0.0.2;
133
}
}
user@R1# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
user@R1# show routing-options
autonomous-system 64512;
Device R2
user@R2# show interfaces
xe-0/2/0 {
description R2-to-R1;
unit 0 {
family inet {
address 10.0.0.2/30;
}
}
}
xe-0/2/1 {
description R2-to-R3;
unit 0 {
family inet {
address 10.1.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
134
}
}
user@R2# show protocols
bgp {
group ext {
type external;
advertise-peer-as;
export send-direct;
neighbor 10.0.0.1 {
peer-as 64512;
}
neighbor 10.1.0.2 {
peer-as 64512;
}
}
}
user@R2# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
user@R2# show routing-options
autonomous-system 64511;
If you are done conguring the devices, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the BGP Routes | 136
135
Conrm that the conguraon is working properly.
Verifying the BGP Routes
Purpose
Make sure that the roung tables on Device R1 and Device R3 contain the expected routes.
Acon
1. On Device R2, deacvate the advertise-peer-as statement in the BGP conguraon.
[edit protocols bgp group ext]
user@R2# deactivate advertise-peer-as
user@R2# commit
2. On Device R3, deacvate the loops statement in the BGP conguraon.
[edit protocols bgp family inet unicast ]
user@R3# deactivate unicast loops
user@R3# commit
3. On Device R1, check to see what routes are adversed to Device R2.
user@R1> show route advertising-protocol bgp 10.0.0.2
inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/30 Self I
* 192.168.0.1/32 Self I
4. On Device R2, check to see what routes are received from Device R1.
user@R2> show route receive-protocol bgp 10.0.0.1
inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.0.0.0/30 10.0.0.1 64512 I
* 192.168.0.1/32 10.0.0.1 64512 I
136
5. On Device R2, check to see what routes are adversed to Device R3.
user@R2> show route advertising-protocol bgp 10.1.0.2
inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/30 Self I
* 10.1.0.0/30 Self I
* 192.168.0.2/32 Self I
6. On Device R2, acvate the advertise-peer-as statement in the BGP conguraon.
[edit protocols bgp group ext]
user@R2# activate advertise-peer-as
user@R2# commit
7. On Device R2, recheck the routes that are adversed to Device R3.
user@R2> show route advertising-protocol bgp 10.1.0.2
inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/30 Self I
* 10.1.0.0/30 Self I
* 192.168.0.1/32 Self 64512 I
* 192.168.0.2/32 Self I
* 192.168.0.3/32 10.1.0.2 64512 I
8. On Device R3, check the routes that are received from Device R2.
user@R3> show route receive-protocol bgp 10.1.0.1
inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/30 10.1.0.1 64511 I
10.1.0.0/30 10.1.0.1 64511 I
* 192.168.0.2/32 10.1.0.1 64511 I
137
9. On Device R3, acvate the loops statement in the BGP conguraon.
[edit protocols bgp family inet unicast ]
user@R3# activate unicast loops
user@R3# commit
10. On Device R3, recheck the routes that are received from Device R2.
user@R3> show route receive-protocol bgp 10.1.0.1
inet.0: 6 destinations, 8 routes (6 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/30 10.1.0.1 64511 I
10.1.0.0/30 10.1.0.1 64511 I
* 192.168.0.1/32 10.1.0.1 64511 64512 I
* 192.168.0.2/32 10.1.0.1 64511 I
Meaning
First the advertise-peer-as statement and the loops statement are deacvated so that the default behavior
can be examined. Device R1 sends to Device R2 a route to Device R1’s loopback interface address,
192.168.0.1/32. Device R2 does not adverse this route to Device R3. Aer acvang the advertise-
peer-as statement, Device R2 does adverse the 192.168.0.1/32 route to Device R3. Device R3 does not
accept this route unl aer the loops statement is acvated.
RELATED DOCUMENTATION
Example: Conguring a Layer 3 VPN with Route Reecon and AS Override
Example: Rejecng Known Invalid Routes
IN THIS SECTION
Requirements | 139
Overview | 139
138
Conguraon | 139
Vericaon | 141
This example shows how to create route-based match condions for a roung policy.
Requirements
Before you begin, be sure your router interfaces and protocols are correctly congured.
Overview
IN THIS SECTION
Topology | 139
In this example, you create a policy called rejectpolicy1 that rejects routes with a mask of /8 and greater
(/8, /9, /10, and so on) that have the rst 8 bits set to 0. This policy also accepts routes less than 8 bits
in length by creang a mask of 0/0 up to /7.
Topology
Conguraon
IN THIS SECTION
Procedure | 140
139
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set policy-options policy-statement rejectpolicy1 term rejectterm1 from route-filter 0.0.0.0/0
upto /7 accept
set policy-options policy-statement rejectpolicy1 term rejectterm1 from route-filter 0.0.0.0/8
orlonger reject
set policy-options policy-statement test term 1 from protocol direct
Step-by-Step Procedure
To create a policy that rejects known invalid routes:
1. Create the roung policy.
[edit]
user@host# edit policy-options policy-statement rejectpolicy1
2. Create the policy term.
[edit policy-options policy-statement rejectpolicy1]
user@host# edit term rejectterm1
3. Create a mask that species which routes to accept.
[edit policy-options policy-statement rejectpolicy1 term rejectterm1]
user@host# set from route-filter 0/0 upto /7 accept
4. Create a mask that species which routes to reject.
[edit policy-options policy-statement rejectpolicy1 term rejectterm1]
user@host# set from route-filter 0/8 orlonger reject
140
Results
Conrm your conguraon by entering the show policy-opons command from conguraon mode. If
the output does not display the intended conguraon, repeat the conguraon instrucons in this
example to correct it.
user@host# show policy-options
policy-statement rejectpolicy1 {
term rejectterm1 {
from {
route-filter 0.0.0.0/0 upto /7 accept;
route-filter 0.0.0.0/8 orlonger reject;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Route-Based Match Condions | 141
To conrm that the conguraon is working properly, perform these tasks:
Verifying the Route-Based Match Condions
Purpose
Verify that the policy and term are congured on the device with the appropriate route-based match
condions.
Acon
From operaonal mode, enter the show policy-opons command.
141
RELATED DOCUMENTATION
Route Filter Match Condions | 72
Example: Grouping Source and Desnaon Prexes into a Forwarding Class | 673
Example: Using Roung Policy in an ISP Network
IN THIS SECTION
Requirements | 142
Overview | 142
Set Commands for All Devices in the Topology | 145
Conguring Device Customer-1 | 153
Conguring Device Customer-2 | 156
Conguring Devices ISP-1 and ISP-2 | 160
Conguring Device ISP-3 | 167
Conguring Device Exchange-2 | 174
Conguring Device Private-Peer-2 | 177
Vericaon | 183
This example is a case study in how roung policies might be used in a typical Internet service provider
(ISP) network.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 143
142
In this network example, the ISP’s AS number is 64510. The ISP has two transit peers (AS 64514 and
AS 64515) to which it connects at an exchange point. The ISP is also connected to two private peers
(AS 64513 and AS 64516) with which it exchanges specic customer routes. The ISP has two customers
(AS 64511 and AS 64512).
The ISP policies are congured in an outbound direcon. That is, the example focuses on the routes that
the ISP announces to its peers and customers, and includes the following:
1. The ISP has been assigned AS 64510 and the roung space of 172.16.32.0/21. With the excepon
of the two customer networks, all other customer routes are simulated with stac routes.
2. The exchange peers are used for transit service to other porons of the Internet. This means that the
ISP is accepng all routes (the full Internet roung table) from those BGP peers. To help maintain an
opmized Internet roung table, the ISP is congured to adverse only two aggregate routes to the
transit peers.
3. The ISP administrators want all data to the private peers to use the direct links. As a result, all the
customer routes from the ISP are adversed to those private peers. These peers then adverse all
their customer routes to the ISP.
4. Finally, each customer has a dierent set of requirements. Customer-1 requires a singe default route.
Customer-2 requires specic routes.
Topology
Figure 13 on page 144 shows the sample network.
143
Figure 13: ISP Network Example
144
Set Commands for All Devices in the Topology
IN THIS SECTION
CLI Quick Conguraon | 145
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device Customer-1
set interfaces fe-1/2/3 unit 0 description to_ISP-3
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.8/32
set protocols bgp group ext type external
set protocols bgp group ext export send-statics
set protocols bgp group ext peer-as 64510
set protocols bgp group ext neighbor 10.1.0.5
set policy-options policy-statement send-statics term static-routes from protocol static
set policy-options policy-statement send-statics term static-routes then accept
set routing-options static route 172.16.40.0/25 reject
set routing-options static route 172.16.40.128/25 reject
set routing-options static route 172.16.41.0/25 reject
set routing-options static route 172.16.41.128/25 reject
set routing-options autonomous-system 64511
Device Customer-2
set interfaces fe-1/2/1 unit 0 description to_ISP-3
set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.10/30
set interfaces fe-1/2/0 unit 0 description to-Private-Peer-2
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.21/30
set interfaces lo0 unit 0 family inet address 192.168.0.9/32
set protocols bgp group ext type external
set protocols bgp group ext import inbound-routes
set protocols bgp group ext export outbound-routes
145
set protocols bgp group ext neighbor 10.0.0.9 peer-as 64510
set protocols bgp group ext neighbor 10.0.0.22 peer-as 64516
set policy-options policy-statement inbound-routes term AS64510-primary from protocol bgp
set policy-options policy-statement inbound-routes term AS64510-primary from as-path AS64510-
routes
set policy-options policy-statement inbound-routes term AS64510-primary then local-preference 200
set policy-options policy-statement inbound-routes term AS64510-primary then accept
set policy-options policy-statement inbound-routes term AS64516-backup from protocol bgp
set policy-options policy-statement inbound-routes term AS64516-backup from as-path AS64516-
routes
set policy-options policy-statement inbound-routes term AS64516-backup then local-preference 50
set policy-options policy-statement inbound-routes term AS64516-backup then accept
set policy-options policy-statement outbound-routes term statics from protocol static
set policy-options policy-statement outbound-routes term statics then accept
set policy-options policy-statement outbound-routes term internal-bgp-routes from protocol bgp
set policy-options policy-statement outbound-routes term internal-bgp-routes from as-path my-own-
routes
set policy-options policy-statement outbound-routes term internal-bgp-routes then accept
set policy-options policy-statement outbound-routes term no-transit then reject
set policy-options as-path my-own-routes "()"
set policy-options as-path AS64510-routes "64510 .*"
set policy-options as-path AS64516-routes "64516 .*"
set routing-options static route 172.16.44.0/26 reject
set routing-options static route 172.16.44.64/26 reject
set routing-options static route 172.16.44.128/26 reject
set routing-options static route 172.16.44.192/26 reject
set routing-options autonomous-system 64512
Device ISP-1
set interfaces fe-1/2/0 unit 0 description to_ISP-3
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_ISP-2
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_Private-Peer-1
set interfaces fe-1/2/2 unit 0 family inet address 10.2.0.2/30
set interfaces fe-1/2/3 unit 0 description to_Exchange-1
set interfaces fe-1/2/3 unit 0 family inet address 10.2.0.6/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 internal-peers
146
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_64513 type external
set protocols bgp group to_64513 export private-peer
set protocols bgp group to_64513 peer-as 64513
set protocols bgp group to_64513 neighbor 10.2.0.1
set protocols bgp group to_64514 type external
set protocols bgp group to_64514 export exchange-peer
set protocols bgp group to_64514 peer-as 64514
set protocols bgp group to_64514 neighbor 10.2.0.5
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 exchange-peer term AS64510-Aggregate from protocol aggregate
set policy-options policy-statement exchange-peer term AS64510-Aggregate from route-filter
172.16.32.0/21 exact
set policy-options policy-statement exchange-peer term AS64510-Aggregate then accept
set policy-options policy-statement exchange-peer term Customer-2-Aggregate from protocol
aggregate
set policy-options policy-statement exchange-peer term Customer-2-Aggregate from route-filter
172.16.40.0/22 exact
set policy-options policy-statement exchange-peer term Customer-2-Aggregate then accept
set policy-options policy-statement exchange-peer term reject-all-other-routes then reject
set policy-options policy-statement internal-peers term statics from protocol static
set policy-options policy-statement internal-peers term statics then accept
set policy-options policy-statement internal-peers term next-hop-self then next-hop self
set policy-options policy-statement private-peer term statics from protocol static
set policy-options policy-statement private-peer term statics then accept
set policy-options policy-statement private-peer term isp-and-customer-routes from protocol bgp
set policy-options policy-statement private-peer term isp-and-customer-routes from route-filter
172.16.32.0/21 orlonger
set policy-options policy-statement private-peer term isp-and-customer-routes then accept
set policy-options policy-statement private-peer term reject-all then reject
set routing-options static route 172.16.32.0/24 reject
set routing-options static route 172.16.33.0/24 reject
set routing-options aggregate route 172.16.32.0/21
set routing-options aggregate route 172.16.40.0/22
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 64510
147
Device ISP-2
set interfaces fe-1/2/1 unit 0 description to_ISP-1
set interfaces fe-1/2/1 unit 0 family inet address 10.1.0.1/30
set interfaces fe-1/2/2 unit 0 description to_ISP-3
set interfaces fe-1/2/2 unit 0 family inet address 10.0.0.6/30
set interfaces fe-1/2/3 unit 0 description to_Private-Peer-2
set interfaces fe-1/2/3 unit 0 family inet address 10.3.0.6/30
set interfaces fe-1/2/0 unit 0 description to_Exchange-2
set interfaces fe-1/2/0 unit 0 family inet address 10.3.0.2/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 export internal-peers
set protocols bgp group int neighbor 192.168.0.1
set protocols bgp group int neighbor 192.168.0.3
set protocols bgp group AS-64516 type external
set protocols bgp group AS-64516 export private-peer
set protocols bgp group AS-64516 peer-as 64516
set protocols bgp group AS-64516 neighbor 10.3.0.5
set protocols bgp group AS-64515 type external
set protocols bgp group AS-64515 export exchange-peer
set protocols bgp group AS-64515 peer-as 64515
set protocols bgp group AS-64515 neighbor 10.3.0.1
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 exchange-peer term AS64510-Aggregate from protocol aggregate
set policy-options policy-statement exchange-peer term AS64510-Aggregate from route-filter
172.16.32.0/21 exact
set policy-options policy-statement exchange-peer term AS64510-Aggregate then accept
set policy-options policy-statement exchange-peer term Customer-2-Aggregate from protocol
aggregate
set policy-options policy-statement exchange-peer term Customer-2-Aggregate from route-filter
172.16.44.0/23 exact
set policy-options policy-statement exchange-peer term Customer-2-Aggregate then accept
set policy-options policy-statement exchange-peer term reject-all-other-routes then reject
set policy-options policy-statement internal-peers term statics from protocol static
set policy-options policy-statement internal-peers term statics then accept
set policy-options policy-statement internal-peers term next-hop-self then next-hop self
set policy-options policy-statement private-peer term statics from protocol static
set policy-options policy-statement private-peer term statics then accept
148
set policy-options policy-statement private-peer term isp-and-customer-routes from protocol bgp
set policy-options policy-statement private-peer term isp-and-customer-routes from route-filter
172.16.32.0/21 orlonger
set policy-options policy-statement private-peer term isp-and-customer-routes then accept
set policy-options policy-statement private-peer term reject-all then reject
set routing-options static route 172.16.34.0/24 reject
set routing-options static route 172.16.35.0/24 reject
set routing-options aggregate route 172.16.44.0/23
set routing-options aggregate route 172.16.32.0/21
set routing-options router-id 192.168.0.2
set routing-options autonomous-system 64510
Device ISP-3
set interfaces fe-1/2/0 unit 0 description to_ISP-1
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_ISP-2
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_Customer-1
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_Customer-2
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.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 export internal-peers
set protocols bgp group int neighbor 192.168.0.1
set protocols bgp group int neighbor 192.168.0.2
set protocols bgp group to_64511 type external
set protocols bgp group to_64511 export customer-1-peer
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 customer-2-peer
set protocols bgp group to_64512 neighbor 10.0.0.10 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 customer-1-peer term defaut-route from route-filter
0.0.0.0/0 exact
set policy-options policy-statement customer-1-peer term defaut-route then accept
set policy-options policy-statement customer-1-peer term reject-all-other-routes then reject
set policy-options policy-statement customer-2-peer term statics from protocol static
149
set policy-options policy-statement customer-2-peer term statics then accept
set policy-options policy-statement customer-2-peer term isp-and-customer-routes from protocol
bgp
set policy-options policy-statement customer-2-peer term isp-and-customer-routes from route-
filter 172.16.32.0/21 orlonger
set policy-options policy-statement customer-2-peer term isp-and-customer-routes then accept
set policy-options policy-statement customer-2-peer term default-route from route-filter
0.0.0.0/0 exact
set policy-options policy-statement customer-2-peer term default-route then accept
set policy-options policy-statement customer-2-peer term reject-all-other-routes then reject
set policy-options policy-statement if-upstream-routes-exist term only-certain-contributing-
routes from route-filter 172.16.8.0/21 exact
set policy-options policy-statement if-upstream-routes-exist term only-certain-contributing-
routes then accept
set policy-options policy-statement if-upstream-routes-exist term reject-all-other-routes then
reject
set policy-options policy-statement internal-peers term statics from protocol static
set policy-options policy-statement internal-peers term statics then accept
set policy-options policy-statement internal-peers term next then next-hop self
set routing-options static route 172.16.36.0/24 reject
set routing-options static route 172.16.37.0/24 reject
set routing-options static route 172.16.38.0/24 reject
set routing-options static route 172.16.39.0/24 reject
set routing-options generate route 0.0.0.0/0 policy if-upstream-routes-exist
set routing-options router-id 192.168.0.3
set routing-options autonomous-system 64510
Device Exchange-1
set interfaces fe-1/2/3 unit 0 description to_ISP-1
set interfaces fe-1/2/3 unit 0 family inet address 10.2.0.5/30
set interfaces fe-1/2/2 unit 0 description to_Exchange-2
set interfaces fe-1/2/2 unit 0 family inet address 10.3.0.42/30
set interfaces fe-1/2/1 unit 0 description to_Private-Peer-1
set interfaces fe-1/2/1 unit 0 family inet address 10.3.0.45/30
set interfaces lo0 unit 0 family inet address 192.168.0.6/32
set protocols bgp group ext type external
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 64510
set protocols bgp group ext neighbor 10.2.0.6
set protocols bgp group ext neighbor 10.3.0.41 peer-as 64515
set policy-options policy-statement send-static from protocol static
150
set policy-options policy-statement send-static then accept
set routing-options static route 172.16.8.0/21 reject
set routing-options autonomous-system 64514
Device Exchange-2
set interfaces fe-1/2/0 unit 0 description to_ISP-2
set interfaces fe-1/2/0 unit 0 family inet address 10.3.0.1/30
set interfaces fe-1/2/2 unit 0 description to_Exchange-1
set interfaces fe-1/2/2 unit 0 family inet address 10.3.0.41/30
set interfaces fe-1/2/1 unit 0 description to_Private-Peer-2
set interfaces fe-1/2/1 unit 0 family inet address 10.3.0.49/30
set interfaces lo0 unit 0 family inet address 192.168.0.7/32
set protocols bgp group ext type external
set protocols bgp group ext export outbound-routes
set protocols bgp group ext neighbor 10.3.0.2 peer-as 64510
set protocols bgp group ext neighbor 10.3.0.50 peer-as 64516
set protocols bgp group ext neighbor 10.3.0.42 peer-as 64514
set policy-options policy-statement outbound-routes term statics from protocol static
set policy-options policy-statement outbound-routes term statics then accept
set routing-options autonomous-system 64515
set routing-options static route 172.16.16.0/21 reject
Device Private-Peer-1
set interfaces fe-1/2/2 unit 0 description to_ISP-1
set interfaces fe-1/2/2 unit 0 family inet address 10.2.0.1/30
set interfaces fe-1/2/1 unit 0 description to_Exchange-1
set interfaces fe-1/2/1 unit 0 family inet address 10.3.0.46/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.2.0.2
set routing-options autonomous-system 64513
Device Private-Peer-2
set interfaces fe-1/2/3 unit 0 description to_ISP-2
set interfaces fe-1/2/3 unit 0 family inet address 10.3.0.5/30
set interfaces fe-1/2/0 unit 0 description to_Customer-1
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.22/30
151
set interfaces fe-1/2/1 unit 0 description to_Exchange-2
set interfaces fe-1/2/1 unit 0 family inet address 10.3.0.50/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 export outbound-routes
set protocols bgp group ext peer-as 64510
set protocols bgp group ext neighbor 10.3.0.6
set protocols bgp group to-64512 type external
set protocols bgp group to-64512 peer-as 64512
set protocols bgp group to-64512 neighbor 10.0.0.21
set protocols bgp group to-64512 export internal-routes
set protocols bgp group to-64515 type external
set protocols bgp group to-64515 export outbound-routes
set protocols bgp group to-64515 peer-as 64515
set protocols bgp group to-64515 neighbor 10.3.0.49
set policy-options policy-statement if-upstream-routes-exist term as-64515-routes from route-
filter 172.16.16.0/21 exact
set policy-options policy-statement if-upstream-routes-exist term as-64515-routes then accept
set policy-options policy-statement if-upstream-routes-exist term reject-all-other-routes then
reject
set policy-options policy-statement internal-routes term statics from protocol static
set policy-options policy-statement internal-routes term statics then accept
set policy-options policy-statement internal-routes term default-route from route-filter
0.0.0.0/0 exact
set policy-options policy-statement internal-routes term default-route then accept
set policy-options policy-statement internal-routes term reject-all-other-routes then reject
set policy-options policy-statement outbound-routes term statics from protocol static
set policy-options policy-statement outbound-routes term statics then accept
set policy-options policy-statement outbound-routes term allowed-bgp-routes from as-path my-own-
routes
set policy-options policy-statement outbound-routes term allowed-bgp-routes from as-path AS64512-
routes
set policy-options policy-statement outbound-routes term allowed-bgp-routes then accept
set policy-options policy-statement outbound-routes term no-transit then reject
set policy-options as-path my-own-routes "()"
set policy-options as-path AS64512-routes 64512
set routing-options static route 172.16.24.0/25 reject
set routing-options static route 172.16.24.128/25 reject
set routing-options static route 172.16.25.0/26 reject
set routing-options static route 172.16.25.64/26 reject
set routing-options generate route 0.0.0.0/0 policy if-upstream-routes-exist
set routing-options autonomous-system 64516
152
Conguring Device Customer-1
IN THIS SECTION
Procedure | 153
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
Device Customer-1 has mulple stac routes congured to simulate customer routes. These routes are
sent to the ISP.
To congure Device Customer-1:
1. Congure the device interfaces.
[edit interfaces]
user@Customer-1# set fe-1/2/3 unit 0 description to_ISP-3
user@Customer-1# set fe-1/2/3 unit 0 family inet address 10.1.0.6/30
user@Customer-1# set lo0 unit 0 family inet address 192.168.0.8/32
2. Congure the stac routes.
[edit routing-options static]
user@Customer-1# set route 172.16.40.0/25 reject
user@Customer-1# set route 172.16.40.128/25 reject
user@Customer-1# set route 172.16.41.0/25 reject
user@Customer-1# set route 172.16.41.128/25 reject
153
3. Congure the policy to send stac routes.
[edit policy-options policy-statement send-statics term static-routes]
user@Customer-1# set from protocol static
user@Customer-1# set then accept
4. Congure the external BGP (EBGP) connecon to the ISP.
[edit protocols bgp group ext]
user@Customer-1# set type external
user@Customer-1# set export send-statics
user@Customer-1# set peer-as 64510
user@Customer-1# set neighbor 10.1.0.5
5. Congure the autonomous system (AS) number.
[edit routing-options]
user@Customer-1# set autonomous-system 64511
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@Customer-1# show interfaces
fe-1/2/1 {
unit 0 {
description to_ISP-3;
family inet {
address 10.1.0.6/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.8/32;
154
}
}
}
user@Customer-1# show protocols
bgp {
group ext {
type external;
export send-statics;
peer-as 64510;
neighbor 10.1.0.5;
}
}
user@Customer-1# show policy-options
policy-statement send-statics {
term static-routes {
from protocol static;
then accept;
}
}
user@Customer-1# show routing-options
static {
route 172.16.40.0/25 reject;
route 172.16.40.128/25 reject;
route 172.16.41.0/25 reject;
route 172.16.41.128/25 reject;
}
autonomous-system 64511;
If you are done conguring the device, enter commit from conguraon mode.
155
Conguring Device Customer-2
IN THIS SECTION
Procedure | 156
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
Device Customer-2 has two stac routes congured to simulate customer routes. These routes are sent
to the ISP. Customer-2 has a link to the ISP, as well as a link to AS 8000. This customer has requested
specic customer routes from the ISP, as well as from AS 64516. Customer-2 wants to use the ISP for
transit service to the Internet, and has requested a default route from the ISP.
To congure Device Customer-2:
1. Congure the device interfaces.
[edit interfaces]
user@Customer-2# set fe-1/2/1 unit 0 description to_ISP-3
user@Customer-2# set fe-1/2/1 unit 0 family inet address 10.0.0.10/30
user@Customer-2# set fe-1/2/0 unit 0 description to-Private-Peer-2
user@Customer-2# set fe-1/2/0 unit 0 family inet address 10.0.0.21/30
user@Customer-2# set lo0 unit 0 family inet address 192.168.0.9/32
2. Congure the stac routes.
[edit routing-options static]
user@Customer-2# set route 172.16.44.0/26 reject
user@Customer-2# set route 172.16.44.64/26 reject
user@Customer-2# set route 172.16.44.128/26 reject
user@Customer-2# set route 172.16.44.192/26 reject
3. Congure the import roung policy.
156
The route with the highest local preference value is preferred. Routes from the ISP are preferred over
the same routes from Device Private-Peer-2
[edit policy-options policy-statement inbound-routes]
user@Customer-2# set term AS64510-primary from protocol bgp
user@Customer-2# set term AS64510-primary from as-path AS64510-routes
user@Customer-2# set term AS64510-primary then local-preference 200
user@Customer-2# set term AS64510-primary then accept
[edit policy-options policy-statement inbound-routes]
user@Customer-2# set term AS64516-backup from protocol bgp
user@Customer-2# set term AS64516-backup from as-path AS64516-routes
user@Customer-2# set term AS64516-backup then local-preference 50
user@Customer-2# set term AS64516-backup then accept
[edit policy-options]
user@Customer-2# set as-path AS64510-routes "64510 .*"
user@Customer-2# set as-path AS64516-routes "64516 .*"
4. Congure the export roung policy.
[edit policy-options policy-statement outbound-routes]
user@Customer-2# set term statics from protocol static
user@Customer-2# set term statics then accept
user@Customer-2# set term internal-bgp-routes from protocol bgp
user@Customer-2# set term internal-bgp-routes from as-path my-own-routes
user@Customer-2# set term internal-bgp-routes then accept
user@Customer-2# set term no-transit then reject
[edit policy-options]
user@Customer-2# set as-path my-own-routes "()"
5. Congure the external BGP (EBGP) connecon to the ISP and to Device Private-Peer-2.
[edit protocols bgp group ext]
user@Customer-2# set type external
user@Customer-2# set import inbound-routes
user@Customer-2# set export outbound-routes
user@Customer-2# set neighbor 10.0.0.9 peer-as 64510
user@Customer-2# set neighbor 10.0.0.22 peer-as 64516
157
6. Congure the autonomous system (AS) number.
[edit routing-options]
user@Customer-2# set autonomous-system 64512
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@Customer-2# show interfaces
fe-1/2/1 {
unit 0 {
description to_ISP-3;
family inet {
address 10.0.0.10/30;
}
}
}
fe-1/2/0 {
unit 0 {
description to-Private-Peer-2;
family inet {
address 10.0.0.21/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.9/32;
}
}
}
user@Customer-2# show protocols
bgp {
group ext {
158
type external;
import inbound-routes;
export outbound-routes;
neighbor 10.0.0.9 {
peer-as 64510;
}
neighbor 10.0.0.22 {
peer-as 64516;
}
}
}
user@Customer-2# show policy-options
policy-statement inbound-routes {
term AS64510-primary {
from {
protocol bgp;
as-path AS64510-routes;
}
then {
local-preference 200;
accept;
}
}
term AS64516-backup {
from {
protocol bgp;
as-path AS64516-routes;
}
then {
local-preference 50;
accept;
}
}
}
policy-statement outbound-routes {
term statics {
from protocol static;
then accept;
}
term internal-bgp-routes {
159
from {
protocol bgp;
as-path my-own-routes;
}
then accept;
}
term no-transit {
then reject;
}
}
as-path my-own-routes "()";
as-path AS64510-routes "64510 .*";
as-path AS64516-routes "64516 .*";
user@Customer-2# show routing-options
static {
route 172.16.44.0/26 reject;
route 172.16.44.64/26 reject;
route 172.16.44.128/26 reject;
route 172.16.44.192/26 reject;
}
autonomous-system 64512;
If you are done conguring the device, enter commit from conguraon mode.
Conguring Devices ISP-1 and ISP-2
IN THIS SECTION
Procedure | 160
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
160
Device ISP-1 and Device ISP-2 each have two policies congured: The private-peer policy and the
exchange-peer policy. Because of their similar conguraons, this example shows the step-by-step
conguraon only for Device ISP-2.
On Device ISP-2, the private-peer policy sends the ISP customer routes to Device Private-Peer-2. The
policy accepts all local stac routes (local Device ISP-2 customers) and all BGP routes in the
172.16.32.0/21 range (adversed by other ISP routers). These two policy terms represent the ISP
customer routes. The nal policy term rejects all other routes, which includes the enre Internet roung
table sent by the exchange peers. These routes do not need to be sent to Device Private-Peer-2 for two
reasons:
• The peer already maintains a connecon to Device Exchange-2 in our example, so the routes are
redundant.
• The private peer wants customer routes only. The private-peer policy accomplishes this goal. The
exchange-peer policy sends routes to Device Exchange-2.
In the example, only two routes need to be sent to Device Exchange-2:
• The aggregate route that represents the AS 64510 roung space of 172.16.32.0/21. This route is
congured as an aggregate route locally and is adversed by the exchange-peer policy.
• The address space assigned to Customer-2, 172.16.44.0/23. This smaller aggregate route needs to
be sent to Device Exchange-2 because the customer is also aached to the AS 64516 peer (Device
Private-Peer-2).
Sending these two routes to Device Exchange-2 allows other networks in the Internet to reach the
customer through either the ISP or the private peer. If just the private peer were to adverse the /23
network while the ISP maintained only its /21 aggregate, all trac desned for the customer would
transit AS 64516 only. Because the customer also wants routes from the ISP, the 172.16.44.0/23 route
is announced by Device ISP-2. Like the larger aggregate route, the 172.16.44.0/23 route is congured
locally and is adversed by the exchange-peer policy. The nal term in that policy rejects all routes,
including the specic customer networks of the ISP, the customer routes from Device Private-Peer-1,
the customer routes from Device Private-Peer-2, and the roung table from Device Exchange-1. In
essence, this nal term prevents the ISP from performing transit services for the Internet at large.
To congure Device ISP-2:
1. Congure the device interfaces.
[edit interfaces]
user@ISP-2# set fe-1/2/1 unit 0 description to_ISP-1
user@ISP-2# set fe-1/2/1 unit 0 family inet address 10.1.0.1/30
user@ISP-2# set fe-1/2/2 unit 0 description to_ISP-3
user@ISP-2# set fe-1/2/2 unit 0 family inet address 10.0.0.6/30
161
user@ISP-2# set fe-1/2/3 unit 0 description to_Private-Peer-2
user@ISP-2# set fe-1/2/3 unit 0 family inet address 10.3.0.6/30
user@ISP-2# set fe-1/2/0 unit 0 description to_Exchange-2
user@ISP-2# set fe-1/2/0 unit 0 family inet address 10.3.0.2/30
user@ISP-2# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure the interior gateway protocol (IGP).
[edit protocols ospf area 0.0.0.0]
user@ISP-2# set interface fe-1/2/2.0
user@ISP-2# set interface fe-1/2/1.0
user@ISP-2# set interface lo0.0 passive
3. Congure the stac and aggregate routes.
[edit routing-options static]
user@ISP-2# set route 172.16.34.0/24 reject
user@ISP-2# set route 172.16.35.0/24 reject
[edit routing-options aggregate]
user@ISP-2# set route 172.16.44.0/23
user@ISP-2# set route 172.16.32.0/21
4. Congure the roung policies for the exchange peers.
[edit policy-options policy-statement exchange-peer]
user@ISP-2# set term AS64510-Aggregate from protocol aggregate
user@ISP-2# set term AS64510-Aggregate from route-filter 172.16.32.0/21 exact
user@ISP-2# set term AS64510-Aggregate then accept
user@ISP-2# set term Customer-2-Aggregate from protocol aggregate
user@ISP-2# set term Customer-2-Aggregate from route-filter 172.16.44.0/23 exact
user@ISP-2# set term Customer-2-Aggregate then accept
user@ISP-2# set term reject-all-other-routes then reject
5. Congure the roung policies for the internal peers.
[edit policy-options policy-statement internal-peers]
user@ISP-2# set term statics from protocol static
162
user@ISP-2# set term statics then accept
user@ISP-2# set term next-hop-self then next-hop self
6. Congure the roung policies for the private peer.
[edit policy-options policy-statement private-peer]
user@ISP-2# set term statics from protocol static
user@ISP-2# set term statics then accept
user@ISP-2# set term isp-and-customer-routes from protocol bgp
user@ISP-2# set term isp-and-customer-routes from route-filter 172.16.32.0/21 orlonger
user@ISP-2# set term isp-and-customer-routes then accept
user@ISP-2# set term reject-all then reject
7. Congure the internal BGP (IBGP) connecons to the other ISP devices.
[edit protocols bgp group int]
user@ISP-2# set type internal
user@ISP-2# set local-address 192.168.0.2
user@ISP-2# set export internal-peers
user@ISP-2# set neighbor 192.168.0.1
user@ISP-2# set neighbor 192.168.0.3
8. Congure the EBGP connecons to the exchange peer and the private peer.
[edit protocols bgp group AS-64516]
user@ISP-2# set type external
user@ISP-2# set export private-peer
user@ISP-2# set peer-as 64516
user@ISP-2# set neighbor 10.3.0.5
[edit protocols bgp group AS-64515]
user@ISP-2# set type external
user@ISP-2# set export exchange-peer
user@ISP-2# set peer-as 64515
user@ISP-2# set neighbor 10.3.0.1
163
9. Congure the autonomous system (AS) number and the router ID.
[edit routing-options]
user@ISP-2# set router-id 192.168.0.2
user@ISP-2# set autonomous-system 64510
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@ISP-2# show interfaces
fe-1/2/0 {
unit 0{
description to_Exchange-2;
family inet {
address 10.3.0.2/30;
}
}
}
fe-1/2/1 {
unit 0{
description to_ISP-1;
family inet {
address 10.1.0.1/30;
}
}
}
fe-1/2/2 {
unit 0 {
description to_ISP-3;
family inet {
address 10.0.0.6/30;
}
}
}
fe-1/2/3 {
unit 0 {
description to_Private-Peer-2;
164
family inet {
address 10.3.0.6/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@ISP-2# show protocols
bgp {
group int {
type internal;
local-address 192.168.0.2;
export internal-peers;
neighbor 192.168.0.1;
neighbor 192.168.0.3;
}
group AS-64516 {
type external;
export private-peer;
peer-as 64516;
neighbor 10.3.0.5;
}
group AS-64515 {
type external;
export exchange-peer;
peer-as 64515;
neighbor 10.3.0.1;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/2.0;
interface fe-1/2/1.0;
interface lo0.0 {
passive;
165
}
}
}
user@ISP-2# show policy-options
policy-statement exchange-peer {
term AS64510-Aggregate {
from {
protocol aggregate;
route-filter 172.16.32.0/21 exact;
}
then accept;
}
term Customer-2-Aggregate {
from {
protocol aggregate;
route-filter 172.16.44.0/23 exact;
}
then accept;
}
term reject-all-other-routes {
then reject;
}
}
policy-statement internal-peers {
term statics {
from protocol static;
then accept;
}
term next-hop-self {
then {
next-hop self;
}
}
}
policy-statement private-peer {
term statics {
from protocol static;
then accept;
}
term isp-and-customer-routes {
166
from {
protocol bgp;
route-filter 172.16.32.0/21 orlonger;
}
then accept;
}
term reject-all {
then reject;
}
}
user@ISP-2# show routing-options
static {
route 172.16.34.0/24 reject;
route 172.16.35.0/24 reject;
}
aggregate {
route 172.16.44.0/23;
route 172.16.32.0/21;
}
router-id 192.168.0.2;
autonomous-system 64510;
If you are done conguring the device, enter commit from conguraon mode.
Conguring Device ISP-3
IN THIS SECTION
Procedure | 167
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
167
On Device ISP-3, a separate policy is in place for each customer. The default route for Customer-1 is
being sent by the customer-1-peer policy. This policy nds the 0.0.0.0/0 default route in inet.0 and accepts
it. The policy also rejects all other routes, thereby not sending all BGP routes on the ISP router. The
customer-2-peer policy is for Customer-2 and contains the same policy terms, which also send the default
route and no other transit BGP routes. The addional terms in the customer-2-peer policy send the ISP
customer routes to Customer-2. Because there are local stac routes on Device ISP-3 that represent
local customers, these routes are sent as well as all other internal routes announced to the local router
by the other ISP routers.
If the upstream route from Device Exchange-1 (172.16.8.0/21) is present, Device ISP-3 generates a
default route.
To congure Device ISP-3:
1. Congure the device interfaces.
[edit interfaces]
user@ISP-3# set fe-1/2/0 unit 0 description to_ISP-1
user@ISP-3# set fe-1/2/0 unit 0 family inet address 10.0.0.1/30
user@ISP-3# set fe-1/2/2 unit 0 description to_ISP-2
user@ISP-3# set fe-1/2/2 unit 0 family inet address 10.0.0.5/30
user@ISP-3# set fe-1/2/3 unit 0 description to_Customer-1
user@ISP-3# set fe-1/2/3 unit 0 family inet address 10.1.0.5/30
user@ISP-3# set fe-1/2/1 unit 0 description to_Customer-2
user@ISP-3# set fe-1/2/1 unit 0 family inet address 10.0.0.9/30
user@ISP-3# set lo0 unit 0 family inet address 192.168.0.3/32
2. Congure the interior gateway protocol (IGP).
[edit protocols ospf area 0.0.0.0]
user@ISP-3# set interface fe-1/2/0.0
user@ISP-3# set interface fe-1/2/2.0
user@ISP-3# set interface lo0.0 passive
3. Congure the stac routes.
[edit routing-options static]
user@ISP-3# set route 172.16.36.0/24 reject
user@ISP-3# set route 172.16.37.0/24 reject
user@ISP-3# set route 172.16.38.0/24 reject
user@ISP-3# set route 172.16.39.0/24 reject
168
4. Congure a roung policy that generates a default stac route only if a certain upstream route
exists.
[edit policy-options policy-statement if-upstream-routes-exist term only-certain-
contributing-routes]
user@ISP-3# set from route-filter 172.16.8.0/21 exact
user@ISP-3# set then accept
[edit policy-options policy-statement if-upstream-routes-exist]
user@ISP-3# set term reject-all-other-routes then reject
[edit routing-options generate route 0.0.0.0/0]
user@ISP-3# set policy if-upstream-routes-exist
5. Congure the roung policy for Customer-1.
[edit policy-options policy-statement customer-1-peer]
user@ISP-3# set term defaut-route from route-filter 0.0.0.0/0 exact
user@ISP-3# set term defaut-route then accept
user@ISP-3# set term reject-all-other-routes then reject
6. Congure the roung policy for Customer-2.
[edit policy-options policy-statement customer-2-peer]
user@ISP-3# set term statics from protocol static
user@ISP-3# set term statics then accept
user@ISP-3# set term isp-and-customer-routes from protocol bgp
user@ISP-3# set term isp-and-customer-routes from route-filter 172.16.32.0/21 orlonger
user@ISP-3# set term isp-and-customer-routes then accept
user@ISP-3# set term default-route from route-filter 0.0.0.0/0 exact
user@ISP-3# set term default-route then accept
user@ISP-3# set term reject-all-other-routes then reject
7. Congure the roung policies for the internal peers.
[edit policy-options policy-statement internal-peers]
user@ISP-3# set term statics from protocol static
user@ISP-3# set term statics then accept
user@ISP-3# set term next then next-hop self
169
8. Congure the internal BGP (IBGP) connecons to the other ISP devices.
[edit protocols bgp group int]
user@ISP-3# set type internal
user@ISP-3# set local-address 192.168.0.3
user@ISP-3# set export internal-peers
user@ISP-3# set neighbor 192.168.0.1
user@ISP-3# set neighbor 192.168.0.2
9. Congure the EBGP connecons to the customer peers.
[edit protocols bgp group to_64511]
user@ISP-3# set type external
user@ISP-3# set export customer-1-peer
user@ISP-3# set neighbor 10.1.0.6 peer-as 64511
[edit protocols bgp group to_64512]
user@ISP-3# set type external
user@ISP-3# set export customer-2-peer
user@ISP-3# set neighbor 10.0.0.10 peer-as 64512
10. Congure the autonomous system (AS) number and the router ID.
[edit routing-options]
user@ISP-3# set router-id 192.168.0.3
user@ISP-3# set autonomous-system 64510
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@ISP-3# show interfaces
fe-1/2/0 {
unit 0 {
description to_ISP-1;
family inet {
address 10.0.0.1/30;
170
}
}
}
fe-1/2/1 {
unit 0 {
description to_Customer-2;
family inet {
address 10.0.0.9/30;
}
}
}
fe-1/2/2 {
unit 0 {
description to_ISP-2;
family inet {
address 10.0.0.5/30;
}
}
}
fe-1/2/3 {
unit 0 {
description to_Customer-1;
family inet {
address 10.1.0.5/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.3/32;
}
}
}
user@ISP-3# show protocols
bgp {
group int {
type internal;
local-address 192.168.0.3;
export internal-peers;
171
neighbor 192.168.0.1;
neighbor 192.168.0.2;
}
group to_64511 {
type external;
export customer-1-peer;
neighbor 10.1.0.6 {
peer-as 64511;
}
}
group to_64512 {
type external;
export customer-2-peer;
neighbor 10.0.0.10 {
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@ISP-3# show policy-options
policy-statement customer-1-peer {
term defaut-route {
from {
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term reject-all-other-routes {
then reject;
}
}
policy-statement customer-2-peer {
172
term statics {
from protocol static;
then accept;
}
term isp-and-customer-routes {
from {
protocol bgp;
route-filter 172.16.32.0/21 orlonger;
}
then accept;
}
term default-route {
from {
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term reject-all-other-routes {
then reject;
}
}
policy-statement if-upstream-routes-exist {
term only-certain-contributing-routes {
from {
route-filter 172.16.8.0/21 exact;
}
then accept;
}
term reject-all-other-routes {
then reject;
}
}
policy-statement internal-peers {
term statics {
from protocol static;
then accept;
}
term next {
then {
next-hop self;
}
173
}
}
user@ISP-3# show routing-options
static {
route 172.16.36.0/24 reject;
route 172.16.37.0/24 reject;
route 172.16.38.0/24 reject;
route 172.16.39.0/24 reject;
}
generate {
route 0.0.0.0/0 policy if-upstream-routes-exist;
}
router-id 192.168.0.3;
autonomous-system 64510;
If you are done conguring the device, enter commit from conguraon mode.
Conguring Device Exchange-2
IN THIS SECTION
Procedure | 174
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
Device Exchange-2 exchanges all BGP routes with all BGP peers. The outbound-routes policy for Device
Exchange-2 adverses locally dened stac routes using BGP. The exclusion of a nal then reject term
causes the default BGP export policy to take eect, which is to send all BGP routes to all external BGP
peers.
To congure Device Exchange-2:
174
1. Congure the device interfaces.
[edit interfaces]
user@Exchange-2# set fe-1/2/0 unit 0 description to_ISP-2
user@Exchange-2# set fe-1/2/0 unit 0 family inet address 10.3.0.1/30
user@Exchange-2# set fe-1/2/2 unit 0 description to_Exchange-1
user@Exchange-2# set fe-1/2/2 unit 0 family inet address 10.3.0.41/30
user@Exchange-2# set fe-1/2/1 unit 0 description to_Private-Peer-2
user@Exchange-2# set fe-1/2/1 unit 0 family inet address 10.3.0.49/30
user@Exchange-2# set lo0 unit 0 family inet address 192.168.0.7/32
2. Congure the stac routes.
[edit routing-options static]
set route 172.16.16.0/21 reject
3. Congure a roung policy that generates a default stac route only if certain internal routes exist.
[edit policy-options policy-statement outbound-routes term statics]
user@Exchange-2# set from protocol static
user@Exchange-2# set then accept
4. Congure the EBGP connecons to the customer peers.
[edit protocols bgp group ext]
user@Exchange-2# set type external
user@Exchange-2# set export outbound-routes
user@Exchange-2# set neighbor 10.3.0.2 peer-as 64510
user@Exchange-2# set neighbor 10.3.0.50 peer-as 64516
user@Exchange-2# set neighbor 10.3.0.42 peer-as 64514
5. Congure the autonomous system (AS) number.
[edit routing-options]
user@Exchange-2# set autonomous-system 64515
175
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@Exchange-2 show interfaces
fe-1/2/0 {
unit 0 {
description to_ISP-2;
family inet {
address 10.3.0.1/30;
}
}
}
fe-1/2/1 {
unit 0 {
description to_Private-Peer-2;
family inet {
address 10.3.0.49/30;
}
}
}
fe-1/2/2 {
unit 0 {
description to_Exchange-1;
family inet {
address 10.3.0.41/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.7/32;
}
}
}
user@Exchange-2# show protocols
bgp {
176
group ext {
type external;
export outbound-routes;
neighbor 10.3.0.2 {
peer-as 64510;
}
neighbor 10.3.0.50 {
peer-as 64516;
}
neighbor 10.3.0.42 {
peer-as 64514;
}
}
}
user@Exchange-2# show policy-options
policy-statement outbound-routes {
term statics {
from protocol static;
then accept;
}
}
user@Exchange-2# show routing-options
static {
route 172.16.16.0/21 reject;
}
autonomous-system 64515;
If you are done conguring the device, enter commit from conguraon mode.
Conguring Device Private-Peer-2
IN THIS SECTION
Procedure | 178
177
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
Device Private-Peer-2 performs two main funcons:
• Adverses routes local to AS 64516 to both the exchange peers and the ISP routers. The outbound-
routes policy adverses the local stac routes (that is, customers) on the router, and also adverses all
routes learned by BGP that originated in either AS 64516 or AS 64512. These routes include other
AS 64516 customer routes in addion to the AS 64512 customer. The AS routes are idened by an
AS path regular expression match criteria in the policy.
• Adverses the 0.0.0.0/0 default route to the AS 64512 customer router. To accomplish this, the
private peer creates a generated route for 0.0.0.0/0 locally on the router. This generated route is
further assigned a policy called if-upstream-routes-exist, which allows only certain routes to contribute
to the generated route, making it an acve route in the roung table. Once the route is acve, it can
be sent to the AS 64512 router using BGP and the congured policies. The if-upstream-routes-exist
policy accepts only the 172.16.32.0/21 route from Device Exchange-2, and rejects all other routes. If
the 172.16.32.0/21 route is withdrawn by the exchange peer, the private peer loses the 0.0.0.0/0
default route and withdraws the default route from the AS 64512 customer router.
To congure Device Private-Peer-2:
1. Congure the device interfaces.
[edit interfaces]
user@Private-Peer-2# set fe-1/2/3 unit 0 description to_ISP-2
user@Private-Peer-2# set fe-1/2/3 unit 0 family inet address 10.3.0.5/30
user@Private-Peer-2# set fe-1/2/0 unit 0 description to_Customer-1
user@Private-Peer-2# set fe-1/2/0 unit 0 family inet address 10.0.0.22/30
user@Private-Peer-2# set fe-1/2/1 unit 0 description to_Exchange-2
user@Private-Peer-2# set fe-1/2/1 unit 0 family inet address 10.3.0.50/30
user@Private-Peer-2# set lo0 unit 0 family inet address 192.168.0.5/32
2. Congure the stac routes.
[edit routing-options static]
user@Private-Peer-2# set route 172.16.24.0/25 reject
user@Private-Peer-2# set route 172.16.24.128/25 reject
178
user@Private-Peer-2# set route 172.16.25.0/26 reject
user@Private-Peer-2# set route 172.16.25.64/26 reject
3. Congure a roung policy that generates a default stac route only if certain internal routes exist.
[edit policy-options policy-statement if-upstream-routes-exist]
user@Private-Peer-2# set term as-64515-routes from route-filter 172.16.16.0/21 exact
user@Private-Peer-2# set term as-64515-routes then accept
user@Private-Peer-2# set term reject-all-other-routes then reject
[edit routing-options generate route 0.0.0.0/0]
user@Private-Peer-2# set policy if-upstream-routes-exist
4. Congure the roung policy that adverses local stac routes and the default route.
[edit policy-options policy-statement internal-routes]
user@Private-Peer-2# set term statics from protocol static
user@Private-Peer-2# set term statics then accept
user@Private-Peer-2# set term default-route from route-filter 0.0.0.0/0 exact
user@Private-Peer-2# set term default-route then accept
user@Private-Peer-2# set term reject-all-other-routes then reject
5. Congure the roung policy that adverses local customer routes.
[edit policy-options policy-statement outbound-routes]
user@Private-Peer-2# set term statics from protocol static
user@Private-Peer-2# set term statics then accept
user@Private-Peer-2# set term allowed-bgp-routes from as-path my-own-routes
user@Private-Peer-2# set term allowed-bgp-routes from as-path AS64512-routes
user@Private-Peer-2# set term allowed-bgp-routes then accept
user@Private-Peer-2# set term no-transit then reject
[edit policy-options]
user@Private-Peer-2# set as-path my-own-routes "()"
user@Private-Peer-2# set as-path AS64512-routes 64512
6. Congure the EBGP connecon to Customer-2.
[edit protocols bgp group to-64512]
user@Private-Peer-2# set type external
user@Private-Peer-2# set export internal-routes
179
user@Private-Peer-2# set peer-as 64512
user@Private-Peer-2# set neighbor 10.0.0.21
7. Congure the EBGP connecon to Device Exchange-2.
[edit protocols bgp group to-64515]
user@Private-Peer-2# set type external
user@Private-Peer-2# set export outbound-routes
user@Private-Peer-2# set peer-as 64515
user@Private-Peer-2# set neighbor 10.3.0.49
8. Congure the EBGP connecons to the ISP.
[edit protocols bgp group ext]
user@Private-Peer-2# set type external
user@Private-Peer-2# set export outbound-routes
user@Private-Peer-2# set peer-as 64510
user@Private-Peer-2# set neighbor 10.3.0.6
9. Congure the autonomous system (AS) number.
[edit routing-options]
user@Private-Peer-2# set autonomous-system 64516
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@Private-Peer-2# show interfaces
fe-1/2/0 {
unit 0 {
description to_Customer-1;
family inet {
address 10.0.0.22/30;
}
}
180
}
fe-1/2/1 {
unit 0 {
description to_Exchange-2;
family inet {
address 10.3.0.50/30;
}
}
}
fe-1/2/3 {
unit 0 {
description to_ISP-2;
family inet {
address 10.3.0.5/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.5/32;
}
}
}
user@Private-Peer-2# show protocols
bgp {
group ext {
type external;
export outbound-routes;
peer-as 64510;
neighbor 10.3.0.6;
}
group to-64512 {
type external;
export internal-routes;
peer-as 64512;
neighbor 10.0.0.21;
}
group to-64515 {
type external;
181
export outbound-routes;
peer-as 64515;
neighbor 10.3.0.49;
}
}
user@Private-Peer-2# show policy-options
policy-statement if-upstream-routes-exist {
term as-64515-routes {
from {
route-filter 172.16.16.0/21 exact;
}
then accept;
}
term reject-all-other-routes {
then reject;
}
}
policy-statement internal-routes {
term statics {
from protocol static;
then accept;
}
term default-route {
from {
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term reject-all-other-routes {
then reject;
}
}
policy-statement outbound-routes {
term statics {
from protocol static;
then accept;
}
term allowed-bgp-routes {
from as-path [ my-own-routes AS64512-routes ];
then accept;
182
}
term no-transit {
then reject;
}
}
as-path my-own-routes "()";
as-path AS64512-routes 64512;
user@Private-Peer-2# show routing-options
static {
route 172.16.24.0/25 reject;
route 172.16.24.128/25 reject;
route 172.16.25.0/26 reject;
route 172.16.25.64/26 reject;
}
generate {
route 0.0.0.0/0 policy if-upstream-routes-exist;
}
autonomous-system 64516;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Routes on Device Customer-1 | 184
Verifying the Routes on Device Customer-2 | 185
Verifying the Routes on Device ISP-1 | 186
Verifying the Routes on Device ISP-2 | 190
Verifying the Routes on Device ISP-3 | 194
Verifying the Routes on Device Exchange-1 | 197
Verifying the Routes on Device Exchange-2 | 199
Verifying the Routes on Device Private-Peer-1 | 201
Verifying the Routes on Device Private-Peer-2 | 202
183
Conrm that the conguraon is working properly.
Verifying the Routes on Device Customer-1
Purpose
On Device Customer-1, check the routes in the roung table.
Acon
user@Customer-1> show route
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:09:25, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.1.0.5 via fe-1/2/3.0
10.1.0.4/30 *[Direct/0] 23:50:20
> via fe-1/2/3.0
10.1.0.6/32 *[Local/0] 5d 21:56:47
Local via fe-1/2/3.0
172.16.40.0/25 *[Static/5] 22:59:04
Reject
172.16.40.128/25 *[Static/5] 22:59:04
Reject
172.16.41.0/25 *[Static/5] 22:59:04
Reject
172.16.41.128/25 *[Static/5] 22:59:04
Reject
192.168.0.8/32 *[Direct/0] 5d 21:25:45
> via lo0.0
Meaning
Device Customer-1 has its four stac routes, and it has learned the default route through BGP.
184
Verifying the Routes on Device Customer-2
Purpose
On Device Customer-2, check the routes in the roung table.
Acon
user@Customer-2> show route
inet.0: 22 destinations, 23 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:10:35, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
[BGP/170] 04:58:09, localpref 50
AS path: 64516 I, validation-state: unverified
> to 10.0.0.22 via fe-1/2/0.0
10.0.0.8/30 *[Direct/0] 23:51:29
> via fe-1/2/0.10
10.0.0.10/32 *[Local/0] 23:52:49
Local via fe-1/2/0.10
10.0.0.20/30 *[Direct/0] 23:52:49
> via fe-1/2/0.0
10.0.0.21/32 *[Local/0] 23:52:49
Local via fe-1/2/0.0
172.16.24.0/25 *[BGP/170] 04:58:09, localpref 50
AS path: 64516 I, validation-state: unverified
> to 10.0.0.22 via fe-1/2/0.0
172.16.24.128/25 *[BGP/170] 04:58:09, localpref 50
AS path: 64516 I, validation-state: unverified
> to 10.0.0.22 via fe-1/2/0.0
172.16.25.0/26 *[BGP/170] 04:58:09, localpref 50
AS path: 64516 I, validation-state: unverified
> to 10.0.0.22 via fe-1/2/0.0
172.16.25.64/26 *[BGP/170] 04:58:09, localpref 50
AS path: 64516 I, validation-state: unverified
> to 10.0.0.22 via fe-1/2/0.0
172.16.32.0/24 *[BGP/170] 22:38:47, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.33.0/24 *[BGP/170] 22:38:47, localpref 200
185
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.34.0/24 *[BGP/170] 22:38:47, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.35.0/24 *[BGP/170] 22:38:47, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.36.0/24 *[BGP/170] 22:38:47, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.37.0/24 *[BGP/170] 22:38:47, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.38.0/24 *[BGP/170] 22:38:47, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.39.0/24 *[BGP/170] 22:38:47, localpref 200
AS path: 64510 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/0.10
172.16.44.0/26 *[Static/5] 22:57:28
Reject
172.16.44.64/26 *[Static/5] 22:57:28
Reject
172.16.44.128/26 *[Static/5] 22:57:28
Reject
172.16.44.192/26 *[Static/5] 22:57:28
Reject
192.168.0.9/32 *[Direct/0] 23:52:49
> via lo0.0
Meaning
Device Customer-2 has learned the default route through its session with the ISP and also through its
session with the private peer. The route learned from the ISP is preferred because it has a higher local
preference.
Verifying the Routes on Device ISP-1
Purpose
On Device ISP-1, check the routes in the roung table.
186
Acon
user@ISP-1> show route
inet.0: 42 destinations, 53 routes (42 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 22:44:26, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
10.0.0.0/30 *[Direct/0] 23:52:01
> via fe-1/2/0.0
10.0.0.2/32 *[Local/0] 23:52:01
Local via fe-1/2/0.0
10.0.0.4/30 *[OSPF/10] 23:51:06, metric 2
to 10.1.0.1 via fe-1/2/1.0
> to 10.0.0.1 via fe-1/2/0.0
10.0.0.20/30 *[BGP/170] 23:50:55, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
[BGP/170] 23:51:28, localpref 100
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
10.1.0.0/30 *[Direct/0] 23:52:01
> via fe-1/2/1.0
10.1.0.2/32 *[Local/0] 23:52:01
Local via fe-1/2/1.0
10.2.0.0/30 *[Direct/0] 23:52:01
> via fe-1/2/2.0
10.2.0.2/32 *[Local/0] 23:52:01
Local via fe-1/2/2.0
10.2.0.4/30 *[Direct/0] 23:52:00
> via fe-1/2/3.0
10.2.0.6/32 *[Local/0] 23:52:00
Local via fe-1/2/3.0
10.3.0.4/30 *[BGP/170] 23:51:28, localpref 100
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
10.3.0.48/30 *[BGP/170] 23:50:55, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
172.16.8.0/21 *[BGP/170] 00:11:08, localpref 100
AS path: 64514 I, validation-state: unverified
187
> to 10.2.0.5 via fe-1/2/3.0
172.16.16.0/21 *[BGP/170] 02:02:10, localpref 100, from 192.168.0.2
AS path: 64515 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
[BGP/170] 02:02:10, localpref 100
AS path: 64514 64515 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.24.0/25 *[BGP/170] 23:06:33, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
[BGP/170] 23:06:33, localpref 100
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.24.128/25 *[BGP/170] 23:06:33, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
[BGP/170] 23:06:33, localpref 100
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.25.0/26 *[BGP/170] 23:06:33, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
[BGP/170] 23:06:33, localpref 100
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.25.64/26 *[BGP/170] 23:06:33, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
[BGP/170] 23:06:33, localpref 100
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.32.0/21 *[Aggregate/130] 22:44:27
Reject
172.16.32.0/24 *[Static/5] 22:44:27
Reject
172.16.33.0/24 *[Static/5] 22:44:27
Reject
172.16.34.0/24 *[BGP/170] 22:39:20, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
172.16.35.0/24 *[BGP/170] 22:39:20, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
188
172.16.36.0/24 *[BGP/170] 22:39:20, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.37.0/24 *[BGP/170] 22:39:20, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.38.0/24 *[BGP/170] 22:39:20, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.39.0/24 *[BGP/170] 22:39:20, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.40.0/22 *[Aggregate/130] 22:44:27
Reject
172.16.40.0/25 *[BGP/170] 23:00:47, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.40.128/25 *[BGP/170] 23:00:47, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.41.0/25 *[BGP/170] 23:00:47, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.41.128/25 *[BGP/170] 23:00:47, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.44.0/26 *[BGP/170] 22:58:01, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
[BGP/170] 22:58:01, localpref 100
AS path: 64514 64515 64516 64512 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.44.64/26 *[BGP/170] 22:58:01, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
[BGP/170] 22:58:01, localpref 100
AS path: 64514 64515 64516 64512 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.44.128/26 *[BGP/170] 22:58:01, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
[BGP/170] 22:58:01, localpref 100
AS path: 64514 64515 64516 64512 I, validation-state: unverified
189
> to 10.2.0.5 via fe-1/2/3.0
172.16.44.192/26 *[BGP/170] 22:58:01, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
[BGP/170] 22:58:01, localpref 100
AS path: 64514 64515 64516 64512 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
192.168.0.1/32 *[Direct/0] 23:52:01
> via lo0.0
192.168.0.2/32 *[OSPF/10] 23:51:06, metric 1
> to 10.1.0.1 via fe-1/2/1.0
192.168.0.3/32 *[OSPF/10] 23:51:06, metric 1
> to 10.0.0.1 via fe-1/2/0.0
192.168.0.5/32 *[BGP/170] 23:50:55, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.1.0.1 via fe-1/2/1.0
[BGP/170] 23:51:28, localpref 100
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.2.0.5 via fe-1/2/3.0
172.16.233.5/32 *[OSPF/10] 23:52:07, metric 1
MultiRecv
Verifying the Routes on Device ISP-2
Purpose
On Device ISP-2, check the routes in the roung table.
Acon
user@ISP-2> show route
inet.0: 41 destinations, 59 routes (41 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 22:45:44, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
10.0.0.0/30 *[OSPF/10] 23:52:25, metric 2
to 10.0.0.5 via fe-1/2/2.0
> to 10.1.0.2 via fe-1/2/1.0
10.0.0.4/30 *[Direct/0] 23:53:21
190
> via fe-1/2/2.0
10.0.0.6/32 *[Local/0] 23:53:23
Local via fe-1/2/2.0
10.0.0.20/30 *[BGP/170] 23:53:11, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 23:53:09, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
10.1.0.0/30 *[Direct/0] 23:53:19
> via fe-1/2/1.0
10.1.0.1/32 *[Local/0] 23:53:23
Local via fe-1/2/1.0
10.3.0.0/30 *[Direct/0] 23:53:22
> via fe-1/2/0.0
10.3.0.2/32 *[Local/0] 23:53:23
Local via fe-1/2/0.0
10.3.0.4/30 *[Direct/0] 23:53:23
> via fe-1/2/3.0
[BGP/170] 23:53:11, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 23:53:09, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
[BGP/170] 23:52:13, localpref 100, from 192.168.0.1
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
10.3.0.6/32 *[Local/0] 23:53:23
Local via fe-1/2/3.0
10.3.0.48/30 *[BGP/170] 23:53:11, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
172.16.8.0/21 *[BGP/170] 00:12:26, localpref 100, from 192.168.0.1
AS path: 64514 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
[BGP/170] 00:12:26, localpref 100
AS path: 64515 64514 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.16.0/21 *[BGP/170] 02:03:28, localpref 100
AS path: 64515 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.24.0/25 *[BGP/170] 23:07:51, localpref 100
191
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 23:07:51, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.24.128/25 *[BGP/170] 23:07:51, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 23:07:51, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.25.0/26 *[BGP/170] 23:07:51, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 23:07:51, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.25.64/26 *[BGP/170] 23:07:51, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 23:07:51, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.32.0/21 *[Aggregate/130] 22:40:38
Reject
172.16.32.0/24 *[BGP/170] 22:45:44, localpref 100, from 192.168.0.1
AS path: I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
172.16.33.0/24 *[BGP/170] 22:45:44, localpref 100, from 192.168.0.1
AS path: I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
172.16.34.0/24 *[Static/5] 22:40:38
Reject
172.16.35.0/24 *[Static/5] 22:40:38
Reject
172.16.36.0/24 *[BGP/170] 22:40:38, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
172.16.37.0/24 *[BGP/170] 22:40:38, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
172.16.38.0/24 *[BGP/170] 22:40:38, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
192
> to 10.0.0.5 via fe-1/2/2.0
172.16.39.0/24 *[BGP/170] 22:40:38, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
172.16.40.0/25 *[BGP/170] 23:02:05, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
172.16.40.128/25 *[BGP/170] 23:02:05, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
172.16.41.0/25 *[BGP/170] 23:02:05, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
172.16.41.128/25 *[BGP/170] 23:02:05, localpref 100, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
172.16.44.0/23 *[Aggregate/130] 22:40:38
Reject
172.16.44.0/26 *[BGP/170] 22:59:19, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
[BGP/170] 22:59:19, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 22:59:19, localpref 100
AS path: 64515 64516 64512 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.44.64/26 *[BGP/170] 22:59:19, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
[BGP/170] 22:59:19, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 22:59:19, localpref 100
AS path: 64515 64516 64512 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.44.128/26 *[BGP/170] 22:59:19, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
[BGP/170] 22:59:19, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 22:59:19, localpref 100
193
AS path: 64515 64516 64512 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.44.192/26 *[BGP/170] 22:59:19, localpref 100, from 192.168.0.3
AS path: 64512 I, validation-state: unverified
> to 10.0.0.5 via fe-1/2/2.0
[BGP/170] 22:59:19, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 22:59:19, localpref 100
AS path: 64515 64516 64512 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
192.168.0.1/32 *[OSPF/10] 23:52:25, metric 1
> to 10.1.0.2 via fe-1/2/1.0
192.168.0.2/32 *[Direct/0] 23:53:23
> via lo0.0
192.168.0.3/32 *[OSPF/10] 23:52:30, metric 1
> to 10.0.0.5 via fe-1/2/2.0
192.168.0.5/32 *[BGP/170] 23:53:11, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.5 via fe-1/2/3.0
[BGP/170] 23:53:09, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.1 via fe-1/2/0.0
172.16.233.5/32 *[OSPF/10] 23:53:25, metric 1
MultiRecv
Verifying the Routes on Device ISP-3
Purpose
On Device ISP-3, check the routes in the roung table.
Acon
user@ISP-3> show route
inet.0: 40 destinations, 41 routes (40 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Aggregate/130] 23:53:57, metric2 1
> to 10.0.0.2 via fe-1/2/0.0
194
[BGP/170] 22:46:17, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
10.0.0.0/30 *[Direct/0] 23:53:52
> via fe-1/2/0.0
10.0.0.1/32 *[Local/0] 23:53:53
Local via fe-1/2/0.0
10.0.0.4/30 *[Direct/0] 23:53:54
> via fe-1/2/2.0
10.0.0.5/32 *[Local/0] 23:53:54
Local via fe-1/2/2.0
10.0.0.8/30 *[Direct/0] 23:53:53
> via fe-1/2/1.0
10.0.0.9/32 *[Local/0] 23:53:53
Local via fe-1/2/1.0
10.0.0.20/30 *[BGP/170] 23:53:02, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
10.1.0.0/30 *[OSPF/10] 23:53:03, metric 2
> to 10.0.0.6 via fe-1/2/2.0
to 10.0.0.2 via fe-1/2/0.0
10.1.0.4/30 *[Direct/0] 23:53:54
> via fe-1/2/3.0
10.1.0.5/32 *[Local/0] 23:53:54
Local via fe-1/2/3.0
10.3.0.4/30 *[BGP/170] 23:52:46, localpref 100, from 192.168.0.1
AS path: 64514 64515 64516 I, validation-state: unverified
> to 10.0.0.2 via fe-1/2/0.0
10.3.0.48/30 *[BGP/170] 23:53:02, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.8.0/21 *[BGP/170] 00:12:59, localpref 100, from 192.168.0.1
AS path: 64514 I, validation-state: unverified
> to 10.0.0.2 via fe-1/2/0.0
172.16.16.0/21 *[BGP/170] 02:04:01, localpref 100, from 192.168.0.2
AS path: 64515 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.24.0/25 *[BGP/170] 23:08:24, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.24.128/25 *[BGP/170] 23:08:24, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
195
172.16.25.0/26 *[BGP/170] 23:08:24, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.25.64/26 *[BGP/170] 23:08:24, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.32.0/24 *[BGP/170] 22:46:17, localpref 100, from 192.168.0.1
AS path: I, validation-state: unverified
> to 10.0.0.2 via fe-1/2/0.0
172.16.33.0/24 *[BGP/170] 22:46:17, localpref 100, from 192.168.0.1
AS path: I, validation-state: unverified
> to 10.0.0.2 via fe-1/2/0.0
172.16.34.0/24 *[BGP/170] 22:41:11, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.35.0/24 *[BGP/170] 22:41:11, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.36.0/24 *[Static/5] 22:41:11
Reject
172.16.37.0/24 *[Static/5] 22:41:11
Reject
172.16.38.0/24 *[Static/5] 22:41:11
Reject
172.16.39.0/24 *[Static/5] 22:41:11
Reject
172.16.40.0/25 *[BGP/170] 23:02:38, localpref 100
AS path: 64511 I, validation-state: unverified
> to 10.1.0.6 via fe-1/2/3.0
172.16.40.128/25 *[BGP/170] 23:02:38, localpref 100
AS path: 64511 I, validation-state: unverified
> to 10.1.0.6 via fe-1/2/3.0
172.16.41.0/25 *[BGP/170] 23:02:38, localpref 100
AS path: 64511 I, validation-state: unverified
> to 10.1.0.6 via fe-1/2/3.0
172.16.41.128/25 *[BGP/170] 23:02:38, localpref 100
AS path: 64511 I, validation-state: unverified
> to 10.1.0.6 via fe-1/2/3.0
172.16.44.0/26 *[BGP/170] 22:59:52, localpref 100
AS path: 64512 I, validation-state: unverified
> to 10.0.0.10 via fe-1/2/1.0
172.16.44.64/26 *[BGP/170] 22:59:52, localpref 100
AS path: 64512 I, validation-state: unverified
196
> to 10.0.0.10 via fe-1/2/1.0
172.16.44.128/26 *[BGP/170] 22:59:52, localpref 100
AS path: 64512 I, validation-state: unverified
> to 10.0.0.10 via fe-1/2/1.0
172.16.44.192/26 *[BGP/170] 22:59:52, localpref 100
AS path: 64512 I, validation-state: unverified
> to 10.0.0.10 via fe-1/2/1.0
192.168.0.1/32 *[OSPF/10] 23:53:03, metric 1
> to 10.0.0.2 via fe-1/2/0.0
192.168.0.2/32 *[OSPF/10] 23:53:03, metric 1
> to 10.0.0.6 via fe-1/2/2.0
192.168.0.3/32 *[Direct/0] 23:53:54
> via lo0.0
192.168.0.5/32 *[BGP/170] 23:53:02, localpref 100, from 192.168.0.2
AS path: 64516 I, validation-state: unverified
> to 10.0.0.6 via fe-1/2/2.0
172.16.233.5/32 *[OSPF/10] 23:53:58, metric 1
MultiRecv
Verifying the Routes on Device Exchange-1
Purpose
On Device Exchange-1, check the routes in the roung table.
Acon
user@Exchange-1> show route
inet.0: 23 destinations, 24 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.20/30 *[BGP/170] 23:53:51, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
10.2.0.4/30 *[Direct/0] 23:54:23
> via fe-1/2/3.0
10.2.0.5/32 *[Local/0] 23:54:29
Local via fe-1/2/3.0
10.3.0.4/30 *[BGP/170] 23:53:51, localpref 100
AS path: 64515 64516 I, validation-state: unverified
197
> to 10.3.0.41 via fe-1/2/2.0
10.3.0.40/30 *[Direct/0] 23:54:27
> via fe-1/2/2.0
10.3.0.42/32 *[Local/0] 23:54:29
Local via fe-1/2/2.0
10.3.0.44/30 *[Direct/0] 23:54:29
> via fe-1/2/1.0
10.3.0.45/32 *[Local/0] 23:54:29
Local via fe-1/2/1.0
172.16.8.0/21 *[Static/5] 00:13:31
Reject
172.16.16.0/21 *[BGP/170] 02:04:33, localpref 100
AS path: 64515 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.24.0/25 *[BGP/170] 23:08:56, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.24.128/25 *[BGP/170] 23:08:56, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.25.0/26 *[BGP/170] 23:08:56, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.25.64/26 *[BGP/170] 23:08:56, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.32.0/21 *[BGP/170] 22:46:49, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.6 via fe-1/2/3.0
[BGP/170] 22:41:43, localpref 100
AS path: 64515 64510 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.40.0/22 *[BGP/170] 22:46:49, localpref 100
AS path: 64510 64511 I, validation-state: unverified
> to 10.2.0.6 via fe-1/2/3.0
172.16.44.0/23 *[BGP/170] 22:41:43, localpref 100
AS path: 64515 64510 64512 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.44.0/26 *[BGP/170] 23:00:24, localpref 100
AS path: 64515 64516 64512 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.44.64/26 *[BGP/170] 23:00:24, localpref 100
AS path: 64515 64516 64512 I, validation-state: unverified
198
> to 10.3.0.41 via fe-1/2/2.0
172.16.44.128/26 *[BGP/170] 23:00:24, localpref 100
AS path: 64515 64516 64512 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
172.16.44.192/26 *[BGP/170] 23:00:24, localpref 100
AS path: 64515 64516 64512 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
192.168.0.5/32 *[BGP/170] 23:53:51, localpref 100
AS path: 64515 64516 I, validation-state: unverified
> to 10.3.0.41 via fe-1/2/2.0
192.168.0.6/32 *[Direct/0] 23:54:29
> via lo0.0
Verifying the Routes on Device Exchange-2
Purpose
On Device Exchange-2, check the routes in the roung table.
Acon
user@Exchange-2> show route
inet.0: 24 destinations, 26 routes (23 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.20/30 *[BGP/170] 23:54:44, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
10.3.0.0/30 *[Direct/0] 23:54:57
> via fe-1/2/0.0
10.3.0.1/32 *[Local/0] 23:54:57
Local via fe-1/2/0.0
10.3.0.4/30 *[BGP/170] 23:54:44, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
10.3.0.40/30 *[Direct/0] 23:54:57
> via fe-1/2/2.0
10.3.0.41/32 *[Local/0] 23:54:57
Local via fe-1/2/2.0
10.3.0.48/30 *[Direct/0] 23:54:57
> via fe-1/2/1.0
199
[BGP/170] 23:54:44, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
10.3.0.49/32 *[Local/0] 23:54:57
Local via fe-1/2/1.0
172.16.8.0/21 *[BGP/170] 00:14:01, localpref 100
AS path: 64514 I, validation-state: unverified
> to 10.3.0.42 via fe-1/2/2.0
172.16.16.0/21 *[Static/5] 02:05:03
Reject
172.16.24.0/25 *[BGP/170] 23:09:26, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
172.16.24.128/25 *[BGP/170] 23:09:26, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
172.16.25.0/26 *[BGP/170] 23:09:26, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
172.16.25.64/26 *[BGP/170] 23:09:26, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
172.16.32.0/21 *[BGP/170] 22:42:13, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.2 via fe-1/2/0.0
[BGP/170] 22:47:19, localpref 100
AS path: 64514 64510 I, validation-state: unverified
> to 10.3.0.42 via fe-1/2/2.0
172.16.40.0/22 *[BGP/170] 22:47:19, localpref 100
AS path: 64514 64510 64511 I, validation-state: unverified
> to 10.3.0.42 via fe-1/2/2.0
172.16.44.0/23 *[BGP/170] 22:42:13, localpref 100
AS path: 64510 64512 I, validation-state: unverified
> to 10.3.0.2 via fe-1/2/0.0
172.16.44.0/26 *[BGP/170] 23:00:54, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
172.16.44.64/26 *[BGP/170] 23:00:54, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
172.16.44.128/26 *[BGP/170] 23:00:54, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
200
172.16.44.192/26 *[BGP/170] 23:00:54, localpref 100
AS path: 64516 64512 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
192.168.0.5/32 *[BGP/170] 23:54:44, localpref 100
AS path: 64516 I, validation-state: unverified
> to 10.3.0.50 via fe-1/2/1.0
192.168.0.7/32 *[Direct/0] 23:54:57
> via lo0.0
Meaning
On Device Exchange-2, the default route 0/0 is hidden because the next hop for the route is its own
interface to Device Private-Peer-2, from which the route was received. The route is hidden to avoid a
loop.
Verifying the Routes on Device Private-Peer-1
Purpose
On Device Private-Peer-1, check the routes in the roung table.
Acon
user@Private-Peer-1> show route
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.0.0/30 *[Direct/0] 23:58:57
> via fe-1/2/2.0
10.2.0.1/32 *[Local/0] 5d 21:34:22
Local via fe-1/2/2.0
10.3.0.44/30 *[Direct/0] 23:59:02
> via fe-1/2/1.0
10.3.0.46/32 *[Local/0] 1d 03:19:52
Local via fe-1/2/1.0
172.16.32.0/24 *[BGP/170] 22:51:22, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.2 via fe-1/2/2.0
172.16.33.0/24 *[BGP/170] 22:51:22, localpref 100
AS path: 64510 I, validation-state: unverified
201
> to 10.2.0.2 via fe-1/2/2.0
172.16.34.0/24 *[BGP/170] 22:46:16, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.2 via fe-1/2/2.0
172.16.35.0/24 *[BGP/170] 22:46:16, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.2 via fe-1/2/2.0
172.16.36.0/24 *[BGP/170] 22:46:16, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.2 via fe-1/2/2.0
172.16.37.0/24 *[BGP/170] 22:46:16, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.2 via fe-1/2/2.0
172.16.38.0/24 *[BGP/170] 22:46:16, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.2 via fe-1/2/2.0
172.16.39.0/24 *[BGP/170] 22:46:16, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.2.0.2 via fe-1/2/2.0
192.168.0.4/32 *[Direct/0] 5d 21:34:22
> via lo0.0
Verifying the Routes on Device Private-Peer-2
Purpose
On Device Private-Peer-2, check the routes in the roung table.
Acon
user@Private-Peer-2> show route
inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Aggregate/130] 1d 02:13:28
> to 10.3.0.49 via fe-1/2/1.0
10.0.0.20/30 *[Direct/0] 1d 00:00:53
> via fe-1/2/0.0
10.0.0.22/32 *[Local/0] 4d 23:51:14
202
Local via fe-1/2/0.0
10.3.0.4/30 *[Direct/0] 23:59:36
> via fe-1/2/3.0
10.3.0.5/32 *[Local/0] 5d 21:34:57
Local via fe-1/2/3.0
10.3.0.48/30 *[Direct/0] 23:59:35
> via fe-1/2/1.0
10.3.0.50/32 *[Local/0] 1d 03:20:27
Local via fe-1/2/1.0
172.16.8.0/21 *[BGP/170] 00:18:39, localpref 100
AS path: 64515 64514 I, validation-state: unverified
> to 10.3.0.49 via fe-1/2/1.0
172.16.16.0/21 *[BGP/170] 02:09:41, localpref 100
AS path: 64515 I, validation-state: unverified
> to 10.3.0.49 via fe-1/2/1.0
172.16.24.0/25 *[Static/5] 23:14:04
Reject
172.16.24.128/25 *[Static/5] 23:14:04
Reject
172.16.25.0/26 *[Static/5] 23:14:04
Reject
172.16.25.64/26 *[Static/5] 23:14:04
Reject
172.16.32.0/21 *[BGP/170] 22:46:51, localpref 100
AS path: 64515 64510 I, validation-state: unverified
> to 10.3.0.49 via fe-1/2/1.0
172.16.32.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.6 via fe-1/2/3.0
172.16.33.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.6 via fe-1/2/3.0
172.16.34.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.6 via fe-1/2/3.0
172.16.35.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.6 via fe-1/2/3.0
172.16.36.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.6 via fe-1/2/3.0
172.16.37.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
203
> to 10.3.0.6 via fe-1/2/3.0
172.16.38.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.6 via fe-1/2/3.0
172.16.39.0/24 *[BGP/170] 22:46:51, localpref 100
AS path: 64510 I, validation-state: unverified
> to 10.3.0.6 via fe-1/2/3.0
172.16.40.0/22 *[BGP/170] 22:51:57, localpref 100
AS path: 64515 64514 64510 64511 I, validation-state: unverified
> to 10.3.0.49 via fe-1/2/1.0
172.16.44.0/23 *[BGP/170] 22:46:51, localpref 100
AS path: 64515 64510 64512 I, validation-state: unverified
> to 10.3.0.49 via fe-1/2/1.0
172.16.44.0/26 *[BGP/170] 23:05:32, localpref 100
AS path: 64512 I, validation-state: unverified
> to 10.0.0.21 via fe-1/2/0.0
172.16.44.64/26 *[BGP/170] 23:05:32, localpref 100
AS path: 64512 I, validation-state: unverified
> to 10.0.0.21 via fe-1/2/0.0
172.16.44.128/26 *[BGP/170] 23:05:32, localpref 100
AS path: 64512 I, validation-state: unverified
> to 10.0.0.21 via fe-1/2/0.0
172.16.44.192/26 *[BGP/170] 23:05:32, localpref 100
AS path: 64512 I, validation-state: unverified
> to 10.0.0.21 via fe-1/2/0.0
192.168.0.5/32 *[Direct/0] 5d 21:34:57
> via lo0.0
RELATED DOCUMENTATION
Example: Conguring Policy Chains and Route Filters | 259
Example: Conguring Roung Policy Prex Lists | 398
204
Understanding Policy Expressions
IN THIS SECTION
Policy Expression Examples | 207
Policy Expression Evaluaon | 208
Evaluang Policy Expressions | 209
Policy expressions give the policy framework soware a dierent way to evaluate roung policies. A
policy expression
uses Boolean logical operators with policies. The logical operators establish rules by
which the policies are evaluated.
During evaluaon of a roung policy in a policy expression, the policy acon of accept, reject, or next
policy is converted to the value of TRUE or FALSE. This value is then evaluated against the specied
logical operator to produce output of either TRUE or FALSE. The output is then converted back to a
ow control acon of accept, reject, or next policy. The result of the policy expression is applied as it
would be applied to a single policy; the route is accepted or rejected and the evaluaon ends, or the
next policy is evaluated.
Table 12 on page 205 summarizes the policy acons and their corresponding TRUE and FALSE values
and ow control acon values. Table 13 on page 206 describes the logical operators. For complete
informaon about policy expression evaluaon, see "Policy Expression Evaluaon" on page 208.
You must enclose a policy expression in parentheses. You can place a policy expression anywhere in the
import or export statements and in the from policy statement.
Table 12: Policy
Acon Conversion Values
Policy Acon Conversion Value Flow Control Acon Conversion Value
Accept TRUE Accept
Reject FALSE Reject
Next policy TRUE Next policy
205
Table 13: Policy Expression Logical Operators
Logical Operator Policy Expression Logic How Logical Operator Aects Policy Expression
Evaluaon
&& (Logical AND) Logical AND requires that all values
must be TRUE to produce output of
TRUE.
Roung policy value of TRUE and
TRUE produces output of TRUE.
Value of TRUE and FALSE produces
output of FALSE. Value of FALSE
and FALSE produces output of
FALSE.
If the rst roung policy returns the value of TRUE, the
next policy is evaluated. If the rst policy returns the
value of FALSE, the evaluaon of the expression ends
and subsequent policies in the expression are not
evaluated.
|| (Logical OR) Logical OR requires that at least one
value must be TRUE to produce
output of TRUE.
Roung policy value of TRUE and
FALSE produces output of TRUE.
Value of TRUE and TRUE produces
output of TRUE. Value of FALSE and
FALSE produces output of FALSE.
If the rst roung policy returns the value of TRUE, the
evaluaon of the expression ends and subsequent
policies in the expression are not evaluated. If the rst
policy returns the value of FALSE, the next policy is
evaluated.
! (Logical NOT) Logical NOT reverses value of TRUE
to FALSE and of FALSE to TRUE. It
also reverses the acons of accept
and next policy to reject, and reject
to accept.
If used with the logical AND operator and the rst
roung policy value of FALSE is reversed to TRUE, the
next policy is evaluated. If the value of TRUE is
reversed to FALSE, the evaluaon of the expression
ends and subsequent policies in the expression are not
evaluated.
If used with the logical OR operator and the rst
roung policy value of FALSE is reversed to TRUE, the
evaluaon of the expression ends and subsequent
policies in the expression are not evaluated. If the value
of TRUE is reversed to FALSE, the next policy is
evaluated.
If used with a policy and the ow control acon is
accept or next policy, these acons are reversed to
reject. If the ow control acon is reject, this acon is
reversed to accept.
For more informaon, see the following secons:
206
Policy Expression Examples
The following examples show how to use the logical operators to create policy expressions:
• Logical AND—In the following example, policy1 is evaluated rst. If aer policy1 is evaluated, a value
of TRUE is returned, policy2 is evaluated. If a value of FALSE is returned, policy2 is not evaluated.
export (policy1 && policy2)
• Logical OR—In the following example, policy1 is evaluated rst. If aer policy1 is evaluated, a value of
TRUE is returned, policy2 is not evaluated. If a value of FALSE is returned, policy2 is evaluated.
export (policy1 || policy2)
• Logical OR and logical AND—In the following example, policy1 is evaluated rst. If aer policy1 is
evaluated, a value of TRUE is returned, policy2 is skipped and policy3 is evaluated. If aer policy1 is
evaluated, a value of FALSE is returned, policy2 is evaluated. If policy2 returns a value of TRUE, policy3
is evaluated. If policy2 returns a value of FALSE, policy3 is not evaluated.
export [(policy1 || policy2) && policy3]
• Logical NOT—In the following example, policy1 is evaluated rst. If aer policy1 is evaluated, a value of
TRUE is returned, the value is reversed to FALSE and policy2 is not evaluated. If a value of FALSE is
returned, the value is reversed to TRUE and policy2 is evaluated.
export (!policy1 && policy2)
The sequenal list [policy1 policy2 policy3] is not the same as the policy expression (policy1 && policy2 &&
policy3).
The sequenal list is evaluated on the basis of a route matching a roung policy. For example, if policy1
matches and the acon is accept or reject, policy2 and policy3 are not evaluated. If policy1 does not match,
policy2 is evaluated and so on unl a match occurs and the acon is accept or reject.
The policy expressions are evaluated on the basis of the acon in a roung policy that is converted to
the value of TRUE or FALSE and the logic of the specied logical operator. (For complete informaon
about policy expression evaluaon, see "Policy Expression Evaluaon" on page 208.) For example, if
policy1
returns a value of FALSE,
policy2
and
policy3
are not evaluated. If
policy1
returns a value of TRUE,
207
policy2 is evaluated. If policy2 returns a value of FALSE, policy3 is not evaluated. If policy2 returns a value
of TRUE, policy3 is evaluated.
You can also combine policy expressions and sequenal lists. In the following example, if policy1 returns
a value of FALSE, policy2 is evaluated. If policy2 returns a value of TRUE and contains a next policy acon,
policy3 is evaluated. If policy2 returns a value of TRUE but does not contain an acon, including a next
policy acon, policy3 is sll evaluated (because if you do not specify an acon, next term or next policy
are the default acons). If policy2 returns a value of TRUE and contains an accept acon, policy3 is not
evaluated.
export [(policy1 || policy2) policy3]
Policy Expression Evaluaon
During evaluaon, the policy framework soware converts policy acons to values of TRUE or FALSE,
which are factors in determining the ow control acon that is performed upon a route. However, the
soware does not actually perform a ow control acon on a route unl it evaluates an enre policy
expression.
The policy framework soware evaluates a policy expression as follows:
1. The soware evaluates a route against the rst roung policy in a policy expression and converts the
specied or default acon to a value of TRUE or FALSE. (For informaon about the policy acon
conversion values, see Table 12 on page 205.)
2. The soware takes the value of TRUE or FALSE and evaluates it against the logical operator used in
the policy expression (see Table 13 on page 206). Based upon the logical operator used, the soware
determines whether or not to evaluate the next policy, if one is present.
The policy framework soware uses a shortcut method of evaluaon: if the result of evaluang a
policy predetermines the value of the enre policy expression, the soware does not evaluate the
subsequent policies in the expression. For example, if the policy expression uses the logical AND
operator and the evaluaon of a policy returns the value of FALSE, the soware does not evaluate
subsequent policies in the expression because the nal value of the expression is guaranteed to be
FALSE no maer what the values of the unevaluated policies.
3. The soware performs Step 1 and Step 2 for each subsequent roung policy in the policy expression,
if they are present and it is necessary to evaluate them.
4. Aer evaluang the last roung policy, if it is appropriate, the soware evaluates the value of TRUE
or FALSE obtained from each roung policy evaluaon. Based upon the logical operator used, it
calculates an output of TRUE or FALSE.
208
5. The soware converts the output of TRUE or FALSE back to an acon. (For informaon about the
policy acon conversion values, see Table 12 on page 205.) The acon is performed.
If each policy in the expression returned a value of TRUE, the soware converts the output of TRUE
back to the ow control acon specied in the last policy. For example, if the policy expression
(policy1 && policy2) is specied and policy1 species accept and policy2 species next term, the next term
acon is performed.
If an acon specied in one of the policies manipulates a route characterisc, the policy framework
soware carries the new route characterisc forward during the evaluaon of the remaining policies.
For example, if the acon specied in the rst policy of a policy expression sets a route’s metric
to 500, this route matches the criteria of metric 500 dened in the next policy. However, if a route
characterisc manipulaon acon is specied in a policy located in the middle or the end of a policy
expression, it is possible, because of the shortcut evaluaon, that the policy is never evaluated and
the manipulaon of the route characterisc never occurs.
Evaluang Policy Expressions
The following sample roung policy uses three policy expressions:
[edit]
policy-options {
policy-statement policy-A {
from {
route-filter 10.10.0.0/16 orlonger;
}
then reject;
}
}
policy-options {
policy-statement policy-B {
from {
route-filter 10.20.0.0/16 orlonger;
}
then accept;
}
}
protocols {
bgp {
neighbor 192.168.1.1 {
export (policy-A && policy-B);
}
neighbor 192.168.2.1 {
209
export (policy-A || policy-B);
}
neighbor 192.168.3.1 {
export (!policy-A);
}
}
}
The policy framework soware evaluates the transit BGP route 10.10.1.0/24 against the three policy
expressions specied in the sample roung policy as follows:
• (policy-A && policy-B)—10.10.1.0/24 is evaluated against policy-A. 10.10.1.0/24 matches the route
list specied in policy-A, so the specied acon of reject is returned. reject is converted to a value of
FALSE, and FALSE is evaluated against the specied logical AND. Because the result of FALSE is
certain no maer what the results of the evaluaon of policy-B are (in policy expression logic, any
result AND a value of FALSE produces the output of FALSE), policy-B is not evaluated and the output
of FALSE is produced. The FALSE output is converted to reject, and 10.10.1.0/24 is rejected.
• (policy-A || policy-B)—10.10.1.0/24 is evaluated against policy-A. 10.10.1.0/24 matches the route list
specied in policy-A, so the specied acon of reject is returned. reject is converted to a value of
FALSE, then FALSE is evaluated against the specied logical OR. Because logical OR requires at least
one value of TRUE to produce an output of TRUE, 10.10.1.0/24 is evaluated against policy-B.
10.10.1.0/24 does not match policy-B, so the default acon of next-policy is returned. The next-policy
is converted to a value of TRUE, then the value of FALSE (for policy-A evaluaon) and TRUE (for
policy-B evaluaon) are evaluated against the specied logical OR. In policy expression logic, FALSE
OR TRUE produce an output of TRUE. The output of TRUE is converted to next-policy. (TRUE is
converted to next-policy because next-policy was the last acon retained by the policy framework
soware.) policy-B is the last roung policy in the policy expression, so the acon specied by the
default export policy for BGP is taken.
• (!policy-A)—10.10.1.0/24 is evaluated against policy-A. 10.10.1.0/24 matches the route list specied
in policy-A, so the specied acon of reject is returned. reject is converted to a value of FALSE, and
FALSE is evaluated against the specied logical NOT. The value of FALSE is reversed to an output of
TRUE based on the rules of logical NOT. The output of TRUE is converted to accept, and route
10.10.1.0/24 is accepted.
RELATED DOCUMENTATION
Example: Tesng a Roung Policy with Complex Regular Expressions | 762
Example: Conguring a Policy Subroune | 291
Example: Conguring Policy Chains and Route Filters | 259
Example: Conguring Roung Policy Prex Lists | 398
210
Understanding Backup Selecon Policy for OSPF Protocol
Support for OSPF loop-free alternate (LFA) routes essenally adds IP fast-reroute capability for OSPF.
Junos OS precomputes mulple loop-free backup routes for all OSPF routes. These backup routes are
pre-installed in the Packet Forwarding Engine, which performs a local repair and implements the backup
path when the link for a primary next hop for a parcular route is no longer available. The selecon of
LFA is done randomly by selecng any matching LFA to progress to the given desnaon. This does not
ensure best backup coverage available for the network. In order to choose the best LFA, Junos OS
allows you to congure network-wide backup selecon policies for each desnaon (IPv4 and IPv6) and
a primary next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth,
protecon-type, metric, and node informaon.
During backup shortest-path-rst (SPF) computaon, each node and link aribute of the backup path is
accumulated by IGP and is associated with every node (router) in the topology. The next hop in the best
backup path is selected as the backup next hop in the roung table. In general, backup evaluaon policy
rules are categorized into the following types:
• Pruning — Rules congured to select the eligible backup path.
• Ordering — Rules congured to select the best among the eligible backup paths.
The backup selecon policies can be congured with both pruning and ordering rules. While evaluang
the backup policies, each backup path is assigned a score, an integer value that signies the total weight
of the evaluated criteria. The backup path with the highest score is selected.
To enforce LFA selecon, congure various rules for the following aributes:
• admin-group– Administrave groups, also known as link coloring or resource class, are manually
assigned aributes that describe the “color” of links, such that links with the same color conceptually
belong to the same class. These congured administrave groups are dened under protocol MPLS.
You can use administrave groups to implement a variety of backup selecon policies using exclude,
include-all, include-any, or preference.
• srlg— A shared risk link group (SRLG) is a set of links sharing a common resource, which aects all
links in the set if the common resource fails. These links share the same risk of failure and are
therefore considered to belong to the same SRLG. For example, links sharing a common ber are said
to be in the same SRLG because a fault with the ber might cause all links in the group to fail. An
SRLG is represented by a 32-bit number unique within an IGP (OSPF) domain. A link might belong to
mulple SRLGs. You can dene the backup selecon to either allow or reject the common SRLGs
between the primary and the backup path. This rejecon of common SRLGs are based on the non-
existence of link having common SRLGs in the primary next-hop and the backup SPF.
NOTE: Administrave groups and SRLGs can be created only for default topologies.
211
• bandwidth—The bandwidth species the bandwidth constraints between the primary and the backup
path. The backup next-hop link can be used only if the bandwidth of the backup next-hop interface is
greater than or equal to the bandwidth of the primary next hop.
• protecon-type— The protecon-type protects the desnaon from node failure of the primary
node or link failure of the primary link. You can congure node, link, or node-link to protect the
desnaon. If link-node is congured , then the node-protecng LFA is preferred over link-protecon
LFA.
• node- The node is per-node policy informaon. Here, node can be a directly connected router,
remote router like RSVP backup LSP tail-end, or any other router in the backup SPF path. The nodes
are idened through the route-id adversed by a node in the LSP. You can list the nodes to either
prefer or exclude them in the backup path.
• metric— Metric decides how the LFAs should be preferred. In backup selecon path, root metric and
dest-metric are the two types of metrics. root-metric indicates the metric to the one-hop neighbor or
a remote router such as an RSVP backup LSP tail-end router. The dest-metric indicates the metric
from a one-hop neighbor or remote router such as an RSVP backup LSP tail-end router to the nal
desnaon. The metric evaluaon is done either in ascending or descending order. By default, the
rst preference is given to backup paths with lowest desnaon evaluaon and then to backup paths
with lowest root metrics.
The evaluaon-order allows you to control the order and criteria of evaluang these aributes in the
backup path. You can explicitly congure the evaluaon order. Only the congured aributes inuence
the backup path selecon. The default order of evaluaon of these aributes for the LFA is [ admin-
group srlg bandwidth protecon-type node metric ] .
NOTE: TE aributes are not supported in OSPFv3 and cannot be used for backup selecon
policy evaluaon for IPv6 prexes.
RELATED DOCUMENTATION
backup-selecon (Protocols IS-IS)
Conguring Backup Selecon Policy for the OSPF Protocol
Support for OSPF loop-free alternate (LFA) routes essenally adds IP fast-reroute capability for OSPF.
Junos OS precomputes mulple loop-free backup routes for all OSPF routes. These backup routes are
pre-installed in the Packet Forwarding Engine, which performs a local repair and implements the backup
212
path when the link for a primary next hop for a parcular route is no longer available. The selecon of
LFA is done randomly by selecng any matching LFA to progress to the given desnaon. This does not
ensure best backup coverage available for the network. In order to choose the best LFA, Junos OS
allows you to congure network-wide backup selecon policies for each desnaon (IPv4 and IPv6) and
a primary next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth,
protecon-type, metric, and node informaon.
Before you begin to congure the backup selecon policy for the OSPF protocol:
• Congure the router interfaces. See the
Junos OS Network Management Administraon Guide for
Roung Devices
.
• Congure an interior gateway protocol or stac roung. See the
Junos OS Roung Protocols Library
for Roung Devices
.
To congure the backup selecon policy for the OSPF protocol:
1. Congure per-packet load balancing.
[edit policy-options]
user@host# set policy-statement ecmp term 1 then load-balance per-packet
2. Enable RSVP on all the interfaces.
[edit protocols]
user@host# set rsvp interface all
3. Congure administrave groups.
[edit protocols mpls]
user@host# set admin-groups
group-name
4. Congure srlg values.
[edit routing-options]
user@host# set srlg
srlg-name
srlg-value
srlg-value
5. Enable MPLS on all the interfaces.
[edit protocols mpls]
user@host# set interface all
213
6. Apply MPLS to an interface congured with an administrave group.
[edit protocols mpls]
user@host# set interface
interface-name
admin-group
group-name
7. Congure the ID of the router.
[edit routing-options]
user@host# set router-id
router-id
8. Apply the roung policy to all equal cost mulpaths exported from the roung table to the
forwarding table.
[edit routing-options]
user@host# set forwarding-table export ecmp
9. Enable link protecon and congure metric values on all the interfaces for an area.
[edit protocols ospf]
user@host# set area
area-id
interface
interface-name
link-protection
user@host# set area
area-id
interface
interface-name
metric
metric
10. Congure the administrave group of the backup selecon policy for an IP address.
You can choose to exclude, include all, include any, or prefer the administrave groups from the
backup path.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
admin-group
• Specify the administrave group to be excluded.
[edit routing-options backup-selection destination
ip-address
interface
interface-name
admin-group]
user@host# set exclude
group-name
The backup path is not selected as the loop-free alternate (LFA) or backup nexthop if any of the
links in the path have any one of the listed administrave groups.
214
For example, to exclude the group c1 from the administrave group:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]
user@host# set exclude c1
• Congure all the administrave groups if each link in the backup path requires all the listed
administrave groups in order to accept the path.
[edit routing-options backup-selection destination
ip-address
interface
interface-name
admin-group]
user@host# set include-all
group-name
For example, to set all the administrave groups if each link requires all the listed administrave
groups in order to accept the path:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]
user@host# set include-all c2
• Congure any administrave group if each link in the backup path requires at least one of the
listed administrave groups in order to select the path.
[edit routing-options backup-selection destination
ip-address
interface
interface-name
admin-group]
user@host# set include-any
group-name
For example, to set any administrave group if each link in the backup path requires at least one
of the listed administrave groups in order to select the path:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]
user@host# set include-any c3
• Dene an ordered set of an administrave group that species the preference of the backup
path.
215
The lemost element in the set is given the highest preference.
[edit routing-options backup-selection destination
ip-address
interface
interface-name
admin-group]
user@host# set preference
group-name
For example, to set an ordered set of an administrave group that species the preference of
the backup path:
[edit routing-options backup-selection destination 0.0.0.0/0 interface all admin-group]
user@host# set preference c4
11. Congure the backup path to allow the selecon of the backup next hop only if the bandwidth is
greater than or equal to the bandwidth of the primary next hop.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
bandwidth-
greater-equal-primary
12. Congure the backup path to specify the metric from the one-hop neighbor or from the remote
router such as an RSVP backup label-switched-path (LSP) tail-end router to the nal desnaon.
The desnaon metric can be either highest or lowest.
• Congure the backup path that has the highest desnaon metric.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
dest-
metric highest
• Congure the backup path that has the lowest desnaon metric.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
dest-
metric lowest
216
13. Congure the backup path that is a downstream path to the desnaon.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
downstream-
paths-only
14. Set the order of preference of the root and the desnaon metric during backup path selecon.
The preference order can be :
• [root dest] — Backup path selecon or preference is rst based on the root-metric criteria. If the
criteria of all the root-metric is the same, then the selecon or preference is based on the dest-
metric.
• [dest root] — Backup path selecon or preference is rst based on the dest-metric criteria. If the
criteria of all the dest-metric is the same, then the selecon is based on the root-metric.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
metric-
order dest
user@host# set backup-selection destination
ip-address
interface
interface-name
metric-
order root
15. Congure the backup path to dene a list of loop-back IP addresses of the adjacent neighbors to
either exclude or prefer in the backup path selecon.
The neighbor can be a local (adjacent router) neighbor, remote neighbor, or any other router in the
backup path.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
node
• Congure the list of neighbors to be excluded.
[edit routing-options backup-selection destination
ip-address
interface
interface-name
node]
user@host# set exclude
node-address
The backup path that has a router from the list is not selected as the loop-free alternave or
backup next hop.
217
• Congure an ordered set of neighbors to be preferred.
[edit routing-options backup-selection destination
ip-address
interface
interface-name
node]
user@host# set preference
node-address
The backup path having the lemost neighbor is selected.
16. Congure the backup path to specify the required protecon type of the backup path to be link,
node, or node-link.
• Select the backup path that provides link protecon.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
protection-type link
• Select the backup path that provides node protecon.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
protection-type node
• Select the backup path that allows either node or link protecon LFA where node-protecon
LFA is preferred over link-protecon LFA.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface
interface-name
protection-type node-link
17. Specify the metric to the one-hop neighbor or to the remote router such as an RSVP backup label-
switched-path (LSP) tail-end router.
• Select the path with highest root metric.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface all root-metric highest
218
• Select the path with lowest root metric.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface all root-metric lowest
18. Congure the backup selecon path to either allow or reject the common shared risk link groups
(SRLGs) between the primary link and each link in the backup path.
• Congure the backup path to allow common srlgs between the primary link and each link in the
backup path.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface all srlg loose
A backup path with a fewer number of srlg collisions is preferred.
• Congure the backup path to reject the backup path that has common srlgs between the
primary next-hop link and each link in the backup path.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface all srlg strict
19. Congure the backup path to control the order and the criteria of evaluang the backup path based
on the administrave group, srlg, bandwidth, protecon type, node, and metric.
The default order of evaluaon is admin-group, srlg, bandwidth, protecon-type, node, and metric.
[edit routing-options]
user@host# set backup-selection destination
ip-address
interface all evaluation-order admin-
group
user@host# set backup-selection destination
ip-address
interface all evaluation-order srlg
user@host# set backup-selection destination
ip-address
interface all evaluation-order
bandwidth
RELATED DOCUMENTATION
backup-selecon (Protocols IS-IS)
219
Conguring Backup Selecon Policy for IS-IS Protocol
IN THIS SECTION
Understanding Backup Selecon Policy for IS-IS Protocol | 220
Understanding Backup Selecon Policy for IS-IS Protocol
Support for IS-IS loop-free alternate (LFA) routes essenally adds IP fast-reroute capability for IS-IS.
Junos OS precomputes mulple loop-free backup routes for all IS-IS routes. These backup routes are
pre-installed in the Packet Forwarding Engine, which performs a local repair and implements the backup
path when the link for a primary next hop for a parcular route is no longer available. The selecon of
LFA is done randomly by selecng any matching LFA to progress to the given desnaon. This does not
ensure best backup coverage available for the network. In order to choose the best LFA, Junos OS
allows you to congure network-wide backup selecon policies for each desnaon (IPv4 and IPv6) and
a primary next-hop interface. These policies are evaluated based on admin-group, srlg, bandwidth,
protecon-type, metric, and neighbor informaon.
During backup shortest-path-rst (SPF) computaon, each node and link aribute of the backup path is
accumulated by IGP and is associated with every node (router) in the topology. The next hop in the best
backup path is selected as the backup next hop in the roung table. In general, backup evaluaon policy
rules are categorized into the following types:
• Pruning — Rules congured to select the eligible backup path.
• Ordering — Rules congured to select the best among the eligible backup paths.
The backup selecon policies can be congured with both pruning and ordering rules. While evaluang
the backup policies, each backup path is assigned a score, an integer value that signies the total weight
of the evaluated criteria. The backup path with the highest score is selected.
To enforce LFA selecon, congure various rules for the following aributes:
• admin-group– Administrave groups, also known as link coloring or resource class, are manually
assigned aributes that describe the “color” of links, such that links with the same color conceptually
belong to the same class. These congured administrave groups are dened under protocol MPLS.
You can use administrave groups to implement a variety of backup selecon policies using exclude,
include-all, include-any, or preference.
• backup-neighbor— A neighbor ID to either prefer or exclude in the backup path selecon.
220
• node— A list of loop-back IP addresses of the adjacent nodes to either prefer or exclude in the
backup path selecon. The node can be a local (adjacent router) node, remote node, or any other
router in the backup path. The nodes are idened through the TE-router-ID TLV adversed by a
node in the LSP.
• node-tag— A node tag idenes a group of nodes in the network based on criteria such as the same
neighbor tag values for all PE nodes to either prefer or exclude in the a backup path selecon. This is
implemented using IS-IS admin-tags. The routers are not idened with the explicit router-id but
with an admin-tag prex to their lo0 address prex. These tags are adversed as part of extended IP
reachability with a /32 prex length that represents the TE-router _ID or node-ID of a router.
• srlg— A shared risk link group (SRLG) is a set of links sharing a common resource, which aects all
links in the set if the common resource fails. These links share the same risk of failure and are
therefore considered to belong to the same SRLG. For example, links sharing a common ber are said
to be in the same SRLG because a fault with the ber might cause all links in the group to fail. An
SRLG is represented by a 32-bit number unique within an IGP (IS-IS) domain. A link might belong to
mulple SRLGs. You can dene the backup selecon to either allow or reject the common SRLGs
between the primary and the backup path.
• bandwidth—The bandwidth species the bandwidth constraints between the primary and the backup
path. The backup next-hop link can be used only if the bandwidth of the backup next-hop interface is
greater than or equal to the bandwidth of the primary next hop.
• protecon-type— The protecon-type protects the desnaon from node failure of the primary
node or link failure of the primary link. You can congure node, link, or node-link to protect the
desnaon.. If link-node is congured , then the node-protecng LFA is preferred over link-
protecon LFA.
• metric— Metric decides how the LFAs should be preferred. In backup selecon path, root metric and
dest-metric are the two types of metrics. root-metric indicates the metric to the one-hop neighbor or
a remote router such as an RSVP backup LSP tail-end router. The dest-metric indicates the metric
from a one-hop neighbor or remote router such as an RSVP backup LSP tail-end router to the nal
desnaon. The metric evaluaon is done either in ascending or descending order. By default, the
rst preference is given to backup paths with lowest desnaon evaluaon and then to backup paths
with lowest root metrics.
The evaluaon-order allows you to control the order and criteria of evaluang these aributes in the
backup path. You can explicitly congure the evaluaon order. Only the congured aributes inuence
the backup path selecon. The default order of evaluaon of these aributes for the LFA is [ admin-
group srlg bandwidth protecon-type neighbor neighbor-tag metric ] .
SEE ALSO
Example: Conguring Backup Selecon Policy for IS-IS Protocol
221
backup-selecon (Protocols IS-IS)
Example: Conguring Backup Selecon Policy for the OSPF or OSPF3
Protocol
IN THIS SECTION
Requirements | 222
Overview | 223
Conguraon | 224
Vericaon | 249
This example shows how to congure the backup selecon policy for the OSPF or OSPF3 protocol,
which enables you to select a loop-free alternate (LFA) in the network.
When you enable backup selecon policies, Junos OS allows selecon of LFA based on the policy rules
and aributes of the links and nodes in the network. These aributes are admin-group, srlg, bandwidth,
protecon-type, metric, and node.
Requirements
This example uses the following hardware and soware components:
• Eight routers that can be a combinaon of M Series Mulservice Edge Routers, MX Series 5G
Universal Roung Plaorms, PTX Series Packet Transport Routers, and T Series Core Routers
• Junos OS Release 15.1 or later running on all devices
Before you begin:
1. Congure the device interfaces.
2. Congure OSPF.
222
Overview
IN THIS SECTION
Topology | 223
In Junos OS, the default loop-free alternave (LFA) selecon algorithm or criteria can be overridden with
an LFA policy. These policies are congured for each desnaon (IPv4 and IPv6) and a primary next-hop
interface . These backup policies enforce LFA selecon based on admin-group, srlg, bandwidth,
protecon-type, metric, and node aributes of the backup path. During backup shortest-path-rst (SPF)
computaon, each aribute (both node and link) of the backup path, stored per backup next-hop, is
accumulated by IGP. For the routes created internally by IGP, the aribute set of every backup path is
evaluated against the policy congured for each desnaon (IPv4 and IPv6) and a primary next-hop
interface. The rst or the best backup path is selected and installed as the backup next hop in the
roung table. To congure the backup selecon policy, include the backup-selection conguraon
statement at the [edit routing-options] hierarchy level. The show backup-selection command displays the
congured policies for a given interface and desnaon. The display can be ltered against a parcular
desnaon, prex, interface, or logical systems.
Topology
In this topology shown in Figure 14 on page 224, the backup selecon policy is congured on Device
R3.
223
Figure 14: Example Backup Selecon Policy for OSPF or OPSF3
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 225
Conguring Device R3 | 239
Results | 243
224
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from conguraon mode.
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/30
set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:10:1:1::1/64
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/1/0 unit 0 family inet address 172.16.15.1/30
set interfaces ge-0/1/0 unit 0 family inet6 address 2001:db8:15:1:1::1/64
set interfaces ge-0/1/0 unit 0 family mpls
set interfaces xe-0/2/0 unit 0 family inet address 172.16.20.1/30
set interfaces xe-0/2/0 unit 0 family inet6 address 2001:db8:20:1:1::1/64
set interfaces xe-0/2/0 unit 0 family mpls
set interfaces ge-1/0/5 unit 0 family inet address 172.16.150.1/24
set interfaces ge-1/0/5 unit 0 family inet6 address 2001:db8:150:1:1::1/64
set interfaces ge-1/0/5 unit 0 family mpls
set interfaces ge-1/1/1 unit 0 family inet address 172.16.30.1/30
set interfaces ge-1/1/1 unit 0 family inet6 address 2001:db8:30:1:1::1/64
set interfaces ge-1/1/1 unit 0 family mpls
set interfaces xe-1/3/0 unit 0 family inet address 172.16.25.1/30
set interfaces xe-1/3/0 unit 0 family inet6 address 2001:db8:25:1:1::1/64
set interfaces xe-1/3/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.10.10.10/32 primary
set interfaces lo0 unit 0 family inet6 address 2001:db8::10:10:10:10/128 primary
set interfaces lo0 unit 0 family mpls
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 10.10.10.10
225
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 25
set protocols mpls admin-groups c26 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
set protocols mpls interface all
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 metric 18
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 51
set protocols ospf area 0.0.0.0 interface ge-1/1/1.0 metric 23
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 52
set protocols ospf area 0.0.0.0 interface ge-1/0/5.0
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 metric 18
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 51
226
set protocols ospf3 area 0.0.0.0 interface ge-1/1/1.0 metric 23
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 52
set protocols ospf3 area 0.0.0.0 interface ge-1/0/5.0
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.2/30
set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:10:1:1::2/64
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/5 unit 0 family inet address 172.16.35.1/30
set interfaces ge-0/0/5 unit 0 family inet6 address 2001:db8:35:1:1::1/64
set interfaces ge-0/0/5 unit 0 family mpls
set interfaces xe-0/2/0 unit 0 family inet address 172.16.40.1/30
set interfaces xe-0/2/0 unit 0 family inet6 address 2001:db8:40:1:1::1/64
set interfaces xe-0/2/0 unit 0 family mpls
set interfaces xe-0/3/0 unit 0 family inet address 172.16.45.1/30
set interfaces xe-0/3/0 unit 0 family inet6 address 2001:db8:45:1:1::1/64
set interfaces xe-0/3/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 172.16.1.1/32 primary
set interfaces lo0 unit 0 family inet6 address 2001:db8::1:1:1:1/128 primary
set interfaces lo0 unit 0 family mpls
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 172.16.1.1
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
227
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 25
set protocols mpls admin-groups c26 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
set protocols mpls interface all
set protocols mpls interface ge-0/0/0.0 srlg srlg9
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 metric 10
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 10
set protocols ospf area 0.0.0.0 interface xe-0/3/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-0/3/0.0 metric 10
R2
set interfaces ge-0/0/2 unit 0 family inet address 172.16.35.2/30
set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:35:1:1::2/64
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/1/0 unit 0 family inet address 172.16.50.1/30
228
set interfaces ge-0/1/0 unit 0 family inet6 address 2001:db8:50:1:1::1/64
set interfaces ge-0/1/0 unit 0 family mpls
set interfaces xe-0/2/1 unit 0 family inet address 172.16.55.1/30
set interfaces xe-0/2/1 unit 0 family inet6 address 2001:db8:55:1:1::1/64
set interfaces xe-0/2/1 unit 0 family mpls
set interfaces ge-1/0/2 unit 0 family inet address 172.16.60.1/30
set interfaces ge-1/0/2 unit 0 family inet6 address 2001:db8:60:1:1::1/64
set interfaces ge-1/0/2 unit 0 family mpls
set interfaces ge-1/0/9 unit 0 family inet address 172.16.65.1/30
set interfaces ge-1/0/9 unit 0 family inet6 address 2001:db8:65:1:1::1/64
set interfaces ge-1/0/9 unit 0 family mpls
set interfaces ge-1/1/5 unit 0 family inet address 172.16.70.1/30
set interfaces ge-1/1/5 unit 0 family inet6 address 2001:db8:70:1:1::1/64
set interfaces ge-1/1/5 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 172.16.2.2/32 primary
set interfaces lo0 unit 0 family inet6 address 2001:db8::2:2:2:2/128 primary
set interfaces lo0 unit 0 family mpls
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 172.16.2.2
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
229
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 25
set protocols mpls admin-groups c26 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
set protocols mpls interface all
set protocols mpls interface ge-0/1/0.0 srlg srlg1
set protocols mpls interface ge-1/0/9.0 srlg srlg1
set protocols mpls interface ge-1/1/5.0 srlg srlg7
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 link-protection
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0 metric 12
set protocols ospf area 0.0.0.0 interface ge-1/0/2.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-1/0/9.0 metric 12
set protocols ospf area 0.0.0.0 interface ge-1/1/5.0 metric 13
set protocols ospf3 area 0.0.0.0 interface ge-0/0/2.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 link-protection
set protocols ospf3 area 0.0.0.0 interface xe-0/2/1.0 metric 12
set protocols ospf3 area 0.0.0.0 interface ge-1/0/2.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-1/0/9.0 metric 12
set protocols ospf3 area 0.0.0.0 interface ge-1/1/5.0 metric 13
R3
set interfaces ge-0/0/5 unit 0 family inet address 172.16.50.2/30
set interfaces ge-0/0/5 unit 0 family inet6 address 2001:db8:50:1:1::2/64
set interfaces ge-0/0/5 unit 0 family mpls
230
set interfaces xe-0/3/1 unit 0 family inet address 172.16.75.1/30
set interfaces xe-0/3/1 unit 0 family inet6 address 2001:db8:75:1:1::1/64
set interfaces xe-0/3/1 unit 0 family mpls
set interfaces ge-1/0/0 unit 0 family inet address 172.16.80.1/30
set interfaces ge-1/0/0 unit 0 family inet6 address 2001:db8:80:1:1::1/64
set interfaces ge-1/0/0 unit 0 family mpls
set interfaces ge-1/0/5 unit 0 family inet address 172.16.200.1/24
set interfaces ge-1/0/5 unit 0 family inet6 address 2001:db8:200:1:1::1/64
set interfaces ge-1/0/6 unit 0 family inet address 172.16.85.1/30
set interfaces ge-1/0/6 unit 0 family inet6 address 2001:db8:85:1:1::1/64
set interfaces ge-1/0/6 unit 0 family mpls
set interfaces xe-1/3/0 unit 0 family inet address 172.16.90.1/30
set interfaces xe-1/3/0 unit 0 family inet6 address 2001:db8:90:1:1::1/64
set interfaces xe-1/3/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 172.16.3.3/32 primary
set interfaces lo0 unit 0 family inet6 address 2001:db8::3:3:3:3/128 primary
set interfaces lo0 unit 0 family mpls
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 172.16.3.3
set routing-options forwarding-table export ecmp
set routing-options backup-selection destination 10.1.1.0/30 interface xe-1/3/0.0 admin-group
include-all c2
set routing-options backup-selection destination 10.1.1.0/30 interface all admin-group exclude c3
set routing-options backup-selection destination 10.1.1.0/30 interface all srlg strict
set routing-options backup-selection destination 10.1.1.0/30 interface all protection-type node
set routing-options backup-selection destination 10.1.1.0/30 interface all bandwidth-greater-
equal-primary
set routing-options backup-selection destination 10.1.1.0/30 interface all neighbor preference
172.16.7.7
set routing-options backup-selection destination 10.1.1.0/30 interface all root-metric lowest
set routing-options backup-selection destination 10.1.1.0/30 interface all metric-order root
set routing-options backup-selection destination 172.16.30.0/30 interface all admin-group
231
exclude c5
set routing-options backup-selection destination 172.16.30.0/30 interface all srlg strict
set routing-options backup-selection destination 172.16.30.0/30 interface all protection-type
node
set routing-options backup-selection destination 172.16.30.0/30 interface all bandwidth-greater-
equal-primary
set routing-options backup-selection destination 172.16.30.0/30 interface all neighbor
preference 172.16.7.7
set routing-options backup-selection destination 172.16.30.0/30 interface all root-metric lowest
set routing-options backup-selection destination 172.16.30.0/30 interface all metric-order root
set routing-options backup-selection destination 172.16.45.0/30 interface all admin-group
exclude c5
set routing-options backup-selection destination 172.16.45.0/30 interface all srlg strict
set routing-options backup-selection destination 172.16.45.0/30 interface all protection-type
node
set routing-options backup-selection destination 172.16.45.0/30 interface all bandwidth-greater-
equal-primary
set routing-options backup-selection destination 172.16.45.0/30 interface all neighbor
preference 172.16.7.7
set routing-options backup-selection destination 172.16.45.0/30 interface all root-metric lowest
set routing-options backup-selection destination 172.16.45.1/30 interface all metric-order root
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
232
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 25
set protocols mpls admin-groups c26 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
set protocols mpls interface all
set protocols mpls interface ge-0/0/5.0 admin-group c0
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 link-protection
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 metric 10
set protocols ospf area 0.0.0.0 interface xe-0/3/1.0 metric 21
set protocols ospf area 0.0.0.0 interface ge-1/0/0.0 metric 13
set protocols ospf area 0.0.0.0 interface ge-1/0/6.0 metric 15
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 link-protection
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 22
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 link-protection
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-0/3/1.0 metric 21
set protocols ospf3 area 0.0.0.0 interface ge-1/0/0.0 metric 13
set protocols ospf3 area 0.0.0.0 interface ge-1/0/6.0 metric 15
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 link-protection
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 22
set policy-options policy-statement ecmp term 1 then load-balance per-packet
R4
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
233
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 172.16.4.4
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 25
set protocols mpls admin-groups c26 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
set protocols mpls interface all
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 metric 18
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 10
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-1/1/0.0 metric 10
set protocols ospf area 0.0.0.0 interface xe-0/3/1.0 metric 21
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 metric 18
234
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-1/1/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-0/3/1.0 metric 21
R5
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 172.16.5.5
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
235
set protocols mpls admin-groups c20 20
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 25
set protocols mpls admin-groups c26 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
set protocols mpls interface all
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 51
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 metric 13
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 51
set protocols ospf3 area 0.0.0.0 interface ge-0/0/1.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-0/0/5.0 metric 13
set protocols ospf3 area 0.0.0.0 interface ge-0/1/0.0 metric 10
R6
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 172.16.6.6
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
236
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 25
set protocols mpls admin-groups c26 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
set protocols mpls interface all
set protocols ospf area 0.0.0.0 interface xe-0/3/0.0 metric 52
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 12
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 metric 15
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface xe-0/3/0.0 metric 52
set protocols ospf3 area 0.0.0.0 interface ge-0/0/0.0 metric 12
set protocols ospf3 area 0.0.0.0 interface ge-0/0/4.0 metric 15
set protocols ospf3 area 0.0.0.0 interface xe-0/2/0.0 metric 10
R7
set routing-options srlg srlg1 srlg-value 1001
set routing-options srlg srlg2 srlg-value 1002
237
set routing-options srlg srlg3 srlg-value 1003
set routing-options srlg srlg4 srlg-value 1004
set routing-options srlg srlg5 srlg-value 1005
set routing-options srlg srlg6 srlg-value 1006
set routing-options srlg srlg7 srlg-value 1007
set routing-options srlg srlg8 srlg-value 1008
set routing-options srlg srlg9 srlg-value 1009
set routing-options srlg srlg10 srlg-value 10010
set routing-options srlg srlg11 srlg-value 10011
set routing-options srlg srlg12 srlg-value 10012
set routing-options router-id 172.16.7.7
set protocols rsvp interface all
set protocols mpls admin-groups c0 0
set protocols mpls admin-groups c1 1
set protocols mpls admin-groups c2 2
set protocols mpls admin-groups c3 3
set protocols mpls admin-groups c4 4
set protocols mpls admin-groups c5 5
set protocols mpls admin-groups c6 6
set protocols mpls admin-groups c7 7
set protocols mpls admin-groups c8 8
set protocols mpls admin-groups c9 9
set protocols mpls admin-groups c10 10
set protocols mpls admin-groups c11 11
set protocols mpls admin-groups c12 12
set protocols mpls admin-groups c13 13
set protocols mpls admin-groups c14 14
set protocols mpls admin-groups c15 15
set protocols mpls admin-groups c16 16
set protocols mpls admin-groups c17 17
set protocols mpls admin-groups c18 18
set protocols mpls admin-groups c19 19
set protocols mpls admin-groups c20 20
set protocols mpls admin-groups c21 21
set protocols mpls admin-groups c22 22
set protocols mpls admin-groups c23 23
set protocols mpls admin-groups c24 24
set protocols mpls admin-groups c25 26
set protocols mpls admin-groups c27 27
set protocols mpls admin-groups c28 28
set protocols mpls admin-groups c29 29
set protocols mpls admin-groups c30 30
set protocols mpls admin-groups c31 31
238
set protocols mpls interface all
set protocols mpls interface xe-0/3/0.0 srlg srlg8
set protocols ospf area 0.0.0.0 interface ge-0/1/5.0 metric 23
set protocols ospf area 0.0.0.0 interface xe-0/3/0.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-1/0/0.0 metric 13
set protocols ospf area 0.0.0.0 interface xe-1/3/0.0 metric 22
set protocols ospf area 0.0.0.0 interface xe-1/2/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-0/1/5.0 metric 23
set protocols ospf3 area 0.0.0.0 interface xe-0/3/0.0 metric 10
set protocols ospf3 area 0.0.0.0 interface ge-1/0/0.0 metric 13
set protocols ospf3 area 0.0.0.0 interface xe-1/3/0.0 metric 22
set protocols ospf3 area 0.0.0.0 interface xe-1/2/0.0 metric 10
Conguring Device R3
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure Device R3:
1. Congure the interfaces.
[edit interfaces]
user@R3# set ge-0/0/5 unit 0 family inet address 172.16.50.2/30
user@R3# set ge-0/0/5 unit 0 family inet6 address 2001:db8:50:1:1::2/64
user@R3# set ge-0/0/5 unit 0 family mpls
user@R3# set xe-0/3/1 unit 0 family inet address 172.16.75.1/30
user@R3# set xe-0/3/1 unit 0 family inet6 address 2001:db8:75:1:1::1/64
user@R3# set xe-0/3/1 unit 0 family mpls
user@R3# set ge-1/0/0 unit 0 family inet address 172.16.80.1/30
user@R3# set ge-1/0/0 unit 0 family inet6 address 2001:db8:80:1:1::1/64
user@R3# set ge-1/0/0 unit 0 family mpls
user@R3# set ge-1/0/5 unit 0 family inet address 172.16.200.1/24
user@R3# set ge-1/0/5 unit 0 family inet6 address 2001:db8:200:1:1::1/64
user@R3# set ge-1/0/6 unit 0 family inet address 172.16.85.1/30
user@R3# set ge-1/0/6 unit 0 family inet6 address 2001:db8:85:1:1::1/64
user@R3# set ge-1/0/6 unit 0 family mpls
user@R3# set xe-1/3/0 unit 0 family inet address 172.16.90.1/30
user@R3# set xe-1/3/0 unit 0 family inet6 address 2001:db8:90:1:1::1/64
239
user@R3# set xe-1/3/0 unit 0 family mpls
user@R3# set lo0 unit 0 family inet address 172.16.3.3/32 primary
user@R3# set lo0 unit 0 family inet6 address 2001:db8::3:3:3:3/128 primary
user@R3# set lo0 unit 0 family mpls
2. Congure srlg values.
[edit routing-options]
user@R3# set srlg srlg1 srlg-value 1001
user@R3# set srlg srlg2 srlg-value 1002
user@R3# set srlg srlg3 srlg-value 1003
user@R3# set srlg srlg4 srlg-value 1004
user@R3# set srlg srlg5 srlg-value 1005
user@R3# set srlg srlg6 srlg-value 1006
user@R3# set srlg srlg7 srlg-value 1007
user@R3# set srlg srlg8 srlg-value 1008
user@R3# set srlg srlg9 srlg-value 1009
user@R3# set srlg srlg10 srlg-value 10010
user@R3# set srlg srlg11 srlg-value 10011
user@R3# set srlg srlg12 srlg-value 10012
3. Congure the ID of the router.
[edit routing-options]
user@R3# set router-id 172.16.3.3
4. Apply the roung policy to all equal-cost mulpaths exported from the roung table to the
forwarding table.
[edit routing-options]
user@R3# set forwarding-table export ecmp
5. Congure aributes of the backup selecon policy.
[edit routing-options backup-selection]
user@R3# set destination 10.1.1.0/30 interface xe-1/3/0.0 admin-group include-all c2
user@R3# set destination 10.1.1.0/30 interface all admin-group exclude c3
user@R3# set destination 10.1.1.0/30 interface all srlg strict
user@R3# set destination 10.1.1.0/30 interface all protection-type node
240
user@R3# set destination 10.1.1.0/30 interface all bandwidth-greater-equal-primary
user@R3# set destination 10.1.1.0/30 interface all neighbor preference 172.16.7.7
user@R3# set destination 10.1.1.0/30 interface all root-metric lowest
user@R3# set destination 10.1.1.0/30 interface all metric-order root
user@R3# set destination 172.16.30.0/30 interface all admin-group exclude c5
user@R3# set destination 172.16.30.0/30 interface all srlg strict
user@R3# set destination 172.16.30.0/30 interface all protection-type node
user@R3# set destination 172.16.30.0/30 interface all bandwidth-greater-equal-primary
user@R3# set destination 172.16.30.0/30 interface all neighbor preference 172.16.7.7
user@R3# set destination 172.16.30.0/30 interface all root-metric lowest
user@R3# set destination 172.16.30.0/30 interface all metric-order root
user@R3# set destination 192.168.45.0/30 interface all admin-group exclude c5
user@R3# set destination 192.168.45.0/30 interface all srlg strict
user@R3# set destination 192.168.45.0/30 interface all protection-type node
user@R3# set destination 192.168.45.0/30 interface all bandwidth-greater-equal-primary
user@R3# set destination 192.168.45.0/30 interface all neighbor preference 172.16.7.7
user@R3# set destination 192.168.45.0/30 interface all root-metric lowest
user@R3# set destination 192.168.45.0/30 interface all metric-order root
6. Enable RSVP on all the interfaces.
[edit protocols]
user@R3# set rsvp interface all
7. Congure administrave groups.
[edit protocols mpls]
user@R3# set admin-groups c0 0
user@R3# set admin-groups c1 1
user@R3# set admin-groups c2 2
user@R3# set admin-groups c3 3
user@R3# set admin-groups c4 4
user@R3# set admin-groups c5 5
user@R3# set admin-groups c6 6
user@R3# set admin-groups c7 7
user@R3# set admin-groups c8 8
user@R3# set admin-groups c9 9
user@R3# set admin-groups c10 10
user@R3# set admin-groups c11 11
user@R3# set admin-groups c12 12
user@R3# set admin-groups c13 13
241
user@R3# set admin-groups c14 14
user@R3# set admin-groups c15 15
user@R3# set admin-groups c16 16
user@R3# set admin-groups c17 17
user@R3# set admin-groups c18 18
user@R3# set admin-groups c19 19
user@R3# set admin-groups c20 20
user@R3# set admin-groups c21 21
user@R3# set admin-groups c22 22
user@R3# set admin-groups c23 23
user@R3# set admin-groups c24 24
user@R3# set admin-groups c25 25
user@R3# set admin-groups c26 26
user@R3# set admin-groups c27 27
user@R3# set admin-groups c28 28
user@R3# set admin-groups c29 29
user@R3# set admin-groups c30 30
user@R3# set admin-groups c31 31
8. Enable MPLS on all the interfaces and congure administrave group for an interface.
[edit protocols mpls]
user@R3# set interface all
user@R3# set interface ge-0/0/5.0 admin-group c0
9. Enable link protecon and congure metric values on all the interfaces for an OSPF area.
[edit protocols ospf]
user@R3# set area 0.0.0.0 interface ge-0/0/5.0 link-protection
user@R3# set area 0.0.0.0 interface ge-0/0/5.0 metric 10
user@R3# set area 0.0.0.0 interface xe-0/3/1.0 metric 21
user@R3# set area 0.0.0.0 interface ge-1/0/0.0 metric 13
user@R3# set area 0.0.0.0 interface ge-1/0/6.0 metric 15
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protection
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 metric 22
10. Enable link protecon and congure metric values on all the interfaces for an OSPF3 area.
[edit protocols ospf3]
user@R3# set area 0.0.0.0 interface ge-0/0/5.0 link-protection
242
user@R3# set area 0.0.0.0 interface ge-0/0/5.0 metric 10
user@R3# set area 0.0.0.0 interface xe-0/3/1.0 metric 21
user@R3# set area 0.0.0.0 interface ge-1/0/0.0 metric 13
user@R3# set area 0.0.0.0 interface ge-1/0/6.0 metric 15
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 link-protection
user@R3# set area 0.0.0.0 interface xe-1/3/0.0 metric 22
11. Congure the roung policy.
[edit policy-options]
user@R3# set policy-statement ecmp term 1 then load-balance per-packet
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R3# show interfaces
ge-0/0/5 {
unit 0 {
family inet {
address 192.168.50.2/30;
}
family inet6 {
address 2001:db8:50:1:1::2/64;
}
family mpls;
}
}
xe-0/3/1 {
unit 0 {
family inet {
address 192.168.75.1/30;
}
family inet6 {
address 2001:db8:75:1:1::1/64;
}
family mpls;
}
243
}
ge-1/0/0 {
unit 0 {
family inet {
address 192.168.80.1/30;
}
family inet6 {
address 2001:db8:80:1:1::1/64;
}
family mpls;
}
}
ge-1/0/5 {
unit 0 {
family inet {
address 172.16.200.1/24;
}
family inet6 {
address 2001:db8:200:1:1::1/64;
}
}
}
ge-1/0/6 {
unit 0 {
family inet {
address 192.168.85.1/30;
}
family inet6 {
address 2001:db8:85:1:1::1/64;
}
family mpls;
}
}
xe-1/3/0 {
unit 0 {
family inet {
address 192.168.90.1/30;
}
family inet6 {
address 2001:db8:90:1:1::1/64;
}
family mpls;
}
244
}
lo0 {
unit 0 {
family inet {
address 172.16.3.3/32 {
primary;
}
}
family inet6 {
address 2001:db8:3:3:3:3/128 {
primary;
}
}
family mpls;
}
}
user@R3# show protocols
rsvp {
interface all;
}
mpls {
admin-groups {
c0 0;
c1 1;
c2 2;
c3 3;
c4 4;
c5 5;
c6 6;
c7 7;
c8 8;
c9 9;
c10 10;
c11 11;
c12 12;
c13 13;
c14 14;
c15 15;
c16 16;
c17 17;
245
c18 18;
c19 19;
c20 20;
c21 21;
c22 22;
c23 23;
c24 24;
c25 25;
c26 26;
c27 27;
c28 28;
c29 29;
c30 30;
c31 31;
}
interface all;
interface ge-0/0/5.0 {
admin-group c0;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/5.0 {
link-protection;
metric 10;
}
interface xe-0/3/1.0 {
metric 21;
}
interface ge-1/0/0.0 {
metric 13;
}
interface ge-1/0/6.0 {
metric 15;
}
interface xe-1/3/0.0 {
link-protection;
metric 22;
}
}
}
ospf3 {
area 0.0.0.0 {
246
interface ge-0/0/5.0 {
link-protection;
metric 10;
}
interface xe-0/3/1.0 {
metric 21;
}
interface ge-1/0/0.0 {
metric 13;
}
interface ge-1/0/6.0 {
metric 15;
}
interface xe-1/3/0.0 {
link-protection;
metric 22;
}
}
}
user@R3# show routing-options
srlg {
srlg1 srlg-value 1001;
srlg2 srlg-value 1002;
srlg3 srlg-value 1003;
srlg4 srlg-value 1004;
srlg5 srlg-value 1005;
srlg6 srlg-value 1006;
srlg7 srlg-value 1007;
srlg8 srlg-value 1008;
srlg9 srlg-value 1009;
srlg10 srlg-value 10010;
srlg11 srlg-value 10011;
srlg12 srlg-value 10012;
}
router-id 172.16.3.3;
forwarding-table {
export ecmp;
}
backup-selection {
destination 10.1.1.0/30 {
247
interface xe-1/3/0.0 {
admin-group {
include-all c2;
}
}
interface all {
admin-group {
exclude c3;
}
srlg strict;
protection-type node;
bandwidth-greater-equal-primary;
node {
preference 172.16.7.7;
}
root-metric lowest;
metric-order root;
}
}
destination 172.16.30.0/30 {
interface all {
admin-group {
exclude c5;
}
srlg strict;
protection-type node;
bandwidth-greater-equal-primary;
node {
preference 172.16.7.7;
}
root-metric lowest;
metric-order root;
}
}
destination 192.168.45.0/30 {
interface all {
admin-group {
exclude c5;
}
srlg strict;
protection-type node;
bandwidth-greater-equal-primary;
node {
248
preference 172.16.7.7;
}
root-metric lowest;
metric-order root;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Routes | 249
Verifying the OSPF Route | 253
Verifying the OSPF3 Route | 254
Verifying the Backup Selecon Policy for Device R3 | 254
Conrm that the conguraon is working properly.
Verifying the Routes
Purpose
Verify that the expected routes are learned.
Acon
From operaonal mode, run the show route command for the roung table.
user@R3> show route
inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.3.3/32 *[Direct/0] 02:22:27
> via lo0.0
10.4.0.0/16 *[Static/5] 02:22:57
249
> to 10.92.31.254 via fxp0.0
10.5.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.6.128.0/17 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.9.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.10.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.13.4.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.13.10.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.82.0.0/15 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.84.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.85.12.0/22 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.92.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.92.16.0/20 *[Direct/0] 02:22:57
> via fxp0.0
10.92.24.195/32 *[Local/0] 02:22:57
Local via fxp0.0
10.94.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.99.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.102.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.150.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.155.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.157.64.0/19 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.160.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.204.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.205.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
250
10.206.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.207.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.209.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.212.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.213.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.214.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.215.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.216.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.13.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.14.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.16.0/20 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.218.32.0/20 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
10.227.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
172.16.50.0/30 *[Direct/0] 02:19:55
> via ge-0/0/5.0
172.16.50.2/32 *[Local/0] 02:19:58
Local via ge-0/0/5.0
172.16.75.0/30 *[Direct/0] 02:19:55
> via xe-0/3/1.0
172.16.75.1/32 *[Local/0] 02:19:57
Local via xe-0/3/1.0
172.16.24.195/32 *[Direct/0] 02:22:57
> via lo0.0
172.16.0.0/12 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.0.0/16 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.102.0/23 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.136.0/24 *[Static/5] 02:22:57
251
> to 10.92.31.254 via fxp0.0
192.168.136.192/32 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.137.0/24 *[Static/5] 02:22:57
> to 10.92.31.254 via fxp0.0
192.168.233.5/32 *[OSPF/10] 00:16:55, metric 1
MultiRecv
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
47.0005.80ff.f800.0000.0108.0001.1280.9202.4195/152
*[Direct/0] 02:22:57
> via lo0.0
mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 00:16:55, metric 1
Receive
1 *[MPLS/0] 00:16:55, metric 1
Receive
2 *[MPLS/0] 00:16:55, metric 1
Receive
13 *[MPLS/0] 00:16:55, metric 1
Receive
inet6.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8:50:1:1::/64 *[Direct/0] 02:19:44
> via ge-0/0/5.0
2001:db8:50:1:1::2/128 *[Local/0] 02:19:58
Local via ge-0/0/5.0
2001:db8:75:1:1::/64 *[Direct/0] 02:19:44
> via xe-0/3/1.0
2001:db8:75:1:1::1/128 *[Local/0] 02:19:57
Local via xe-0/3/1.0
2001:db8::3:3:3:3/128 *[Direct/0] 02:22:27
> via lo0.0
2001:db8::128:92:24:195/128
*[Direct/0] 02:22:57
> via lo0.0
252
fe80::/64 *[Direct/0] 02:19:44
> via ge-0/0/5.0
[Direct/0] 02:19:43
> via xe-0/3/1.0
fe80::205:86ff:fe00:ed05/128
*[Local/0] 02:19:58
Local via ge-0/0/5.0
fe80::205:86ff:fe00:ed3d/128
*[Local/0] 02:19:57
Local via xe-0/3/1.0
fe80::5668:a50f:fcc1:3ca2/128
*[Direct/0] 02:22:57
> via lo0.0
Meaning
The output shows all Device R3 routes.
Verifying the OSPF Route
Purpose
Verify the roung table of OSPF.
Acon
From operaonal mode, run the show ospf route detail command for Device R3.
user@R3> show ospf route detail
Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop
Type Type Type Interface Address/LSP
172.16.50.0/30 Intra Network IP 10 ge-0/0/5.0
area 0.0.0.0, origin 172.16.3.3, priority low
172.16.75.0/30 Intra Network IP 21 xe-0/3/1.0
area 0.0.0.0, origin 172.16.3.3, priority low
253
Meaning
The output displays the roung table of OSPF routers.
Verifying the OSPF3 Route
Purpose
Verify the roung table of OSPF3.
Acon
From operaonal mode, run the show ospf3 route detail command for Device R3.
user@R3> show ospf3 route detail
Prefix Path Route NH Metric
Type Type Type
2001:db8:50:1:1::/64 Intra Network IP 10
NH-interface ge-0/0/5.0
Area 0.0.0.0, Origin 172.16.3.3, Priority low
2001:db8:75:1:1::/64 Intra Network IP 21
NH-interface xe-0/3/1.0
Area 0.0.0.0, Origin 172.16.3.3, Priority low
Meaning
The output displays the roung table of OSPF3 routers.
Verifying the Backup Selecon Policy for Device R3
Purpose
Verify the backup selecon policy for Device R3.
254
Acon
From operaonal mode, run the show backup-selection command for Device R3.
user@R3> show backup-selection
Prefix: 10.1.1.0/30
Interface: all
Admin-group exclude: c3
Neighbor preference: 172.16.7.7
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= Primary:
Enabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Root-metric, Dest-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric
Interface: xe-1/3/0.0
Admin-group include-all: c2
Protection Type: Link, Downstream Paths Only: Disabled, SRLG: Loose, B/w >= Primary:
Disabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Dest-metric, Root-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric Prefix:
172.16.30.0/30
Interface: all
Admin-group exclude: c5
Neighbor preference: 172.16.7.7
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= Primary:
Enabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Root-metric, Dest-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric
Prefix: 172.16.45.0/30
Interface: all
Admin-group exclude: c5
Neighbor preference: 172.16.7.7
Protection Type: Node, Downstream Paths Only: Disabled, SRLG: Strict, B/w >= Primary:
Enabled, Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Root-metric, Dest-metric
Policy Evaluation Order: Admin-group, SRLG, Bandwidth, Protection, node, Metric
Meaning
The output displays the congured policies per prex per primary next-hop interface.
255
RELATED DOCUMENTATION
backup-selecon (Protocols IS-IS)
256
CHAPTER 3
Evaluang Complex Cases Using Policy Chains and
Subrounes
IN THIS CHAPTER
Understanding How a Roung Policy Chain Is Evaluated | 257
Example: Conguring Policy Chains and Route Filters | 259
Example: Using Firewall Filter Chains | 276
Understanding Policy Subrounes in Roung Policy Match Condions | 284
How a Roung Policy Subroune Is Evaluated | 288
Example: Conguring a Policy Subroune | 291
Understanding How a Roung Policy Chain Is Evaluated
Figure 15 on page 258 shows how a chain of roung policies is evaluated. These roung policies consist
of mulple terms. Each term consists of match condions and acons to apply to matching routes. Each
route is evaluated against the policies as follows:
NOTE: On Junos OS Evolved, next term cannot appear as the last term of the acon. A lter term
where next term is specied as an acon but without any match condions congured is not
supported.
1. The route is evaluated against the rst term in the rst roung policy. If it matches, the specied
acon is taken. If the acon is to accept or reject the route, that acon is taken and the evaluaon of
the route ends. If the next term acon is specied, if no acon is specied, or if the route does not
match, the evaluaon connues as described in Step 2. If the next policy acon is specied, any
accept or reject acon specied in this term is skipped, all remaining terms in this policy are skipped,
all other acons are taken, and the evaluaon connues as described in Step 3.
2. The route is evaluated against the second term in the rst roung policy. If it matches, the specied
acon is taken. If the acon is to accept or reject the route, that acon is taken and the evaluaon of
257
the route ends. If the next term acon is specied, if no acon is specied, or if the route does not
match, the evaluaon connues in a similar manner against the last term in the rst roung policy. If
the next policy acon is specied, any accept or reject acon specied in this term is skipped, all
remaining terms in this policy are skipped, all other acons are taken, and the evaluaon connues as
described in Step 3.
3. If the route does not match a term or matches a term with a next policy acon in the rst roung
policy, it is evaluated against the rst term in the second roung policy.
4. The evaluaon connues unl the route matches a term with an accept or reject acon dened or
unl there are no more roung policies to evaluate. If there are no more roung policies, then the
accept or reject acon specied by the default policy is taken.
Figure 15: Roung Policy Chain Evaluaon
RELATED DOCUMENTATION
Default Roung Policies | 40
Example: Conguring Policy Chains and Route Filters | 259
258
Example: Conguring Policy Chains and Route Filters
IN THIS SECTION
Requirements | 259
Overview | 259
Conguraon | 262
Vericaon | 271
A
policy chain
is the applicaon of mulple policies within a specic secon of the conguraon. A
route lter
is a collecon of match prexes.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 261
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;
}
259
The adv-statics, adv-large-aggregates, and adv-small-aggregates policies, in addion to the default BGP policy,
make up the policy chain applied to the BGP peers of Device R1. Two of the policies demonstrate route
lters with dierent match types. The other policy matches all stac routes, so no route lter 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;
}
}
Oponally, you can convert this policy chain into a single multerm 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
dierent purposes.
Figure 16 on page 261 displays Device R1 in AS 64510 with its IBGP peers, Device R2 and Device R3.
Device R1 also has external BGP (EBGP) connecons to Device R4 in AS 64511 and Device R5 in AS
64512. The current administrave policy within AS 64510 is to send the customer stac 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 poron of these administrave policies is
congured in a separate roung policy within the
[edit policy-opitons]
conguraon hierarchy. These
260
policies provide the administrators of AS 64510 with mulple conguraon opons for adversing
routes to peers.
Device R4 is providing transit service to AS 64510, which allows the AS to adverse its assigned roung
space to the Internet. On the other hand, the peering service provided by Device R5 allows AS 64510 to
route trac directly between the autonomous systems (ASs) for all customer routes.
Topology
Figure 16 on page 261 shows the sample network.
Figure 16: BGP Topology for Policy Chains
"CLI Quick Conguraon" on page 262 shows the conguraon for all of the devices in Figure 16 on
page 261.
The secon "Procedure" on page 265 describes the steps on Device R1.
261
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 262
Procedure | 265
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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
262
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
263
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
264
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 conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure Device R1:
1. Congure the device interfaces.
[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
2. Congure the IBGP connecons to Device R2 and Device R3.
[edit protocols bgp group int]
user@R1# set type internal
user@R1# set local-address 192.168.0.1
265
user@R1# set neighbor 192.168.0.2
user@R1# set neighbor 192.168.0.3
3. Apply the export policies for the internal peers.
[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
4. Congure the EBGP connecon to Device R4.
[edit protocols bgp group to_64511]
user@R1# set type external
user@R1# set neighbor 10.1.0.6 peer-as 64511
5. Apply the export policy for Device R4.
[edit protocols bgp group to_64511]
user@R1# set export adv-large-aggregates
6. Congure the EBGP connecon to Device R5.
[edit protocols bgp group to_64512]
user@R1# set type external
user@R1# set neighbor 10.0.0.9 peer-as 64512
7. Apply the export policies for Device R5.
[edit protocols bgp group to_64512]
user@R1# set export adv-small-aggregates
user@R1# set export adv-statics
8. Congure OSPF connecons to Device R2 and Device R3.
[edit protocols ospf area 0.0.0.0]
user@R1# set interface fe-1/2/0.0
266
user@R1# set interface fe-1/2/2.0
user@R1# set interface lo0.0 passive
9. Congure the roung policies.
[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
10. Congure the stac and aggregate routes.
[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
11. Congure the autonomous system (AS) number and router ID.
[edit routing-options]
user@R1# set router-id 192.168.0.1
user@R1# set autonomous-system 64510
267
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
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 {
268
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;
}
269
}
}
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;
}
270
router-id 192.168.0.1;
autonomous-system 64510;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Route Adversement to Device R4 | 271
Checking Where the Longer Routes Are Originang | 272
Blocking the More Specic Routes | 273
Verifying the Route Adversement to Device R5 | 273
Conrm that the conguraon is working properly.
Verifying the Route Adversement to Device R4
Purpose
On Device R1, make sure that the customer routes are adversed to Device R4.
Acon
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
271
* 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 adverse 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 dened by the administrave policy, but a number of other routes with larger subnet masks are
also being sent to Device R4.
Checking Where the Longer Routes Are Originang
Purpose
On Device R1, nd where the other routes are coming from.
Acon
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 acve BGP
route, it is automacally adversed 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 specic
routes from being adversed.
272
Blocking the More Specic 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 adversed, thus accomplishing the goal of the administrave policy.
Acon
1. On Device R1, congure the not-larger-than-18 policy.
[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
2. On Device R1, apply the policy to the peering session with Device R4.
[edit protocols bgp group to_64511]
user@R1# set export not-larger-than-18
user@R1# commit
3. On Device R1, check which routes are adversed to Device R4.
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
Meaning
The policy chain is working correctly. Only the 172.16.0.0 /16 route is adversed to Device R4.
Verifying the Route Adversement to Device R5
Purpose
On Device R1, make sure that the customer routes are adversed to Device R5.
273
Device R5 is Device R1’s EBGP peer in AS 64512. The administrave policy states that this peer
receives only aggregate routes larger than 18 bits in length and all customer routes. In ancipaon 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.
Acon
1. On Device R2, congure an aggregate route for 172.16.128.0/17.
[edit routing-options aggregate]
user@R2# set route 172.16.128.0/17 discard
user@R2# commit
2. On Device R1, check which routes are adversed to Device R5.
user@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 adversed, in violaon of the administrave policy
274
3. On Device R1, congure the not-smaller-than-18 policy.
[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
4. On Device R1, apply the policy to the peering session with Device R5.
[edit protocols bgp group to_64512]
user@R1# set export not-smaller-than-18
user@R1# commit
5. On Device R1, check which routes are adversed to Device R5.
user@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 adversed to Device R5.
275
RELATED DOCUMENTATION
Understanding Route Filters for Use in Roung Policy Match Condions | 305
Route Filter Match Condions | 72
Example: Conguring Roung Policy Prex Lists | 398
Example: Conguring a Policy Subroune | 291
Example: Using Firewall Filter Chains
IN THIS SECTION
Requirements | 276
Overview | 277
Conguraon | 278
Vericaon | 283
This example shows the use of rewall lter chains. Firewall lters lter1, lter2, and lter3, are applied
to interface ge-0/1/1.0 using the input-chain and the output-chain conguraon statements.
Requirements
Before you begin:
• You should have a MX Series router with MPCs and running Junos release 18.4R1 or later.
If you are using PTX10001-36MR, PTX10004, PTX10008, or PTX10016 routers for this feature,
install Junos OS Evolved Release 21.4R1.
• The router should be congured for IP version 4 (IPv4) protocol (family inet) and congured the
logical interface with an interface address. All other inial router conguraons should be complete,
with basic IPv4 connecvity between the devices conrmed.
• The trac you send should be compable with the rewall lter rules so the rules you congure can
match the test trac you send.
276
Overview
IN THIS SECTION
Topology | 278
This examples shows how to chain mulple rewall lters for both ingress and egress so they can be
applied to a given interface and evaluated in sequence. The order of execuon occurs in the same order
as the chain, from le to right.
Using lter chains (as opposed to input-list lter) has the advantage of allowing mulple levels of
ltering, such as using an inial lter to perform generic classicaon (such as QoS), and then one or
more subsequent lters for addional renement (such as security) .
An input-list stops processing of packets upon accept or discard; subsequent rewall lters are not
evaluated, whereas in a rewall lter chain an accept or discard acon stops processing of the current
rewall lter, but the packet is presented to subsequent rewall lters in the rewall lter chain, if any.
Starng from Junos OS Evolved Release 21.4R1, you can use rewall lter chains on PTX10001-36MR,
PTX10004, PTX10008, and PTX10016 routers.
You can apply the lter chain as follows:
set interfaces
interface-name
unit
unit
family inet filter input-chain [
filter1 filter2 filter3
];
set interfaces
interface-name
unit
unit
family inet filter output-chain [
filter1 filter2 filter3
];
On PTX Evo plaorms, the feature has the following limitaons:
• You can congure only the rst lter in a chain of lters as interface specic. On MX Series routers,
you can congure all lters in a chain of lters as interface specic.
• You cannot congure the same lters as part of a regular CLI lter and chain lters on the same
interface specic bind point. On such interface specic bind points, replace the exisng CLI lter
with lter chains or vice-versa and commit them separately, to avoid an error.
• You cannot congure chain lters along with “family ANY” and interface-policers on the same bind
point.
• On loopback interfaces, output chain lters are not supported.
• On loopback interfaces, you cannot congure both input CLI regular lter and chain lters.
• For IRB interfaces, you cannot congure both regular CLI interface-specic lter and lter chains.
277
• For Layer 2 SP style output, you cannot congure both regular CLI interface specic lter and chain
lters.
• Filters such as fast-lookup-filter are not supported as part of CLI chain lters.
• CLI lters chains are not supported for Urpf-fail-lters.
• As egress lters for MPLS family are supported as fast-lookup-filter only and chain lters do not
support fast-lookup-lters, relevant commit check will be provided while conguring the family
MPLS egress chain lters.
Topology
In this example, you congure mulple rewall lters and then apply them in sequence by chaining them
to a given interface. This example uses ge-0/1/1.0 congured with the IP address 172.16.1.1/30 for both
the input and output chain. If a packet does not match any of the lters in the chain list, the packet is
dropped.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 278
Congure IPv4 Firewall Filters | 279
Apply the Chain of Input Filters | 280
Conrm and Commit Your Candidate Conguraon | 281
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level. The lter names used here are
lter1, and so on, while the term names are t1_f1 (term1, using lter1), and so on.
set firewall family inet filter filter1 term t1_f1 from protocol tcp
set firewall family inet filter filter1 term t1_f1 then count f1_t1_cnt
set firewall family inet filter filter1 term t2_f1 from precedence 7
278
set firewall family inet filter filter1 term t2_f1 then count f1_t2_cnt
set firewall family inet filter filter1 term t2_f1 then accept
set firewall family inet filter filter2 term t1_f2 from dscp 0
set firewall family inet filter filter2 term t1_f2 then count f2_t1_cnt
set firewall family inet filter filter2 term t2_f2 from source-port 1020
set firewall family inet filter filter2 term t2_f2 then count f2_t2_cnt
set firewall family inet filter filter2 term t2_f2 then accept
set firewall family inet filter filter3 term t1_f3 from destination-address 172.30.1.1/32
set firewall family inet filter filter3 term t1_f3 then count f3_t1_cnt
set firewall family inet filter filter3 term t2_f3 from destination-port 5454
set firewall family inet filter filter3 term t2_f3 then count f3_t2_cnt
set firewall family inet filter filter3 term t2_f3 then accept
set interfaces ge-0/1/1 unit 0 family inet address 172.16.1.1/30
set interfaces ge-0/1/1 unit 0 family inet filter input-chain [ filter1 filter2 filter3 ]
set interfaces ge-0/1/1 unit 0 family inet filter output-chain [ filter1 filter2 filter3 ]
Congure IPv4 Firewall Filters
Here we congure the rewall lters. Each has dierent match condions and count acons. The rst
two lters have mulple terms with the non-terminang acon of count, which means matching packets
will be passed on to the next lter in the chain, while the third has an acon of accept. Packets that
don't match any of the specied condions would be dropped.
Step-by-Step Procedure
To congure the rewall lters:
1. Navigate the CLI to the hierarchy level at which you congure IPv4 rewall lters.
[edit]
user@host# edit firewall family inet
2. Congure the rst rewall lter to count TCP packets, or packets with a precedence of 7, before
sending them on to the next lter in the chain.
[edit firewall family inet]
user@host# set filter filter1 term t1_f1 from protocol tcp
user@host# set filter filter1 term t1_f1 then count f1_t1_cnt
user@host# set filter filter1 term t2_f1 from precedence 7
279
user@host# set filter filter1 term t2_f1 then count f1_t2_cnt
user@host# set filter filter1 term t2_f1 then accept
3. Congure the second rewall lter to count DSCP packets, or packets with a source port of 1020,
before sending them on to the next lter in the chain.
[edit firewall family inet]
user@host# set filter filter2 term t1_f2 from dscp 0
user@host# set filter filter2 term t1_f2 then count f2_t1_cnt
user@host# set filter filter2 term t2_f2 from source-port 1020
user@host# set filter filter2 term t2_f2 then count f2_t2_cnt
user@host# set filter filter2 term t2_f2 then accept
4. Congure the last rewall lter to count and accept packets with a desnaon address of
172.30.1.1/32, or a desnaon port of 5454.
[edit firewall family inet]
user@host# set filter filter3 term t1_f3 from destination-address 172.30.1.1/32
user@host# set filter filter3 term t1_f3 then count f3_t1_cnt
user@host# set filter filter3 term t2_f3 from destination-port 5454
user@host# set filter filter3 term t2_f3 then count f3_t2_cnt
user@host# set filter filter3 term t2_f3 then accept
Apply the Chain of Input Filters
Here we aach the rewall lters to a given interface. The order of execuon occurs in the same order
as the chain, from le to right.
Step-by-Step Procedure
To assign the interface an IP address:
1. Navigate to the interface we are using for the lters, ge-0/1/1.0.
[edit]
user@host# edit interfaces ge-0/1/1 unit 0 family inet
280
2. Assign an IPv4 address to the logical interface.
[edit interfaces ge-0/1/1 unit 0 family inet]
user@host# set address 172.16.1.1/30
3. Apply the lters as a list of input lters.
[edit interfaces ge-0/1/1 unit 0 family inet]
user@host# set filter input-chain [ filter1 filter2 filter3 ]
user@host# set filter out-chain [ filter1 filter2 filter3 ]
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the rewall lters by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit firewall]
user@host# show
family inet {
}
filter filter1 {
term t1_f1 {
from {
protocol tcp;
}
then count f1_t1_cnt;
accept;
}
term t2_f1 {
from {
precedence 7;
}
then count f1_t2_cnt;
accept;
}
281
}
filter filter2 {
term t1_f2 {
from {
dscp 0;
}
then count f2_t1_cnt;
}
term t2_f2 {
from {
source-port 1020;
}
then count f2_t2_cnt;
}
}
filter filter3 {
term t1_f3 {
from {
destination-address {
172.30.1.1/32;
}
}
then {
count f3_t1_cnt;
}
}
term t2_f3 {
from {
destination-port 5454;
}
then {
count f3_t2_cnt;
accept;
}
}
}
}
}
282
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command.
[edit]
user@host# show interfaces
ge-0/1/1 {
unit 0 {
family inet {
filter {
input-chain [ filter1 filter2 filter3 ];
}
address 172.16.1.1/30;
}
}
}
3. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Vericaon
IN THIS SECTION
Send Trac Through the Firewall Filters | 283
Conrm that the conguraon works as expected, that is, that the matching trac is evaluated by each
of the lters lter1, lter2, and lter3, and that the expected acon (count or accept) has been taken.
Send Trac Through the Firewall Filters
Purpose
Send trac from one device to the router you have congured to see whether matching packets are
being evaluated by all relevant lters in the chain.
283
Acon
To verify that input packets are evaluated by lter1, lter2, and lter3:
1. From the remote host that is connected to ge-0/1/1.0, send a packet with a precedence of 7. The
packet should be counted and then evaluated by lter2.
2. From the remote host that is connected to ge-0/1/1.0, send a packet with DSCP value of 0. The packet
should be counted and then evaluated by lter3.
3. From the remote host that is connected to ge-0/1/1.0, send a packet with a desnaon address of
172.30.1.1/32 and a desnaon port number of 5454. The packet should be counted and then
accepted.
4. To display counter informaon for the lters you congured, enter the show firewall filter
filter-name
operaonal mode command. The command output displays the number of bytes and packets that
match lter terms associated with the counters.
RELATED DOCUMENTATION
output-chain
input-chain
Understanding Policy Subrounes in Roung Policy Match Condions
IN THIS SECTION
Conguring Subrounes | 285
You can use a roung policy called from another roung policy as a match condion. This process makes
the called policy a
subroune
.
In some ways, the Junos OS policy framework is similar to a programming language. This similarity
includes the concept of nesng policies into a policy subroune. A subroune in a soware program is a
secon of code that you reference on a regular basis. A policy subroune works in the same fashion—
you reference an exisng policy as a match criterion in another policy. The roung device rst evaluates
the subroune and then evaluates the main policy. The evaluaon of the subroune returns a true or
false Boolean result to the main policy. Because you are referencing the subroune as a match criterion,
284
a true result means that the main policy has a match and can perform any congured acons. A false
result from the subroune, however, means that the main policy does not have a match.
Conguring Subrounes
To congure a subroune in a roung policy to be called from another roung policy, create the
subroune and specify its name using the policy match condion in the from or to statement of another
roung policy.
NOTE: Do not evaluate a roung policy within itself. The result is that no prexes ever match the
roung policy.
The acon specied in a subroune is used to provide a match condion to the calling policy. If the
subroune species an acon of accept, the calling policy considers the route to be a match. If the
subroune species an acon of reject, the calling policy considers the route not to match. If the
subroune species an acon that is meant to manipulate the route characteriscs, the changes are
made.
Possible Consequences of Terminaon Acons in Subrounes
A subroune with parcular statements can behave dierently from a roung policy that contains the
same statements. With a subroune, you must remember that the possible terminaon acons of
accept or reject specied by the subroune or the default policy can greatly aect the expected results.
In parcular, you must consider what happens if a match does not occur with routes specied in a
subroune and if the default policy acon that is taken is the acon that you expect and want.
For example, imagine that you are a network administrator at an Internet service provider (ISP) that
provides service to Customer A. You have congured several roung policies for the dierent classes of
neighbors that Customer A presents on various links. To save me maintaining the roung policies for
Customer A, you have congured a subroune that idenes their routes and various roung policies
that call the subroune, as shown below:
[edit]
policy-options {
policy-statement customer-a-subroutine {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
285
then accept;
}
}
policy-options {
policy-statement send-customer-a-default {
from {
policy customer-a-subroutine;
}
then {
set metric 500;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-primary {
from {
policy customer-a-subroutine;
}
then {
set metric 100;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-secondary {
from {
policy customer-a-subroutine;
}
then {
set metric 200;
accept;
}
}
}
protocols {
bgp {
group customer-a {
export send-customer-a-default;
neighbor 10.1.1.1;
neighbor 10.1.2.1;
neighbor 10.1.3.1 {
286
export send-customer-a-primary;
}
neighbor 10.1.4.1 {
export send-customer-a-secondary;
}
}
}
}
The following results occur with this conguraon:
• The group-level export statement resets the metric to 500 when adversing all BGP routes to
neighbors 10.1.1.1 and 10.1.2.1 rather than just the routes that match the subroune route lters.
• The neighbor-level export statements reset the metric to 100 and 200 when adversing all BGP
routes to neighbors 10.1.3.1 and 10.1.4.1, respecvely, rather than just the BGP routes that match
the subroune route lters.
These unexpected results occur because the subroune policy does not specify a terminaon acon for
routes that do not match the route lter and therefore, the default BGP export policy of accepng all
BGP routes is taken.
If the statements included in this parcular subroune had been contained within the calling policies
themselves, only the desired routes would have their metrics reset.
This example illustrates the dierences between roung policies and subrounes and the importance of
the terminaon acon in a subroune. Here, the default BGP export policy acon for the subroune
was not carefully considered. A soluon to this parcular example is to add one more term to the
subroune that rejects all other routes that do not match the route lters:
[edit]
policy-options {
policy-statement customer-a-subroutine {
term accept-exact {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
then accept;
}
term reject-others {
then reject;
}
287
}
}
Terminaon acon strategies for subrounes in general include the following:
• Depend upon the default policy acon to handle all other routes.
• Add a term that accepts all other routes.
• Add a term that rejects all other routes.
The opon that you choose depends upon what you want to achieve with your subroune. Plan your
subrounes carefully.
RELATED DOCUMENTATION
How a Roung Policy Subroune Is Evaluated | 288
Example: Conguring a Policy Subroune | 291
How a Roung Policy Subroune Is Evaluated
Figure 17 on page 290 shows how a subroune is evaluated. The subroune is included in the rst term
of the rst roung policy in a chain. Each route is evaluated against the subroune as follows:
1. The route is evaluated against the rst term in the rst roung policy. If the route does not match all
match condions specied before the subroune, the subroune is skipped and the next term in the
roung policy is evaluated (see Step "2" on page 289). If the route matches all match condions
specied before the subroune, the route is evaluated against the subroune. If the route matches
the match condions in any of the subroune terms, two levels of evaluaon occur in the following
order:
a. The acons in the subroune term are evaluated. If one of the acons is accept, evaluaon of the
subroune ends and a Boolean value of TRUE is returned to the calling policy. If one of the
acons is reject, evaluaon of the subroune ends and FALSE is returned to the calling policy.
If the subroune does not specify the accept, reject or next-policy acon, it uses the accept or reject
acon specied by the default policy, and the values of TRUE or FALSE are returned to the calling
policy as described in the previous paragraph.
b. The calling policy’s subroune match condion is evaluated. During this part of the evaluaon,
TRUE equals a match and FALSE equals no match. If the subroune returns TRUE to the calling
288
policy, then the evaluaon of the calling policy connues. If the subroune returns FALSE to the
calling policy, then the evaluaon of the current term ends and the next term is evaluated.
2. The route is evaluated against the second term in the rst roung policy.
If you specify a policy chain as a subroune, the enre chain acts as a single subroune. As with other
chains, the acon specied by the default policy is taken only when the enre chain does not accept or
reject a route.
If a term denes mulple match condions, including a subroune, and a route does not match a
condion specied before the subroune, the evaluaon of the term ends and the subroune is not
called and evaluated. In this situaon, an acon specied in the subroune that manipulates a route’s
characteriscs is not implemented.
289
Figure 17: Roung Policy Subroune Evaluaon
RELATED DOCUMENTATION
Default Roung Policies | 40
Understanding Policy Subrounes in Roung Policy Match Condions | 284
Understanding How a Roung Policy Chain Is Evaluated | 257
290
Example: Conguring a Policy Subroune | 291
Example: Conguring a Policy Subroune
IN THIS SECTION
Requirements | 291
Overview | 291
Conguraon | 293
Vericaon | 300
This example demonstrates the use of a policy subroune in a roung policy match condion.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 293
On Device R1, a policy called main is congured.
user@R1# show policy-options
policy-statement main {
term subroutine-as-a-match {
from policy subroutine;
then accept;
}
term nothing-else {
then reject;
291
}
}
This main policy calls a subroune called subroutine.
user@R1# show policy-options
policy-statement subroutine {
term get-routes {
from protocol static;
then accept;
}
term nothing-else {
then reject;
}
}
The router evaluates the logic of main in a dened manner. The match criterion of from policy subroutine
allows the roung device to locate the subroune. All terms of the subroune are evaluated, in order,
following the normal policy processing rules. In this example, all stac routes in the roung table match
the subroune with an acon of accept. This returns a true result to the original, or calling, policy which
informs the device that a posive match has occurred. The acons in the calling policy are executed and
the route is accepted. All other routes in the roung table do not match the subroune and return a
false result to the calling policy. The device evaluates the second term of main and rejects the routes.
The acons in the subroune do not actually accept or reject a specic route. The subroune acons are
only translated into a true or a false result. Acons that modify a route’s aributes, however, are applied
to the route regardless of the outcome of the subroune.
Device R1 in AS 64510 has mulple customer routes, some of which are stac routes congured locally,
and some of which are received from Device R2 and Device R3 through internal BGP (IBGP). AS 64510
is connected to Device R4 in AS 64511. The policy main is applied as an export policy in Device R1’s BGP
peering session with Device R4. This causes Device R1 to send only its own stac routes to Device R4.
Because of the policy main, Device R1 does not send the routes received from its internal peers, Device
R2 and Device R3.
When you are working with policy subrounes, it is important to remember that the default EBGP
export policy is to adverse all learned BGP routes to all EBGP peers. This default policy is in eect in
the main policy and also in the subroune. Therefore, as shown in this example, if you do not want the
default EBGP export policy to take eect, you must congure a then reject terminang acon as the nal
term in both the main policy and in the policy subroune. This example demonstrates what happens
when the nal then reject term is missing either from the main policy or from the policy subroune.
292
Topology
Figure 18 on page 293 shows the sample network.
Figure 18: BGP Topology for Policy Subroune
"CLI Quick
Conguraon" on page 294 shows the conguraon for all of the devices in Figure 18 on
page 293.
The secon "No Link Title" on page 296 describes the steps on Device R1.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 294
Procedure | 296
293
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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 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 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 main
set protocols bgp group to_64511 neighbor 10.1.0.6 peer-as 64511
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 main term subroutine-as-a-match from policy subroutine
set policy-options policy-statement main term subroutine-as-a-match then accept
set policy-options policy-statement main term nothing-else then reject
set policy-options policy-statement subroutine term get-routes from protocol static
set policy-options policy-statement subroutine term get-routes then accept
set policy-options policy-statement subroutine term nothing-else then reject
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 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
294
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
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 term 1 from protocol static
set policy-options policy-statement send-static 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 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
set protocols bgp group int neighbor 192.168.0.2
set protocols ospf area 0.0.0.0 interface fe-1/2/2.6
set protocols ospf area 0.0.0.0 interface fe-1/2/0.4
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set policy-options policy-statement send-static from protocol static
set policy-options policy-statement send-static 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 router-id 192.168.0.3
set routing-options autonomous-system 64510
295
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
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure Device R1:
1. Congure the device interfaces.
[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 lo0 unit 0 family inet address 192.168.0.1/32
2. Congure the internal BGP (IBGP) connecons to Device R2 and Device R3.
[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
296
3. Congure the EBGP connecon to Device R4.
[edit protocols bgp group to_64511]
user@R1# set type external
user@R1# set export main
user@R1# set neighbor 10.1.0.6 peer-as 64511
4. Congure OSPF connecons to Device R2 and Device R3.
[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
5. Congure the policy main.
[edit policy-options policy-statement main term subroutine-as-a-match]
user@R1# set from policy subroutine
user@R1# set then accept
[edit policy-options policy-statement main term nothing-else]
user@R1# set then reject
6. Congure the policy subroutine.
[edit policy-options policy-statement subroutine term get-routes]
user@R1# set from protocol static
user@R1# set then accept
[edit policy-options policy-statement subroutine term nothing-else]
user@R1# set then reject
7. Congure the stac route to the 172.16.5.0/24 network.
[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
297
8. Congure the autonomous system (AS) number and router ID.
[edit routing-options]
user@R1# set router-id 192.168.0.1
user@R1# set autonomous-system 64510
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
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;
}
}
}
lo0 {
unit 0 {
family inet {
298
address 192.168.0.1/32;
}
}
}
user@R1# show protocols
bgp {
group int {
type internal;
local-address 192.168.0.1;
neighbor 192.168.0.2;
neighbor 192.168.0.3;
}
group to_64511 {
type external;
export main;
neighbor 10.1.0.6 {
peer-as 64511;
}
}
}
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 main {
term subroutine-as-a-match {
from policy subroutine;
then accept;
}
term nothing-else {
then reject;
}
299
}
policy-statement subroutine {
term get-routes {
from protocol static;
then accept;
}
term nothing-else {
then reject;
}
}
user@R1# show routing-options
static {
route 172.6.1.16/28 discard;
route 172.6.1.32/28 discard;
route 172.6.1.48/28 discard;
route 172.6.1.64/28 discard;
}
router-id 192.168.0.1;
autonomous-system 64510;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Routes on Device R1 | 300
Verifying the Route Adversement to Device R4 | 301
Experimenng with the Default BGP Export Policy | 302
Conrm that the conguraon is working properly.
Verifying the Routes on Device R1
Purpose
On Device R1, check the stac routes in the roung table.
300
Acon
user@R1> show route protocol static
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.16/28 *[Static/5] 1d 02:02:13
Discard
172.16.1.32/28 *[Static/5] 1d 02:02:13
Discard
172.16.1.48/28 *[Static/5] 1d 02:02:13
Discard
172.16.1.64/28 *[Static/5] 1d 02:02:13
Discard
Meaning
Device R1 has four stac routes.
Verifying the Route Adversement to Device R4
Purpose
On Device R1, make sure that the stac routes are adversed to Device R4.
Acon
user@R1> show route advertising-protocol bgp 10.1.0.6
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 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
301
Meaning
As expected, Device R1 only adverses its stac routes to Device R4.
Experimenng with the Default BGP Export Policy
Purpose
See what can happen when you remove the nal then reject term from the policy main or the policy
subroutine.
Acon
1. On Device R1, deacvate the nal term in the policy main.
[edit policy-options policy-statement main]
user@R1# deactivate term nothing-else
user@R1# commit
2. On Device R1, check to see which routes are adversed to Device R4.
user@R1> show route advertising-protocol bgp 10.1.0.6
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 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.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.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
Now, all the BGP routes from Device R1 are sent to Device R4. This is because aer the processing is
returned to policy main, the default BGP export policy takes eect.
302
3. On Device R1, reacvate the nal term in the policy main, and deacvate the nal term in the policy
subroutine.
[edit policy-options policy-statement main]
user@R1# activate term nothing-else
[edit policy-options policy-statement subroutine]
user@R1# deactivate term nothing-else
user@R1# commit
4. On Device R1, check to see which routes are adversed to Device R4.
user@R1> show route advertising-protocol bgp 10.1.0.6
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 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.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.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
Now, all the BGP routes from Device R1 are sent to Device R4. This is because before the processing
is returned to policy main, the default BGP export policy takes eect in the policy subroutine.
Meaning
To prevent the default BGP export policy from taking eect, you must include a nal then reject term in
the main policy and in all referenced subrounes.
RELATED DOCUMENTATION
Understanding Policy Subrounes in Roung Policy Match Condions | 284
303
How a Roung Policy Subroune Is Evaluated | 288
304
CHAPTER 4
Conguring Route Filters and Prex Lists as Match
Condions
IN THIS CHAPTER
Understanding Route Filters for Use in Roung Policy Match Condions | 305
Understanding Route Filter and Source Address Filter Lists for Use in Roung Policy Match Condions | 329
Understanding Load Balancing Using Source or Desnaon IP Only | 329
Conguring Load Balancing Using Source or Desnaon IP Only | 330
Walkup for Route Filters Overview | 332
Conguring Walkup for Route Filters to Improve Operaonal Eciency | 336
Example: Conguring Route Filter Lists | 342
Example: Conguring Walkup for Route Filters Globally to Improve Operaonal Eciency | 348
Example: Conguring Walkup for Route Filters Locally to Improve Operaonal Eciency | 356
Example: Conguring a Route Filter Policy to Specify Priority for Prexes Learned Through OSPF | 364
Example: Conguring the MED Using Route Filters | 370
Example: Conguring Layer 3 VPN Protocol Family Qualiers for Route Filters | 390
Understanding Prex Lists for Use in Roung Policy Match Condions | 394
Example: Conguring Roung Policy Prex Lists | 398
Example: Conguring the Priority for Route Prexes in the RPD Infrastructure | 414
Conguring Priority for Route Prexes in RPD Infrastructure | 428
Understanding Route Filters for Use in Roung Policy Match Condions
IN THIS SECTION
Radix Trees | 306
305
Conguring Route Filters | 308
How Route Filters Are Evaluated in Roung Policy Match Condions | 316
Route Filter Examples | 319
A
route lter
is a collecon of match prexes. When specifying a match prex, you can specify an exact
match with a parcular route or a less precise match. You can congure either a common acon that
applies to the enre list or an acon associated with each prex.
NOTE: Because the conguraon of route lters includes seng up prexes and prex lengths,
before proceeding with the conguraon you should have a thorough understanding of IP
addressing, including superneng, and how route lters are evaluated (explained here: "How
Route Filters Are Evaluated in Roung Policy Match Condions" on page 316).
This secon discusses the following topics:
Radix Trees
To understand the operaon of a route lter, you need to be familiar with a device used for binary
number matching known as a radix tree (somemes called a patricia trie or radix trie). A radix tree uses
binary lookups to idenfy IP addresses (routes). Remember that an IP address is a 32-bit number
represented in a doed decimal format for easy comprehension by humans. These 8-bit groupings can
each have a value between 0 and 255. A radix tree can be a graphical representaon of these binary
numbers.
In Figure 19 on page 306, the radix tree starts with no congured value (starts at 0) and is at the
lemost posion of the binary IP address. This is shown as 0/0, which is oen referred to as the default
route.
Figure 19: Beginning of a Radix Tree
306
Because this is binary, each bit can have only one of two possible values—a 0 or a 1. Moving down the
le branch represents a value of 0, while moving to the right represents a value of 1. The rst step is
shown in Figure 20 on page 307. At the rst posion, the rst octet of the IP address has a value of
00000000 or 10000000—a 0 or 128, respecvely. This is represented in Figure 20 on page 307 by the
values 0/1 and 128/1.
Figure 20: First Step of a Radix Tree
The second step is shown in Figure 21 on page 307. This second level of the tree has four possible
binary values for the rst octet: 00000000, 01000000, 10000000, and 11000000. These decimal values
of 0, 64, 128, and 192 are represented by the IP addresses of 0/2, 64/2, 128/2, and 192/2 on the radix
tree.
Figure 21: Second Step of a Radix Tree
This step-by-step process connues for 33 total levels to represent every possible IP address.
The radix tree structure is helpful when locang a group of routes that all share the same most
signicant bits. Figure 22 on page 308 shows the point in the radix tree that represents the
192.168.0.0/16 network. All of the routes that are more specic than 192.168.0.0/16 are shown in the
highlighted secon.
307
Figure 22: Locang a Group of Routes
Conguring Route Filters
NOTE: The topic, Conguring Route Filters, describes default Junos OS behavior. The walkup
feature, which is not covered in this topic, alters the evaluaon results discussed in this topic by
allowing the router to consider shorter match condions congured within the same term. See
"Walkup for Route Filters Overview" on page 332 for details.
To congure a route lter, include one or more route-filter or source-address-filter statements:
[edit policy-options policy-statement
policy-name
term
term-name
from]
route-filter
destination-prefix
match-type
{
actions
;
}
The route-filter opon is typically used to match an incoming route address to desnaon match
prexes of any type except for unicast source addresses.
The
destination-prefix
address is the IP version 4 (IPv4) or IP version 6 (IPv6) address prex specied as
prefix
/
prefix-length
. If you omit
prefix-length
for an IPv4 prex, the default is /32. If you omit
prefix-length
for an IPv6 prex, the default is /128. Prexes specied in a from statement must be either all IPv4
addresses or all IPv6 addresses.
308
The source-address-filter opon is typically used to match an incoming route address to unicast source
addresses in mulprotocol BGP (MBGP) and Mulcast Source Discovery Protocol (MSDP) environments.
source-address-filter
source-prefix
match-type
{
actions
;
}
source-prefix
address is the IPv4 or IPv6 address prex specied as
prefix
/
prefix-length
. If you omit
prefix-
length
for an IPv4 prex, the default is /32
prefix-length
. If you omit
prefix-length
for an IPv6 prex, the
default is /128. Prexes specied in a from statement must be either all IPv4 addresses or all IPv6
addresses.
match-type
is the type of match to apply to the source or desnaon prex. It can be one of the match
types listed in Table 14 on page 310. For examples of the match types and the results when presented
with various routes, see Table 15 on page 315.
actions
are the acons to take if a route address matches the criteria specied for a desnaon match
prex (specied as part of a route-filter opon) or for a source match prex (specied as part of a
destination-address-filter opon). The acons can consist of one or more of the acons described in
"Acons in Roung Policy Terms" on page 75.
In a route lter you can specify acons in two ways:
• In the route-filter or source-address-filter opon—These acons are taken immediately aer a match
occurs, and the then statement is not evaluated.
• In the then statement—These acons are taken aer a match occurs but no acons are specied for
the route-filter or source-address-filter opon.
The upto and prefix-length-range match types are similar in that both specify the most-signicant bits and
provide a range of prex lengths that can match. The dierence is that upto allows you to specify an
upper limit only for the prex length range, whereas prefix-length-range allows you to specify both lower
and upper limits.
For more examples of these route lter match types, see "Route Filter Examples" on page 319.
309
Table 14: Route Filter Match Types for a Prex List
Match Type Match Criteria
address-mask
netmask-
value
All of the following are true:
• The bit-wise logical AND of the
netmask-value
paern and the incoming IPv4 or IPv6 route
address and the bit-wise logical AND of the
netmask-value
paern and the
destination-
prefix
address are the same. The bits set in the
netmask-value
paern do not need to be
conguous.
• The
prefix-length
component of the incoming IPv4 or IPv6 route address and the
prefix-
length
component of the
destination-prefix
address are the same.
NOTE: The address-mask roung policy match type is valid only for matching an incoming IPv4
(family inet) or IPv6 (family inet6) route address to a list of desnaon match prexes
specied in a route-filter statement.
The address-mask roung policy match type enables you to match an incoming IPv4 or IPv6
route address on a congured netmask address in addion to the length of a congured
desnaon match prex. The length of the route address must match exactly with the length
of the congured desnaon match prex, as the address-mask match type does not support
prex length variaons for a range of prex lengths.
When the longest-match lookup is performed on a route lter, the lookup evaluates an
address-mask match type dierently from other roung policy match types. The lookup
does not consider the length of the desnaon match prex. Instead, the lookup considers
the number of conguous high-order bits set in the netmask value.
For more informaon about this route lter match type, see "How an Address Mask Match
Type Is Evaluated" on page 318.
For example conguraons showing route lters that contain the address-mask match type,
see the following topics:
• "Accepng Incoming IPv4 Routes by Applying an Address Mask to the Route Address and
the Desnaon Match Prex" on page 325.
• "Accepng Incoming IPv4 Routes with Similar Paerns But Dierent Prex Lengths" on
page 326.
• "Evaluaon of an Address Mask Match Type with Longest-Match Lookup" on page 327.
310
Table 14: Route Filter Match Types for a Prex List
(Connued)
Match Type Match Criteria
exact
All of the following are true:
• The route address shares the same most-signicant bits as the match prex (
destination-
prefix
or
source-prefix
). The number of signicant bits is described by the
prefix-length
component of the match prex.
• The
prefix-length
component of the match prex is equal to the route’s prex length.
longer
All of the following are true:
• The route address shares the same most-signicant bits as the match prex (
destination-
prefix
or
source-prefix
). The number of signicant bits is described by the
prefix-length
component of the match prex.
• The route’s prex length is greater than the
prefix-length
component of the match prex.
orlonger
All of the following are true:
• The route address shares the same most-signicant bits as the match prex (
destination-
prefix
or the
source-prefix
). The number of signicant bits is described by the
prefix-
length
component of the match prex.
• The route’s prex length is equal to or greater than the
prefix-length
component of the
congured match prex.
prefix-length-range
prefix-length2
-
prefix-
length3
All of the following are true:
• The route address shares the same most-signicant bits as the match prex (
destination-
prefix
or
source-prefix
). The number of signicant bits is described by the
prefix-length
component of the match prex.
• The route’s prex length falls between
prefix-length2
and
prefix-length3
, inclusive.
311
Table 14: Route Filter Match Types for a Prex List
(Connued)
Match Type Match Criteria
through {
destination-
prefix2
|
source-
prefix2
}
All of the following are true:
• The route address shares the same most-signicant bits as the rst match prex
(
destination-prefix
or
source-prefix
). The number of signicant bits is described by the
prefix-length
component of the rst match prex.
• The route address shares the same most-signicant bits as the second match prex
(
destination-prefix2
or
source-prefix2
). The number of signicant bits is described by the
prefix-length
component of the second match prex.
• The route’s prex length is less than or equal to the
prefix-length
component of the
second match prex.
You do not use the through match type in most roung policy conguraons. For an example,
see "Rejecng Routes from Specic Hosts" on page 321.
upto
prefix-length2
All of the following are true:
• The route address shares the same most-signicant bits as the match prex (
destination-
prefix
or
source-prefix
). The number of signicant bits is described by the
prefix-length
component of the match prex.
• The route’s prex length falls between the
prefix-length
component of the rst match
prex and
prefix-length2
.
Figure 23 on page 313
shows the detailed radix tree for the route 192.168.0.0/16.
312
Figure 23: Poron of the Radix Tree
Figure 24 on page 314 and Table 15 on page 315 demonstrate the operaon of the various route lter
match types.
313
Figure 24: Route Filter Match Types
314
Table 15: Match Type Examples
Prex 192.168/1
6 exact
192.168/1
6 longer
192.168/1
6 orlonger
192.168/1
6 upto /24
192.168/16
prex-length-
range/18 –
/20
192.168/16
through192.
168.16/20
192.168/19
address-
mask255.255.
0.0
10.0.0.0/8 – – – – – – –
192.168.0.
0/16
Match – Match Match – Match –
192.168.0.
0/17
– Match Match Match – Match –
192.168.0.
0/18
– Match Match Match Match Match –
192.168.0.
0/19
– Match Match Match Match Match Match
192.168.4.
0/24
– Match Match Match – – –
192.168.5.
4/30
– Match Match – – – –
192.168.1
2.4/30
– Match Match – – – –
192.168.1
2.128/32
– Match Match – – – –
192.168.1
6.0/20
– Match Match Match Match Match –
192.168.1
92.0/18
– Match Match Match Match – –
315
Table 15: Match Type Examples
(Connued)
Prex 192.168/1
6 exact
192.168/1
6 longer
192.168/1
6 orlonger
192.168/1
6 upto /24
192.168/16
prex-length-
range/18 –
/20
192.168/16
through192.
168.16/20
192.168/19
address-
mask255.255.
0.0
192.168.2
24.0/19
– Match Match Match Match – Match
10.169.1.0
/24
– – – – – – –
10.170.0.0
/16
– – – – – – –
How Route Filters Are Evaluated in Roung Policy Match Condions
During route lter evaluaon, the policy framework soware compares each route’s source address with
the desnaon prexes in the route lter. The evaluaon occurs in two steps:
1. The policy framework soware performs a
longest-match lookup
, which means that the soware
searches for the prex in the list with the longest length.
The longest-match lookup considers the
prefix
and
prefix-length
components of the congured match
prex only, and not the
match-type
component. The following sample route lter illustrates this point:
from {
route-filter 192.168.0.0/14 upto /24 reject;
route-filter 192.168.0.0/15 exact;
}
then accept;
The longest match for the candidate route 192.168.1.0/24 is the second route-lter,
192.168.0.0/15, which is based on prex and prex length only.
2. When an incoming route matches a prex (longest rst), the following acons occur:
a. The route lter stops evaluang other prexes, even if the match type fails.
b. The soware examines the match type and acon associated with that prex.
316
NOTE: When a route source address is evaluated against a match criteria that uses the address-
mask match type, both steps of the evaluaon include the congured netmask value. For more
informaon, see "How an Address Mask Match Type Is Evaluated" on page 318.
In Step 1, if route 192.168.1.0/24 were evaluated, it would fail to match. It matches the longest prex of
192.168.0.0/15, but it does not match exact. The route lter is nished because it matched a prex, but
the result is a failed match because the match type failed.
If a match occurs, the acon specied with the prex is taken. If an acon is not specied with the
prex, the acon in the then statement is taken. If neither acon is specied, the soware evaluates the
next term or roung policy, if present, or takes the accept or reject acon specied by the default policy.
For more informaon about the default roung policies, see "Default Roung Policies" on page 40.
NOTE: If you specify mulple prexes in the route lter, only one prex needs to match for a
match to occur. The route lter matching is eecvely a logical OR operaon.
If a match does not occur, the soware evaluates the next term or roung policy, if present, or takes the
accept or reject acon specied by the default policy.
For example, compare the prex 192.168.254.0/24 against the following route lter:
route-filter 192.168.0.0/16 orlonger;
route-filter 192.168.254.0/23 exact;
The prex 192.168.254.0/23 is determined to be the longest prex. When the soware evaluates
192.168.254.0/24 against the longest prex, a match occurs (192.168.254.0/24 is a subset of
192.168.254.0/23). Because of the match between 192.168.254.0/24 and the longest prex, the
evaluaon connues. However, when the soware evaluates the match type, a match does not occur
between 192.168.254.0/24 and 192.168.254.0/23 exact. The soware concludes that the term does
not match and goes on to the next term or roung policy, if present, or takes the accept or reject acon
specied by the default policy.
NOTE: The walkup feature allows terms with mulple route lters to “walk-up” the evaluaon
process to include less-specic routes as well as the longest match. In other words, enabling
walkup changes the default behavior from “if one fails, then the term fails” to “if one matches,
317
then the term matches.” For more informaon about the
walkup
feature, see "Walkup for Route
Filters Overview" on page 332.
How Prex Order Aects Route Filter Evaluaon
The order in which the prexes are specied (from top to boom) typically does not maer, because the
policy framework soware scans the route lter looking for the longest prex during evaluaon. An
excepon to this rule is when you use the same desnaon prex mulple mes in a list. In this case,
the order of the prexes is important, because the list of idencal prexes is scanned from top to
boom, and the rst match type that matches the route applies.
NOTE: The walkup feature allows terms with mulple route lters to “walk-up” the evaluaon
process to include less-specic routes as well as the longest match. In other words, enabling
walkup changes the default behavior from “if one fails, then the term fails” to “if one matches,
then the term matches.” For more informaon about the
walkup
feature, see "Walkup for Route
Filters Overview" on page 332.
In the following example, dierent match types are specied for the same prex. The route 0.0.0.0/0
would be rejected, the route 0.0.0.0/8 would be marked with next-hop self, and the route 0.0.0.0/25
would be rejected.
route-filter 0.0.0.0/0 upto /7 reject;
route-filter 0.0.0.0/0 upto /24 next-hop self;
route-filter 0.0.0.0/0 orlonger reject;
How an Address Mask Match Type Is Evaluated
The address-mask roung policy match type enables you to match incoming IPv4 or IPv6 route addresses
on a congured netmask value in addion to the length of a congured desnaon match prex. During
route lter evaluaon, an address-mask match type is processed dierently from other roung policy
match types, taking into consideraon the congured netmask value:
•
When a longest-match lookup evaluates an address-mask roung policy match type, the
prefix-length
component of the congured match prex is not considered. Instead, the lookup considers the
number of conguous high-order bits set in the congured netmask value.
• When an incoming IPv4 or IPv6 route address is evaluated against a route lter match criteria that
uses the address-mask roung policy match type, the match succeeds if the following values are
idencal:
318
• The bit-wise logical AND of the congured netmask value and the incoming IPv4 or IPv6 route
address
• The bit-wise logical AND of the congured netmask value and the congured desnaon match
prex
For an example conguraon of a route lter that contains two address-mask match types, see "Evaluaon
of an Address Mask Match Type with Longest-Match Lookup" on page 327.
Common Conguraon Problem with the Longest-Match Lookup
A common problem when dening a route lter is including a shorter prex that you want to match with
a longer, similar prex in the same list. For example, imagine that the prex 192.168.254.0/24 is
compared against the following route lter:
route-filter 192.168.0.0/16 orlonger;
route-filter 192.168.254.0/23 exact;
Because the policy framework soware performs longest-match lookup, the prex 192.168.254.0/23 is
determined to be the longest prex. An exact match does not occur between 192.168.254.0/24 and
192.168.254.0/23 exact. The soware determines that the term does not match and goes on to the
next term or roung policy, if present, or takes the accept or reject acon specied by the default policy.
(For more informaon about the default roung policies, see "Default Roung Policies" on page 40.) The
shorter prex 192.168.0.0/16 orlonger that you wanted to match is inadvertently ignored.
One soluon to this problem is to remove the prex 192.168.0.0/16 orlonger from the route lter in this
term and move it to another term where it is the only prex or the longest prex in the list.
Another soluon is to enable the
walkup
feature. See "Walkup for Route Filters Overview" on page 332
for details.
Route Filter Examples
The examples in this secon show only fragments of roung policies. Normally, you would combine
these fragments with other terms or roung policies.
In all examples, remember that the following acons apply to nonmatching routes:
• Evaluate next term, if present.
• Evaluate next policy, if present.
•
Take the accept or reject acon specied by the default policy. For more informaon about the default
roung policies, see "Default Roung Policies" on page 40.
319
The following examples show how to congure route lters for various purposes:
Rejecng Routes with Specic Desnaon Prexes and Mask Lengths
Reject routes with a desnaon prex of 0.0.0.0 and a mask length from 0 through 8, and accept all
other routes:
[edit]
policy-options {
policy-statement policy-statement from-hall2 {
term 1 {
from {
route-filter 0.0.0.0/0 upto /8 reject;
}
}
then accept;
}
}
Rejecng Routes with a Mask Length Greater than Eight
Reject routes with a mask of /8 and greater (that is, /8, /9, /10, and so on) that have the rst 8 bits set
to 0 and accept routes less than 8 bits in length:
[edit]
policy-options {
policy-statement from-hall3 {
term term1 {
from {
route-filter 0/0 upto /7 accept;
route-filter 0/8 orlonger;
}
then reject;
}
}
}
320
Rejecng Routes with Mask Length Between 26 and 29
Reject routes with the desnaon prex of 192.168.10/24 and a mask between /26 and /29 and accept
all other routes:
[edit]
policy-options {
policy-statement from-customer-a {
term term1 {
from {
route-filter 192.168.10/24 prefix-length-range /26–/29 reject;
}
then accept;
}
}
}
Rejecng Routes from Specic Hosts
Reject a range of routes from specic hosts, and accept all other routes:
[edit]
policy-options {
policy-statement hosts-only {
from {
route-filter 10.125.0.0/16 upto /31 reject;
route-filter 0/0;
}
then accept;
}
}
You do not use the through match type in most roung policy conguraons. You should think of through
as a tool to group a conguous set of exact matches. For example, instead of specifying four exact
matches:
from route-filter 0.0.0.0/1 exact
from route-filter 0.0.0.0/2 exact
321
from route-filter 0.0.0.0/3 exact
from route-filter 0.0.0.0/4 exact
You could represent them with the following single match:
from route-filter 0.0.0.0/1 through 0.0.0.0/4
Accepng Routes with a Dened Set of Prexes
Explicitly accept a limited set of prexes (in the rst term) and reject all others (in the second term):
policy-options {
policy-statement internet-in {
term 1 {
from {
route-filter 192.168.231.0/24 exact accept;
route-filter 192.168.244.0/24 exact accept;
route-filter 192.168.198.0/24 exact accept;
route-filter 192.168.160.0/24 exact accept;
route-filter 192.168.59.0/24 exact accept;
}
}
term 2 {
then {
reject;
}
}
}
Rejecng Routes with a Dened Set of Prexes
Reject a few groups of prexes, and accept the remaining prexes:
[edit policy-options]
policy-statement drop-routes {
term 1{
from { # first, reject a number of prefixes:
route-filter default exact reject; # reject 0.0.0.0/0 exact
route-filter 0.0.0.0/8 orlonger reject; # reject prefix 0, mask /8 or longer
322
route-filter 10.0.0.0/8 orlonger reject; # reject loopback addresses
}
route-filter 10.105.0.0/16 exact { # accept 10.105.0.0/16
as-path-prepend “1 2 3”;
accept;
}
route-filter 192.0.2.0/24 orlonger reject; # reject test network packets
route-filter 172.16.233.0/3 orlonger reject; # reject multicast and higher
route-filter 0.0.0.0/0 upto /24 accept; # accept everything up to /24
route-filter 0.0.0.0/0 orlonger accept; # accept everything else
}
}
}
}
Rejecng Routes with Prexes Longer than 24 Bits
Reject all prexes longer than 24 bits. You would install this roung policy in a sequence of roung
policies in an export statement. The rst term in this lter passes on all routes with a prex length of up
to 24 bits. The second, unnamed term rejects everything else.
[edit policy-options]
policy-statement 24bit-filter {
term acl20 {
from {
route-filter 0.0.0.0/0 upto /24;
}
then next policy;
}
then reject;
}
If, in this example, you were to specify route-filter 0.0.0.0/0 upto /24 accept, matching prexes would be
accepted immediately and the next roung policy in the export statement would never get evaluated.
If you were to include the then reject statement in the term acl20, prexes greater than 24 bits would
never get rejected because the policy framework soware, when evaluang the term, would move on to
evaluang the next statement before reaching the then reject statement.
323
Rejecng PIM Mulcast Trac Joins
Congure a roung policy for rejecng Protocol Independent Mulcast (PIM) mulcast trac joins for a
source desnaon prex from a neighbor:
[edit]
policy-options {
policy-statement join-filter {
from {
neighbor 10.14.12.20;
source-address-filter 10.83.0.0/16 orlonger;
}
then reject;
}
}
Rejecng PIM Trac
Congure a roung policy for rejecng PIM trac for a source desnaon prex from an interface:
[edit]
policy-options {
policy-statement join-filter {
from {
interface so-1/0/0.0;
source-address-filter 10.83.0.0/16 orlonger;
}
then reject;
}
}
The following roung policy qualiers apply to PIM:
• interface—Interface over which a join is received
•
neighbor—Source from which a join originates
• route-filter—Group address
•
source-address-filter—Source address for which to reject a join
324
For more informaon about imporng a PIM join lter in a PIM protocol denion, see the Junos OS
Mulcast Protocols User Guide.
Accepng Incoming IPv4 Routes by Applying an Address Mask to the Route Address and the
Desnaon Match Prex
Accept incoming IPv4 routes with a desnaon prex of 10.1.0/24 and the third byte an even number
from 0 to 14, inclusive:
[edit]
policy-options {
policy-statement from_customer_a {
term term_1 {
from {
route-filter 10.1.0.0/24 address-mask 255.255.241.0;
}
then {
...
reject;
}
}
}
}
The route lter in roung policy term term_1 matches the following incoming IPv4 route addresses:
• 10.1.0.0/24
• 10.1.2.0/24
• 10.1.4.0/24
• 10.1.6.0/24
• 10.1.8.0/24
• 10.1.10.0/24
• 10.1.12.0/24
• 10.1.14.0/24
The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise
logical AND of the netmask value and the match prex address. That is, where the netmask bit paern
325
255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value
of the corresponding bit in the desnaon prex address 10.1.0.0/24.
• The rst two bytes of the netmask value are binary 1111 1111 1111 1111, which means that a
candidate route address will fail the match if the rst two bytes are not 10.1.
• The third byte of the netmask value is binary 1111 0001, which means that a candidate route
address will fail the match if the third byte is greater than 15 (decimal), an odd number, or both.
• The prex length of the match prex address is 24 (decimal), which means that a candidate route
address will fail the match if its prex length is not exactly 24.
As an example, suppose that the candidate route address being tested in the policy is 10.1.8.0/24
(binary 0000 1010 0000 0001 0000 1000).
• When the netmask value is applied to this candidate route address, the result is
binary 0000 1010 0000 0001 0000 0000.
• When the netmask value is applied to the congured desnaon prex address, the result is also
binary 0000 1010 0000 0001 0000 0000.
• Because the results of both AND operaons are the same, the match connues to the second match
criteria.
• Because the prex lengths of the candidate address and the congured desnaon prex address are
the same (24 bits), the match succeeds.
As another example, suppose that the candidate route address being tested in the policy is 10.1.3.0/24
(binary 0000 1010 0000 0001 0000 0011).
• When the netmask value is applied to this candidate route address, the result is
binary 0000 1010 0000 0001 0000 0001.
• However, when the netmask value is applied to the congured desnaon prex address, the result
is binary 0000 1010 0000 0001 0000 0000.
• Because the results of the two AND operaons are dierent (in the third byte), the match fails.
Accepng Incoming IPv4 Routes with Similar Paerns But Dierent Prex Lengths
Accept incoming IPv4 route addresses of the form 10.*.1/24 or 10.*.1.*/32:
[edit]
policy-options {
policy-statement from_customer_b {
term term_2 {
326
from {
route-filter 10.0.1.0/24 address-mask 255.0.255.0;
route-filter 10.0.1.0/32 address-mask 255.0.255.0;
}
then {
...
reject;
}
}
}
}
The route lter match criteria 10.0.1.0/24 address-mask 255.0.255.0 matches an incoming IPv4 route address
of the form 10.*.1/24. The route’s prex length must be exactly 24 bits long, and any value is acceptable
in the second byte.
The route lter match criteria 10.0.1.0/32 address-mask 255.0.255.0 matches an incoming IPv4 route address
of the form 10.*.1.*/32. The route’s prex length must be exactly 32 bits long, and any value is
acceptable in the second byte and the fourth byte.
Evaluaon of an Address Mask Match Type with Longest-Match Lookup
This example illustrates how a longest-match lookup evaluates a route lter that contains two address-
mask match types. Consider the route lter congured in the roung policy term term_3 below:
[edit]
policy-options {
policy-statement from_customer_c {
term term_3 {
from {
route-filter 10.0.1.0/24 address-mask 255.0.255.0;
route-filter 10.0.2.0/24 address-mask 255.240.255.0;
}
then {
...
}
}
}
}
Suppose that the incoming IPv4 route source address 10.1.1.0/24 is tested against the route lter
congured in the policy term term_3:
327
1. The longest-match lookup tree for roung policy term term_3 contains two match prexes: one prex
for 10.0.1.0/24 address-mask 255.0.255.0 and one prex for 10.0.2.0/24 address-mask 255.240.255.0. When
searching the tree for the longest-prex match for a candidate, the longest-match lookup considers
the number of conguous high-order bits in the congured
netmask-value
instead of the length of the
congured
destination-prefix
:
• For the rst route lter match criteria, the longest-match lookup entry is 10.0.0.0/8 because the
netmask value contains 8 conguous high-order bits.
• For second route lter match criteria, the longest-match lookup entry is 10.0.0.0/12 because the
netmask value contains 12 conguous high-order bits.
For the candidate route address 10.1.1.0/24, the longest-match lookup returns the tree entry
10.0.0.0/12, which is corresponds to the route lter match criteria 10.0.2.0/24 address-mask
255.240.255.0.
2. Now that the longest-match prex in term_3 has been idened for the candidate route address, the
candidate route address is evaluated against the route lter match criteria 10.0.2.0/24 address-mask
255.240.255.0:
a. To test the incoming IPv4 route address 10.1.1.0/24, the netmask value 255.240.255.0 is applied
to 10.1.1.0/24. The result is 10.0.1.0.
b. To test the congured desnaon prex address 10.0.2.0/24, the netmask value 255.240.255.0 is
applied to 10.0.2.0/24. The result is 10.0.2.0.
c. Because the results are dierent, the route lter match fails. No acons, whether specied with
the match criteria or with the then statement, are taken. The incoming IPv4 route address is not
evaluated against any other match criteria.
RELATED DOCUMENTATION
Walkup for Route Filters Overview | 332
Example: Conguring Policy Chains and Route Filters | 259
Example: Conguring a Route Filter Policy to Specify Priority for Prexes Learned Through OSPF |
364
Example: Conguring the MED Using Route Filters | 370
328
Understanding Route Filter and Source Address Filter Lists for Use in
Roung Policy Match Condions
Exisng route lters and source address lters are congured and processed inline within the term of
the policy statement. When route policies are changed, the enre policy is purged and rebuilt during the
conguraon parsing operaon. When this happens on roung policies that include hundreds or even
thousands of route lters and source address lters, a signicant amount of me is added to the rebuild
of the policy.
In order to speed the parsing operaon, the route-filter-list and source-address-filter-list statements are
available as another means of conguring route lters and source address lters. These statements
maintain all the capabilies of the route-filter and source-address-filter statements, including
consideraon of the prex length and match type of the individual prexes in the list.
Route lters and route lter lists are typically used to match an incoming route address to desnaon
match prexes of any type except for unicast source addresses.
Source address lters and source address lter lists are typically used to match an incoming route
address to unicast source addresses in Mulprotocol BGP (MBGP) and Mulcast Source Discovery
Protocol (MSDP) environments.
Mulple route lter lists and source address lter lists can be used within the same policy statements.
Route lter lists and source address lter lists can also be used in conjuncon with route lters and
source address lters.
RELATED DOCUMENTATION
route-lter-list
Understanding Route Filters for Use in Roung Policy Match Condions | 305
Understanding Load Balancing Using Source or Desnaon IP Only
In deep packet inspecon (DPI) networks with per-subscriber awareness or transparent caches, all of the
PE routers in the service provider network should route all trac to and from a parcular subscriber
through the specic content server that maintains subscriber state for that subscriber. To reach the
same server consistently, the trac must be hashed onto the same link towards that specic server for
trac in both direcons.
In order to accomplish this consistency, certain MX Series routers can be congured to make load-
balancing decisions based solely on the source IP address or the desnaon IP address of the trac.
329
From a service provider perspecve, using only the source IP for inbound trac, and the desnaon IP
for outbound trac limits the criteria used in hashing, making it more likely that a parcular link will be
chosen to forward the trac.
NOTE: This feature will only work on IP-based trac. In the case of L3VPN trac, only MPLS
lookup will be performed on the PE routers when the default label assignment scheme is used. In
order to use source-or-desnaon only load-balancing with L3VPN, you can either congure vrf-
table-label or add a vt- interface in the roung instance.
RELATED DOCUMENTATION
Conguring Load Balancing Using Source or Desnaon IP Only | 330
vrf-table-label
interface
Conguring Load Balancing Using Source or Desnaon IP Only
In equal-cost mulpath, (ECMP) per-subscriber aware environments such as content service providers
who service residenal customers, trac in both direcons within the service provider network should
always pass through the content servers that maintain the subscriber state informaon for a given
subscriber. This is accomplished by calculang the load balancing hash based solely on source address
for trac coming into the service provider network and calculang the load balancing hash based solely
on the desnaon address for trac leaving the service provider network.
Source and desnaon only load balancing is generally congured in an ECMP or aggregated ethernet
(AE) environment on an service provider network. It is usually applied to all of the PE routers. It is only
supported for IPv4 (inet) and IPv6 (inet6) trac.
You do not need any special conguraon in place before starng this conguraon.
NOTE: This feature will only work on IP-based trac. In the case of L3VPN trac, only MPLS
lookup will be performed on the PE routers when the default label assignment scheme is used. In
order to use source-or-desnaon only load-balancing with L3VPN, you can either congure vrf-
table-label or add a vt- interface in the roung instance.
To congure load balancing using source or desnaon IP only, you rst congure system-wide
forwarding opons with a prex-length to use when calculang the hash-key. Then, you congure a
330
policy acon of either load-balance source-ip-only or load-balance destination-ip-only within a policy
statement.
1. To congure system-wide prex length for use with source and desnaon IP only load balancing,
insert the source-destination-only-load-balancing conguraon statement at the [edit forwarding-options
enhanced-hash-key] hierarchy level and add a prex length:
[edit forwarding-options enhanced-hash-key]
source-destination-only-load-balancing {
family inet {
prefix-length
prefix-length
;
}
family inet6 {
prefix-length
prefix-length
;
}
}
2. To congure roung policy to use load balancing based on source or desnaon IP only, insert either
the source-ip-only or destination-ip-only as an acon statement within a policy statement at the [edit
policy-options policy-statement
policy-name
] hierarchy level:
[edit policy-options policy-statement
policy-name
]
term
term-name
{
from {
route-filter
filter-spec
’
}
then {
load-balance (
source-ip-only | destination-ip-only
);
}
}
NOTE: The source-ip-only and destination-ip-only conguraon elements cannot be used together
in the same term. This is because of the direconal nature of the trac that we are load
balancing. To use the two elements in the same policy statement, you create two separate terms,
each using a route lter specicaon that addresses the same trac. Then use source-ip-only for
the inbound trac and destination-ip-only for the outbound trac.
331
NOTE:
RELATED DOCUMENTATION
Conguring VPLS Load Balancing on MX Series 5G Universal Roung Plaorms
Understanding Load Balancing Using Source or Desnaon IP Only | 329
Conguring Stateful Load Balancing on Aggregated Ethernet Interfaces
Walkup for Route Filters Overview
Use the walkup feature if you have concerns about policy performance because of split route lters
across mulple policy terms. The walkup feature enables the consolidaon of route lters under one
policy term.
By default, Junos evaluates mulple route lters in a policy statement term by rst nding the longest
match prex and then evaluang the condions aached to the route lter, such as prex range. If the
route lter condion is false (for example, the prex is not in the specied range), then the whole term is
false, even if there are potenally true shorter route lter prexes. Due to this behavior, there can be
performance issues if route lters are split into individual policy statement terms. The walkup feature
changes the default route lter behavior.
Some automated policy tools — for example, those used for autonomous system border routers in the
Border Gateway Protocol (BGP) — break up route lters into mulple terms because of the default route
lter behavior. Route lters are also used in roung protocols other than BGP; the walkup feature is not
limited to BGP route lters.
NOTE: Technically, BGP does not deal with routes in the same way as OSPF or IS-IS. BGP
“routes” are more properly called network layer reachability informaon (NLRI) updates.
However, the term “route” is used in most documentaon and is used here.
Route lters consist of three major parts:
1. A prex and prex length (for example, 10.0.0.0/8)
2.
A match condion (for example, exact)
332
3. An acon that is carried out if both previous parts — the prex and match condion — both evaluate
to true (for example, accept)
So the 10.0.0.0/8 exact accept route lter succeeds if and only if the prex considered is 10.0.0.0/8 exactly.
This route lter rejects routes with all other longer prexes, such as 10.0.0.0/10, although there might be
other route lter terms in the policy chain that accept the 10.0.0.0/10 route.
NOTE: Although the 10.0.0.0/8 route and variaons are not specically reserved for
documentaon, the private RFC 1918 10.0.0.0/8 address space is used in this topic because of
the exibility and realisc scenarios that this address spaces provides.
Route lters can be combined in a single policy statement term. In that case, evaluaon becomes more
complex. Consider the following roung policy:
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
Note that the 10.0.0.0/8 orlonger lter includes the 10.0.0.0/16 prefix-length-range /22-/24 lter in its scope.
That is, any 10.0.0.0 route with a prex of 8 bits or longer could also be a route with a prex in the range
between 22 and 24 bits.
By default, evaluaon of a policy statement term with mulple route lters is a two-step process:
1. The policy framework soware performs a longest-match lookup on the list based on prex and
prex-length values.
2. The soware considers the route lter condion (orlonger, exact, and so on). The route either fullls
the route lter condion (success) or does not match the route lter condion (failure).
333
Based on the results of these two steps, the acon determined by the match or failure is applied to the
route. In Route-Filter-A, this means that any route that is “true” is accepted and any route that is “false” in
the RouteFilter-1 term is rejected. This route becomes a hidden (ltered) route.
For example, consider what happens when the route 10.0.0.0/18 is evaluated by the policy statement
RouteFilter-A:
First, the 10.0.0.0/18 route is evaluated by the RouteFilter-1 term. Because 10.0.0.0/16 is longer than
10.0.0.0/8, the 10.0.0.0/18 route matches the longer and more specic route prex. Next, the match fails
because the 10.0.0.0/18 route does not match the prefix-length-range /22-/24 condion. So the route match
fails in the RouteFilter-1 term, and the policy examines the next term, the default term. The 10.0.0.0/18
route is rejected by the default term.
As a result, the 10.0.0.0/18 route is hidden (ltered). (The 10.0.0.0/18 route can sll be found with the
show route hidden command.)
The issue is that the user might actually want the 10.0.0.0/18 route to be accepted, not rejected.
Naturally, a route lter with a 10.0.0.0/18 exact conguraon could be added. But in a backbone roung
table with 100,000 or more entries, it is not possible to congure a route lter tuned to every possible
route or every possible new route added to the network.
The default workaround to achieve the proper behavior from the example roung policy is to congure
a separate term for each route lter. This is frequently done, as follows:
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
}
then accept;
}
term RouteFilter-2 {
from {
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
334
Now the 10.0.0.0/18 route is accepted because, although it sll fails the RouteFilter-1 match condion, it
matches the new RouteFilter-2 term (10.0.0.0/8 is the longest match, and the orlonger condion is true).
The problem with this approach is that the complete roung policy now takes more me to evaluate
than when mulple route lters are grouped. This method also makes maintenance more complex.
The issues with the one-term-per-route-lters approach are solved with the walkup statement and
feature. Walkup alters the default behavior of route lter evaluaon globally or on a per-policy basis.
The walkup feature allows terms with mulple route lters to “walk-up” the evaluaon process to
include less-specic routes as well as the longest match. In other words, the walkup knob changes the
default behavior from “if one fails, then the term fails” to if “one matches, then the term matches.”
Consider the applicaon of the walkup feature to the example policy statement (you can also apply
walk-up globally to all policies congured):
[edit policy-options]
policy-statement RouteFilter-A {
defaults {
route-filter walkup;
}
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
This is what happens when the route prex 10.0.0.0/18 is evaluated by the policy statement RouteFilter-A:
The default behavior is altered by the walkup knob. As before, the 10.0.0.0/18 route matches the longer
and more specic route prex because 10.0.0.0/16 is longer than 10.0.0.0/8. As before, this match fails
because the 10.0.0.0/18 route does not match the prefix-length-range /22-/24 condion. However, this me
the process connues by a “walk up” and examines the less specic 10.0.0.0/8 route lter. The route
condion of orlonger matches this lter and therefore the route is accepted by the RouteFilter-1 term.
This can be veried (for a BGP route) by the show route protocol bgp 10.0.0.0/18 command. This me,
the route is not hidden.
335
If you enable the walkup feature globally, you can override it locally on a per-policy basis with the [edit
policy-options policy-statements policy-statement-name defaults route-filter no-walkup] statement.
RELATED DOCUMENTATION
Example: Conguring Walkup for Route Filters Globally to Improve Operaonal Eciency | 348
Example: Conguring Walkup for Route Filters Locally to Improve Operaonal Eciency | 356
Conguring Walkup for Route Filters to Improve Operaonal Eciency | 336
Route Filter Match Condions | 72
BGP Conguraon Overview
Verify That a Parcular BGP Route Is Received on Your Router
Example: Conguring BGP Route Adversement
Conguring Walkup for Route Filters to Improve Operaonal Eciency
Use the walkup feature if you have concerns about policy performance because of split route lters
across mulple policy terms. The walkup feature enables the consolidaon of route lters under one
policy term.
If policy statements have been split into mulple terms because of the default route lter behavior, the
route lter walkup feature allows you to consolidate mulple route lters into one policy statement
term. By default, Junos OS evaluates mulple route lters in a policy statement term by rst nding the
longest match prex and then evaluang the condions aached to the route lter, such as the prex
range. If the route lter condion is false (for example, the prex is not in the specied range), then the
whole term is false, even if there are potenally true shorter route lter prexes. The walkup feature
alters this default behavior, locally or globally.
The route lter walkup feature is used anywhere mulple route lters are used in a policy statement.
The walkup opon is supported in the main roung instance at the [edit policy-options] hierarchy level
and in logical systems at the [edit logical-systems policy-options] hierarchy level.
Before you begin conguring route lter walkup, be sure you have:
• A properly congured roung policy or set of roung policies
• A need to consolidate mulple route lter terms into fewer roung policy terms
Route lter walkup can be congured in two dierent ways. You can congure the walkup opon globally
at the [edit policy-options default route-filter] hierarchy level or in logical systems at the [edit logical-
systems policy-options default route-filter] hierarchy level. When you congure the walkup opon globally,
336
you alter the policy route lter behavior in every policy statement. Instead of the default policy
statement behavior (if the longest match route lter is false, then the term is false), the walkup opon
changes this behavior globally (to “walk up” from the longest match route lter to less specic, and if any
is true, then the term is true).
If you congure the walkup opon globally, you can sll override it locally on a per-roung-policy basis.
So if you have enabled walkup globally, you can override it in a roung policy by conguring the no-walkup
opon statement at the [edit policy-options policy-statement default route-filter] hierarchy level. The no-
walkup opon restores the default route lter behavior locally for this policy statement.
NOTE: At the [edit policy-options default route-filter] global level, the only opon is the walkup
statement because the default behavior globally is “no walkup.” However, for an individual policy
statement at the [edit policy-options policy-statement default route-filter] hierarchy level, you can
congure either the walkup or no-walkup opon statement. In this way, at the local level, you can
control whether the policy statement performs a walkup (with the walkup statement congured)
or no walkup (with the no-walkup statement congured. This gives the user maximum control over
the walkup opon
You congure the walkup feature globally with:
user@host> set policy-opons defaults route-lter walkup
Alternavely, congure the walkup feature globally in a logical system with:
user@host> set logical-systems
logical-system-name
policy-opons defaults route-lter walkup
You congure the walkup or no-walkup feature locally in a policy statement with:
user@host> set policy-opons policy-statement
policy-statement-name
defaults route-lter [ no-
walkup | walkup ]
Alternavely, congure the walkup feature locally in a logical system with:
user@host> set logical-systems
logical-system-name
policy-opons policy-statement policy-
statement-name defaults route-lter [ no-walkup | walkup ]
Route lter walkup behavior can be complex when the statements are congured at the global and local
level at the same me. Table 16 on page 338 shows the behavior of a policy statement with all six
possible combinaons of the walkup opon when you congure the feature both globally and locally.
337
Table 16: Route Filter Walkup and Policy Statements
Case: Global Conguraon Local Conguraon Result
1 (none) (none) The device does not perform a
walkup for any policy (default
operaon).
2 (none)
walkup
The device performs a walkup for
this policy.
3 (none)
no-walkup
The device does not perform a
walkup for any policy (default
operaon).
4
walkup
(none) The device performs a walkup for
all policies.
5
walkup walkup
The device performs a walkup for
all policies.
6
walkup no-walkup
The device does not perform a
walkup for this policy only.
Each row forms a possible use case numbered 1 through 6. Each walkup case is congured as follows:
• Case #1: This is a trivial conguraon for backward compability. No route lter walkup is enabled
either globally or locally. The device behaves exactly as it did before the feature was introduced. No
route lter walkup occurs in any policy.
• Case #2: Route lter walkup is not enabled globally, but is enabled locally for a specic policy named
RouteFilter-Case2. Route lter walkup occurs in this policy.
To congure the route lter walkup locally for a specic policy:
1. Enable the walkup feature locally for this policy statement.
[edit policy-options]
user@host# set policy-statement RouteFilter-Case2 defaults route-filter walkup
338
2. Congure policy terms locally (walkup applies to all terms in this policy).
[edit policy-options]
user@host# set policy-statement RouteFilter-Case2 term ...
3. Apply the policy statement to a roung protocol.
• Case #3: Route lter walkup is not enabled globally, but no-walkup is enabled locally for a specic policy
named RouteFilter-Case3. (This case is not parcularly helpful, because no walkup takes place in all
policies by default, but does make local behavior explicit, even if walkup is enabled globally in the
future.)
To congure the route lter no-walkup locally for a specic policy:
1. Enable the no-walkup feature locally for this policy statement.
[edit policy-options]
user@host# set policy-statement RouteFilter-Case3 defaults route-filter no-walkup
2. Congure policy terms locally (no-walkup applies to this policy).
[edit policy-options]
user@host# set policy-statement RouteFilter-Case3 term ...
3. Apply the policy statement to a roung protocol.
• Case #4: Route lter walkup is enabled globally, but not enabled locally for a specic policy named
RouteFilter-Case4. Because of the global conguraon, route lter walkup occurs in this policy.
To congure the route lter walkup globally for a device:
1. Enable the walkup feature globally for this device.
[edit policy-options]
user@host# set defaults route-filter walkup
NOTE: Global walkup, in contrast to the walkup or no-walkup statements congured locally in a
policy statement, is congured at the [edit policy-options defaults] or [edit logical-systems
logical-system-name
policy-options defaults] hierarchy level and applies to all policies.
339
2. Congure policy statement RouteFilter-Case4 and terms locally (walkup applies to this policy).
[edit policy-options]
user@host# set policy-statement RouteFilter-Case4 term ...
3. Apply the policy statement to a roung protocol.
• Case #5: Route lter walkup is enabled globally, and enabled locally for a specic policy named
RouteFilter-Case5. Although this conguraon might appear redundant (walkup enabled globally as well
as locally), this ensures that route lter walkup occurs in this policy even if route lter walkup is
deleted at the global level.
To congure the route lter walkup globally for a device and locally for a specic policy:
1. Enable the walkup feature globally for this device.
[edit policy-options]
user@host# set defaults route-filter walkup
NOTE: Global walkup is congured at the [edit policy-options defaults] or [edit logical-
systems
logical-system-name
policy-options defaults] hierarchy level and applies to all policies.
2. Congure policy statement RouteFilter-Case5 and enable walkup locally (walkup applies to this policy).
[edit policy-options]
user@host# set policy-statement Route-Filter-Case5 defaults route-filter walkup
3. Congure policy statement RouteFilter-Case5 and terms locally (walkup applies to this policy).
[edit policy-options]
user@host# set policy-statement RouteFilter-Case5 term ...
4. Apply the policy statement to a roung protocol.
• Case #6: Route lter walkup is enabled globally, but overridden locally with no-walkup for a specic
policy named RouteFilter-Case6. Because of the local conguraon, no route lter walkup occurs in this
policy. This case is useful to make sure that a local policy sll funcons exactly as before global
walkup was enabled.
340
To congure the route lter walkup globally for a device and the no-walkup feature locally for a
specic policy:
1. Enable the walkup feature globally for this device.
[edit policy-options]
user@host# set defaults route-filter walkup
NOTE: Global walkup is congured at the [edit policy-options defaults] or [edit logical-
systems
logical-system-name
policy-options defaults] hierarchy level and applies to all policies.
2. Congure policy statement RouteFilter-Case6 and disable walkup locally with the no-walkup
statement (no walkup is performed in this policy).
[edit policy-options]
user@host# set policy-statement Route-Filter-Case6 defaults route-filter walkup
3. Congure policy statement RouteFilter-Case6 and terms locally.
[edit policy-options]
user@host# set policy-statement RouteFilter-Case6 term ...
4. Apply the policy statement to a roung protocol.
NOTE: Keep in mind that a policy statement does nothing unl it is applied as an import or
export policy for the roung protocol itself. For BGP, this can be done at the global, group or
neighbor level.
RELATED DOCUMENTATION
Walkup for Route Filters Overview | 332
Example: Conguring Walkup for Route Filters Globally to Improve Operaonal Eciency | 348
Example: Conguring Walkup for Route Filters Locally to Improve Operaonal Eciency | 356
Route Filter Match Condions | 72
341
Verify That a Parcular BGP Route Is Received on Your Router
Example: Conguring BGP Route Adversement
Example: Conguring Route Filter Lists
IN THIS SECTION
Requirements | 342
Overview | 342
Conguraon | 343
Vericaon | 345
Junos OS has long supported route lters for use in policy statements. Whenever policies are changed,
the route lters have to be processed inline with the policy. Policies that contain large numbers of route
lters take me to load.
This example shows how to create a route lter list and use that list in a policy statement. Route lter
lists reduce the amount of me needed to reload a given policy.
NOTE: There is no speed benet to using route lter lists in place of individual route lter entries
when there are only a few route lters to process. The speed benet is seen mainly in
environments where there are hundreds or thousands of route lters listed within the policies.
Requirements
• A router congured with a roung protocol such as BGP or OSPF that is acvely exchanging route
informaon with its peers.
• The router that is congured with route lter lists must be running Junos OS Release 15.2 or later.
Overview
The route-filter-list statement allows for the creaon of a pre-dened list of route lters for use in
roung policies. You congure the list at the [edit policy-options] hierarchy level. The congured route
lter list is then referenced as a match condion in the from secon of a policy statement at the [edit
policy-options policy-statement
policy-statement-name
term
term-name
from] hierarchy level.
342
In this example, the router that you are conguring is receiving some routes from its BGP neighbor
192.0.2.1. This is shown in the output of the show route receive-protocol bgp 192.0.2.1 operaonal
command.
user@router> show route receive-protocol bgp 192.0.2.1
inet.0: 17 destinations, 18 routes (16 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 198.151.100.0/29 192.0.2.1 103 I
* 198.151.100.8/29 192.0.2.1 103 I
* 203.0.113.0/29 192.0.2.1 103 I
* 203.0.113.8/29 192.0.2.1 103 I
* 203.0.113.16/29 192.0.2.1 103 I
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 343
Procedure | 344
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set policy-options route-filter-list rf-list-1 203.0.113.0/29 exact
set policy-options route-filter-list rf-list-1 203.0.113.8/29 exact
set policy-options route-filter-list rf-list-1 203.0.113.16/29 orlonger accept
set policy-options policy-statement rf-test-policy term term2 from route-filter 198.51.100.0/29
upto 198.51.100.0/30
set policy-options policy-statement rf-test-policy term term2 from route-filter 198.51.100.8/29
upto 198.51.100.8/30 accept
set policy-options policy-statement rf-test-policy term term2 from route-filter-list rf-list-1
set policy-options policy-statement rf-test-policy then reject
set protocols bgp group test-group import rf-test-policy
343
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
The following step-by-step procedure will lead you through the steps needed to:
• Congure a route lter list named rf-list-1 and populate the list for later use in a route policy.
• Congure a roung policy statement named rf-test-policy that uses route lters and the congured
route lter list.
• Congure BGP to use rf-test-policy as an import lter.
1. Congure a route lter list named rf-list-1 for later use in a route policy.
[edit policy-options]
user@router# set route-filter-list rf-list-1
2. Populate the list rf-list-1.
Note that one of the statements in the list has an acon congured. This acon will be carried out
immediately upon a match with a received desnaon prex.
[edit policy-options]
user@router# set route-filter-list rf-list-1 203.0.113.0/29 exact
user@router# set route-filter-list rf-list-1 203.0.113.8/29 exact
user@router# set route-filter-list rf-list-1 203.0.113.16/29 orlonger accept
3. Congure a roung policy statement named rf-test-policy that uses route lters and the congured
route lter list.
The overall acon for this policy is reject. There are individual route lters and elements of the route
lter list that have a congured acon of accept. The acons congured in the individual route lter
statements and elements of the route lter list are carried out immediately upon matching a received
desnaon prex.
[edit policy-options]
user@router# set policy-statement rf-test-policy term term2 from route-filter 198.51.100.0/29
344
upto 198.51.100.0/30
user@router# set policy-statement rf-test-policy term term2 from route-filter 198.51.100.8/29
upto 198.51.100.8/30 accept
user@router# set policy-statement rf-test-policy term term2 from route-filter-list rf-list-1
user@router# set policy-statement rf-test-policy then reject
4. Congure BGP to use the congured policy as an import lter to selecvely allow some routes and
reject other routes from being added to the roung table.
[edit protocols bgp group test-group]
user@router# set import rf-test-policy
Vericaon
IN THIS SECTION
Verifying the Congured Route Filter List | 345
Verifying the Congured Policy Statement | 346
Verifying That the Policy Statement Is Applied as an Import Policy in the BGP Protocol | 346
Verifying That the Route Filter List Is Operang as Expected | 347
Verifying the Congured Route Filter List
Purpose
To conrm that the route lter list is properly congured, issue the show policy-options route-filter-list
route-filter-list-name
command at the [edit] hierarchy level.
Acon
[edit]
user@routershow policy-options route-filter-list rf-list-1
203.0.113.0/29 exact;
203.0.113.8/29 exact;
203.0.113.16/29 orlonger accept;
345
Meaning
The output shows that the stored conguraon is correct.
Verifying the Congured Policy Statement
Purpose
To conrm that the policy statement is properly congured, issue the show policy-options policy-statement
policy-statement-name
command at the [edit] hierarchy level.
Acon
[edit]
user@router# show policy-options policy-statement rf-test-policy
from {
route-filter 198.51.100.0/29 upto 198.51.100.0/30;
route-filter 198.51.100.8/29 upto 198.51.100.8/30 accept;
route-filter-list rf-list-1;
}
then reject;
Meaning
The output conrms that the stored conguraon is correct.
Verifying That the Policy Statement Is Applied as an Import Policy in the BGP Protocol
Purpose
To conrm that the congured policy statement is applied as an import policy in the BGP Protocol, issue
the show protocols bgp import command at the [edit] hierarchy level.
Acon
[edit]
user@router# show protocols bgp import
import rf-test-policy;
346
Meaning
The outptut conrms that the stored conguraon is correct.
If you have not already done so, you can issue the commit command at the [edit] hierarchy level so that
the conguraon is made acve.
Verifying That the Route Filter List Is Operang as Expected
Purpose
Now that the conguraon has been veried and commied, conrm the operaon of the route lter
list by issuing the show route receive-protocol bgp 192.0.2.1 operaonal command.
Acon
If you compare this output with the output of the same command issued prior to conguring the route
lter list and policy statement, you see that some routes are no longer installed in the roung table.
user@router> show route receive-protocol bgp 192.0.2.1
inet.0: 14 destinations, 15 routes (13 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 198.151.100.8/29 192.0.2.1 103 I
* 203.0.113.16/29 192.0.2.1 103 I
Meaning
The output shows that three of the ve previously installed BGP routes have been rejected by the policy
statement rf-test-policy. The only routes that remain from the previous list are the two that had accept
acons listed as part of the lter denion. The other routes were rejected by the acon of the policy-
statement.
RELATED DOCUMENTATION
route-lter-list
Understanding Route Filter and Source Address Filter Lists for Use in Roung Policy Match
Condions | 329
347
Example: Conguring Walkup for Route Filters Globally to Improve
Operaonal Eciency
IN THIS SECTION
Requirements | 348
Overview | 349
Conguring Route Filter Walkup Globally | 350
Vericaon | 354
Troubleshoong | 355
Use the walkup feature if you have concerns about policy performance because of split route lters
across mulple policy terms. The walkup feature enables the consolidaon of route lters under one
policy term.
This example shows how to congure the route lter walkup feature globally for policy statements with
route lters. When congured at the global level, the route lter walkup opon applies to all policy
statements. This example changes the default behavior of policy terms with mulple route lters
globally, so that any reversion to the default “no walkup” behavior must be established locally.
Requirements
This example uses the following hardware and soware components:
• A Juniper Networks router
• A Junos operang system from 13.3 or above
Before you congure route lter walkup locally, be sure you have:
• A properly congured roung policy or set of roung policies
• A need to consolidate mulple route lter terms into fewer roung policy terms
348
Overview
IN THIS SECTION
Topology | 349
Roung protocols exchange informaon with other routers running the same roung protocols. In many
cases, route lters are used in roung policy statements to lter prexes for import or export. In some
cases, when route lters are split into many separate terms, performance is impacted. The route lter
walkup feature allows consolidaon of policy statement terms for operaonal eciency.
This example uses BGP, but the same walkup feature applies to any roung protocol that supports route
ltering of input or output.
You can congure a Juniper Networks router to change the default operaon of a term in a policy
statement with route lters. By default, only a single longest match aempt is made for all route lters in
a term. The walkup feature allows the router to “walk up” the route lters in a term from longest match
to less specic in search of a true condion. This allows consolidaon of mulple terms in a policy
statement and corresponding operaonal eciency.
This example changes the default behavior globally, for all policy statements. You can sll congure no-
walkup for an individual policy.
Topology
In the sample network in Figure 25 on page 350, the router CE1 is a router from another vendor. The
rest are Juniper Networks routers. The walkup feature can be congured on any router in the gure,
except for router CE1. The vendor of router CE1 might or not might support a similar feature.
349
Figure 25: Topology for the Global Walkup Example
In the example, the following addresses are used:
• 10.0.0.0/16
• 10.0.0.0/8
NOTE: Although the 10.0.0.0/8 address space is not specically reserved for documentaon, the
private RFC 1918 10.0.0.0/8 address space is used in this topic because of the exibility and
realisc scenarios that this address spaces provides.
Conguring Route Filter Walkup Globally
IN THIS SECTION
CLI Quick Conguraon | 350
Procedure | 351
Results | 352
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details such as addresses and interfaces to match your network conguraon,
and then copy and paste the commands into the CLI at the [edit] hierarchy level.
350
Device PE1
set policy-options defaults route-filter walkup
set policy-options policy-statement routeset1-import term prefixes1 from route-filter
10.0.0.0/16 prefix-length-range /22-/24
set policy-options policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/8
orlonger
set policy-options policy-statement routeset1-import term prefixes1 then accept
set policy-options policy-statement routeset1-import term reject-the-rest then reject
set policy-options policy-statement import-route-filter-a term import-routes from protocol bgp
set policy-options policy-statement import-route-filter-a term import-routes from policy
routeset1-import
set policy-options policy-statement import-route-filter-a term import-routes then next policy
set policy-options policy-statement import-route-filter-a term all-others then reject
set policy-options policy-statement route-filter-a-export term all then reject
set protocols bgp group routeset1 type external
set protocols bgp group routeset1 neighbor 10.0.10.13 import import-route-filter-a
set protocols bgp group routeset1 neighbor 10.0.10.13 family inet unicast
set protocols bgp group routeset1 neighbor 10.0.10.13 export route-filter-a-export
set protocols bgp group routeset1 neighbor 10.0.10.13 peer-as 64506
Procedure
Step-by-Step Procedure
The following example requires that you navigate to various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide
To congure router PE1 to perform walkup globally and combine mulple route lters in one term:
1. Congure the walkup feature globally.
[edit policy-options defaults]
user@PE1# set route-filter walkup
2. Congure the policy statements for an import policy named routeset1-import.
[edit policy-options]
user@PE1# set policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/16
351
prefix-length-range /22-/24
user@PE1# set policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/8
orlonger
user@PE1# set policy-statement routeset1-import term prefixes1 then accept
user@PE1# set policy-statement routeset1-import term reject-the-rest then reject
3. Congure the policy opons for the import and export policy statements.
[edit policy-options]
user@PE1# set policy-statement import-route-filter-a term import-routes from protocol bgp
user@PE1# set policy-statement import-route-filter-a term import-routes from policy routeset1-
import
user@PE1# set policy-statement import-route-filter-a term import-routes then next policy
user@PE1# set policy-statement route-filter-a-export term all-others then reject
4. Apply the import and export policies to a BGP neighbor.
[edit protocols bgp]
user@PE1# set group routeset1 type external
user@PE1# set group routeset1 neighbor 10.0.10.13 import import-route-filter-a
user@PE1# set group routeset1 neighbor 10.0.10.13 family inet unicast
user@PE1# set group routeset1 neighbor 10.0.10.13 export route-filter-a-export
user@PE1# set group routeset1 neighbor 10.0.10.13 peer-as 64506
Results
From conguraon mode, conrm your conguraon by entering the show protocols and show policy-
options commands. If the output does not display the intended conguraon, repeat the instrucons in
this example to correct the conguraon.
user@PE1# show policy-options
defaults {
route-filter walkup;
}
policy-statement routeset1-import {
term prefixes1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
352
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term reject-the-rest {
then reject;
}
}
policy-statement import-route-filter-a {
term import-routes {
from {
protocol bgp;
policy routeset1-import;
}
then next policy;
}
term all-others {
then reject;
}
}
policy-statement route-filter-a-export {
term all {
then reject;
}
}
user@PE!# show protocols bgp
group routeset1 {
type external;
neighbor 10.0.10.13 {
import import-route-filter-a;
family inet {
unicast;
}
export router-filter-a-export;
peer-as 64506;
}
}
If you are done conguring the device, enter commit from conguraon mode.
353
Vericaon
IN THIS SECTION
Verifying Route Filter Operaon | 354
Verifying Route Filter Operaon
Purpose
Display expected informaon about the routes to conrm the route lters are working as expected.
Noce that the 10.0.0.0/8 orlonger lter includes the 10.0.0.0/16 prefix-length-range /22-/24 lter in its
scope. That is, any 10.0.0.0 route with a prex of 8 bits or longer could also be a route with a prex in the
range between 22 and 24 bits. Without the walkup feature enabled, a route such as 10.0.0.0/16 would be
rejected and become a hidden route. If the walkup feature is working as expected, then a route such as
10.0.0.0/16 would be accepted by the policy.
Acon
From operaonal mode, enter the
show route protocol
bgp 10.0.0.0/16 command. Make sure that
10.0.0.0/16 is not a hidden route.
user@PE1>show route protocol bgp 10.0.0.0/16
inet.0: 520762 destinations, 520764 routes (520760 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/16 *[BGP/170] 01:07:37, localpref 100
AS path: 64506, I, validation-state: unverified
> to 10.0.100.13 via xe-0/2/0.0
As a further check, make sure that no routes that should be accepted are hidden routes. From
operaonal mode, enter the
show route protocol
bgp
ip-address-prefix
hidden command to verify this.
Meaning
The presence of routes that are not the longest match in the congured policy route lter term shows
that the walkup feature is funconing globally.
354
Troubleshoong
IN THIS SECTION
Troubleshoong BGP | 355
Troubleshoong Policy Statements | 355
Troubleshoong Route Filters | 355
To troubleshoot route lter walkup globally:
Troubleshoong BGP
Problem
BGP is not funconing as expected.
Soluon
See the BGP Conguraon Overview topic, examples, and troubleshoong.
Troubleshoong Policy Statements
Problem
The policy statements are not funconing as expected.
Soluon
See the Verify That a Parcular BGP Route Is Received on Your Router and Example: Conguring BGP
Route Adversement topics, related examples, and troubleshoong.
Troubleshoong Route Filters
Problem
The route lters are not funconing as expected.
355
Soluon
See the "Route Filter Match Condions" on page 72 topic, examples, and troubleshoong.
RELATED DOCUMENTATION
Example: Conguring Walkup for Route Filters Locally to Improve Operaonal Eciency | 356
Walkup for Route Filters Overview | 332
Conguring Walkup for Route Filters to Improve Operaonal Eciency | 336
Route Filter Match Condions | 72
BGP Conguraon Overview
Verify That a Parcular BGP Route Is Received on Your Router
Example: Conguring BGP Route Adversement
Example: Conguring Walkup for Route Filters Locally to Improve
Operaonal Eciency
IN THIS SECTION
Requirements | 357
Overview | 357
Conguring Route Filter Walkup Locally | 358
Vericaon | 362
Troubleshoong | 363
Use the walkup feature if you have concerns about policy performance because of split route lters
across mulple policy terms. The walkup feature enables the consolidaon of route lters under one
policy term.
This example shows how to congure the route lter walkup feature locally for policy statements with
route lters. When congured at the local level, the route lter walkup opon applies only to the policy
statement in which it is congured. This example does
not
change the default behavior of policy terms
with route lters globally. This example establishes route lter walkup locally.
356
Requirements
This example uses the following hardware and soware components:
• A Juniper Networks router
• A Junos operang system from 13.3 or above
Before you congure route lter walkup globally, be sure you have:
• A properly congured roung policy or set of roung policies
• A need to consolidate mulple route lter terms into fewer roung policy terms
Overview
IN THIS SECTION
Topology | 357
Roung protocols exchange informaon with other routers running the same roung protocols. In many
cases, route lters are used in roung policy statements to lter prexes for import or export. In some
cases, when route lters are split into many separate terms, performance is impacted. The route lter
walkup feature allows consolidaon of policy statement terms for operaonal eciency.
This example uses BGP, but the same walkup feature applies to any roung protocol that supports route
ltering of input or output.
You can congure a Juniper Networks router to change the default operaon of a term in a policy
statement with route lters. By default, only a single longest match aempt is made for all route lters in
a term. The walkup feature allows the router to “walk up” the route lters in a term from longest match
to less specic in search of a true condion. This allows consolidaon of mulple terms in a policy
statement and corresponding operaonal eciency.
This example changes the default behavior locally in a single policy statement. It does not aect the
behavior of other policy statements.
Topology
In the sample network in Figure 26 on page 358, the router CE1 is a router from another vendor. The
rest are Juniper Networks routers. The walkup feature can be congured on any router in the gure,
except for router CE1. The vendor of router CE1 might or not might support a similar feature.
357
Figure 26: Topology for the Local Walkup Example
In the example, the following addresses are used:
• 10.0.0.0/16
• 10.0.0.0/8
NOTE: Although the 10.0.0.0/8 address space is not specically reserved for documentaon, the
private RFC 1918 10.0.0.0/8 address space is used in this topic because of the exibility and
realisc scenarios that this address spaces provides.
Conguring Route Filter Walkup Locally
IN THIS SECTION
CLI Quick Conguraon | 358
Procedure | 359
Results | 360
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details such as addresses and interfaces to match your network conguraon,
and then copy and paste the commands into the CLI at the [edit] hierarchy level.
358
Device PE1
set policy-options policy-statement routeset1-import defaults route-filter walkup
set policy-options policy-statement routeset1-import term prefixes1 from route-filter
10.0.0.0/16 prefix-length-range /22-/24
set policy-options policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/8
orlonger
set policy-options policy-statement routeset1-import term prefixes1 then accept
set policy-options policy-statement routeset1-import term reject-the-rest then reject
set policy-options policy-statement import-route-filter-a term import-routes from protocol bgp
set policy-options policy-statement import-route-filter-a term import-routes from policy
routeset1-import
set policy-options policy-statement import-route-filter-a term import-routes then next policy
set policy-options policy-statement import-route-filter-a term all-others then reject
set policy-options policy-statement route-filter-a-export term all then reject
set protocols bgp group routeset1 type external
set protocols bgp group routeset1 neighbor 10.0.10.13 import import-route-filter-a
set protocols bgp group routeset1 neighbor 10.0.10.13 family inet unicast
set protocols bgp group routeset1 neighbor 10.0.10.13 export route-filter-a-export
set protocols bgp group routeset1 neighbor 10.0.10.13 peer-as 64506
Procedure
Step-by-Step Procedure
The following example requires that you navigate to various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide
To congure router PE1 to perform walkup locally for mulple route lters in one term:
1. Congure the walkup feature locally in a policy named routeset1-import.
[edit policy-options policy-statement routeset1-import defaults]
user@PE1# set route-filter walkup
2. Congure the policy statements for an import policy named routeset1-import.
[edit policy-options ]
user@PE1# set policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/16
359
prefix-length-range /22-/24
user@PE1# set policy-statement routeset1-import term prefixes1 from route-filter 10.0.0.0/8
orlonger
user@PE1# set policy-statement routeset1-import term prefixes1 then accept
user@PE1# set policy-statement routeset1-import term reject-the-rest then reject
3. Congure the policy opons for the import and export policy statements.
[edit policy-options]
user@PE1# set policy-statement import-route-filter-a term import-routes from protocol bgp
user@PE1# set policy-statement import-route-filter-a term import-routes from policy routeset1-
import
user@PE1# set policy-statement import-route-filter-a term import-routes then next policy
user@PE1# set policy-statement route-filter-a-export term all-others then reject
4. Apply the import and export policies to a BGP neighbor.
[edit protocols bgp]
user@PE1# set group routeset1 type external
user@PE1# set group routeset1 neighbor 10.0.10.13 import import-route-filter-a
user@PE1# set group routeset1 neighbor 10.0.10.13 family inet unicast
user@PE1# set group routeset1 neighbor 10.0.10.13 export route-filter-a-export
user@PE1# set group routeset1 neighbor 10.0.10.13 peer-as 64506
Results
From conguraon mode, conrm your conguraon by entering the show protocols and show policy-
options commands. If the output does not display the intended conguraon, repeat the instrucons in
this example to correct the conguraon.
user@PE1# show policy-options
policy-statement routeset1-import {
defaults {
route-filter walkup;
}
term prefixes1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
360
}
then accept;
}
term reject-the-rest {
then reject;
}
}
policy-statement import-route-filter-a {
term import-routes {
from {
protocol bgp;
policy routeset1-import;
}
then next policy;
}
term all-others {
then reject;
}
}
policy-statement route-filter-a-export {
term all {
then reject;
}
}
user@PE!# show protocols bgp
group routeset1 {
type external;
neighbor 10.0.10.13 {
import import-route-filter-a;
family inet {
unicast;
}
export router-filter-a-export;
peer-as 64506;
}
}
If you are done conguring the device, enter commit from conguraon mode.
361
Vericaon
IN THIS SECTION
Verifying Route Filter Operaon | 362
Verifying Route Filter Operaon
Purpose
Display expected informaon about the routes to conrm the route lters are working as expected.
Noce that the 10.0.0.0/8 orlonger lter includes the 10.0.0.0/16 prefix-length-range /22-/24 lter in its
scope. That is, any 10.0.0.0 route with a prex of 8 bits or longer could also be a route with a prex in the
range between 22 and 24 bits. Without the walkup feature enabled in the policy example given, a route
such as 10.0.0.0/16 would be rejected and become a hidden route. If the walkup feature is working as
expected, then a route such as 10.0.0.0/16 would be accepted by the policy.
Acon
From operaonal mode, enter the
show route protocol
bgp 10.0.0.0/16 command. Make sure that
10.0.0.0/16 is not a hidden route.
user@PE1>show route protocol bgp 10.0.0.0/16
inet.0: 520762 destinations, 520764 routes (520760 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/16 *[BGP/170] 01:07:37, localpref 100
AS path: 64506, I, validation-state: unverified
> to 10.0.100.13 via xe-0/2/0.0
As a further check, make sure that no routes that should be accepted are hidden routes. From
operaonal mode, enter the
show route protocol
bgp
ip-address-prefix
hidden command to verify this.
Meaning
The presence of routes that are not the longest match in the congured policy route lter term shows
that the walkup feature is funconing locally.
362
Troubleshoong
IN THIS SECTION
Troubleshoong BGP | 363
Troubleshoong Policy Statements | 363
Troubleshoong Route Filters | 363
To troubleshoot route lter walkup locally:
Troubleshoong BGP
Problem
BGP is not funconing as expected.
Soluon
See the BGP Conguraon Overview topic, examples, and troubleshoong.
Troubleshoong Policy Statements
Problem
The policy statements are not funconing as expected.
Soluon
See the Verify That a Parcular BGP Route Is Received on Your Router and Example: Conguring BGP
Route Adversement topics, related examples, and troubleshoong.
Troubleshoong Route Filters
Problem
The route lters are not funconing as expected.
363
Soluon
See the "Route Filter Match Condions" on page 72 topic, examples, and troubleshoong.
RELATED DOCUMENTATION
Example: Conguring Walkup for Route Filters Globally to Improve Operaonal Eciency | 348
Walkup for Route Filters Overview | 332
Conguring Walkup for Route Filters to Improve Operaonal Eciency | 336
Route Filter Match Condions | 72
BGP Conguraon Overview
Verify That a Parcular BGP Route Is Received on Your Router
Example: Conguring BGP Route Adversement
Example: Conguring a Route Filter Policy to Specify Priority for Prexes
Learned Through OSPF
IN THIS SECTION
Requirements | 364
Overview | 365
Conguraon | 366
Vericaon | 370
This example shows how to create an OSPF import policy that priorizes specic prexes learned
through OSPF.
Requirements
Before you begin:
• Congure the device interfaces. See the Interfaces User Guide for Security Devices.
• Congure the router ideners for the devices in your OSPF network. See
Example: Conguring an
OSPF Router Idener
.
364
• Control OSPF designated router elecon See
Example: Controlling OSPF Designated Router Elecon
• Congure a single-area OSPF network. See
Example: Conguring a Single-Area OSPF Network
.
• Congure a mularea OSPF network. See
Example: Conguring a Mularea OSPF Network
.
Overview
IN THIS SECTION
Topology | 366
In a network with a large number of OSPF routes, it can be useful to control the order in which routes
are updated in response to a network topology change. In Junos OS Release 9.3 and later, you can
specify a priority of high, medium, or low for prexes included in an OSPF import policy. In the event of
an OSPF topology change, high priority prexes are updated in the roung table rst, followed by
medium and then low priority prexes.
OSPF import policy can only be used to set priority or to lter OSPF external routes. If an OSPF import
policy is applied that results in a reject terminang acon for a nonexternal route, then the reject acon
is ignored and the route is accepted anyway. By default, such a route is now installed in the roung table
with a priority of low. This behavior prevents trac black holes, that is, silently discarded trac, by
ensuring consistent roung within the OSPF domain.
In general, OSPF routes that are not explicitly assigned a priority are treated as priority medium, except
for the following:
• Summary discard routes have a default priority of low.
• Local routes that are not added to the roung table are assigned a priority of low.
• External routes that are rejected by import policy and thus not added to the roung table are
assigned a priority of low.
Any available match criteria applicable to OSPF routes can be used to determine the priority. Two of the
most commonly used match criteria for OSPF are the route-filter and tag statements.
In this example, the roung device is in area 0.0.0.0, with interfaces fe-0/1/0 and fe-1/1/0 connecng to
neighboring devices. You congure an import roung policy named ospf-import to specify a priority for
prexes learned through OSPF. Routes associated with these prexes are installed in the roung table in
the order of the prexes’ specied priority. Routes matching 192.0.2.0/24 orlonger are installed rst
because they have a priority of high. Routes matching 198.51.100.0/24 orlonger are installed next because
365
they have a priority of medium. Routes matching 203.0.113.0/24 orlonger are installed last because they have
a priority of low. You then apply the import policy to OSPF.
NOTE: The priority value takes eect when a new route is installed, or when there is a change to
an exisng route.
Topology
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 366
Procedure | 367
CLI Quick Conguraon
To quickly congure an OSPF import policy that priorizes specic prexes learned through OSPF, copy
the following commands, paste them into a text le, remove any line breaks, change any details
necessary to match your network conguraon, copy and paste the commands into the CLI at the [edit]
hierarchy level, and then enter commit from conguraon mode.
[edit]
set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30
set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.5/30
set policy-options policy-statement ospf-import term t1 from route-filter 203.0.113.0/24 orlonger
set policy-options policy-statement ospf-import term t1 then priority low
set policy-options policy-statement ospf-import term t1 then accept
set policy-options policy-statement ospf-import term t2 from route-filter 198.51.100.0/24
orlonger
set policy-options policy-statement ospf-import term t2 then priority medium
set policy-options policy-statement ospf-import term t2 then accept
set policy-options policy-statement ospf-import term t3 from route-filter 192.0.2.0/24 orlonger
set policy-options policy-statement ospf-import term t3 then priority high
set policy-options policy-statement ospf-import term t3 then accept
set protocols ospf import ospf-import
366
set protocols ospf area 0.0.0.0 interface fe-0/1/0
set protocols ospf area 0.0.0.0 interface fe-1/1/0
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Modifying the Junos OS Conguraon
in theCLI User Guide.
To congure an OSPF import policy that priorizes specic prexes:
1. Congure the interfaces.
[edit]
user@host# set interfaces fe-0/1/0 unit 0 family inet address 192.168.8.4/30
user@host# set interfaces fe-0/2/0 unit 0 family inet address 192.168.8.5/30
2. Enable OSPF on the interfaces.
NOTE: For OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.
[edit]
user@host# set protocols ospf area 0.0.0.0 interface fe-0/1/0
user@host# set protocols ospf area 0.0.0.0 interface fe-0/2/0
3. Congure the policy to specify the priority for prexes learned through OSPF.
[edit ]
user@host# set policy-options policy-statement ospf-import term t1 from route-filter
203.0.113.0/24 orlonger
user@host# set policy-options policy-statement ospf-import term t1 then priority low
user@host# set policy-options policy-statement ospf-import term t1 then accept
user@host# set policy-options policy-statement ospf-import term t2 from route-filter
198.51.100.0/24 orlonger
user@host# set policy-options policy-statement ospf-import term t2 then priority medium
user@host# set policy-options policy-statement ospf-import term t2 then accept
user@host# set policy-options policy-statement ospf-import term t3 from route-filter
367
192.0.2.0/24 orlonger
user@host# set policy-options policy-statement ospf-import term t3 then priority high
user@host# set policy-options policy-statement ospf-import term t3 then accept
4. Apply the policy to OSPF.
[edit]
user@host# set protocols ospf import ospf-import
5. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Results
Conrm your conguraon by entering the show interfaces, show policy-options, and the show protocols ospf
commands. If the output does not display the intended conguraon, repeat the instrucons in this
example to correct the conguraon.
user@host# show interfaces
fe-0/1/0 {
unit 0 {
family inet {
address 192.168.8.4/30;
}
}
}
fe-0/2/0 {
unit 0 {
family inet {
address 192.168.8.5/30;
}
}
}
user@host# show protocols ospf
import ospf-import;
368
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-0/2/0.0;
}
user@host# show policy-options
policy-statement ospf-import {
term t1 {
from {
route-filter 203.0.113.0/24 orlonger;
}
then {
priority low;
accept;
}
}
term t2 {
from {
route-filter 198.51.100.0/24 orlonger;
}
then {
priority medium;
accept;
}
}
term t3 {
from {
route-filter 192.0.2.0/24 orlonger;
}
then {
priority high;
accept;
}
}
}
user@host# show protocols ospf
import ospf-import;
area 0.0.0.0 {
interface fe-0/1/0.0;
369
interface fe-0/2/0.0;
}
To conrm your OSPFv3 conguraon, enter the show interfaces, show policy-options, and show protocols
ospf3 commands.
Vericaon
IN THIS SECTION
Verifying the Prex Priority in the OSPF Roung Table | 370
Conrm that the conguraon is working properly.
Verifying the Prex Priority in the OSPF Roung Table
Purpose
Verify the priority assigned to the prex in the OSPF roung table.
Acon
From operaonal mode, enter the show ospf route detail for OSPFv2, and enter the show ospf3 route detail
command for OSPFv3.
Example: Conguring the MED Using Route Filters
IN THIS SECTION
Requirements | 371
Overview | 371
Conguraon | 372
370
Vericaon | 387
This example shows how to congure a policy that uses route lters to modify the mulple exit
discriminator (MED) metric to adverse in BGP update messages.
Requirements
No special conguraon beyond device inializaon is required before you congure this example.
Overview
To congure a route-lter policy that modies the adversed MED metric in BGP update messages,
include the metric statement in the policy acon.
Figure 27 on page 371 shows a typical network with internal peer sessions and mulple exit points to a
neighboring autonomous system (AS).
Figure 27: Typical Network with IBGP Sessions and Mulple Exit Points
Device R4 has mulple loopback interfaces congured to simulate adversed prexes. The extra
loopback interface addresses are 172.16.44.0/32 and 172.16.144.0/32. This example shows how to
congure Device R4 to adverse a MED value of 30 to Device R3 for all routes except 172.16.144.0.
371
For 172.16.144.0, a MED value of 10 is adversed to Device 3. A MED value of 20 is adversed to
Device R2, regardless of the route prex.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 372
Conguring Device R1 | 374
Conguring Device R2 | 377
Conguring Device R3 | 380
Conguring Device R4 | 384
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces fe-1/2/0 unit 1 family inet address 172.16.12.1/24
set interfaces fe-1/2/1 unit 2 family inet address 172.16.13.1/24
set interfaces lo0 unit 1 family inet address 192.168.1.1/32
set protocols bgp group internal type internal
set protocols bgp group internal local-address 192.168.1.1
set protocols bgp group internal export send-direct
set protocols bgp group internal neighbor 192.168.2.1
set protocols bgp group internal neighbor 192.168.3.1
set protocols ospf area 0.0.0.0 interface lo0.1 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.1
set protocols ospf area 0.0.0.0 interface fe-1/2/1.2
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 123
set routing-options router-id 192.168.1.1
372
Device R2
set interfaces fe-1/2/0 unit 3 family inet address 172.16.12.2/24
set interfaces fe-1/2/1 unit 4 family inet address 172.16.24.2/24
set interfaces lo0 unit 2 family inet address 192.168.2.1/32
set protocols bgp group internal type internal
set protocols bgp group internal local-address 192.168.2.1
set protocols bgp group internal export send-direct
set protocols bgp group internal neighbor 192.168.1.1
set protocols bgp group internal neighbor 192.168.3.1
set protocols bgp group external type external
set protocols bgp group external export send-direct
set protocols bgp group external peer-as 4
set protocols bgp group external neighbor 172.16.24.4
set protocols ospf area 0.0.0.0 interface lo0.2 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.3
set protocols ospf area 0.0.0.0 interface fe-1/2/1.4
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 123
set routing-options router-id 192.168.2.1
Device R3
set interfaces fe-1/2/0 unit 5 family inet address 172.16.13.3/24
set interfaces fe-1/2/1 unit 6 family inet address 172.16.34.3/24
set interfaces lo0 unit 3 family inet address 192.168.3.1/32
set protocols bgp group internal type internal
set protocols bgp group internal local-address 192.168.3.1
set protocols bgp group internal export send-direct
set protocols bgp group internal neighbor 192.168.1.1
set protocols bgp group internal neighbor 192.168.2.1
set protocols bgp group external type external
set protocols bgp group external export send-direct
set protocols bgp group external peer-as 4
set protocols bgp group external neighbor 172.16.34.4
set protocols ospf area 0.0.0.0 interface lo0.3 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.5
set protocols ospf area 0.0.0.0 interface fe-1/2/1.6
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
373
set routing-options autonomous-system 123
set routing-options router-id 192.168.3.1
Device R4
set interfaces fe-1/2/0 unit 7 family inet address 172.16.24.4/24
set interfaces fe-1/2/1 unit 8 family inet address 172.16.34.4/24
set interfaces lo0 unit 4 family inet address 192.168.4.1/32
set interfaces lo0 unit 4 family inet address 172.16.44.0/32
set interfaces lo0 unit 4 family inet address 172.16.144.0/32
set protocols bgp group external type external
set protocols bgp group external export send-direct
set protocols bgp group external peer-as 123
set protocols bgp group external neighbor 172.16.34.3 export med-10
set protocols bgp group external neighbor 172.16.34.3 export med-30
set protocols bgp group external neighbor 172.16.24.2 metric-out 20
set policy-options policy-statement med-10 from route-filter 172.16.144.0/32 exact
set policy-options policy-statement med-10 then metric 10
set policy-options policy-statement med-10 then accept
set policy-options policy-statement med-30 from route-filter 0.0.0.0/0 longer
set policy-options policy-statement med-30 then metric 30
set policy-options policy-statement med-30 then accept
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 4
set routing-options router-id 192.168.4.1
Conguring Device R1
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R1:
1. Congure the device interfaces.
[edit interfaces fe-1/2/0 unit 1]
user@R1# set family inet address 172.16.12.1/24
374
[edit interfaces fe-1/2/1 unit 2]
user@R1# set family inet address 172.16.13.1/24
[edit interfaces lo0 unit 1]
user@R1# set family inet address 192.168.1.1/32
2. Congure BGP.
[edit protocols bgp group internal]
user@R1# set type internal
user@R1# set local-address 192.168.1.1
user@R1# set export send-direct
user@R1# set neighbor 192.168.2.1
user@R1# set neighbor 192.168.3.1
3. Congure OSPF.
[edit protocols ospf area 0.0.0.0]
user@R1# set interface lo0.1 passive
user@R1# set interface fe-1/2/0.1
user@R1# set interface fe-1/2/1.2
4. Congure a policy that accepts direct routes.
Other useful opons for this scenario might be to accept routes learned through OSPF or local
routes.
[edit policy-options policy-statement send-direct term 1]
user@R1# set from protocol direct
user@R1# set then accept
5. Congure the router ID and autonomous system (AS) number.
[edit routing-options]
user@R1# set autonomous-system 123
user@R1# set router-id 192.168.1.1
375
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R1# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 172.16.12.1/24;
}
}
}
fe-1/2/1 {
unit 2 {
family inet {
address 172.16.13.1/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.1.1/32;
}
}
}
user@R1# show protocols
bgp {
group internal {
type internal;
local-address 192.168.1.1;
export send-direct;
neighbor 192.168.2.1;
neighbor 192.168.3.1;
}
}
ospf {
area 0.0.0.0 {
376
interface lo0.1 {
passive;
}
interface fe-1/2/0.1;
interface fe-1/2/1.2;
}
}
user@R1# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
user@R1# show routing-options
autonomous-system 123;
router-id 192.168.1.1;
If you are done conguring the device, enter commit from conguraon mode.
Conguring Device R2
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R2:
1. Congure the device interfaces.
[edit interfaces fe-1/2/0 unit 3]
user@R2# set family inet address 172.16.12.21/24
[edit interfaces fe-1/2/1 unit 4]
user@R2# set family inet address 172.16.24.2/24
377
[edit interfaces lo0 unit 2]
user@R2# set family inet address 192.168.2.1/32
2. Congure BGP.
[edit protocols bgp group internal]
user@R2# set type internal
user@R2# set local-address 192.168.2.1
user@R2# set export send-direct
user@R2# set neighbor 192.168.1.1
user@R2# set neighbor 192.168.3.1
[edit protocols bgp group external]
user@R2# set type external
user@R2# set export send-direct
user@R2# set peer-as 4
user@R2# set neighbor 172.16.24.4
3. Congure OSPF.
[edit protocols ospf area 0.0.0.0]
user@R2# set interface lo0.2 passive
user@R2# set interface fe-1/2/0.3
user@R2# set interface fe-1/2/1.4
4. Congure a policy that accepts direct routes.
Other useful opons for this scenario might be to accept routes learned through OSPF or local
routes.
[edit policy-options policy-statement send-direct term 1]
user@R2# set from protocol direct
user@R2# set then accept
5. Congure the router ID and autonomous system (AS) number.
[edit routing-options]
user@R2# set autonomous-system 123
user@R2# set router-id 192.168.2.1
378
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R2# show interfaces
fe-1/2/0 {
unit 3 {
family inet {
address 172.16.12.2/24;
}
}
}
fe-1/2/1 {
unit 4 {
family inet {
address 172.16.24.2/24;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.168.2.1/32;
}
}
}
user@R2# show protocols
bgp {
group internal {
type internal;
local-address 192.168.2.1;
export send-direct;
neighbor 192.168.1.1;
neighbor 192.168.3.1;
}
group external {
type external;
export send-direct;
379
peer-as 4;
neighbor 172.16.24.4;
}
}
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface fe-1/2/0.3;
interface fe-1/2/1.4;
}
}
user@R2# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
user@R2# show routing-options
autonomous-system 123;
router-id 192.168.2.1;
If you are done conguring the device, enter commit from conguraon mode.
Conguring Device R3
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R3:
380
1. Congure the device interfaces.
[edit interfaces fe-1/2/0 unit 5]
user@R3# set family inet address 172.16.13.3/24
[edit interfaces fe-1/2/1 unit 6]
user@R3# set family inet address 172.16.34.3/24
[edit interfaces lo0 unit 3]
user@R3# set family inet address 192.168.3.1/32
2. Congure BGP.
[edit protocols bgp group internal]
user@R3# set type internal
user@R3# set local-address 192.168.3.1
user@R3# set export send-direct
user@R3# set neighbor 192.168.1.1
user@R3# set neighbor 192.168.2.1
[edit protocols bgp group external]
user@R3# set type external
user@R3# set export send-direct
user@R3# set peer-as 4
user@R3# set neighbor 172.16.34.4
3. Congure OSPF.
[edit protocols ospf area 0.0.0.0]
user@R3# set interface lo0.3 passive
user@R3# set interface fe-1/2/0.5
user@R3# set interface fe-1/2/1.6
4. Congure a policy that accepts direct routes.
Other useful opons for this scenario might be to accept routes learned through OSPF or local
routes.
[edit policy-options policy-statement send-direct term 1]
user@R3# set from protocol direct
user@R3# set then accept
381
5. Congure the router ID and autonomous system (AS) number.
[edit routing-options]
user@R3# set autonomous-system 123
user@R3# set router-id 192.168.3.1
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R3# show interfaces
fe-1/2/0 {
unit 5 {
family inet {
address 172.16.13.3/24;
}
}
}
fe-1/2/1 {
unit 6 {
family inet {
address 172.16.34.3/24;
}
}
}
lo0 {
unit 3 {
family inet {
address 192.168.3.1/32;
}
}
}
user@R3# show protocols
bgp {
group internal {
type internal;
382
local-address 192.168.3.1;
export send-direct;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
}
group external {
type external;
export send-direct;
peer-as 4;
neighbor 172.16.34.4;
}
}
ospf {
area 0.0.0.0 {
interface lo0.3 {
passive;
}
interface fe-1/2/0.5;
interface fe-1/2/1.6;
}
}
user@R3# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
user@R3# show routing-options
autonomous-system 123;
router-id 192.168.3.1;
If you are done conguring the device, enter commit from conguraon mode.
383
Conguring Device R4
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R4:
1. Congure the device interfaces.
[edit interfaces fe-1/2/0 unit 7]
user@R4# set family inet address 172.16.24.4/24
[edit interfaces fe-1/2/1 unit 8]
user@R4# set family inet address 172.16.34.4/24
[edit interfaces lo0 unit 4]
user@R4# set family inet address 192.168.4.1/32
user@R4# set family inet address 172.16.44.0/32
user@R4# set family inet address 172.16.144.0/32
Device R4 has mulple loopback interface addresses to simulate adversed prexes.
2. Congure a policy that accepts direct routes.
Other useful opons for this scenario might be to accept routes learned through OSPF or local
routes.
[edit policy-options policy-statement send-direct term 1]
user@R4# set from protocol direct
user@R4# set then accept
3. Congure BGP.
[edit protocols bgp group external]
user@R4# set type external
user@R4# set export send-direct
user@R4# set peer-as 123
384
4. Congure the two MED policies.
[edit policy-options]
set policy-statement med-10 from route-filter 172.16.144.0/32 exact
set policy-statement med-10 then metric 10
set policy-statement med-10 then accept
set policy-statement med-30 from route-filter 0.0.0.0/0 longer
set policy-statement med-30 then metric 30
set policy-statement med-30 then accept
5. Congure the two EBGP neighbors, applying the two MED policies to Device R3, and a MED value of
20 to Device R2.
[edit protocols bgp group external]
user@R4# set neighbor 172.16.34.3 export med-10
user@R4# set neighbor 172.16.34.3 export med-30
user@R4# set neighbor 172.16.24.2 metric-out 20
6. Congure the router ID and autonomous system (AS) number.
[edit routing-options]
user@R4# set autonomous-system 4
user@R4# set router-id 192.168.4.1
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R4# show interfaces
fe-1/2/0 {
unit 7 {
family inet {
address 172.16.24.4/24;
}
}
}
385
fe-1/2/1 {
unit 8 {
family inet {
address 172.16.34.4/24;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.4.1/32;
address 172.16.44.0/32;
address 172.16.144.0/32;
}
}
}
user@R4# show protocols
bgp {
group external {
type external;
export send-direct;
peer-as 123;
neighbor 172.16.24.2 {
metric-out 20;
}
neighbor 172.16.34.3 {
export [ med-10 med-30 ];
}
}
}
user@R4# show policy-options
policy-statement med-10 {
from {
route-filter 172.16.144.0/32 exact;
}
then {
metric 10;
accept;
386
}
}
policy-statement med-30 {
from {
route-filter 0.0.0.0/0 longer;
}
then {
metric 30;
accept;
}
}
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
user@R4# show routing-options
autonomous-system 4;
router-id 192.168.4.1;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Checking the Acve Path from Device R1 to Device R4 | 387
Verifying That Device R4 Is Sending Its Routes Correctly | 389
Conrm that the conguraon is working properly.
Checking the Acve Path from Device R1 to Device R4
Purpose
Verify that the acve path goes through Device R2.
387
Acon
From operaonal mode, enter the show route protocol bgp command.
user@R1> show route protocol bgp
inet.0: 13 destinations, 19 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.12.0/24 [BGP/170] 4d 01:13:32, localpref 100, from 192.168.2.1
AS path: I
> to 172.16.12.2 via fe-1/2/0.1
172.16.13.0/24 [BGP/170] 3d 05:36:10, localpref 100, from 192.168.3.1
AS path: I
> to 172.16.13.3 via fe-1/2/1.2
172.16.24.0/24 [BGP/170] 4d 01:13:32, localpref 100, from 192.168.2.1
AS path: I
> to 172.16.12.2 via fe-1/2/0.1
172.16.34.0/24 [BGP/170] 3d 05:36:10, localpref 100, from 192.168.3.1
AS path: I
> to 172.16.13.3 via fe-1/2/1.2
172.16.44.0/32 *[BGP/170] 00:06:03, MED 20, localpref 100, from 192.168.2.1
AS path: 4 I
> to 172.16.12.2 via fe-1/2/0.1
172.16.144.0/32 *[BGP/170] 00:06:03, MED 10, localpref 100, from 192.168.3.1
AS path: 4 I
> to 172.16.13.3 via fe-1/2/1.2
192.168.2.1/32 [BGP/170] 4d 01:13:32, localpref 100, from 192.168.2.1
AS path: I
> to 172.16.12.2 via fe-1/2/0.1
192.168.3.1/32 [BGP/170] 3d 05:36:10, localpref 100, from 192.168.3.1
AS path: I
> to 172.16.13.3 via fe-1/2/1.2
192.168.4.1/32 *[BGP/170] 00:06:03, MED 20, localpref 100, from 192.168.2.1
AS path: 4 I
> to 172.16.12.2 via fe-1/2/0.1
Meaning
The output shows that the preferred path to the routes adversed by Device R4 is through Device R2
for all routes except 172.16.144.0/32. For 172.16.144.0/32, the preferred path is through Device R3.
388
Verifying That Device R4 Is Sending Its Routes Correctly
Purpose
Make sure that Device R4 is sending update messages with a value of 20 to Device R2 and a value of 30
to Device R3.
Acon
From operaonal mode, enter the show route advertising-protocol bgp command.
user@R4> show route advertising-protocol bgp 172.16.24.2
inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.24.0/24 Self 20 I
* 172.16.34.0/24 Self 20 I
* 172.16.44.0/32 Self 20 I
* 172.16.144.0/32 Self 20 I
* 192.168.4.1/32 Self 20 I
user@R4> show route advertising-protocol bgp 172.16.34.3
inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.24.0/24 Self 30 I
* 172.16.34.0/24 Self 30 I
* 172.16.44.0/32 Self 30 I
* 172.16.144.0/32 Self 10 I
* 192.168.4.1/32 Self 30 I
Meaning
The MED column shows that Device R4 is sending the correct MED values to its two EBGP neighbors.
RELATED DOCUMENTATION
Example: Associang the MED Path Aribute with the IGP Metric and Delaying MED Updates
Understanding Route Filters for Use in Roung Policy Match Condions | 305
Understanding BGP Path Selecon
389
Understanding External BGP Peering Sessions
Example: Conguring Layer 3 VPN Protocol Family Qualiers for Route
Filters
IN THIS SECTION
Requirements | 390
Overview | 390
Conguraon | 391
Vericaon | 394
This example shows how to control the scope of BGP import policies by conguring a family qualier for
the BGP import policy. The family qualier species routes of type inet, inet6, inet-vpn, or inet6-vpn.
Requirements
This example uses Junos OS Release 10.0 or later.
Before you begin:
• Congure the device interfaces.
• Congure an interior gateway protocol. See the Junos OS Roung Protocols Library.
• Congure a BGP session for mulple route types. For example, congure the session for both family
inet routes and family inet-vpn routes. See
Conguring IBGP Sessions Between PE Routers in VPNs
and
Conguring Layer 3 VPNs to Carry IPv6 Trac
.
Overview
Family qualiers cause a route lter to match only one specic family. When you congure an IPv4 route
lter without a family qualier, as shown here, the route lter matches inet and inet-vpn routes.
route-filter
ipv4-address/mask
;
390
Likewise, when you congure an IPv6 route lter without a family qualier, as shown here, the route
lter matches inet6 and inet6-vpn routes.
route-filter
ipv6-address/mask
;
Consider the case in which a BGP session has been congured for both family inet routes and family
inet-vpn routes, and an import policy has been congured for this BGP session. This means that both
family inet and family inet-vpn routes, when received, share the same import policy. The policy term
might look as follows:
from {
route-filter 0.0.0.0/0 exact;
}
then {
next-hop self;
accept;
}
This route-lter logic matches an inet route of 0.0.0.0 and an inet-vpn route whose IPv4 address poron
is 0.0.0.0. The 8-byte route disnguisher poron of the inet-vpn route is not considered in the route-lter
matching. This is a change in Junos OS behavior that was introduced in Junos OS Release 10.0.
If you do not want your policy to match both types of routes, add a family qualier to your policy. To
have the route-lter match only inet routes, add the family inet policy qualier. To have the route-lter
match only inet-vpn routes, add the family inet-vpn policy qualier.
The family qualier is evaluated before the route-lter is evaluated. Thus, the route-lter is not
evaluated if the family match fails. The same logic applies to family inet6 and family inet6-vpn. The route-
lter used in the inet6 example must use an IPv6 address. There is a potenal eciency gain in using a
family qualier because the family qualier is tested before most other qualiers, quickly eliminang
routes from undesired families.
Conguraon
IN THIS SECTION
Procedure | 392
Results | 393
391
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
inet Example
set policy-options policy-statement specific-family from family inet
set policy-options policy-statement specific-family from route-filter 0.0.0.0/0 exact
set policy-options policy-statement specific-family then next-hop self
set policy-options policy-statement specific-family then accept
set protocols bgp import specific-family
Inet-vpn Example
set policy-options policy-statement specific-family from family inet-vpn
set policy-options policy-statement specific-family from route-filter 0.0.0.0/0 exact
set policy-options policy-statement specific-family then next-hop self
set policy-options policy-statement specific-family then accept
set protocols bgp import specific-family
inet6 Example
set policy-options policy-statement specific-family from family inet6
set policy-options policy-statement specific-family from route-filter 0::0/0 exact
set policy-options policy-statement specific-family then next-hop self
set policy-options policy-statement specific-family then accept
set protocols bgp import specific-family
Inet6-vpn Example
set policy-options policy-statement specific-family from family inet6-vpn
set policy-options policy-statement specific-family from route-filter 0::0/0 exact
set policy-options policy-statement specific-family then next-hop self
set policy-options policy-statement specific-family then accept
set protocols bgp import specific-family
392
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure a ow map:
1. Congure the family qualier.
[edit policy-options]
user@host# set policy-statement specific-family from family inet
2. Congure the route lter.
[edit policy-options]
user@host# set policy-statement specific-family from route-filter 0.0.0.0/0 exact
3. Congure the policy acons.
[edit policy-options]
user@host# set policy-statement specific-family then next-hop self
user@host# set policy-statement specific-family then accept
4. Apply the policy.
[edit protocols bgp]
user@host# set import specific-family
Results
From conguraon mode, conrm your conguraon by issuing the show protocols and show policy-options
command. If the output does not display the intended conguraon, repeat the instrucons in this
example to correct the conguraon.
user@host# show protocols
bgp {
import specific-family;
393
}
user@host# show policy-options
policy-statement specific-family {
from {
family inet;
route-filter 0.0.0.0/0 exact;
}
then {
next-hop self;
accept;
}
}
If you are done conguring the device, enter commit from conguraon mode.
Repeat the procedure for every protocol family for which you need a specic route-lter policy.
Vericaon
To verify the conguraon, run the following commands:
• show route advertising-protocol bgp
neighbor
detail
• show route instance
instance-name
detail
Understanding Prex Lists for Use in Roung Policy Match Condions
IN THIS SECTION
Conguring Prex Lists | 396
How Prex Lists Are Evaluated in Roung Policy Match Condions | 397
Conguring Prex List Filters | 397
A
prex list
is a named list of IP addresses. You can specify an exact match with incoming routes and
(oponally) apply a common acon to all matching prexes in the list.
394
Suppose, for example, that you congure the following prex list:
prefix-list bgp179 {
apply-path "protocols bgp group <*> neighbor <*>";
}
This works well when all neighbors on the device are in the same address family.
When the neighbors are in dierent address families, for example when both IPv4 and IPv6 neighbors
are congured, you can use a prex list as follows:
prefix-list IPV4-BGP-NEIGHBORS {
apply-path "protocols bgp group <*> neighbor <*.*.*.*>";
}
prefix-list IPV6-BGP-NEIGHBORS {
apply-path "protocols bgp group <*> neighbor <*:*:*>";
}
One prex list matches IPv4 addresses. The other matches IPv6 addresses. You can run the show
configuration policy-options prefix-list prefix-list name | display inheritance command to verify the
conguraon.
A prex list funcons like a route list that contains mulple instances of the exact match type only. The
dierences between these two extended match condions are summarized in Table 17 on page 395.
Table 17:
Prex List and Route List Dierences
Feature Prex List Route Lists
Acon
Can specify acon in a then statement
only. If specied, the acons are applied
to all prexes that match the term.
Can specify acon that is applied to a
parcular prex in a route-filter match
condion in a from statement, or to all
prexes in the list using a then statement.
For informaon about conguring route lists, see "Understanding Route Filters for Use in Roung Policy
Match Condions" on page 305.
This secon includes the following informaon:
395
Conguring Prex Lists
You can create a named prex list and include it in a roung policy with the prefix-list match condion
(described in "Roung Policy Match Condions" on page 58).
To dene a prex list, include the prefix-list statement:
[edit policy-options]
prefix-list
prefix-list-name
{
apply-path
path
;
ip-addresses
;
}
You can use the apply-path statement to include all prexes (and their associated network mask) pointed
to by a dened path, or you can specify one or more addresses, or both.
To include a prex list in a roung policy, specify the prefix-list match condion in the from statement at
the [edit policy-options policy-statement
policy-name
term
term-name
] hierarchy level:
[edit policy-options policy-statement
policy-name
term
term-name
]
from {
prefix-list
prefix-list-name
;
}
then
actions
;
name
idenes the prex list. It can contain leers, numbers, and hyphens (-) and can be up to 127 bytes
long. To include spaces in the name, enclose the enre name in quotaon marks (“ ”).
ip-addresses
are the IPv4 or IP version 6 (IPv6) prexes specied as
prefix
/
prefix-length
. If you omit
prefix-
length
for an IPv4 prex, the default is /32
prefix-length
. If you omit
prefix-length
for an IPv6 prex, the
default is /128. Prexes specied in a from statement must be either all IPv4 addresses or all IPv6
addresses. You cannot apply acons to individual prexes in the list.
You can specify the same prex list in the from statement of mulple roung policies or rewall lters.
For informaon about rewall lters, see "Guidelines for Conguring Firewall Filters" on page 816 and
"Guidelines for Applying Standard Firewall Filters" on page 823.
Use the apply-path statement to congure a prex list comprising all IP prexes pointed to by a dened
path. This eliminates most of the eort required to maintain a group prex list.
The path consists of elements separated by spaces. Each element matches a conguraon keyword or
an idener, and you can use wildcards to match more than one idener. Wildcards must be enclosed
in angle brackets, for example, <*>.
396
NOTE: You cannot add a path element, including wildcards, aer a leaf statement in the apply-path
statement. Path elements, including wildcards, can only be used aer a container statement.
When you use apply-path to dene a prex list, you can also use the same prex list in a policy
statement.
For examples of conguring a prex list, see "Example: Conguring Roung Policy Prex Lists " on page
398.
How Prex Lists Are Evaluated in Roung Policy Match Condions
During prex list evaluaon, the policy framework soware performs a
longest-match lookup
, which
means that the soware searches for the prex in the list with the longest length. The order in which
you specify the prexes, from top to boom, does not maer. The soware then compares a route’s
source address to the longest prex.
You can use prex list qualiers for prexes contained in a prex list by conguring a prex list lter. For
more informaon, see
Conguring Prex Lists for Use in Roung Policy Match Condions
.
If a match occurs, the evaluaon of the current term connues. If a match does not occur, the evaluaon
of the current term ends.
If you specify mulple prexes in the prex list, only one prex must match for a match to occur. The
prex list matching is eecvely a logical OR operaon.
Conguring Prex List Filters
A prex list lter allows you to apply prex list qualiers to a list of prexes within a prex list. The
prexes within the list are evaluated using the specied qualiers. You can congure mulple prex list
lters under the same policy term.
To congure a prex list lter, include the prefix-list-filter statement at the [edit policy-options policy-
statement
policy-name
from] hierarchy level:
[edit policy-options policy-statement
policy-name
]
from {
prefix-list-filter
prefix-list-name
match-type
actions
;
}
The
prefix-list-name
opon is the name of the prex list to be used for evaluaon. You can specify only
one prex list.
397
The
match-type
opon is the type of match to apply to the prexes in the prex list. It can be one of the
match types listed in Table 18 on page 398.
The
actions
opon is the acon to take if the prex list matches. It can be one or more of the acons
listed in "Conguring Flow Control Acons" on page 76 and "Conguring Acons That Manipulate Route
Characteriscs" on page 77.
Table 18: Route List Match Types for a Prex List Filter
Match Type Match Condion
exact The route shares the same most-signicant bits (described by
prefix-length
), and
prefix-
length
is equal to the route’s prex length.
longer The route shares the same most-signicant bits (described by
prefix-length
), and
prefix-
length
is greater than the route’s prex length.
orlonger The route shares the same most-signicant bits (described by
prefix-length
), and
prefix-
length
is equal to or greater than the route’s prex length.
RELATED DOCUMENTATION
Example: Conguring Roung Policy Prex Lists | 398
Example: Conguring a Filter to Limit TCP Access to a Port Based On a Prex List | 1063
Example: Conguring Roung Policy Prex Lists
IN THIS SECTION
Requirements | 399
Overview | 399
Conguraon | 402
Vericaon | 410
398
In Junos OS, prex lists provide one method of dening a set of routes. Junos OS provides other
methods of accomplishing the same task, such as route lters. A prex list is a lisng of IP prexes that
represent a set of routes that are used as match criteria in an applied policy. Such a list might be useful
for represenng a list of customer routes in your autonomous system (AS). A prex list is given a name
and is congured within the [edit policy-options] conguraon hierarchy.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Updated and re-validated using Junos OS Release 22.1R1.
Overview
IN THIS SECTION
Topology | 401
Prex lists are similar to a list of route lters. The funconal dierence between route lters and prex
lists is that you cannot specify a range using a prex list. You can simulate a range using a prex list by
including addional prexes in the list, or by using two prex lists, one shorter and one longer, seng
one to accept and the other to reject. You can also lter a prex list using the prefix-list-filter match
condion. Your choices are exact, longer, and orlonger.
The benet of a prex list over a list of route lters is seen when the prexes are referenced in several
dierent locaons. For instance, a prex list can be referenced in a BGP import policy, an export policy,
an RPF policy, in rewall lters, in loopback lters, in seng a mulcast scope, and so on.
When your list of prexes changes, rather than trying to remember the many dierent locaons prexes
are congured, you can instead update the prex list, changing the prex one me instead of mulple
mes. This helps to reduce the likelihood of conguraon errors, such as mistyping the address in a
locaon or forgeng to update one or more locaons.
Prex lists also help when managing a large number of devices. You can write the various lters and
policies as generically as possible, referencing prex lists instead of specic IP addresses. The more
complex logic in the lters and policies has to be wrien only one me, with minimal per-device and
per-site customizaons.
As shown in Figure 28 on page 402, each router in AS 65000 has customer routes. Device R1 assigns
customer routes within the 172.16.1.0/24 subnet. Device R2 and Device R3 assign customer routes
within the 172.16.2.0/24 and 172.16.3.0/24 subnets, respecvely. Device R1 has been designated the
399
central point in AS 65000 to maintain a complete list of customer routes. Device R1 has a prex list
called customers, as follows:
user@R1# show policy-options
prefix-list customers {
172.16.1.16/28;
172.16.1.32/28;
172.16.1.48/28;
172.16.1.64/28;
172.16.2.16/28;
172.16.2.32/28;
172.16.2.48/28;
172.16.2.64/28;
172.16.3.16/28;
172.16.3.32/28;
172.16.3.48/28;
172.16.3.64/28;
}
As you can see, the prex list does not contain a match type for each route (as you would see with a
route lter). This is an important point when using a prex list in a policy. Routes match only if they
exactly match one of the prexes in the list. In other words, each route in the list must appear in the
roung table exactly as it is congured in the prex list.
You reference the prex list as a match criterion within a policy like this:
user@R1# show policy-options
policy-statement customer-routes {
term get-routes {
from {
prefix-list customers;
}
then accept;
}
term others {
then reject;
}
}
In this example, all the routes in the customers prex list appear in the roung table on Device R1. Device
R2 and Device R3 export to Device R1 stac routes to their customers.
400
As previously menoned, you can use the prefix-list-filter match condion with the exact, longer, or
orlonger match type. This provides a way to avoid the prex list exact-match limitaon of prex lists. For
example:
user@R1# show policy-options
policy-statement customer-routes {
term get-routes {
from {
prefix-list-filter customers orlonger;
}
then accept;
}
term others {
then reject;
}
}
The example demonstrates the eects of both the prefix-list match condion and the prefix-list-filter
match condion.
Topology
Figure 28 on page 402 shows the sample network.
401
Figure 28: BGP Topology for Policy Prex Lists
"CLI Quick Conguraon" on page 403 shows the conguraon for all of the devices in Figure 28 on
page 402.
The secon "No Link Title" on page 405 describes the steps on Device R1.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 403
Procedure | 405
402
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces ge-0/0/0 unit 0 description to_R2
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30
set interfaces ge-0/0/1 unit 0 description to_R3
set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.5/30
set interfaces ge-0/0/2 unit 0 description to_R4
set interfaces ge-0/0/2 unit 0 family inet address 10.1.0.5/30
set interfaces lo0 unit 0 family inet address 192.168.0.1/32
set policy-options prefix-list customers 172.16.1.16/28
set policy-options prefix-list customers 172.16.1.32/28
set policy-options prefix-list customers 172.16.1.48/28
set policy-options prefix-list customers 172.16.1.64/28
set policy-options prefix-list customers 172.16.2.16/28
set policy-options prefix-list customers 172.16.2.32/28
set policy-options prefix-list customers 172.16.2.48/28
set policy-options prefix-list customers 172.16.2.64/28
set policy-options prefix-list customers 172.16.3.16/28
set policy-options prefix-list customers 172.16.3.32/28
set policy-options prefix-list customers 172.16.3.48/28
set policy-options prefix-list customers 172.16.3.64/28
set policy-options policy-statement customer-routes term get-routes from prefix-list customers
set policy-options policy-statement customer-routes term get-routes then accept
set policy-options policy-statement customer-routes term others then reject
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 65000
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 protocols bgp group int type internal
set protocols bgp group int local-address 192.168.0.1
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_65001 type external
set protocols bgp group to_65001 export customer-routes
403
set protocols bgp group to_65001 neighbor 10.1.0.6 peer-as 65001
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
Device R2
set interfaces ge-0/0/0 unit 0 description to_R1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/30
set interfaces ge-0/0/1 unit 0 description to_R3
set interfaces ge-0/0/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 policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options router-id 192.168.0.2
set routing-options autonomous-system 65000
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 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
set protocols bgp group int neighbor 192.168.0.3
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
Device R3
set interfaces ge-0/0/0 unit 0 description to_R1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.6/30
set interfaces ge-0/0/1 unit 0 description to_R2
set interfaces ge-0/0/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 policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options router-id 192.168.0.3
set routing-options autonomous-system 65000
set routing-options static route 172.16.3.16/28 discard
set routing-options static route 172.16.3.32/28 discard
404
set routing-options static route 172.16.3.48/28 discard
set routing-options static route 172.16.3.64/28 discard
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
set protocols bgp group int neighbor 192.168.0.2
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
Device R4
set interfaces ge-0/0/0 unit 0 description to_R1
set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.6/30
set interfaces lo0 unit 0 family inet address 192.168.0.4/32
set routing-options autonomous-system 65001
set protocols bgp group ext type external
set protocols bgp group ext peer-as 65000
set protocols bgp group ext neighbor 10.1.0.5
Procedure
Step-by-Step Procedure
We are showing the step-by-step procedure to congure R1. The other routers have a similar step-by-
step process. The following example requires that you navigate various levels in the conguraon
hierarchy. For informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on
page 1892 in the Junos OS CLI User Guide.
To congure R1:
1. Congure the interfaces.
[edit]
user@R1# set interfaces ge-0/0/0 unit 0 description to_R2
user@R1# set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30
user@R1# set interfaces ge-0/0/1 unit 0 description to_R3
user@R1# set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.5/30
user@R1# set interfaces ge-0/0/2 unit 0 description to_R4
405
user@R1# set interfaces ge-0/0/2 unit 0 family inet address 10.1.0.5/30
user@R1# set interfaces lo0 unit 0 family inet address 192.168.0.1/32
2. Congure the internal BGP (IBGP) peerings to R2 and R3.
[edit]
user@R1# set protocols bgp group int type internal
user@R1# set protocols bgp group int local-address 192.168.0.1
user@R1# set protocols bgp group int neighbor 192.168.0.2
user@R1# set protocols bgp group int neighbor 192.168.0.3
3. Congure the external BGP (EBGP) peering to R4. The export policy conguraon is shown in a later
step.
[edit]
user@R1# set protocols bgp group to_65001 type external
user@R1# set protocols bgp group to_65001 export customer-routes
user@R1# set protocols bgp group to_65001 neighbor 10.1.0.6 peer-as 65001
4. Congure the OSPF peerings to R2 and R3. The OSPF protocol provides the learning of the loopback
address for each device which allows the IBGP peerings to establish.
[edit]
user@R1# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
user@R1# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
user@R1# set protocols ospf area 0.0.0.0 interface lo0.0 passive
5. Congure the prex list.
[edit]
user@R1# set policy-options prefix-list customers 172.16.1.16/28
user@R1# set policy-options prefix-list customers 172.16.1.32/28
user@R1# set policy-options prefix-list customers 172.16.1.48/28
user@R1# set policy-options prefix-list customers 172.16.1.64/28
user@R1# set policy-options prefix-list customers 172.16.2.16/28
user@R1# set policy-options prefix-list customers 172.16.2.32/28
user@R1# set policy-options prefix-list customers 172.16.2.48/28
user@R1# set policy-options prefix-list customers 172.16.2.64/28
user@R1# set policy-options prefix-list customers 172.16.3.16/28
406
user@R1# set policy-options prefix-list customers 172.16.3.32/28
user@R1# set policy-options prefix-list customers 172.16.3.48/28
user@R1# set policy-options prefix-list customers 172.16.3.64/28
6. Congure the roung policy that references the prex list as a match criterion.
[edit]
user@R1# set policy-options policy-statement customer-routes term get-routes from prefix-list
customers
user@R1# set policy-options policy-statement customer-routes term get-routes then accept
user@R1# set policy-options policy-statement customer-routes term others then reject
7. Congure the stac routes for the 172.16.1.0/24 network. We are using stac routes to emulate the
customer routes.
[edit]
user@R1# set routing-options static route 172.16.1.16/28 discard
user@R1# set routing-options static route 172.16.1.32/28 discard
user@R1# set routing-options static route 172.16.1.48/28 discard
user@R1# set routing-options static route 172.16.1.64/28 discard
8. Congure the autonomous system (AS) number and router ID.
[edit]
user@R1# set routing-options router-id 192.168.0.1
user@R1# set routing-options autonomous-system 65000
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
description to_R2;
family inet {
407
address 10.0.0.1/30;
}
}
}
ge-0/0/1 {
unit 0 {
description to_R3;
family inet {
address 10.0.0.5/30;
}
}
}
ge-0/0/2 {
unit 0 {
description to_R4;
family inet {
address 10.1.0.5/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;
neighbor 192.168.0.2;
neighbor 192.168.0.3;
}
group to_65001 {
type external;
export customer-routes;
neighbor 10.1.0.6 {
peer-as 65001;
408
}
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface lo0.0 {
passive;
}
}
}
user@R1# show policy-options
prefix-list customers {
172.16.1.16/28;
172.16.1.32/28;
172.16.1.48/28;
172.16.1.64/28;
172.16.2.16/28;
172.16.2.32/28;
172.16.2.48/28;
172.16.2.64/28;
172.16.3.16/28;
172.16.3.32/28;
172.16.3.48/28;
172.16.3.64/28;
}
policy-statement customer-routes {
term get-routes {
from {
prefix-list customers;
}
then accept;
}
term others {
then reject;
409
}
}
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;
}
router-id 192.168.0.1;
autonomous-system 65000;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Routes on R1 | 410
Verifying the Route Adversement to R4 | 411
Experimenng with the prex-list-lter Statement | 412
Conrm that the conguraon is working properly.
Verifying the Routes on R1
Purpose
On R1, check the routes in the roung table.
Acon
user@R1> show route terse 172.16/16
inet.0: 30 destinations, 30 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
410
A V Destination P Prf Metric 1 Metric 2 Next hop AS path
* ? 172.16.1.16/28 S 5 Discard
* ? 172.16.1.32/28 S 5 Discard
* ? 172.16.1.48/28 S 5 Discard
* ? 172.16.1.64/28 S 5 Discard
* ? 172.16.2.16/28 B 170 100 I
unverified >10.0.0.2
* ? 172.16.2.32/28 B 170 100 I
unverified >10.0.0.2
* ? 172.16.2.48/28 B 170 100 I
unverified >10.0.0.2
* ? 172.16.2.64/28 B 170 100 I
unverified >10.0.0.2
* ? 172.16.3.16/28 B 170 100 I
unverified >10.0.0.6
* ? 172.16.3.32/28 B 170 100 I
unverified >10.0.0.6
* ? 172.16.3.48/28 B 170 100 I
unverified >10.0.0.6
* ? 172.16.3.64/28 B 170 100 I
unverified >10.0.0.6
Meaning
Device R1 has learned its own stac routes (S) and the BGP routes from Devices R2 and R3 (B).
Verifying the Route Adversement to R4
Purpose
On R1, make sure that the customer routes are adversed to R4.
Acon
user@R1> show route advertising-protocol bgp 10.1.0.6
inet.0: 30 destinations, 30 routes (30 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.1.16/28 Self I
* 172.16.1.32/28 Self I
411
* 172.16.1.48/28 Self I
* 172.16.1.64/28 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.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
As expected, only the routes from the customer prex list are adversed to R4.
Experimenng with the prex-list-lter Statement
Purpose
See what can happen when you use prefix-list-filter instead of prefix-list.
Acon
1. On R3, add a stac route that is longer than one of the exisng stac routes.
[edit routing-options static]
user@R3# set route 172.16.3.65/32 discard
user@R3# commit
2. On R1, deacvate the prex list and congure a prex list lter with the orlonger match type.
[edit policy-options policy-statement customer-routes term get-routes]
user@R1# deactivate from prefix-list customers
user@R1# set from prefix-list-filter customers orlonger
user@R1# commit
412
3. On R1, check which routes are adversed to R4.
user@R1> show route advertising-protocol bgp 10.1.0.6
inet.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 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.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.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.3.65/32 Self I
Meaning
As expected, R1 is now adversing the 172.16.3.65/32 route to R4, even though 172.16.3.65/32 is not
in the prex list.
RELATED DOCUMENTATION
Understanding Prex Lists for Use in Roung Policy Match Condions | 394
Example: Conguring Policy Chains and Route Filters | 259
Example: Conguring a Policy Subroune | 291
413
Example: Conguring the Priority for Route Prexes in the RPD
Infrastructure
IN THIS SECTION
Requirements | 414
Overview | 415
Conguraon | 416
Vericaon | 423
This example shows how to
congure priority for route prexes in the RPD infrastructure for the OSPF,
LDP, and BGP protocols.
Requirements
This example uses the following hardware and soware components:
• Three routers in a combinaon of ACX Series, M Series, MX Series, PTX Series, and T Series.
• Junos OS Release 16.1 or later running on all devices.
Before you begin:
1. Congure the device interfaces.
2. Congure the following protocols:
• BGP
• MPLS
• OSPF
• LDP
414
Overview
IN THIS SECTION
Topology | 415
In a network with a large number of routes, it is somemes important to control the order in which
routes get updated for beer convergence and to provide dierenated services. Prex priorizaon
helps users to priorize certain routes/prexes over others and have control over the order in which
routes get updated in the RIB (roung table) and the FIB (forwarding table). In Junos OS Release 16.1
and later, you can control the order in which the routes get updated from LDP/OSPF to rpd and rpd to
kernel. You can specify a priority of high or low through the exisng import policy in the protocols. In the
event of a topology change, high priority prexes are updated in the roung table rst, followed by low
priority prexes. In general, routes that are not explicitly assigned a priority are treated as medium
priority. Within the same priority level, routes will connue to be updated in lexicographic order.
In this example, the roung device is in area 0.0.0.0, with interface ge-1/3/0 connected to the
neighboring device. You congure three import roung policies: next-hop-self, ospf-prio, and
prio_for_bgp. The roung policy next-hop-self accepts routes from BGP. For the OSPF roung policy,
routes matching 172.16.25.3/32 are installed rst because they have a priority of high. LDP imports
routes from OSPF. For BGP priorizaon, routes matching 172.16.50.1/32 are installed rst because
they have a priority of high. Routes associated with these prexes are installed in the roung table in the
order of the specied priority of the prex.
Topology
Figure 29 on page 415 shows the sample topology.
Figure 29: Priority for Route Prexes in the rpd Infrastructure
415
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 416
Conguring Device R1 | 418
Results | 420
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from the conguraon mode.
R1
set interfaces ge-1/3/0 unit 0 family inet address 172.16.12.1/24
set interfaces ge-1/3/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 172.16.25.1/32
set protocols mpls interface ge-1/3/0.0
set protocols bgp group prio_internal type internal
set protocols bgp group prio_internal local-address 172.16.25.1
set protocols bgp group prio_internal import prio_for_bgp
set protocols bgp group prio_internal neighbor 172.16.25.3 family inet unicast
set protocols bgp group prio_internal neighbor 172.16.25.3 export next-hop-self
sset protocols ospf import ospf_prio
set protocols ospf area 0.0.0.0 interface ge-1/3/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ldp interface ge-1/3/0.0
set protocols ldp interface lo0.0
set policy-options policy-statement next-hop-self term nhself from protocol bgp
set policy-options policy-statement next-hop-self term nhself then next-hop self
set policy-options policy-statement next-hop-self term nhself then accept
set policy-options policy-statement ospf_prio term ospf_ldp from protocol ospf
set policy-options policy-statement ospf_prio term ospf_ldp from route-filter 172.16.25.3/32
exact
set policy-options policy-statement ospf_prio term ospf_ldp then priority high
set policy-options policy-statement ospf_prio term ospf_ldp then accept
set policy-options policy-statement prio_for_bgp term bgp_prio from protocol bgp
416
set policy-options policy-statement prio_for_bgp term bgp_prio from route-filter 172.16.50.1/32
exact
set policy-options policy-statement prio_for_bgp term bgp_prio then priority high
set routing-options nonstop-routing
set routing-options router-id 172.16.25.1
set routing-options autonomous-system 2525
R2
set interfaces ge-1/0/5 unit 0 family inet address 172.16.12.2/24
set interfaces ge-1/0/5 unit 0 family mpls
set interfaces ge-1/3/0 unit 0 family inet address 172.16.23.2/24
set interfaces ge-1/3/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 172.16.25.2/32
set protocols mpls interface ge-1/0/5.0
set protocols mpls interface ge-1/3/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-1/0/5.0
set protocols ospf area 0.0.0.0 interface ge-1/3/0.0
set protocols ldp interface ge-1/0/5.0
set protocols ldp interface ge-1/3/0.0
set protocols ldp interface lo0.0
set routing-options nonstop-routing
set routing-options router-id 172.16.25.2
set routing-options autonomous-system 2525
R3
set interfaces ge-1/0/1 unit 0 family inet address 172.16.23.3/24
set interfaces ge-1/0/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 172.16.25.3/32
set protocols mpls interface ge-1/0/1.0
set protocols bgp group prio_internal type internal
set protocols bgp group prio_internal local-address 172.16.25.3
set protocols bgp group prio_internal neighbor 172.16.25.1 family inet unicast
set protocols bgp group prio_internal neighbor 172.16.25.1 export next-hop-self
set protocols bgp group prio_internal neighbor 172.16.25.1 export static_to_bgp
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-1/0/1.0
set protocols ldp interface ge-1/0/1.0
set protocols ldp interface lo0.0
417
set policy-options policy-statement next-hop-self term nhself from protocol bgp
set policy-options policy-statement next-hop-self term nhself then next-hop self
set policy-options policy-statement next-hop-self term nhself then accept
set policy-options policy-statement static_to_bgp term s_to_b from protocol static
set policy-options policy-statement static_to_bgp term s_to_b from route-filter 172.16.50.1/32
exact
set policy-options policy-statement static_to_bgp term s_to_b from route-filter 172.16.50.2/32
exact
set policy-options policy-statement static_to_bgp term s_to_b then accept
set routing-options nonstop-routing
set routing-options static route 172.16.50.1/32 receive
set routing-options static route 172.16.50.2/32 receive
set routing-options router-id 172.16.25.3
set routing-options autonomous-system 2525
Conguring Device R1
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
CLI User Guide.
To congure Device R1:
1. Congure the interfaces.
[edit interfaces]
user@R1# set interfaces ge-1/3/0 unit 0 family inet address 172.16.12.1/24
user@R1# set interfaces ge-1/3/0 unit 0 family mpls
user@R1# set interfaces lo0 unit 0 family inet address 172.16.25.1/32
2. Assign the loopback address to the device.
[edit lo0 unit 0 family]
user@R1# set address 172.16.25.1/32
418
3. Congure MPLS.
[edit protocols]
user@R1# set protocols mpls interface ge-1/3/0.0
4. Congure the router ID and autonomous system of Router R1.
[edit routing-options]
user@R1# set router-id 172.16.7.7
user@R1# set autonomous-system 100
5. Enable OSPF on the interfaces of Router R1.
[edit protocols]
user@R1# set protocols ospf import ospf_prio
user@R1# set protocols ospf area 0.0.0.0 interface ge-1/3/0.0
user@R1# set protocols ospf area 0.0.0.0 interface lo0.0 passive
6. Congure LDP protocols on the interfaces.
[edit protocols]
user@R1# set protocols ldp interface ge-1/3/0.0
user@R1# set protocols ldp interface lo0.0
7. Congure BGP.
[edit protocols]
user@R1# set protocols bgp group prio_internal type internal
user@R1# set protocols bgp group prio_internal local-address 172.16.25.1
user@R1# set protocols bgp group prio_internal import prio_for_bgp
user@R1# set protocols bgp group prio_internal neighbor 172.16.25.3 family inet unicast
user@R1# set protocols bgp group prio_internal neighbor 172.16.25.3 export next-hop-self
8. Congure the policy opons to priorize the routes. The policy next-hop-self accepts routes from
BGP. You congure three import roung policies: next-hop-self, ospf-prio, and prio_for_bgp. The
roung policy next-hop-self accepts routes from BGP. For the ospf-prio roung policy, routes
matching 172.16.25.3/32 are installed rst because they have a priority of high. LDP imports routes
419
from OSPF. For prio_for_bgp policy, routes matching 172.16.50.1/32 are installed rst because they
have a priority of high.
[edit policy-options policy-statement]
user@R1# set policy-options policy-statement next-hop-self term nhself from protocol bgp
user@R1# set policy-options policy-statement next-hop-self term nhself then next-hop self
user@R1# set policy-options policy-statement next-hop-self term nhself then accept
user@R1# set policy-options policy-statement ospf_prio term ospf_ldp from protocol ospf
user@R1# set policy-options policy-statement ospf_prio term ospf_ldp from route-filter
172.16.25.3/32 exact
set policy-options policy-statement ospf_prio term ospf_ldp then priority high
set policy-options policy-statement ospf_prio term ospf_ldp then accept
set policy-options policy-statement prio_for_bgp term bgp_prio from protocol bgp
set policy-options policy-statement prio_for_bgp term bgp_prio from route-filter
172.16.50.1/32 exact
set policy-options policy-statement prio_for_bgp term bgp_prio then priority high
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols,
show roung-opons, and show policy-opons commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
[edit]
user@R1# show interfaces
ge-1/3/0 {
unit 0 {
family inet {
address 172.16.12.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address address 172.16.25.1/32;
}
420
}
}
[edit]
user@R1# show protocols
mpls {
interface ge-1/3/0.0;
}
bgp {
group prio_internal {
type internal;
local-address 172.16.25.1;
import prio_for_bgp
neighbor 172.16.25.3 {
family inet {
unicast;
}
export next-hop-self;
}
}
}
ospf {
import ospf_prio;
area 0.0.0.0 {
interface ge-1/3/0.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface ge-1/3/0.0;
interface lo0.0;
}
}
[edit]
user@R1# show routing-options
nonstop-routing;
421
router-id 172.16.25.1;
autonomous-system 2525;
[edit]
user@R1# show policy-options
policy-statement next-hop-self {
term nhself {
from protocol bgp;
then {
next-hop self;
accept;
}
}
}
policy-statement ospf_prio {
term ospf_ldp {
from {
protocol ospf;
route-filter 172.16.25.3/32 exact;
}
then {
priority high;
accept;
}
}
}
policy-statement prio_for_bgp {
term bgp_prio {
from {
protocol bgp;
route-filter 172.16.50.1/32 exact;
}
then priority high;
}
}
If you are done conguring the device, enter commit from the conguraon mode.
422
Vericaon
IN THIS SECTION
Verifying the Priority for OSPF Routes | 423
Verifying the Priority for LDP Routes | 424
Verifying the Priority for BGP Routes | 426
Conrm that the conguraon is working properly.
Verifying the Priority for OSPF Routes
Purpose
Verify that the priority is set for the expected route in OSPF.
Acon
On Device R1, from operaonal mode, run the show ospf route 172.16.25.3/32 extensive command. A
priority of high is applied to OSPF route 172.16.25.3.
user@R1> show ospf route 172.16.25.3/32 extensive
Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop
Type Type Type Interface Address/LSP
172.16.25.3 Intra Router IP 2 ge-1/3/0.0 172.16.12.2
area 0.0.0.0, origin 172.16.25.3, optional-capability 0x0
172.16.25.3/32 Intra Network IP 2 ge-1/3/0.0 172.16.12.2
area 0.0.0.0, origin 172.16.25.3, priority high
Meaning
The output shows priority high is applied for OSPF route 172.16.25.3.
423
Verifying the Priority for LDP Routes
Purpose
Verify if LDP inherits from OSPF.
Acon
From operaonal mode, enter the show route 172.16.25.3 command to verify if LDP has inherited routes
from OSPF.
user@R1> show route 172.16.25.3
inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.25.3/32 *[OSPF/10] 00:10:27, metric 2
> to 172.16.25.2 via ge-1/3/0.0
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.25.3/32 *[LDP/9] 00:10:24, metric 1
> to 172.16.25.2 via ge-1/3/0.0, Push 299824
From operaonal mode, enter the show route 172.16.25.3 extensive command to verify if LDP has inherited
priority.
user@R1> show route 172.16.25.3 extensive
inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
172.16.25.3/32 (1 entry, 1 announced)
State:<Flashall>
TSI:
KRT in-kernel 172.16.25.3/32 -> {172.16.12.2}
*OSPF Preference: 10
Next hop type: Router, Next hop index: 549
Address: 0xa463390
Next-hop reference count: 6
Next hop: 172.16.12.2 via ge-1/3/0.0, selected
Session Id: 0x0
424
State:<Active Int HighPriority>
Local AS: 2525
Age: 10:43 Metric: 2
Validation State: unverified
Area: 0.0.0.0
Task: OSPF
Announcement bits (4): 0-KRT 4-LDP 6-Resolve tree 2 7-Resolve_IGP_FRR task
AS path: I
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
172.16.25.3/32 (1 entry, 1 announced)
State:<Flashall>
LDP Preference: 9
Next hop type: Router, Next hop index: 582
Address: 0xa477810
Next-hop reference count: 12
Next hop: 172.16.12.2 via ge-1/3/0.0, selected
Label operation: Push 299824
Label TTL action: prop-ttl
Load balance label: Label 299824: None;
Label element ptr: 0xa17ad00
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
State:<Active Int HighPriority>
Local AS: 2525
Age: 10:40 Metric: 1
Validation State: unverified
Task: LDP
Announcement bits (3): 2-Resolve tree 1 3-Resolve tree 2 4-Resolve_IGP_FRR task
AS path: I
Meaning
The output shows that LDP inherits priority high for route 172.16.25.3 from OSPF.
425
Verifying the Priority for BGP Routes
Purpose
Verify that priority is set for the expected route in BGP.
Acon
On Device R1, from operaonal mode, run the show route protocol bgp command to display the routes
learned from BGP.
user@R1> show route protocol bgp
inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.50.1/32 *[BGP/170] 00:11:24, localpref 100, from 172.16.25.3
AS path: I, validation-state: unverified
> to 172.16.12.2 via ge-1/3/0.0, Push 299824
172.16.50.2/32 *[BGP/170] 00:11:24, localpref 100, from 172.16.25.3
AS path: I, validation-state: unverified
> to 172.16.12.2 via ge-1/3/0.0, Push 299824
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
On Device R1, from operaonal mode, run the show route 172.16.50.1 extensive command. High priority is
applied for BGP route 172.16.50.1.
user@R1> show route 172.16.50.1 extensive
inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
172.16.50.1/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 172.16.50.1/32 -> {indirect(1048574)}
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0xa487b10
Next-hop reference count: 4
Source: 172.16.25.3
426
Next hop type: Router, Next hop index: 582
Next hop: 172.16.12.2 via ge-1/3/0.0, selected
Label operation: Push 299824
Label TTL action: prop-ttl
Load balance label: Label 299824: None;
Label element ptr: 0xa17ad00
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
Protocol next hop: 172.16.25.3
Indirect next hop: 0xa4a9800 1048574 INH Session ID: 0x0
State: <Active Int Ext HighPriority>
Local AS: 2525 Peer AS: 2525
Age: 11:49 Metric2: 1
Validation State: unverified
Task: BGP_2525.172.16.25.3
Announcement bits (2): 0-KRT 6-Resolve tree 2
AS path: I (Atomic)
Accepted
Localpref: 100
Router ID: 172.16.25.3
Indirect next hops: 1
Protocol next hop: 172.16.25.3 Metric: 1
Indirect next hop: 0xa4a9800 1048574 INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 172.16.12.2 via ge-1/3/0.0
Session Id: 0x0
172.16.25.3/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Nexthop: 172.16.12.2 via ge-1/3/0.0
Meaning
The output shows that priority high is applied for BGP route 172.16.50.1.
427
RELATED DOCUMENTATION
Prex Priorizaon Overview | 15
Conguring Priority for Route Prexes in RPD Infrastructure | 428
Conguring Priority for Route Prexes in RPD Infrastructure
Prex priorizaon helps users to priorize certain routes or prexes for beer convergence and to
provide dierenated services. In a network with a large number of routes, it is somemes important to
control the order in which routes get updated due to changes in the network topology. At a system level,
Junos OS implements reasonable defaults based on heuriscs to determine the order in which routes
get updated. However, the default behavior is not always opmal. Prex priorizaon provides the user
the ability to control the order in which the routes get updated from LDP or OSPF to rpd, and rpd to
kernel. The Junos OS policy language is extended to let the user set relave priority (high and low) for
prexes through the exisng import policy in protocols. Based on the tagged priority, the routes are
placed in dierent priority queues. In the event of a topology change, high priority prexes are updated
in the roung table rst, followed by low priority prexes. Within the same priority level, routes will
connue to be updated in lexicographic order. Routes that are not explicitly assigned a priority are
treated as medium priority.
Before you begin to congure prex priorizaon in rpd for protocols such as OSPF, LDP, and BGP:
• Congure the router interfaces.
• Congure MPLS.
• Congure the OSPF, BGP, and LDP protocols.
To congure the priority high for the OSPF protocol:
1. Congure the policy term.
[edit policy-options policy-statement
policy-name
]
user@host# set term
term-name
For example:
[edit policy-options policy-statement ospf-prio]
user@host# set term t1
428
2. Congure the policy term to accept routes from OSPF.
[edit policy-options policy-statement ospf-prio term t1]
user@host# set from protocol ospf
3. Specify the desired route as a match condion for which you want to set priority high.
[edit policy-options policy-statement ospf-prio term t1]
user@host# set from route-filter
destination-prefix
match-type
For example:
[edit policy-options policy-statement ospf-prio term t1]
user@host# set from route-filter 172.16.25.3/32 exact
4.
Specify that the route is to be accepted and set priority high for the route if the previous condions
are matched.
[edit policy-options policy-statement ospf-prio term t1]
user@host# set then priority high
user@host# set then accept
5. Verify the conguraon.
[edit]
user@host# show policy-options
policy-statement ospf-prio {
term t1 {
from {
route-filter 172.16.25.3/32 exact;
}
then {
priority high;
accept;
}
}
}
LDP inherits from OSPF.
429
To congure priority high for LDP:
1. Congure the policy term that imports from OSPF.
[edit policy-options policy-statement
policy-name
]
user@host# set term
term-name
For example:
[edit policy-options policy-statement ospf-import]
user@host# set term ospf_ldp
2. Congure the term to accept routes and priority from OSPF.
[edit policy-options policy-statement ospf_import term ospf_ldp]
user@host# set from protocol ospf
user@host# set from route-filter
destination-prefix
match-type
For example:
[edit policy-options policy-statement ospf_import term ospf_ldp]
user@host# set from protocol ospf
user@host# set from route-filter 172.16.25.3/32 exact
3. Verify the conguraon.
[edit]
user@host# show policy-options
policy-statement ospf-import {
term ospf_ldp {
from {
protocol ospf ;
route-filter 172.16.25.3/32 exact;
}
then {
priority high;
accept;
}
430
}
}
To congure the priority high for the BGP protocol:
1. Congure the policy term.
[edit policy-options policy-statement
policy-name
]
user@host# set term
term-name
For example:
[edit policy-options policy-statement prio-for-bgp]
user@host# set term bgp_prio
2. Specify the desired route as a match condion.
[edit policy-options policy-statement prio-for-bgp term bgp_prio]
user@host# set from protocol bgp
user@host# set from route-filter
destination-prefix
match-type
For example:
[edit policy-options policy-statement prio-for-bgp term bgp_prio]
user@host# set from protocol bgp
user@host# set from route-filter 172.16.50.1/32 exact
3. Specify that the route is to be accepted and set the priority high for the route if the previous
condions are matched.
[edit policy-options policy-statement prio-for-bgp term bgp_prio]
user@host# set then priority high
user@host# set then accept
4. Verify the conguraon.
policy-statement prio_for_bgp {
term bgp_prio {
431
from {
protocol bgp;
route-filter 172.16.50.1/32 exact;
}
then {
priority high;
accept;
}
}
}
NOTE: For BGP, you can also congure priority based on the route-disnguisher (RD) value in
case of L3VPN. For example, you can congure priority for BGP with route-disnguisher
51.51.51.51:111.
To congure priority for BGP based on the route-disnguisher (RD) value:
1. Congure the policy term.
[edit policy-options policy-statement
policy-name
]
user@host# set term
term-name
For example:
[edit policy-options policy-statement prio-for-bgp]
user@host# set term bgp_prio
2. Specify the desired route as a match condion.
[edit policy-options policy-statement prio-for-bgp term bgp_prio]
user@host# set from rib bgp.l3vpn.0
user@host# set from route-filter
destination-prefix
match-type
user@host# set from route-distinguisher
route-distinguisher value
For example:
[edit policy-options policy-statement prio-for-bgp term bgp_prio]
user@host# set from rib bgp.l3vpn.0
432
user@host# set from route-filter 172.16.1.1/32 exact
user@host# set from route-distinguisher RD1
3. Specify that the route is to be accepted and set the priority high for the route if the previous
condions are matched.
[edit policy-options policy-statement prio-for-bgp term bgp_prio]
user@host# set then priority high
user@host# set then accept
4. Verify the conguraon.
policy-statement prio_for_bgp {
term bgp_prio {
from {
protocol rib bgp.l3vpn.0;
route-filter 172.16.1.1/32 exact;
route-distinguisher RD1;
}
then {
priority high;
accept;
}
}
}
NOTE: Low priority prexes are installed only aer the high priority prexes in the roung table.
You can also congure priority low similarly to priority high for the routes you want to set to low
priority.
NOTE: Priority is applied only when routes are pushed from RIB to FIB. Therefore, you cannot
modify the priority of routes that are already installed. Changing the priority of routes already
installed does not make sense. If you try changing the priority of routes already installed, there is
a show output dierence:
user@R1> show route 172.16.25.3 extensive | match state
State: <FlashAll>
433
State: <Active Int HighPriority> <=== OSPF
Validation State: unverified
State: <FlashAll>
State: <Active Int> <=== LDP
Validation State: unverified
As the route is already installed in FIB, LDP does not show the priority as High.
Restarng the roung daemon to remove the routes and adding it again reects the proper
priority from both the OSPF and LDP protocol perspecve.
user@R1> restart routing
Routing protocols process signalled but still running, waiting 8 seconds more
Routing protocols process started, pid 4512
user@R1> show route 172.16.25.3 extensive |match state
State: <FlashAll>
State: <Active Int HighPriority> <=== OSPF
Validation State: unverified
State: <FlashAll>
State: <Active Int HighPriority> <=== LDP
Validation State: unverified
RELATED DOCUMENTATION
Prex Priorizaon Overview | 15
Example: Conguring the Priority for Route Prexes in the RPD Infrastructure | 414
434
CHAPTER 5
Conguring AS Paths as Match Condions
IN THIS CHAPTER
Understanding AS Path Regular Expressions for Use as Roung Policy Match Condions | 435
Example: Using AS Path Regular Expressions | 444
Understanding Prepending AS Numbers to BGP AS Paths | 459
Example: Conguring a Roung Policy for AS Path Prepending | 460
Understanding Adding AS Numbers to BGP AS Paths | 470
Example: Adversing Mulple Paths in BGP | 471
Improve the Performance of AS Path Lookup in BGP Policy | 508
Understanding AS Path Regular Expressions for Use as Roung Policy
Match Condions
IN THIS SECTION
Conguraon of AS Path Regular Expressions | 436
How AS Path Regular Expressions Are Evaluated | 442
Examples: Conguring AS Path Regular Expressions | 443
A BGP
AS path
is the sequence of autonomous systems that network packets traverse to get to a
specied router. AS numbers are assembled in a sequence that is read from right to le. For example, for
a packet to reach a desnaon using a route with an AS path 5 4 3 2 1, the packet rst traverses AS 5
and so on unl it reaches AS 1. In this case, AS 1 is the last AS before the packet desnaon; it is the AS
that the source of the packet would peer with.
435
When working with AS paths and roung policy match condions, you can use regular expressions to
locate routes. To do so, create one or more match condions based on some or all of the AS path, and
then include it in a roung policy.
The following secons describe AS path regular expressions and provide conguraon examples.
Conguraon of AS Path Regular Expressions
You can create a named AS path regular expression and then include it in a roung policy with the as-
path match condion (described in "Roung Policy Match Condions" on page 58). To create a named AS
path regular expression, include the as-path statement:
[edit policy-options]
as-path
name
regular-expression
;
To include the AS path regular expression in a roung policy, include the as-path match condion in the
from statement.
Addionally, you can create a named AS path group made up of AS path regular expressions and then
include it in a roung policy with the as-path-group match condion. To create a named AS path group,
include the as-path-group statement.
[edit policy-options]
as-path-group
group-name 
{
name
[
regular-expressions
];
}
To include the AS path regular expressions within the AS path group in a roung policy, include the as-
path-group match condion in the from statement.
NOTE: You cannot include both of the as-path and as-path-group statements in the same policy
term.
NOTE: You can include the names of mulple AS path regular expressions in the as-path match
condion in the from statement. If you do this, only one AS path regular expression needs to
match for a match to occur. The AS path regular expression matching is eecvely a logical OR
operaon.
436
The AS path name idenes the regular expression. It can contain leers, numbers, and hyphens (-), and
can be up to 65,536 characters. To include spaces in the name, enclose the enre name in quotaon
marks (“ ”).
The regular expression is used to match all or porons of the AS path. It consists of two components,
which you specify in the following format:
term
<
operator
>
•
term
—Idenes an AS. You can specify it in one of the following ways:
• AS number—The enre AS number composes one term. You cannot reference individual
characters within an AS number, which diers from regular expressions as dened in
POSIX 1003.2.
• Wildcard character—Matches any single AS number. The wildcard character is a period (.). You can
specify mulple wildcard characters.
• AS path—A single AS number or a group of AS numbers enclosed in parentheses. Grouping the
regular expression in this way allows you to perform a common operaon on the group as a whole
and to give the group precedence. The grouped path can itself include operators.
In Junos OS Release 9.1 and later, you can specify 4-byte AS numbers as dened in RFC 4893,
BGP Support for Four-octet AS Number Space
, as well as the 2-byte AS numbers that are
supported in earlier releases of the Junos OS. You can congure a value in the range from 1
through 4,294,967,295.
•
operator
—(Oponal) An operator specifying how the term must match. Most operators describe how
many mes the term must be found to be considered a match (for example, any number of
occurrences, or zero, or one occurrence). Table 19 on page 438 lists the regular expression operators
supported for AS paths. You place operators immediately aer
term
with no intervening space, except
for the pipe ( | ) and dash (–) operators, which you place between two terms, and parentheses, with
which you enclose terms.
You can specify one or more term–operator pairs in a single regular expression.
Table 20 on page 439 shows examples of how to dene regular expressions to match AS paths.
437
Table 19: AS Path Regular Expression Operators
Operator Match Denion
{
m,n
} At least
m
and at most
n
repeons of
term
. Both
m
and
n
must be posive
integers, and
m
must be smaller than
n
.
{
m
} Exactly
m
repeons of
term
.
m
must be a posive integer.
{
m
,}
m
or more repeons of
term
.
m
must be a posive integer.
* Zero or more repeons of
term
. This is equivalent to {0,}.
+ One or more repeons of
term
. This is equivalent to {1,}.
? Zero or one repeon of
term
. This is equivalent to {0,1}.
|
One of two terms on either side of the pipe.
–
Between a starng and ending range, inclusive.
^
A character at the beginning of a community aribute regular expression. This
character is added implicitly; therefore, the use of it is oponal.
$
A character at the end of a community aribute regular expression. This
character is added implicitly; therefore, the use of it is oponal.
( )
A group of terms that are enclosed in the parentheses. Intervening space
between the parentheses and the terms is ignored. If a set of parentheses is
enclosed in quotaon marks with no intervening space "()", it indicates a null
path.
[ ]
Set of AS numbers. One AS number from the set must match. To specify the
start and end of a range, use a hyphen (-). A caret (^) may be used to indicate
that it does not match a parcular AS number in the set, for example [^123].
438
Table 20: Examples of AS Path Regular Expressions
AS Path to Match Regular Expression Sample Matches
AS path is 1234 1234 1234
Zero or more occurrences of AS
number 1234
1234* 1234
1234 1234
1234 1234 1234
Null AS path
Zero or one occurrence of AS
number 1234
1234? or 1234{0,1} 1234
Null AS path
One through four occurrences of AS
number 1234
1234{1,4} 1234
1234 1234
1234 1234 1234
1234 1234 1234 1234
One through four occurrences of AS
number 12, followed by one occurrence
of AS number 34
12{1,4} 34 12 34
12 12 34
12 12 12 34
12 12 12 12 34
Range of AS numbers to match a single
AS number
123–125 123
124
125
439
Table 20: Examples of AS Path Regular Expressions
(Connued)
AS Path to Match Regular Expression Sample Matches
[123–125]* Null AS path
123
124 124
125 125 125
123 124 125 123
Path whose second AS number must
be 56 or 78
(. 56) | (. 78) or . (56 | 78) 1234 56
1234 78
9876 56
3857 78
Path whose second AS number might
be 56 or 78
. (56 | 78)? 1234 56 52
34 56 1234
1234 78 39
794 78 2
Path whose rst AS number is 123 and
second AS number is either 56 or 78
123 (56|78) 123 56
123 78
Path of any length, except nonexistent,
whose second AS number can be
anything, including nonexistent
. .* or . .{0,} 1234 1234 5678 1234 5 6 7 8
AS path is 1 2 3 1 2 3 1 2 3
One occurrence of the AS numbers 1
and 2, followed by one or more
occurrences of the AS number 3
1 2 3+ 1 2 3
1 2 3 3
1 2 3 3 3
440
Table 20: Examples of AS Path Regular Expressions
(Connued)
AS Path to Match Regular Expression Sample Matches
One or more occurrences of AS number
1, followed by one or more occurrences
of AS number 2, followed by one or
more occurrences of AS
number 3
1+ 2+ 3+ 1 2 3
1 1 2 3
1 1 2 2 3
1 1 2 2 3 3
Path of any length that begins with AS
numbers 4, 5, 6
4 5 6 .* 4 5 6
4 5 6 7 8 9
Path of any length that ends with AS
numbers 4, 5, 6
.* 4 5 6 4 5 6
1 2 3 4 5 6
4 9 4 5 6
AS path 5, 12, or 18 5 | 12 | 18 5
12
18
Conguring a Null AS Path
You can use AS path regular expressions to create a null AS path that matches routes (prexes) that have
originated in your AS. These routes have not been adversed to your AS by any external peers. To
create a null AS path, use the parentheses operator enclosed in quotaon marks with no intervening
spaces:
[edit policy-options]
as-path null-as “()";
In the following example, locally administered AS 2 is connected to AS 1 (10.2.2.6) and AS 3. AS 3
adverses its routes to AS 2, but the administrator for AS 2 does not want to adverse AS 3 routes to
AS 1 and thereby allow transit trac from AS 1 to AS 3 through AS 2. To prevent transit trac, the
441
export policy only-my-routes is applied to AS 1. It permits adversement of routes from AS 2 to AS 1 but
prevents adversement of routes for AS 3 (or routes for any other connected AS) to AS 1:
[edit policy-options]
as-path null-as "()";
policy-statement only-my-routes {
term just-my-as {
from {
protocol bgp;
as-path null-as;
}
then accept;
}
term nothing-else {
then reject;
}
}
protocol {
bgp {
neighbor 10.2.2.6 {
export only-my-routes;
}
}
}
How AS Path Regular Expressions Are Evaluated
AS path regular expressions implement the extended (modern) regular expressions as dened in
POSIX 1003.2. They are idencal to the UNIX regular expressions with the following excepons:
• The basic unit of matching in an AS path regular expression is the AS number and not an individual
character.
• A regular expression matches a route only if the AS path in the route exactly matches
regular-
expression
. The equivalent UNIX regular expression is ^
regular-expression
$. For example, the AS path
regular expression 1234 is equivalent to the UNIX regular expression ^1234$.
• You can specify a regular expression using wildcard operators.
442
Examples: Conguring AS Path Regular Expressions
Exactly match routes with the AS path 1234 56 78 9 and accept them:
[edit]
policy-options {
as-path wellington "1234 56 78 9";
policy-statement from-wellington {
term term1 {
from as-path wellington;
}
then {
preference 200;
accept;
}
term term2 {
then reject;
}
}
}
Match alternate paths to an AS and accept them aer modifying the preference:
[edit]
policy-options {
as-path wellington-alternate “1234{1,6} (56|47)? (78|101|112)* 9+”;
policy-statement from-wellington {
from as-path wellington-alternate;
}
then {
preference 200;
accept;
}
}
}
Match routes with an AS path of 123, 124, or 125 and accept them aer modifying the preference:
[edit]
policy-options {
443
as-path addison "123–125";
policy-statement from-addison {
from as-path addison;
}
then {
preference 200;
accept;
}
}
}
RELATED DOCUMENTATION
Example: Using AS Path Regular Expressions | 444
Example: Conguring a Roung Policy for AS Path Prepending | 460
Example: Using AS Path Regular Expressions
IN THIS SECTION
Requirements | 444
Overview | 445
Conguraon | 447
Vericaon | 455
An autonomous system (AS) path is a route aribute used by BGP. The AS path is used both for route
selecon and to prevent potenal roung loops. This example shows how to use regular expressions
with AS path numbers to locate a set of routes.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
444
Overview
IN THIS SECTION
Topology | 445
Figure 30 on page 446 shows several ASs connected through external BGP (EBGP) peering sessions.
Each device is generang customer routes within its assigned address space.
Topology
Figure 30 on page 446 shows the sample network.
445
Figure 30: BGP Topology AS Regular Expressions
The administrators of AS 64516 want to reject all routes originang in AS 64513 and AS 64514. Two AS
path regular expressions called orig-in-64513 and orig-in-64514 are created and referenced in a policy called
reject-some-routes. The roung policy is then applied as an import policy on Device R6.
"CLI Quick Conguraon" on page 447 shows the conguraon for all of the devices in Figure 30 on
page 446.
The secon "No Link Title" on page 450 describes the steps on Device R2 and Device R6. "Vericaon"
on page 455 shows how to use the aspath-regex opon with the show route command on Device R2 to
locate routes using regular expressions.
446
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 447
Procedure | 450
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces fe-1/2/2 unit 0 description to-R2
set interfaces fe-1/2/2 unit 0 family inet address 10.2.0.2/30
set interfaces fe-1/2/3 unit 0 description to-R3
set interfaces fe-1/2/3 unit 0 family inet address 10.2.0.6/30
set interfaces fe-1/2/0 unit 0 description to-R5
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30
set interfaces lo0 unit 0 family inet address 192.168.0.1/32
set protocols bgp export send-static
set protocols bgp group 64512 type external
set protocols bgp group 64512 peer-as 64512
set protocols bgp group 64512 neighbor 10.2.0.1
set protocols bgp group 64513 type external
set protocols bgp group 64513 peer-as 64513
set protocols bgp group 64513 neighbor 10.2.0.5
set protocols bgp group 64515 type external
set protocols bgp group 64515 peer-as 64515
set protocols bgp group 64515 neighbor 10.0.0.1
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.10.1.0/24 reject
set routing-options static route 10.10.2.0/24 reject
set routing-options static route 10.10.3.0/24 reject
set routing-options autonomous-system 64511
447
Device R2
set interfaces fe-1/2/2 unit 0 description to-R1
set interfaces fe-1/2/2 unit 0 family inet address 10.2.0.1/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp export send-static
set protocols bgp group 64511 type external
set protocols bgp group 64511 peer-as 64511
set protocols bgp group 64511 neighbor 10.2.0.2
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.20.1.0/24 reject
set routing-options static route 10.20.2.0/24 reject
set routing-options static route 10.20.3.0/24 reject
set routing-options autonomous-system 64512
Device R3
set interfaces fe-1/2/3 unit 0 description to-R1
set interfaces fe-1/2/3 unit 0 family inet address 10.2.0.5/30
set interfaces fe-1/2/2 unit 0 description to-R4
set interfaces fe-1/2/2 unit 0 family inet address 10.3.0.42/30
set interfaces lo0 unit 0 family inet address 192.168.0.3/32
set protocols bgp export send-static
set protocols bgp group 64511 type external
set protocols bgp group 64511 peer-as 64511
set protocols bgp group 64511 neighbor 10.2.0.6
set protocols bgp group 64514 type external
set protocols bgp group 64514 peer-as 64514
set protocols bgp group 64514 neighbor 10.3.0.41
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.30.1.0/24 reject
set routing-options static route 10.30.2.0/24 reject
set routing-options static route 10.30.3.0/24 reject
set routing-options autonomous-system 64513
Device R4
set interfaces fe-1/2/2 unit 0 description to-R3
set interfaces fe-1/2/2 unit 0 family inet address 10.3.0.41/30
448
set interfaces lo0 unit 0 family inet address 192.168.0.4/32
set protocols bgp export send-static
set protocols bgp group 64513 type external
set protocols bgp group 64513 peer-as 64513
set protocols bgp group 64513 neighbor 10.3.0.42
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.40.1.0/24 reject
set routing-options static route 10.40.2.0/24 reject
set routing-options static route 10.40.3.0/24 reject
set routing-options autonomous-system 64514
Device R5
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.1/30
set interfaces fe-1/2/1 unit 0 description to-R6
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 export send-static
set protocols bgp group 64511 type external
set protocols bgp group 64511 peer-as 64511
set protocols bgp group 64511 neighbor 10.0.0.2
set protocols bgp group 64516 type external
set protocols bgp group 64516 peer-as 64516
set protocols bgp group 64516 neighbor 10.0.0.10
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.50.1.0/24 reject
set routing-options static route 10.50.2.0/24 reject
set routing-options static route 10.50.3.0/24 reject
set routing-options autonomous-system 64515
Device R6
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.6/32
set protocols bgp export send-static
set protocols bgp group 64515 type external
set protocols bgp group 64515 import reject-some-routes
449
set protocols bgp group 64515 peer-as 64515
set protocols bgp group 64515 neighbor 10.0.0.9
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set policy-options policy-statement reject-some-routes term find-routes from as-path orig-
in-64513
set policy-options policy-statement reject-some-routes term find-routes from as-path orig-
in-64514
set policy-options policy-statement reject-some-routes term find-routes then reject
set policy-options as-path orig-in-64513 ".* 64513"
set policy-options as-path orig-in-64514 ".* 64514"
set routing-options static route 10.60.1.0/24 reject
set routing-options static route 10.60.2.0/24 reject
set routing-options static route 10.60.3.0/24 reject
set routing-options autonomous-system 64516
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure Device R2:
1. Congure the device interfaces.
[edit interfaces]
user@R2# set fe-1/2/2 unit 0 description to-R1
user@R2# set fe-1/2/2 unit 0 family inet address 10.2.0.1/30
user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure the EBGP connecon to Device R1.
[edit protocols bgp]
user@R2# set export send-static
user@R2# set group 64511 type external
user@R2# set group 64511 peer-as 64511
user@R2# set group 64511 neighbor 10.2.0.2
450
3. Congure the roung policy.
[edit policy-options policy-statement send-static term 1]
user@R2# set from protocol static
user@R2# set then accept
4. Congure the stac routes.
[edit routing-options static]
user@R2# set route 10.20.1.0/24 reject
user@R2# set route 10.20.2.0/24 reject
user@R2# set route 10.20.3.0/24 reject
5. Congure the AS number.
[edit routing-options]
user@R2# set autonomous-system 64512
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure Device R6:
1. Congure the device interfaces.
[edit interfaces]
user@R6# set fe-1/2/1 unit 0 description to-R5
user@R6# set fe-1/2/1 unit 0 family inet address 10.0.0.10/30
user@R6# set lo0 unit 0 family inet address 192.168.0.6/32
2. Congure the EBGP connecon to Device R5.
[edit protocols bgp]
user@R6# set export send-static
user@R6# set group 64515 type external
451
user@R6# set group 64515 import reject-some-routes
user@R6# set group 64515 peer-as 64515
user@R6# set group 64515 neighbor 10.0.0.9
3. Congure the roung policy that sends stac routes.
[edit policy-options policy-statement send-static term 1]
user@R6# set from protocol static
user@R6# set then accept
4. Congure the roung policy that rejects certain routes.
[edit policy-options policy-statement reject-some-routes term find-routes]
user@R6# set from as-path orig-in-64513
user@R6# set from as-path orig-in-64514
user@R6# set then reject
[edit policy-options]
user@R6# set as-path orig-in-64513 ".* 64513"
user@R6# set as-path orig-in-64514 ".* 64514"
5. Congure the stac routes.
[edit routing-options static]
user@R6# set route 10.60.1.0/24 reject
user@R6# set route 10.60.2.0/24 reject
user@R6# set route 10.60.3.0/24 reject
6. Congure the AS number.
[edit routing-options]
user@R6# set autonomous-system 64516
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
452
Device R2
user@R2# show interfaces
fe-1/2/0 {
unit 0 {
description to-R1;
family inet {
address 10.2.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
export send-static;
group 64511 {
type external;
peer-as 64511;
neighbor 10.2.0.2;
}
}
user@R2# show policy-options
policy-statement send-static {
term 1 {
from protocol static;
then accept;
453
}
}
user@R2# show routing-options
static {
route 10.20.1.0/24 reject;
route 10.20.2.0/24 reject;
route 10.20.3.0/24 reject;
}
autonomous-system 64512;
Device R6
user@R6# show interfaces
fe-1/2/0 {
unit 0 {
description to-R5;
family inet {
address 10.0.0.10/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.6/32;
}
}
}
user@R6# show protocols
bgp {
export send-static;
group 64515 {
type external;
import reject-some-routes;
peer-as 64515;
neighbor 10.0.0.9;
454
}
}
user@R6# show policy-options
policy-statement reject-some-routes {
term find-routes {
from as-path [ orig-in-64513 orig-in-64514 ];
then reject;
}
}
policy-statement send-static {
term 1 {
from protocol static;
then accept;
}
}
as-path orig-in-64513 ".* 64513";
as-path orig-in-64514 ".* 64514";
user@R6# show routing-options
static {
route 10.60.1.0/24 reject;
route 10.60.2.0/24 reject;
route 10.60.3.0/24 reject;
}
autonomous-system 64516;
If you are done conguring the devices, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Finding Routes on Device R2 | 456
Making Sure That Routes Are Excluded on Device R6 | 457
Conrm that the conguraon is working properly.
455
Finding Routes on Device R2
Purpose
On Device R2, use the show route aspath-regex command to locate routes using regular expressions.
Acon
Look for routes that are originated by Device R6 in AS 64516.
user@R2> show route terse aspath-regex ".* 64516"
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A V Destination P Prf Metric 1 Metric 2 Next hop AS path
* ? 10.60.1.0/24 B 170 100 64511 64515 64516 I
unverified >10.2.0.2
* ? 10.60.2.0/24 B 170 100 64511 64515 64516 I
unverified >10.2.0.2
* ? 10.60.3.0/24 B 170 100 64511 64515 64516 I
unverified >10.2.0.2
Look for routes that are originated in either AS 64514 or AS 64516.
user@R2> show route terse aspath-regex ".* (64514|64516)"
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A V Destination P Prf Metric 1 Metric 2 Next hop AS path
* ? 10.40.1.0/24 B 170 100 64511 64513 64514 I
unverified >10.2.0.2
* ? 10.40.2.0/24 B 170 100 64511 64513 64514 I
unverified >10.2.0.2
* ? 10.40.3.0/24 B 170 100 64511 64513 64514 I
unverified >10.2.0.2
* ? 10.60.1.0/24 B 170 100 64511 64515 64516 I
unverified >10.2.0.2
* ? 10.60.2.0/24 B 170 100 64511 64515 64516 I
unverified >10.2.0.2
456
* ? 10.60.3.0/24 B 170 100 64511 64515 64516 I
unverified >10.2.0.2
Look for routes that use AS 64513 as a transit network.
user@R2> show route terse aspath-regex ".* 64513 .+"
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A V Destination P Prf Metric 1 Metric 2 Next hop AS path
* ? 10.40.1.0/24 B 170 100 64511 64513 64514 I
unverified >10.2.0.2
* ? 10.40.2.0/24 B 170 100 64511 64513 64514 I
unverified >10.2.0.2
* ? 10.40.3.0/24 B 170 100 64511 64513 64514 I
unverified
Meaning
The output shows the roung table entries that match the specied AS path regular expressions.
Making Sure That Routes Are Excluded on Device R6
Purpose
On Device R6, use the show route and show route hidden commands to make sure that routes originang
from AS 64513 and AS 64514 are excluded from Device R6’s roung table.
457
Acon
user@R6> show route 10.30.0/22
inet.0: 21 destinations, 21 routes (15 active, 0 holddown, 6 hidden)
user@R6> show route 10.40.0/22
inet.0: 21 destinations, 21 routes (15 active, 0 holddown, 6 hidden)
user@R6> show route hidden
inet.0: 21 destinations, 21 routes (15 active, 0 holddown, 6 hidden)
+ = Active Route, - = Last Active, * = Both
10.30.1.0/24 [BGP ] 02:24:47, localpref 100
AS path: 64515 64511 64513 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/1.0
10.30.2.0/24 [BGP ] 02:24:47, localpref 100
AS path: 64515 64511 64513 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/1.0
10.30.3.0/24 [BGP ] 02:24:47, localpref 100
AS path: 64515 64511 64513 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/1.0
10.40.1.0/24 [BGP ] 02:24:47, localpref 100
AS path: 64515 64511 64513 64514 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/1.0
10.40.2.0/24 [BGP ] 02:24:47, localpref 100
AS path: 64515 64511 64513 64514 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/1.0
10.40.3.0/24 [BGP ] 02:24:47, localpref 100
AS path: 64515 64511 64513 64514 I, validation-state: unverified
> to 10.0.0.9 via fe-1/2/1.0
Meaning
The output shows that the 10.30.0/22 and 10.40.0/22 routes are rejected on Device R6.
458
RELATED DOCUMENTATION
Understanding AS Path Regular Expressions for Use as Roung Policy Match Condions | 435
Example: Tesng a Roung Policy with Complex Regular Expressions | 762
Understanding Prepending AS Numbers to BGP AS Paths
You can
prepend
one or more autonomous system (AS) numbers at the beginning of an AS path. The AS
numbers are added at the beginning of the path aer the actual AS number from which the route
originates has been added to the path. Prepending an AS path makes a shorter AS path look longer and
therefore less preferable to BGP.
The BGP best path algorithm determines how the best path to an autonomous system (AS) is selected.
The AS path length determines the best path when all of the following condions are met:
• There are mulple potenal routes to an AS.
• BGP has the lowest preference value (somemes referred to as administrave distance) of the
available routes.
• The local preferences of the available routes are equal.
When these condions are met, the AS path length is used as the e breaker in the best path algorithm.
When two or more routes exist to reach a parcular prex, BGP prefers the route with the shortest AS
Path length.
If you are an enterprise that has mulhoming to one or more service providers, you might prefer that
incoming trac take a parcular path to reach your network. Perhaps you have two connecons, but
one costs less than the other. Or you might have one fast connecon and another, much slower
connecon that you only want to use as a backup if your primary connecon is down. AS path
prepending is an easy method that you can use to inuence inbound roung to your AS.
In Junos OS Release 9.1 and later, you can specify 4-byte AS numbers as dened in RFC 4893,
BGP
Support for Four-octet AS Number Space
, as well as the 2-byte AS numbers that are supported in earlier
releases of the Junos OS. In plain-number format, you can congure a value in the range from 1
through 4,294,967,295.
If you have a router that does not support 4-byte AS numbers in the AS path, the prependend AS
number displayed in the AS path is the AS_TRANS number, AS 23456. To display the route details, use
the
show route
command.
459
RELATED DOCUMENTATION
Example: Conguring a Roung Policy for AS Path Prepending | 460
Example: Using AS Path Regular Expressions | 444
Understanding BGP Path Selecon
Example: Conguring a Roung Policy for AS Path Prepending
IN THIS SECTION
Requirements | 460
Overview | 460
Conguraon | 461
Vericaon | 466
Appendix Full Conguraons | 469
This example shows how to congure a roung policy to prepend the AS path on specic routes
adversed by BGP.
Requirements
Before you begin, make sure your router interfaces and protocols are correctly congured. We provide
the interface and BGP protocol conguraon used in this document.
NOTE: This example was updated and re-validated on Junos release 22.1R1.
Overview
IN THIS SECTION
Topology | 461
460
In this example, you create a roung policy called
prependpolicy1
and a term called
prependterm1
. The
roung policy prepends AS number 65001 three mes to routes that match the 172.16.0.0/12,
192.168.0.0/16, and 10.0.0.0/8 prexes, when the mask length is equal to or longer than the specied
mask. The result is a match occurs when the route's mask length is equal to or longer than the specied
network mask. The
prependpolicy1
policy is applied as an export policy to the BGP routes adversed by
R1 in AS 65001 to R2 in AS number 65000. Routes that don't match the specied prex ranges do not
undergo AS path prepending.
Topology
In the topology EBGP peering is congured between R1 and R2. Direct interface peering to the
10.1.23.0/24 subnet addresses is used. R1 belongs to AS number 65001 and is congured to prepend
its AS number to a specic set of matching routes when adversed to R2.
By adding AS numbers to the AS path the route becomes less likely to be selected for forwarding. This
might be done by the owner of AS 65001 to reduce the amount of ingress trac it receives from the
operator of AS 65000.
NOTE: In this example we demonstrate AS path prepending through an export policy. You can
also use an import policy to match on routes for aribute manipulaon. In general its a best
pracce to only prepend your local AS number to routes. Prepending AS numbers that belong to
remote networks can lead to unexpected results.
For details on BGP paths selecon see
Understanding BGP Path Selecon
.
Conguraon
IN THIS SECTION
Procedure | 462
461
Procedure
CLI Quick Conguraon
In this secon we focus on the conguraon of the R1 device. Refer to the appendix for the complete
conguraons of all devices used in this example.
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
In this example we assign three test prexes to an unused interface on R1. A fourth test prex is
assigned to R1's loopback address. This provides four direct routes that can be adversed into BGP. Our
policy uses a combinaon of protocol direct and route-filter statements to control which prexes
undergo AS path prepending.
set system host-name R1
set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.23.1/24
set interfaces xe-0/0/0:0 unit 0 family inet address 10.255.1.1/30
set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.0.1/24
set interfaces xe-0/0/0:0 unit 0 family inet address 10.200.1.1/24
set interfaces lo0 unit 0 family inet address 192.168.0.1/32
set policy-options policy-statement prependpolicy1 term prependterm1 from protocol direct
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
172.16.0.0/16 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
192.168.0.0/24 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
10.255.1.0/24 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 then as-path-prepend "65001
65001 65001"
set policy-options policy-statement prependpolicy1 term prependterm1 then accept
set policy-options policy-statement prependpolicy1 term else from protocol direct
set policy-options policy-statement prependpolicy1 term else from route-filter 10.200.0.0/16
orlonger
set policy-options policy-statement prependpolicy1 term else then accept
set routing-options autonomous-system 65001
set routing-options router-id 192.168.0.1
set protocols bgp group ebgp type external
462
set protocols bgp group ebgp export prependpolicy1
set protocols bgp group ebgp peer-as 65000
set protocols bgp group ebgp neighbor 10.1.23.2
Step-by-Step Procedure
The following steps requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the Junos
OS CLI User Guide.
To create a roung policy that prepends AS numbers to specic routes:
1. Congure the peering and loopback interfaces.
user@R1#
[edit]
set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.23.1/24
set interfaces lo0 unit 0 family inet address 192.168.0.1/32
2. Congure the AS number, RID, and the external BGP peer group. You dene the
prependpolicy1
policy in the next step. The policy is applied as an export policy to aect the routes adversed by R1.
user@R1#
[edit]
set routing-options autonomous-system 65001
set routing-options router-id 192.168.0.1
set protocols bgp group ebgp type external
set protocols bgp group ebgp export prependpolicy1
set protocols bgp group ebgp peer-as 65000
set protocols bgp group ebgp neighbor 10.1.23.2
3. Congure the
prependpolicy1
policy. The use of or-longer switch to the route lter statements allows
a match when the mask length is equal to or longer than the specied mask. Other opons like exact
match only when the prex and mask lengths are equal. The
else
term demonstrates how a route
463
that does not match the
prependterm1
term is adversed without AS path prepending by matching
the
else
term.
user@R1#
[edit]
set policy-options policy-statement prependpolicy1 term prependterm1 from protocol direct
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
172.16.0.0/16 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
192.168.0.0/24 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
10.255.1.0/24 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 then as-path-prepend
"65001 65001 65001"
set policy-options policy-statement prependpolicy1 term prependterm1 then accept
set policy-options policy-statement prependpolicy1 term else from protocol direct
set policy-options policy-statement prependpolicy1 term else from route-filter 10.200.0.0/16
orlonger
set policy-options policy-statement prependpolicy1 term else then accept
NOTE: When you enter mulple AS numbers, you must separate each number with a space.
Enclose the string of AS numbers in double quotaon marks.
4. Dene test routes. In our sample topology we assign prexes to an unused interface that is
operaonally up. This provides direct routes for BGP to adverse for tesng the operaon of the
export policy.
user@R1#
[edit]
set interfaces xe-0/0/0:0 unit 0 family inet address 10.255.1.1/30
set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.0.1/24
set interfaces xe-0/0/0:0 unit 0 family inet address 10.200.1.1/24
464
Results
Conrm your conguraon by entering the show policy-opons, show protocols bgp, show roung-
opons, and show interfaces commands from conguraon mode. If the output does not display the
intended conguraon, repeat the conguraon instrucons in this example to correct it.
user@R1#[edit]
user@R1# show policy-options
policy-statement prependpolicy1 {
term prependterm1 {
from {
protocol direct;
route-filter 172.16.0.0/16 orlonger;
route-filter 192.168.0.0/24 orlonger;
route-filter 10.255.1.0/24 orlonger;
}
then {
as-path-prepend "65001 65001 65001";
accept;
}
}
term else {
from {
protocol direct;
route-filter 10.200.0.0/16 orlonger;
}
then accept;
}
}
[edit]
user@R1# show protocols bgp
group ebgp {
type external;
export direct;
peer-as 65000;
neighbor 10.1.23.2;
}
[edit]
user@R1# show routing-options
autonomous-system 65001;
465
router-id 192.168.0.1
user@R1# show interfaces xe-0/0/0:0
unit 0 {
family inet {
address 10.255.1.1/30;
address 172.16.0.1/24;
address 10.200.1.1/24;
}
}
[edit]
user@R1# show interfaces xe-0/0/0:1
unit 0 {
family inet {
address 10.1.23.1/24;
}
}
[edit]
user@R1# show interfaces lo0
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
If you are done conguring the R1 device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the AS Prepending Policy | 467
Verifying Roung Policy Applicaon and BGP Peering | 467
Verify AS Path Prepending | 468
To conrm that the conguraon is working properly, perform these tasks:
466
Verifying the AS Prepending Policy
Purpose
Verify that the policy is congured on the device, and that the appropriate routes are specied to
prepend with AS numbers.
Acon
From operaonal mode, enter the show policy
prependpolicy1
command.
user@R1> show policy prependpolicy1
Policy prependpolicy1: [CHANGED/RESOLVED/]
Term prependterm1:
from proto Direct
route filter:
172.16.0.0/16 orlonger
192.168.0.0/24 orlonger
10.255.1.0/24 orlonger
then aspathprepend 65001 65001 65001 accept
Term else:
from proto Direct
route filter:
10.200.0.0/16 orlonger
then accept
The policy displays the correct match condions and acons.
Verifying Roung Policy Applicaon and BGP Peering
Purpose
Verify the roung policy is applied as an export policy to the EBGP peer group. This step also conrms
the BGP session to R2 is correctly established.
Acon
From operaonal mode, enter the show bgp neighbor 10.1.23.2 command.
user@R1> show bgp neighbor 10.1.23.2
Peer: 10.1.23.2+49642 AS 65000 Local: 10.1.23.1+179 AS 65001
467
Group: ebgp Routing-Instance: master
Forwarding routing-instance: master
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ prependpolicy1 ]
Options: <PeerAS Refresh>
Options: <GracefulShutdownRcv>
Holdtime: 90 Preference: 170
Graceful Shutdown Receiver local-preference: 0
Number of flaps: 1
Last flap event: RecvNotify
Error: 'Cease' Sent: 0 Recv: 1
Peer ID: 192.168.0.2 Local ID: 192.168.0.1 Active Holdtime: 90
. . .
Input messages: Total 2498 Updates 1 Refreshes 0 Octets 47510
Output messages: Total 2500 Updates 3 Refreshes 0 Octets 47620
Output Queue[1]: 0 (inet.0, inet-unicast)
The command output conrms the BGP session is established and that R1 has applied the
prependpolicy1
policy as export.
Verify AS Path Prepending
Purpose
Verify the export policy works as design to prepend AS numbers to matching routes.
Acon
From operaonal mode, enter the show route protocol bgp command on R2. Alternavely, use the show
route adversing-protocol bgp 10.1.23.2 at R1 to display details about the routes it adverses to R2.
user@R2> show route protocol bgp
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.1.0/24 *[BGP/170] 00:04:46, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.1.23.1 via xe-0/0/0:0.0
10.255.1.0/30 *[BGP/170] 00:04:46, localpref 100
468
AS path: 65001 65001 65001 65001 I, validation-state: unverified
> to 10.1.23.1 via xe-0/0/0:0.0
172.16.0.0/24 *[BGP/170] 00:04:46, localpref 100
AS path: 65001 65001 65001 65001 I, validation-state: unverified
> to 10.1.23.1 via xe-0/0/0:0.0
192.168.0.1/32 *[BGP/170] 00:04:46, localpref 100
AS path: 65001 65001 65001 65001 I, validation-state: unverified
> to 10.1.23.1 via xe-0/0/0:0.0
The routes show the expected AS path prepending. Note that the 10.200.1.0/24 route only has one
instance of AS number 65001. This route does not match the route lter statements in the
prependterm1
of the
prependpolicy1
policy and so does not undergo any prepending.
R1's view of the BGP routes it adverses to R2 is provided for completeness:
user@R1> show route advertising-protocol bgp 10.1.23.2
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.200.1.0/24 Self I
* 10.255.1.0/30 Self 65001 65001 65001 [65001] I
* 172.16.0.0/24 Self 65001 65001 65001 [65001] I
* 192.168.0.1/32 Self 65001 65001 65001 [65001] I
Appendix Full Conguraons
The full conguraon for R1.
set system host-name R1
set interfaces xe-0/0/0:0 unit 0 family inet address 10.255.1.1/30
set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.0.1/24
set interfaces xe-0/0/0:0 unit 0 family inet address 10.200.1.1/24
set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.23.1/24
set interfaces lo0 unit 0 family inet address 192.168.0.1/32
set policy-options policy-statement prependpolicy1 term prependterm1 from protocol direct
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
172.16.0.0/16 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
192.168.0.0/24 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 from route-filter
10.255.1.0/24 orlonger
set policy-options policy-statement prependpolicy1 term prependterm1 then as-path-prepend "65001
469
65001 65001"
set policy-options policy-statement prependpolicy1 term prependterm1 then accept
set policy-options policy-statement prependpolicy1 term else from protocol direct
set policy-options policy-statement prependpolicy1 term else from route-filter 10.200.0.0/16
orlonger
set policy-options policy-statement prependpolicy1 term else then accept
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 65001
set protocols bgp group ebgp type external
set protocols bgp group ebgp export prependpolicy1
set protocols bgp group ebgp peer-as 65000
set protocols bgp group ebgp neighbor 10.1.23.2
The full conguraon for R2.
set system host-name R2
set interfaces xe-0/0/0:0 unit 0 family inet address 10.1.23.2/24
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set routing-options router-id 192.168.0.2
set routing-options autonomous-system 65000
set protocols bgp group ebgp type external
set protocols bgp group ebgp peer-as 65001
set protocols bgp group ebgp neighbor 10.1.23.1
Understanding Adding AS Numbers to BGP AS Paths
You can expand or add one or more AS numbers to an AS sequence. The AS numbers are added before
the local AS number has been added to the path. Expanding an AS path makes a shorter AS path look
longer and therefore less preferable to BGP. The last AS number in the exisng path is extracted and
prepended
n
mes, where
n
is a number from 1 through 32. This is similar to the AS path prepend
acon, except that the AS path expand acon adds an arbitrary sequence of AS numbers.
NOTE: If you are conguring both as-path-expand and as-path-prepend policy acons in a roung
policy, ensure that you congure as-path-expand before conguring as-path-prepend to avoid the
misplacement of the AS numbers, which can result in an incorrect AS path calculaon.
For example, from AS 1 there are two equal paths (through AS 2 and AS 3) to reach AS 4. You might
want packets from certain sources to use the path through AS 2. Therefore, you must make the path
470
through AS 3 less preferable so that BGP chooses the path through AS 2. In AS 1, you can expand
mulple AS numbers.
[edit]
policy-options {
policy-statement as-path-expand {
term expand {
from {
route-filter 192.168.0.0/16 orlonger;
route-filter 172.16.0.0/12 orlonger;
route-filter 10.0.0.0/8 orlonger;
}
then as-path-expand last-as count 4;
}
}
}
For routes from AS 2, this makes the route look like 1 2 2 2 2 2 when adversed, where 1 is from AS 1,
the 2 from AS 2 is prepended four mes, and the nal 2 is the original 2 received from the neighbor
router.
RELATED DOCUMENTATION
Example: Adversing Mulple Paths in BGP | 471
Example: Conguring a Roung Policy for AS Path Prepending | 460
Example: Adversing Mulple Paths in BGP
IN THIS SECTION
Requirements | 472
Overview | 472
Conguraon | 474
Vericaon | 501
471
In this example, BGP routers are congured to adverse mulple paths instead of adversing only the
acve path. Adversing mulple paths in BGP is specied in RFC 7911,
Adversement of Mulple Paths
in BGP
.
Requirements
This example uses the following hardware and soware components:
• Eight BGP-enabled devices.
• Five of the BGP-enabled devices do not necessarily need to be routers. For example, they can be EX
Series Ethernet Switches.
• Three of the BGP-enabled devices are congured to send mulple paths or receive mulple paths (or
both send and receive mulple paths). These three BGP-enabled devices must be M Series
Mulservice Edge Routers, MX Series 5G Universal Roung Plaorms, or T Series Core Routers.
• The three routers must be running Junos OS Release 11.4 or later.
Overview
IN THIS SECTION
Topology Diagram | 473
The following statements are used for conguring mulple paths to a desnaon:
[edit protocols bgp group
group-name
family
family
]
add-path {
receive;
send {
include-backup-path
include-backup-path
;
multipath;
path-count
path-count
;
path-selection-mode {
(all-paths | equal-cost-paths);
}
prefix-policy [
policy-names
... ];
}
}
472
In this example, Router R5, Router R6, and Router R7 redistribute stac routes into BGP. Router R1 and
Router R4 are route reectors. Router R2 and Router R3 are clients to Route Reector R1. Router R8 is a
client to Route Reector R4.
Route reecon is oponal when mulple-path adversement is enabled in BGP.
With the add-path send path-count 6 conguraon, Router R1 is congured to send up to six paths (per
desnaon) to Router R4.
With the add-path receive conguraon, Router R4 is congured to receive mulple paths from Router
R1.
With the add-path send path-count 6 conguraon, Router R4 is congured to send up to six paths to
Router R8.
With the add-path receive conguraon, Router R8 is congured to receive mulple paths from Router
R4.
The add-path send prefix-policy allow_199 policy conguraon (along with the corresponding route lter)
limits Router R4 to sending mulple paths for only the 172.16.199.1/32 route.
Topology Diagram
Figure 31 on page 473 shows the topology used in this example.
Figure 31: Adversement of Mulple Paths in BGP
473
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 474
Conguring Router R1 | 478
Conguring Router R2 | 481
Conguring Router R3 | 484
Conguring Router R4 | 487
Conguring Router R5 | 491
Conguring Router R6 | 494
Conguring Router R7 | 496
Conguring Router R8 | 498
Results | 500
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Router R1
set interfaces fe-0/0/0 unit 12 family inet address 10.0.12.1/24
set interfaces fe-0/0/1 unit 13 family inet address 10.0.13.1/24
set interfaces fe-1/0/0 unit 14 family inet address 10.0.14.1/24
set interfaces fe-1/2/0 unit 15 family inet address 10.0.15.1/24
set interfaces lo0 unit 10 family inet address 10.0.0.10/32
set protocols bgp group rr type internal
set protocols bgp group rr local-address 10.0.0.10
set protocols bgp group rr cluster 10.0.0.10
set protocols bgp group rr neighbor 10.0.0.20
set protocols bgp group rr neighbor 10.0.0.30
set protocols bgp group e1 type external
set protocols bgp group e1 neighbor 10.0.15.2 local-address 10.0.15.1
set protocols bgp group e1 neighbor 10.0.15.2 peer-as 2
set protocols bgp group rr_rr type internal
474
set protocols bgp group rr_rr local-address 10.0.0.10
set protocols bgp group rr_rr neighbor 10.0.0.40 family inet unicast add-path send path-count 6
set protocols ospf area 0.0.0.0 interface lo0.10 passive
set protocols ospf area 0.0.0.0 interface fe-0/0/0.12
set protocols ospf area 0.0.0.0 interface fe-0/0/1.13
set protocols ospf area 0.0.0.0 interface fe-1/0/0.14
set protocols ospf area 0.0.0.0 interface fe-1/2/0.15
set routing-options router-id 10.0.0.10
set routing-options autonomous-system 1
Router R2
set interfaces fe-1/2/0 unit 21 family inet address 10.0.12.2/24
set interfaces fe-1/2/1 unit 26 family inet address 10.0.26.1/24
set interfaces lo0 unit 20 family inet address 10.0.0.20/32
set protocols bgp group rr type internal
set protocols bgp group rr local-address 10.0.0.20
set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self
set protocols bgp group e1 type external
set protocols bgp group e1 neighbor 10.0.26.2 peer-as 2
set protocols ospf area 0.0.0.0 interface lo0.20 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.21
set protocols ospf area 0.0.0.0 interface fe-1/2/1.28
set policy-options policy-statement set_nh_self then next-hop self
set routing-options autonomous-system 1
Router R3
set interfaces fe-1/0/1 unit 31 family inet address 10.0.13.2/24
set interfaces fe-1/0/2 unit 37 family inet address 10.0.37.1/24
set interfaces lo0 unit 30 family inet address 10.0.0.30/32
set protocols bgp group rr type internal
set protocols bgp group rr local-address 10.0.0.30
set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self
set protocols bgp group e1 type external
set protocols bgp group e1 neighbor 10.0.37.2 peer-as 2
set protocols ospf area 0.0.0.0 interface lo0.30 passive
set protocols ospf area 0.0.0.0 interface fe-1/0/1.31
set protocols ospf area 0.0.0.0 interface fe-1/0/2.37
set policy-options policy-statement set_nh_self then next-hop self
set routing-options autonomous-system 1
475
Router R4
set interfaces fe-1/2/0 unit 41 family inet address 10.0.14.2/24
set interfaces fe-1/2/1 unit 48 family inet address 10.0.48.1/24
set interfaces lo0 unit 40 family inet address 10.0.0.40/32
set protocols bgp group rr type internal
set protocols bgp group rr local-address 10.0.0.40
set protocols bgp group rr family inet unicast add-path receive
set protocols bgp group rr neighbor 10.0.0.10
set protocols bgp group rr_client type internal
set protocols bgp group rr_client local-address 10.0.0.40
set protocols bgp group rr_client cluster 10.0.0.40
set protocols bgp group rr_client neighbor 10.0.0.80 family inet unicast add-path send path-
count 6
set protocols bgp group rr_client neighbor 10.0.0.80 family inet unicast add-path send prefix-
policy allow_199
set protocols ospf area 0.0.0.0 interface fe-1/2/0.41
set protocols ospf area 0.0.0.0 interface lo0.40 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/1.48
set policy-options policy-statement allow_199 from route-filter 172.16.199.1/32 exact
set policy-options policy-statement allow_199 term match_199 from prefix-list match_199
set policy-options policy-statement allow_199 then add-path send-count 20
set policy-options policy-statement allow_199 then accept
set routing-options autonomous-system 1
Router R5
set interfaces fe-1/2/0 unit 51 family inet address 10.0.15.2/24
set interfaces lo0 unit 50 family inet address 10.0.0.50/32
set protocols bgp group e1 type external
set protocols bgp group e1 neighbor 10.0.15.1 export s2b
set protocols bgp group e1 neighbor 10.0.15.1 peer-as 1
set policy-options policy-statement s2b from protocol static
set policy-options policy-statement s2b from protocol direct
set policy-options policy-statement s2b then as-path-expand 2
set policy-options policy-statement s2b then accept
set routing-options autonomous-system 2
set routing-options static route 172.16.199.1/32 reject
set routing-options static route 172.16.198.1/32 reject
476
Router R6
set interfaces fe-1/2/0 unit 62 family inet address 10.0.26.2/24
set interfaces lo0 unit 60 family inet address 10.0.0.60/32
set protocols bgp group e1 type external
set protocols bgp group e1 neighbor 10.0.26.1 export s2b
set protocols bgp group e1 neighbor 10.0.26.1 peer-as 1
set policy-options policy-statement s2b from protocol static
set policy-options policy-statement s2b from protocol direct
set policy-options policy-statement s2b then accept
set routing-options autonomous-system 2
set routing-options static route 172.16.199.1/32 reject
set routing-options static route 172.16.198.1/32 reject
Router R7
set interfaces fe-1/2/0 unit 73 family inet address 10.0.37.2/24
set interfaces lo0 unit 70 family inet address 10.0.0.70/32
set protocols bgp group e1 type external
set protocols bgp group e1 neighbor 10.0.37.1 export s2b
set protocols bgp group e1 neighbor 10.0.37.1 peer-as 1
set policy-options policy-statement s2b from protocol static
set policy-options policy-statement s2b from protocol direct
set policy-options policy-statement s2b then accept
set routing-options autonomous-system 2
set routing-options static route 172.16.199.1/32 reject
Router R8
set interfaces fe-1/2/0 unit 84 family inet address 10.0.48.2/24
set interfaces lo0 unit 80 family inet address 10.0.0.80/32
set protocols bgp group rr type internal
set protocols bgp group rr local-address 10.0.0.80
set protocols bgp group rr neighbor 10.0.0.40 family inet unicast add-path receive
set protocols ospf area 0.0.0.0 interface lo0.80 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.84
set routing-options autonomous-system 1
477
Conguring Router R1
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Router R1:
1. Congure the interfaces to Router R2, Router R3, Router R4, and Router R5, and congure the
loopback (lo0) interface.
[edit interfaces]
user@R1# set fe-0/0/0 unit 12 family inet address 10.0.12.1/24
user@R1# set fe-0/0/1 unit 13 family inet address 10.0.13.1/24
user@R1# set fe-1/0/0 unit 14 family inet address 10.0.14.1/24
user@R1# set fe-1/2/0 unit 15 family inet address 10.0.15.1/24
user@R1#set lo0 unit 10 family inet address 10.0.0.10/32
2. Congure BGP on the interfaces, and congure IBGP route reecon.
[edit protocols bgp]
user@R1# set group rr type internal
user@R1# set group rr local-address 10.0.0.10
user@R1# set group rr cluster 10.0.0.10
user@R1# set group rr neighbor 10.0.0.20
user@R1# set group rr neighbor 10.0.0.30
user@R1# set group rr_rr type internal
user@R1# set group rr_rr local-address 10.0.0.10
user@R1# set group e1 type external
user@R1# set group e1 neighbor 10.0.15.2 local-address 10.0.15.1
user@R1# set group e1 neighbor 10.0.15.2 peer-as 2
3. Congure Router R1 to send up to six paths to its neighbor, Router R4.
The desnaon of the paths can be any desnaon that Router R1 can reach through mulple paths.
[edit protocols bgp]
user@R1# set group rr_rr neighbor 10.0.0.40 family inet unicast add-path send path-count 6
478
4. Congure OSPF on the interfaces.
[edit protocols ospf]
user@R1# set area 0.0.0.0 interface lo0.10 passive
user@R1# set area 0.0.0.0 interface fe-0/0/0.12
user@R1# set area 0.0.0.0 interface fe-0/0/1.13
user@R1# set area 0.0.0.0 interface fe-1/0/0.14
user@R1# set area 0.0.0.0 interface fe-1/2/0.15
5. Congure the router ID and the autonomous system number.
[edit routing-options]
user@R1# set router-id 10.0.0.10
user@R1# set autonomous-system 1
6. If you are done conguring the device, commit the conguraon.
user@R1# commit
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R1# show interfaces
fe-0/0/0 {
unit 12 {
family inet {
address 10.0.12.1/24;
}
}
}
fe-0/0/1 {
unit 13 {
family inet {
address 10.0.13.1/24;
}
479
}
}
fe-1/0/0 {
unit 14 {
family inet {
address 10.0.14.1/24;
}
}
}
fe-1/2/0 {
unit 15 {
family inet {
address 10.0.15.1/24;
}
}
}
lo0 {
unit 10 {
family inet {
address 10.0.0.10/32;
}
}
}
user@R1# show protocols
bgp {
group rr {
type internal;
local-address 10.0.0.10;
cluster 10.0.0.10;
neighbor 10.0.0.20;
neighbor 10.0.0.30;
}
group e1 {
type external;
neighbor 10.0.15.2 {
local-address 10.0.15.1;
peer-as 2;
}
}
group rr_rr {
480
type internal;
local-address 10.0.0.10;
neighbor 10.0.0.40 {
family inet {
unicast {
add-path {
send {
path-count 6;
}
}
}
}
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.10 {
passive;
}
interface fe-0/0/0.12;
interface fe-0/0/1.13;
interface fe-1/0/0.14;
interface fe-1/2/0.15;
}
}
user@R1# show routing-options
router-id 10.0.0.10;
autonomous-system 1;
Conguring Router R2
Step-by-Step Procedure
To congure Router R2:
481
1. Congure the loopback (lo0) interface and the interfaces to Router R6 and Router R1.
[edit interfaces]
user@R2# set fe-1/2/0 unit 21 family inet address 10.0.12.2/24
user@R2# set fe-1/2/1 unit 26 family inet address 10.0.26.1/24
user@R2# set lo0 unit 20 family inet address 10.0.0.20/32
2. Congure BGP and OSPF on Router R2’s interfaces.
[edit protocols]
user@R2# set bgp group rr type internal
user@R2# set bgp group rr local-address 10.0.0.20
user@R2# set bgp group e1 type external
user@R2# set bgp group e1 neighbor 10.0.26.2 peer-as 2
user@R2# set ospf area 0.0.0.0 interface lo0.20 passive
user@R2# set ospf area 0.0.0.0 interface fe-1/2/0.21
user@R2# set ospf area 0.0.0.0 interface fe-1/2/1.28
3. For routes sent from Router R2 to Router R1, adverse Router R2 as the next hop, because Router
R1 does not have a route to Router R6’s address on the 10.0.26.0/24 network.
[edit]
user@R2# set policy-options policy-statement set_nh_self then next-hop self
user@R2# set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self
4. Congure the autonomous system number.
[edit]
user@R2# set routing-options autonomous-system 1
5. If you are done conguring the device, commit the conguraon.
user@R2# commit
482
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options,and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R2# show interfaces
fe-1/2/0 {
unit 21 {
family inet {
address 10.0.12.2/24;
}
}
}
fe-1/2/1 {
unit 26 {
family inet {
address 10.0.26.1/24;
}
}
}
lo0 {
unit 20 {
family inet {
address 10.0.0.20/32;
}
}
}
user@R2# show protocols
bgp {
group rr {
type internal;
local-address 10.0.0.20;
neighbor 10.0.0.10 {
export set_nh_self;
}
}
group e1 {
type external;
neighbor 10.0.26.2 {
483
peer-as 2;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.20 {
passive;
}
interface fe-1/2/0.21;
interface fe-1/2/1.28;
}
}
user@R2# show policy-options
policy-statement set_nh_self {
then {
next-hop self;
}
}
user@R2# show routing-options
autonomous-system 1;
Conguring Router R3
Step-by-Step Procedure
To congure Router R3:
1. Congure the loopback (lo0) interface and the interfaces to Router R7 and Router R1.
[edit interfaces]
user@R3# set fe-1/0/1 unit 31 family inet address 10.0.13.2/24
user@R3# set fe-1/0/2 unit 37 family inet address 10.0.37.1/24
user@R3# set lo0 unit 30 family inet address 10.0.0.30/32
484
2. Congure BGP and OSPF on Router R3’s interfaces.
[edit protocols]
user@R3# set bgp group rr type internal
user@R3# set bgp group rr local-address 10.0.0.30
user@R3# set bgp group e1 type external
user@R3# set bgp group e1 neighbor 10.0.37.2 peer-as 2
user@R3# set ospf area 0.0.0.0 interface lo0.30 passive
user@R3# set ospf area 0.0.0.0 interface fe-1/0/1.31
user@R3# set ospf area 0.0.0.0 interface fe-1/0/2.37
3. For routes sent from Router R3 to Router R1, adverse Router R3 as the next hop, because Router
R1 does not have a route to Router R7’s address on the 10.0.37.0/24 network.
[edit]
user@R3# set policy-options policy-statement set_nh_self then next-hop self
user@R3# set protocols bgp group rr neighbor 10.0.0.10 export set_nh_self
4. Congure the autonomous system number.
[edit]
user@R3# set routing-options autonomous-system 1
5. If you are done conguring the device, commit the conguraon.
user@R3# commit
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R3# show interfaces
fe-1/0/1 {
unit 31 {
family inet {
485
address 10.0.13.2/24;
}
}
}
fe-1/0/2 {
unit 37 {
family inet {
address 10.0.37.1/24;
}
}
}
lo0 {
unit 30 {
family inet {
address 10.0.0.30/32;
}
}
}
user@R3# show protocols
bgp {
group rr {
type internal;
local-address 10.0.0.30;
neighbor 10.0.0.10 {
export set_nh_self;
}
}
group e1 {
type external;
neighbor 10.0.37.2 {
peer-as 2;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.30 {
passive;
}
interface fe-1/0/1.31;
486
interface fe-1/0/2.37;
}
}
user@R3# show policy-options
policy-statement set_nh_self {
then {
next-hop self;
}
}
user@R3# show routing-options
autonomous-system 1;
Conguring Router R4
Step-by-Step Procedure
To congure Router R4:
1. Congure the interfaces to Router R1 and Router R8, and congure the loopback (lo0) interface.
[edit interfaces]
user@R4# set fe-1/2/0 unit 41 family inet address 10.0.14.2/24
user@R4# set fe-1/2/1 unit 48 family inet address 10.0.48.1/24
user@R4# set lo0 unit 40 family inet address 10.0.0.40/32
2. Congure BGP on the interfaces, and congure IBGP route reecon.
[edit protocols bgp]
user@R4# set group rr type internal
user@R4# set group rr local-address 10.0.0.40
user@R4# set group rr neighbor 10.0.0.10
user@R4# set group rr_client type internal
user@R4# set group rr_client local-address 10.0.0.40
user@R4# set group rr_client cluster 10.0.0.40
3. Congure Router R4 to send up to six paths to its neighbor, Router R8.
487
The desnaon of the paths can be any desnaon that Router R4 can reach through mulple paths.
[edit protocols bgp]
user@R4# set group rr_client neighbor 10.0.0.80 family inet unicast add-path send path-count 6
4. Congure Router R4 to receive mulple paths from its neighbor, Router R1.
The desnaon of the paths can be any desnaon that Router R1 can reach through mulple paths.
[edit protocols bgp group rr family inet unicast]
user@R4# set add-path receive
5. Congure OSPF on the interfaces.
[edit protocols ospf area 0.0.0.0]
user@R4# set interface fe-1/2/0.41
user@R4# set interface lo0.40 passive
user@R4# set interface fe-1/2/1.48
6. Congure a policy that allows Router R4 to send Router R8 mulple paths to the 172.16.199.1/32
route.
• Router R4 receives mulple paths for the 172.16.198.1/32 route and the 172.16.199.1/32 route.
However, because of this policy, Router R4 only sends mulple paths for the 172.16.199.1/32
route.
[edit protocols bgp group rr_client neighbor 10.0.0.80 family inet unicast]
user@R4# set add-path send prefix-policy allow_199
[edit policy-options policy-statement allow_199]
user@R4# set from route-filter 172.16.199.1/32 exact
user@R4# set then accept
• Router R4 can also be congured to send up-to 20 BGP add-path routes for a subset of
add-path
adversed prexes
.
[edit policy-options policy-statement allow_199]
user@R4# set term match_199 from prefix-list match_199
user@R4# set then add-path send-count 20
488
7. Congure the autonomous system number.
[edit routing-options]
user@R4# set autonomous-system 1
8. If you are done conguring the device, commit the conguraon.
user@R4# commit
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R4# show interfaces
fe-1/2/0 {
unit 41 {
family inet {
address 10.0.14.2/24;
}
}
}
fe-1/2/1 {
unit 48 {
family inet {
address 10.0.48.1/24;
}
}
}
lo0 {
unit 40 {
family inet {
address 10.0.0.40/32;
}
489
}
}
user@R4# show protocols
bgp {
group rr {
type internal;
local-address 10.0.0.40;
family inet {
unicast {
add-path {
receive;
}
}
}
neighbor 10.0.0.10;
}
group rr_client {
type internal;
local-address 10.0.0.40;
cluster 10.0.0.40;
neighbor 10.0.0.80 {
family inet {
unicast {
add-path {
send {
path-count 6;
prefix-policy allow_199;
}
}
}
}
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.40 {
passive;
}
interface fe-1/2/0.41;
490
interface fe-1/2/1.48;
}
}
user@R4# show policy-options
policy-statement allow_199 {
from {
route-filter 172.16.199.1/32 exact;
}
from term match_199 {
prefix-list match_199;
}
then add-path send-count 20;
then accept;
}
user@R4# show routing-options
autonomous-system 1;
Conguring Router R5
Step-by-Step Procedure
To congure Router R5:
1. Congure the loopback (lo0) interface and the interface to Router R1.
[edit interfaces]
user@R5# set fe-1/2/0 unit 51 family inet address 10.0.15.2/24
user@R5# set lo0 unit 50 family inet address 10.0.0.50/32
2. Congure BGP on Router R5’s interface.
[edit protocols bgp group e1]
user@R5# set type external
user@R5# set neighbor 10.0.15.1 peer-as 1
491
3. Create stac routes for redistribuon into BGP.
[edit routing-options]
user@R5# set static route 172.16.199.1/32 reject
user@R5# set static route 172.16.198.1/32 reject
4. Redistribute stac and direct routes into BGP.
[edit protocols bgp group e1 neighbor 10.0.15.1]
user@R5# set export s2b
[edit policy-options policy-statement s2b]
user@R5# set from protocol static
user@R5# set from protocol direct
user@R5# set then as-path-expand 2
user@R5# set then accept
5. Congure the autonomous system number.
[edit routing-options]
user@R5# set autonomous-system 2
6. If you are done conguring the device, commit the conguraon.
user@R5# commit
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R5# show interfaces
fe-1/2/0 {
unit 51 {
family inet {
address 10.0.15.2/24;
492
}
}
}
lo0 {
unit 50 {
family inet {
address 10.0.0.50/32;
}
}
}
user@R5# show protocols
bgp {
group e1 {
type external;
neighbor 10.0.15.1 {
export s2b;
peer-as 1;
}
}
}
user@R5# show policy-options
policy-statement s2b {
from protocol [ static direct ];
then {
as-path-expand 2;
accept;
}
}
user@R5# show routing-options
static {
route 172.16.198.1/32 reject;
route 172.16.199.1/32 reject;
}
autonomous-system 2;
493
Conguring Router R6
Step-by-Step Procedure
To congure Router R6:
1. Congure the loopback (lo0) interface and the interface to Router R2.
[edit interfaces]
user@R6# set fe-1/2/0 unit 62 family inet address 10.0.26.2/24
user@R6# set lo0 unit 60 family inet address 10.0.0.60/32
2. Congure BGP on Router R6’s interface.
[edit protocols]
user@R6# set bgp group e1 type external
user@R6# set bgp group e1 neighbor 10.0.26.1 peer-as 1
3. Create stac routes for redistribuon into BGP.
[edit]
user@R6# set routing-options static route 172.16.199.1/32 reject
user@R6# set routing-options static route 172.16.198.1/32 reject
4. Redistribute stac and direct routes from Router R6’s roung table into BGP.
[edit protocols bgp group e1 neighbor 10.0.26.1]
user@R6# set export s2b
[edit policy-options policy-statement s2b]
user@R6# set from protocol static
user@R6# set from protocol direct
user@R6# set then accept
5. Congure the autonomous system number.
[edit routing-options]
user@R6# set autonomous-system 2
494
6. If you are done conguring the device, commit the conguraon.
user@R6# commit
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R6# show interfaces
fe-1/2/0 {
unit 62 {
family inet {
address 10.0.26.2/24;
}
}
}
lo0 {
unit 60 {
family inet {
address 10.0.0.60/32;
}
}
}
user@R6# show protocols
bgp {
group e1 {
type external;
neighbor 10.0.26.1 {
export s2b;
peer-as 1;
}
495
}
}
user@R6# show policy-options
policy-statement s2b {
from protocol [ static direct ];
then accept;
}
user@R6# show routing-options
static {
route 172.16.198.1/32 reject;
route 172.16.199.1/32 reject;
}
autonomous-system 2;
Conguring Router R7
Step-by-Step Procedure
To congure Router R7:
1. Congure the loopback (lo0) interface and the interface to Router R3.
[edit interfaces]
user@R7# set fe-1/2/0 unit 73 family inet address 10.0.37.2/24
user@R7# set lo0 unit 70 family inet address 10.0.0.70/32
2. Congure BGP on Router R7’s interface.
[edit protocols bgp group e1]
user@R7# set type external
user@R7# set neighbor 10.0.37.1 peer-as 1
496
3. Create a stac route for redistribuon into BGP.
[edit]
user@R7# set routing-options static route 172.16.199.1/32 reject
4. Redistribute stac and direct routes from Router R7’s roung table into BGP.
[edit protocols bgp group e1 neighbor 10.0.37.1]
user@R7# set export s2b
[edit policy-options policy-statement s2b]
user@R7# set from protocol static
user@R7# set from protocol direct
user@R7# set then accept
5. Congure the autonomous system number.
[edit routing-options]
user@R7# set autonomous-system 2
6. If you are done conguring the device, commit the conguraon.
user@R7# commit
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R7# show interfaces
fe-1/2/0 {
unit 73 {
family inet {
address 10.0.37.2/24;
}
}
497
}
lo0 {
unit 70 {
family inet {
address 10.0.0.70/32;
}
}
}
user@R7# show protocols
bgp {
group e1 {
type external;
neighbor 10.0.37.1 {
export s2b;
peer-as 1;
}
}
}
user@R7# show policy-options
policy-statement s2b {
from protocol [ static direct ];
then accept;
}
user@R7# show routing-options
static {
route 172.16.199.1/32 reject;
}
autonomous-system 2;
Conguring Router R8
Step-by-Step Procedure
To congure Router R8:
498
1. Congure the loopback (lo0) interface and the interface to Router R4.
[edit interfaces]
user@R8# set fe-1/2/0 unit 84 family inet address 10.0.48.2/24
user@R8# set lo0 unit 80 family inet address 10.0.0.80/32
2. Congure BGP and OSPF on Router R8’s interface.
[edit protocols]
user@R8# set bgp group rr type internal
user@R8# set bgp group rr local-address 10.0.0.80
user@R8# set ospf area 0.0.0.0 interface lo0.80 passive
user@R8# set ospf area 0.0.0.0 interface fe-1/2/0.84
3. Congure Router R8 to receive mulple paths from its neighbor, Router R4.
The desnaon of the paths can be any desnaon that Router R4 can reach through mulple paths.
[edit protocols]
user@R8# set bgp group rr neighbor 10.0.0.40 family inet unicast add-path receive
4. Congure the autonomous system number.
[edit]
user@R8# set routing-options autonomous-system 1
5. If you are done conguring the device, commit the conguraon.
user@R8# commit
499
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R8# show interfaces
fe-1/2/0 {
unit 84 {
family inet {
address 10.0.48.2/24;
}
}
}
lo0 {
unit 80 {
family inet {
address 10.0.0.80/32;
}
}
}
user@R8# show protocols
bgp {
group rr {
type internal;
local-address 10.0.0.80;
neighbor 10.0.0.40 {
family inet {
unicast {
add-path {
receive;
}
}
}
}
}
}
ospf {
500
area 0.0.0.0 {
interface lo0.80 {
passive;
}
interface fe-1/2/0.84;
}
}
user@R8# show routing-options
autonomous-system 1;
Vericaon
IN THIS SECTION
Verifying That the BGP Peers Have the Ability to Send and Receive Mulple Paths | 501
Verifying That Router R1 Is Adversing Mulple Paths | 502
Verifying That Router R4 Is Receiving and Adversing Mulple Paths | 503
Verifying That Router R8 Is Receiving Mulple Paths | 504
Checking the Path ID | 505
Conrm that the conguraon is working properly.
Verifying That the BGP Peers Have the Ability to Send and Receive Mulple Paths
Purpose
Make sure that one or both of the following strings appear in the output of the show bgp neighbor
command:
•
NLRI's for which peer can receive multiple paths: inet-unicast
• NLRI's for which peer can send multiple paths: inet-unicast
501
Acon
user@R1> show bgp neighbor 10.0.0.40
Peer: 10.0.0.40+179 AS 1 Local: 10.0.0.10+64227 AS 1
Type: Internal State: Established Flags: <Sync>
... NLRI's for which peer can receive multiple paths: inet-unicast
...
user@R4> show bgp neighbor 10.0.0.10
Peer: 10.0.0.10+64227 AS 1 Local: 10.0.0.40+179 AS 1
Type: Internal State: Established Flags: <Sync>
...
NLRI's for which peer can send multiple paths: inet-unicast
...
user@R4> show bgp neighbor 10.0.0.80
Peer: 10.0.0.80+55416 AS 1 Local: 10.0.0.40+179 AS 1
Type: Internal State: Established (route reflector client)Flags: <Sync>
,,,
NLRI's for which peer can receive multiple paths: inet-unicast
...
user@R8> show bgp neighbor 10.0.0.40
Peer: 10.0.0.40+179 AS 1 Local: 10.0.0.80+55416 AS 1
Type: Internal State: Established Flags: <Sync>
...
NLRI's for which peer can send multiple paths: inet-unicast
...
Verifying That Router R1 Is Adversing Mulple Paths
Purpose
Make sure that mulple paths to the 172.16.198.1/32 desnaon and mulple paths to the
172.16.199.1/32 desnaon are adversed to Router R4.
502
Acon
user@R1> show route advertising-protocol bgp 10.0.0.40
inet.0: 21 destinations, 25 routes (21 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.50/32 10.0.15.2 100 2 2 I
* 10.0.0.60/32 10.0.0.20 100 2 I
* 10.0.0.70/32 10.0.0.30 100 2 I
* 172.16.198.1/32 10.0.0.20 100 2 I
10.0.15.2 100 2 2 I
* 172.16.199.1/32 10.0.0.20 100 2 I
10.0.0.30 100 2 I
10.0.15.2 100 2 2 I
* 172.16.200.0/30 10.0.0.20 100 2 I
Meaning
When you see one prex and more than one next hop, it means that mulple paths are adversed to
Router R4.
Verifying That Router R4 Is Receiving and Adversing Mulple Paths
Purpose
Make sure that mulple paths to the 172.16.199.1/32 desnaon are received from Router R1 and
adversed to Router R8. Make sure that mulple paths to the 172.16.198.1/32 desnaon are received
from Router R1, but only one path to this desnaon is adversed to Router R8.
Acon
user@R4> show route receive-protocol bgp 10.0.0.10
inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.50/32 10.0.15.2 100 2 2 I
* 10.0.0.60/32 10.0.0.20 100 2 I
* 10.0.0.70/32 10.0.0.30 100 2 I
* 172.16.198.1/32 10.0.0.20 100 2 I
10.0.15.2 100 2 2 I
* 172.16.199.1/32 10.0.0.20 100 2 I
503
10.0.0.30 100 2 I
10.0.15.2 100 2 2 I
* 172.16.200.0/30 10.0.0.20 100 2 I
user@R4> show route advertising-protocol bgp 10.0.0.80
inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.50/32 10.0.15.2 100 2 2 I
* 10.0.0.60/32 10.0.0.20 100 2 I
* 10.0.0.70/32 10.0.0.30 100 2 I
* 172.16.198.1/32 10.0.0.20 100 2 I
* 172.16.199.1/32 10.0.0.20 100 2 I
10.0.0.30 100 2 I
10.0.15.2 100 2 2 I
* 172.16.200.0/30 10.0.0.20 100 2 I
Meaning
The show route receive-protocol command shows that Router R4 receives two paths to the
172.16.198.1/32 desnaon and three paths to the 172.16.199.1/32 desnaon. The show route
advertising-protocol command shows that Router R4 adverses only one path to the 172.16.198.1/32
desnaon and adverses all three paths to the 172.16.199.1/32 desnaon.
Because of the prex policy that is applied to Router R4, Router R4 does not adverse mulple paths to
the 172.16.198.1/32 desnaon. Router R4 adverses only one path to the 172.16.198.1/32
desnaon even though it receives mulple paths to this desnaon.
Verifying That Router R8 Is Receiving Mulple Paths
Purpose
Make sure that Router R8 receives mulple paths to the 172.16.199.1/32 desnaon through Router
R4. Make sure that Router R8 receives only one path to the 172.16.198.1/32 desnaon through
Router R4.
504
Acon
user@R8> show route receive-protocol bgp 10.0.0.40
inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.50/32 10.0.15.2 100 2 2 I
* 10.0.0.60/32 10.0.0.20 100 2 I
* 10.0.0.70/32 10.0.0.30 100 2 I
* 172.16.198.1/32 10.0.0.20 100 2 I
* 172.16.199.1/32 10.0.0.20 100 2 I
10.0.0.30 100 2 I
10.0.15.2 100 2 2 I
* 200.1.1.0/30 10.0.0.20 100 2 I
Checking the Path ID
Purpose
On the downstream devices, Router R4 and Router R8, verify that a path ID uniquely idenes the path.
Look for the Addpath Path ID: string.
Acon
user@R4> show route 172.16.199.1/32 detail
inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden)
172.16.199.1/32 (3 entries, 3 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 9
Source: 10.0.0.10
Next hop type: Router, Next hop index: 676
Next hop: 10.0.14.1 via lt-1/2/0.41, selected
Protocol next hop: 10.0.0.20
Indirect next hop: 92041c8 262146
State: <Active Int Ext>
Local AS: 1 Peer AS: 1
Age: 1:44:37 Metric2: 2
Task: BGP_1.10.0.0.10+64227
Announcement bits (3): 2-KRT 3-BGP RT Background 4-Resolve tree 1
505
AS path: 2 I (Originator) Cluster list: 10.0.0.10
AS path: Originator ID: 10.0.0.20
Accepted
Localpref: 100
Router ID: 10.0.0.10
Addpath Path ID: 1
BGP Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 4
Source: 10.0.0.10
Next hop type: Router, Next hop index: 676
Next hop: 10.0.14.1 via lt-1/2/0.41, selected
Protocol next hop: 10.0.0.30
Indirect next hop: 92042ac 262151
State: <NotBest Int Ext>
Inactive reason: Not Best in its group - Router ID
Local AS: 1 Peer AS: 1
Age: 1:44:37 Metric2: 2
Task: BGP_1.10.0.0.10+64227
Announcement bits (1): 3-BGP RT Background
AS path: 2 I (Originator) Cluster list: 10.0.0.10
AS path: Originator ID: 10.0.0.30
Accepted
Localpref: 100
Router ID: 10.0.0.10
Addpath Path ID: 2
BGP Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 4
Source: 10.0.0.10
Next hop type: Router, Next hop index: 676
Next hop: 10.0.14.1 via lt-1/2/0.41, selected
Protocol next hop: 10.0.15.2
Indirect next hop: 92040e4 262150
State: <Int Ext>
Inactive reason: AS path
Local AS: 1 Peer AS: 1
Age: 1:44:37 Metric2: 2
Task: BGP_1.10.0.0.10+64227
Announcement bits (1): 3-BGP RT Background
AS path: 2 2 I
Accepted
Localpref: 100
506
Router ID: 10.0.0.10
Addpath Path ID: 3
user@R8> show route 172.16.199.1/32 detail
inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
172.16.199.1/32 (3 entries, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 9
Source: 10.0.0.40
Next hop type: Router, Next hop index: 1045
Next hop: 10.0.48.1 via lt-1/2/0.84, selected
Protocol next hop: 10.0.0.20
Indirect next hop: 91fc0e4 262148
State: <Active Int Ext>
Local AS: 1 Peer AS: 1
Age: 1:56:51 Metric2: 3
Task: BGP_1.10.0.0.40+179
Announcement bits (2): 2-KRT 4-Resolve tree 1
AS path: 2 I (Originator) Cluster list: 10.0.0.40 10.0.0.10
AS path: Originator ID: 10.0.0.20
Accepted
Localpref: 100
Router ID: 10.0.0.40
Addpath Path ID: 1
BGP Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 4
Source: 10.0.0.40
Next hop type: Router, Next hop index: 1045
Next hop: 10.0.48.1 via lt-1/2/0.84, selected
Protocol next hop: 10.0.0.30
Indirect next hop: 91fc1c8 262152
State: <NotBest Int Ext>
Inactive reason: Not Best in its group - Router ID
Local AS: 1 Peer AS: 1
Age: 1:56:51 Metric2: 3
Task: BGP_1.10.0.0.40+179
AS path: 2 I (Originator) Cluster list: 10.0.0.40 10.0.0.10
AS path: Originator ID: 10.0.0.30
507
Accepted
Localpref: 100
Router ID: 10.0.0.40
Addpath Path ID: 2
BGP Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 4
Source: 10.0.0.40
Next hop type: Router, Next hop index: 1045
Next hop: 10.0.48.1 via lt-1/2/0.84, selected
Protocol next hop: 10.0.15.2
Indirect next hop: 91fc2ac 262153
State: <Int Ext>
Inactive reason: AS path
Local AS: 1 Peer AS: 1
Age: 1:56:51 Metric2: 3
Task: BGP_1.10.0.0.40+179
AS path: 2 2 I (Originator) Cluster list: 10.0.0.40
AS path: Originator ID: 10.0.0.10
Accepted
Localpref: 100
Router ID: 10.0.0.40
Addpath Path ID: 3
RELATED DOCUMENTATION
Understanding the Adversement of Mulple Paths to a Single Desnaon in BGP
Understanding Adding AS Numbers to BGP AS Paths | 470
Improve the Performance of AS Path Lookup in BGP Policy
SUMMARY
IN THIS SECTION
AS Path Lookup in a BGP Policy Without
Regular Expression Overview | 509
508
Congure AS Path Lookup Without Using
Regular Expression | 510
AS Path Lookup in a BGP Policy Without Regular Expression Overview
IN THIS SECTION
Benets of AS-Path without using regular expression in BGP policy: | 509
When working with BGP AS paths and
roung policy match condions, you can congure BGP policies
to check for an autonomous system (AS) match in an AS path without using regular expressions. The
BGP policy compares the AS to an AS-list or As-list-group and returns true if it nds a match. You can
congure the BGP policy to check for a matching origin, neighbor, or transit AS. This feature provides a
faster alternave to match origin, transit, and peer AS numbers than using a regular expression.
Benets of AS-Path without using regular expression in BGP policy:
• Opmized lookup for origin, neighbor, transit ASes improves the performance.
• Provides a faster lookup in terms of speed.
The following operaons to match the ASes in an AS path are supported:
• Match the Originang AS in the AS Path—Compares the AS that originated the route. Evaluates if the
right most AS number on the AS path belongs to the as-list or as-list-group specied in the as-path-
origins conguraon statement at the [edit policy-options policy-statement
policy-name
from] hierarchy
level. In the case where the route has been aggregated, and the locaon of the originang AS
contains an AS-set, the as-path-origins operator evaluates to true if any AS contained in the AS-set
belongs to the as-list or as-list-group specied in the as-path-origins conguraon statement.
• Match the Neighbor AS in the AS Path—Compares the neighbor AS in the AS path. Evaluates if the
rst AS number on the AS path matches the as-list or as-list-group specied in the as-path-neighbors
conguraon statement at the [edit policy-options policy-statement
policy-name
from] hierarchy level. If
the neighboring AS locaon happens to be an AS-set, the as-path-neighbors operator evaluates to true
if any AS contained in the AS-set belongs to the as-list or as-list-group specied in the as-path-
neighbors conguraon statement.
509
• Match the Transit AS in the AS Path—Compares any AS in the AS-Path. Evaluates when any AS
belongs to the as-list or as-list-group specied in the as-path-transit conguraon statement at the
[edit policy-options policy-statement
policy-name
from] hierarchy level. In the case of AS-set, the as-path-
transit operator compares all the ASes in the AS-set.
Congure AS Path Lookup Without Using Regular Expression
You can congure AS path lookups by dening AS lists, or AS list groups for origin, neighbor, and transit
ASes and lter the routes without using regular expression.
The table here shows conguraons of universal match based on regular expressions and equivalent
match with faster execuon me.
Match type Universal match based on regular
expressions
Equivalent match with faster
execuon me
Peer set policy-opons as-path peer-match
"^101.*"
set policy-opons as-list peer-
match members 101
Transit set policy-opons as-path transit-match
".*61453.*10001.*40007$"
set policy-opons as-list
transit-match members 61453
Origin set policy-opons as-path origin-match
".*54367$"
set policy-opons as-list origin-
match members 54367
The following sample conguraon shows how you can dene AS lists (as-list
as-list-name
) for origin,
neighbor, and transit ASes and how you can use policies to lter the routes without using regular
expression:
Step 1: Dene AS lists for matching origin, neighbor, and transit AS and apply it as a lter to lter the
routes using policies.
set policy-options as-list origin-match members 54367
set policy-options as-list neighbor-match members 101
set policy-options as-list transit-match members 61453
set policy-options as-list transit-match members 10001
NOTE: You can also dene AS list groups (as-list-group
group-name
) for matching origin, neighbor,
and transit ASes to lter the routes using policies. The following is a sample conguraon to
dene AS list groups to match origin ASes to lter the routes using policies:
set policy-options as-list-group origin_group as-list origin-match-1 members 3-4
set policy-options as-list-group origin_group as-list origin-match-2 members 6-9
set policy-options policy-statement neighbor-accept term 1 from as-path-origins as-list-group
510
origin_group
set policy-options policy-statement neighbor-accept term 1 then accept
set policy-options policy-statement neighbor-accept term 2 then reject
NOTE: AS list groups to match the origin, neighbor, and transit ASes could be an AS member (for
example, 101) or a range of AS members (for example, 6-9). In this case, all the routes originang
from 6, 7, 8, 9 will be matched.
If you are using a range of AS members (as-start to as-nish), then the as-start member value
should be less than or equal to as-nish member value. The AS member or the AS member range
(as-start to as-nish) cannot be 0.
The as-list or as-list-group denes an AS set.
While performing an AS set lookup for origins and neighbors, the rst or last AS from an AS path
is matched. In the case of transits, there could be mulple iteraons on the AS path to perform
AS set lookup.
Step 2: Congure policies to match and lter routes based on origin, neighbor, and transit ASes.
set policy-options policy-statement as-list-match term transit-match from as-path-transits as-
list transit-match
set policy-options policy-statement as-list-match term transit-match then local-preference 300
set policy-options policy-statement as-list-match term transit-match then accept
set policy-options policy-statement as-list-match term origin-match from as-path-origins as-list
origin-match
set policy-options policy-statement as-list-match term origin-match then local-preference 400
set policy-options policy-statement as-list-match term origin-match then accept
set policy-options policy-statement as-list-match term neighbor-match from as-path-neighbors as-
list peer-match
set policy-options policy-statement as-list-match term peer-match then local-preference 200
set policy-options policy-statement as-list-match term peer-match then accept
Step 3: Dene the local autonomous system.
set routing-options autonomous-system 100
511
Step 4: Apply the policy as BGP import policy to lter the routes.
set protocols bgp group ebgp-1 type external
set protocols bgp group ebgp-1 import as-list-match
set protocols bgp group ebgp-1 family inet unicast
set protocols bgp group ebgp-1 neighbor 192.168.1.2 peer-as 101
set protocols bgp group ebgp-1 neighbor 192.168.1.6 peer-as 102
NOTE: This policy can be applied as an import or export policy to lter the routes to take
corresponding acon dened in the policy.
You can use the show route CLI command to view the routes in the roung table.
NOTE: The conguraon statements in the from clause match condion occurs in both [edit
policy-options policy-statement
policy-name
from] and [edit policy-options policy-statement
policy-name
term
term-name
from] hierarchy levels.
512
CHAPTER 6
Conguring Communies as Match Condions
IN THIS CHAPTER
Understanding BGP Communies, Extended Communies, and Large Communies as Roung Policy Match
Condions | 513
Understanding How to Dene BGP Communies and Extended Communies | 515
How BGP Communies and Extended Communies Are Evaluated in Roung Policy Match
Condions | 523
Example: Conguring Communies in a Roung Policy | 530
Example: Conguring Extended Communies in a Roung Policy | 550
Example: Conguring BGP Large Communies | 562
Example: Conguring a Roung Policy Based on the Number of BGP Communies | 574
Example: Conguring a Roung Policy That Removes BGP Communies | 585
Understanding BGP Communies, Extended Communies, and Large
Communies as Roung Policy Match Condions
A
BGP community
is a group of desnaons that share a common property. Community informaon is
included as a path aribute in BGP update messages. This informaon idenes community members
and enables you to perform acons on a group without having to elaborate upon each member. You can
use community and extended communies aributes to trigger roung decisions, such as acceptance,
rejecon, preference, or redistribuon.
You can assign community tags to non-BGP routes through conguraon (for stac, aggregate, or
generated routes) or an import roung policy. These tags can then be matched when BGP exports the
routes.
A community value is a 32-bit eld that is divided into two main secons. The rst 16 bits of the value
encode the AS number of the network that originated the community, while the last 16 bits carry a
unique number assigned by the AS. This system aempts to guarantee a globally unique set of
community values for each AS in the Internet. Junos OS uses a notaon of
as-number
:
community-value
,
where each value is a decimal number. The AS values of 0 and 65,535 are reserved, as are all of the
513
community values within those AS numbers. Each community, or set of communies, is given a name
within the [edit policy-options] conguraon hierarchy. The name of the community uniquely idenes it
to the roung device and serves as the method by which routes are categorized. For example, a route
with a community value of 64510:1111 might belong to the community named AS64510-routes. The
community name is also used within a roung policy as a match criterion or as an acon. The command
syntax for creang a community is: policy-opons community
name
members [
community-ids
]. The
community-ids
are either a single community value or mulple community values. When more than one value is
assigned to a community name, the roung device interprets this as a logical AND of the community
values. In other words, a route must have all of the congured values before being assigned the
community name.
The regular community aribute is four octets. Networking enhancements, such as VPNs, have
funconality requirements that can be sased by an aribute such as a community. However, the 4-
octet community value does not provide enough expansion and exibility to accommodate VPN
requirements. This leads to the creaon of extended communies. An extended community is an 8-
octet value that is also divided into two main secons. The rst 2 octets of the community encode a
type eld while the last 6 octets carry a unique set of data in a format dened by the type eld.
Extended communies provide a larger range for grouping or categorizing communies.
The BGP extended communies aribute format has three elds:
type
:
administrator
:
assigned-number
. The
roung device expects you to use the words target or origin to represent the type eld. The
administrator eld uses a decimal number for the AS or an IPv4 address, while the assigned number eld
expects a decimal number no larger than the size of the eld (65,535 for 2 octets or 4,294,967,295 for 4
octets).
When specifying community IDs for standard and extended community aributes, you can use UNIX-
style regular expressions. The only excepon is for VPN import policies (vrf-import), which do not support
regular expressions for the extended communies aribute.
Regular BGP communies aributes are a variable length aribute consisng of a set of one or more 4-
byte values that was split into 16 bit values. The most signicant word is interpreted as an AS number
and least signicant word is a locally dened value assigned by the operator of the AS. Since the
adopon of 4-byte ASNs, the 4-byte BGP regular community and 6-byte BGP extended community can
no longer support BGP community aributes. Operators oen encode AS number in the local poron of
the BGP community that means that somemes the format of the community is ASN:ASN. With the 4-
byte ASN , you need 8-bytes to encode it. Although BGP extended community permits a 4-byte AS to
be encoded as the global administrator eld, the local administrator eld has only 2-byte of available
space. Thus, 6-byte extended community aribute is also unsuitable. To overcome this, Junos OS allows
you to congure oponal transive path aribute - a 12-byte BGP large community that provides the
most signicant 4-byte value to encode autonomous system number as the global administrator and the
remaining two 4-byte assigned numbers to encode the local values as dened in RFC 8092. You can
congure BGP large community at the [edit policy-options community
community-name
members] and [edit
routing-options static route
ip-address
community] hierarchy levels. The BGP large community aributes
format has four elds: large:
global administrator
:
assigned number
:
assigned number
.
514
The BGP IPv6 unicast address specic extended community are encoded as a set of 20-bytes value. The
20-byte value gets interpreted in the following format:
• Most signicant 2-bytes encodes the Type and Sub-Type value (high value (most signicant byte) and
Low value (second most signicant byte)).
• Next 16-bytes encodes the IPv6 unicast address. It is the global administrator in the IETF RFC.
• Last 2-bytes encodes the operator dened local values. It is local administrator in the IETF RFC.
The IPv6 unicast address specic BGP extended community aributes are represented by a keyword
ipv6-target, ipv6-origin, or ipv6-extended followed by IPv6 and local administrator separated by <, >, and :.
NOTE: The length of the BGP large communies aribute value should be a non-zero mulple of
12.
RELATED DOCUMENTATION
Understanding How to Dene BGP Communies and Extended Communies | 515
How BGP Communies and Extended Communies Are Evaluated in Roung Policy Match
Condions | 523
Example: Conguring a Roung Policy That Removes BGP Communies
Example: Conguring Communies in a Roung Policy | 530
Example: Conguring Extended Communies in a Roung Policy | 550
Understanding How to Dene BGP Communies and Extended
Communies
IN THIS SECTION
Dening BGP Communies for Use in Roung Policy Match Condions | 516
Dening BGP Extended Communies for Use in Roung Policy Match Condions | 521
515
To use a BGP community or extended community as a roung policy match condion, you dene the
community as described in the following secons:
Dening BGP Communies for Use in Roung Policy Match Condions
To create a named BGP community and dene the community members, include the community statement:
[edit policy-options]
community
name
{
invert-match;
members [
community-ids
];
}
name
idenes the community. It can contain leers, numbers, and hyphens (-) and can be up to
255 characters long. To include spaces in the name, enclose the enre name in quotaon marks (“ ”).
community-ids
idenes one or more members of the community. Each community ID consists of two
components, which you specify in the following format:
as-number
:
community-value
;
•
as-number
—AS number of the community member. It can be a value from 0 through 65,535. You can
use the following notaon in specifying the AS number:
• String of digits.
• Asterisk (*)—A wildcard character that matches all AS numbers. (In the denion of the
community aribute, the asterisk also funcons as described in Table 21 on page 518.)
• Period (.)—A wildcard character that matches any single digit in an AS number.
• Group of AS numbers—A single AS number or a group of AS numbers enclosed in parentheses.
Grouping the numbers in this way allows you to perform a common operaon on the group as a
whole and to give the group precedence. The grouped numbers can themselves include regular
expression operators. For more informaon about regular expressions, see "Using UNIX Regular
Expressions in Community Names" on page 518.
•
community-value
—Idener of the community member. It can be a number from 0 through 65,535.
You can use the following notaon in specifying the community ID:
• String of digits.
• Asterisk (*)—A wildcard character that matches all community values. (In the denion of the
community aribute, the asterisk also funcons as described in Table 21 on page 518.)
516
• Period (.)—A wildcard character that matches any single digit in a community value number.
• Group of community value numbers—A single community value number or a group of community
value numbers enclosed in parentheses. Grouping the regular expression in this way allows you to
perform a common operaon on the group as a whole and to give the group precedence. The
grouped path can itself include regular expression operators.
You can also include one of the following well-known community names (dened in RFC 1997,
BGP
Communies Aribute
) in the
community-ids
opon for the members statement. This will tag the routes
you specify in [policy-options policy-statement] with the congured name or community value. In a
separate conguraon, you also need to create a lter for the imported routes in your BGP import
policy.
• no-adverse—Routes in this community name must not be adversed to other BGP peers.
• no-export—Routes in this community must not be adversed outside a BGP confederaon boundary.
A stand alone autonomous system that is not part of a confederaon should be considered a
confederaon itself.
• no-export-subconfed—Routes in this community must not be adversed to external BGP peers,
including peers in other members’ ASs inside a BGP confederaon.
You can include the following IPv6 unicast address community names (dened in RFC 5701, BGP
Communies Aribute) to accommodate IPv6 unicast address specic extended community:
[edit policy-options]
policy-statement send-direct {
term 1 {
then {
community add
community-name
;
community add
community-name
;
community add
community-name
;
accept;
}
}
}
community
community-name
members [ ipv6-target:<
IPv6 unicast address
>:
operator-defined local values
ipv6-
target:<
IPv6 unicast address
>:
operator-defined local values
];
community
community-name
members [ ipv6-origin:<
IPv6 unicast address
>:
operator-defined local values
ipv6-
origin:<
IPv6 unicast address
>:
operator-defined local values
];
community
community-name
members [ ipv6-extended:
type-and-subtype value
:<
IPv6 unicast address
>:
operator-
defined local values
ipv6-extended:
type-and-subtype value
:<
IPv6 unicast address
>:
operator-defined
local values
];
517
ipv6-target
idenes the VPN IPv6 target unicast address used in a policy match.
ipv6-origin
idenes
the source of the IPv6 unicast address in a policy match.
ipv6-extended
idenes the extended format
of the IPv6 unicast address in a policy match.
Using UNIX Regular Expressions in Community Names
When specifying the members of a named BGP community (in the members [
community-ids
] statement),
you can use UNIX-style regular expressions to specify the AS number and the member idener. A
regular expression consists of two components, which you specify in the following format:
term
operator
;
term
idenes the string to match.
operator
species how the term must match. Table 21 on page 518 lists the regular expression
operators supported in community IDs. You place an operator immediately aer
term
with no
intervening space, except for the pipe ( | ) and dash (–) operators, which you place between two terms,
and parentheses, with which you enclose terms. Table 22 on page 520 shows examples of how to
dene
community-ids
using community regular expressions. The operator is oponal.
Community regular expressions are idencal to the UNIX regular expressions. Both implement the
extended (or modern) regular expressions as dened in POSIX 1003.2.
Community regular expressions evaluate the string specied in
term
on a character-by-character basis.
For example, if you specify 1234:5678 as
term
, the regular expressions see nine discrete characters,
including the colon (:), instead of two sets of numbers (1234 and 5678) separated by a colon.
NOTE: In Junos OS Release 9.1 and later, you can specify 4-byte AS numbers as dened in
RFC 4893,
BGP Support for Four-octet AS Number Space
, as well as the 2-byte AS numbers that
are supported in earlier releases of the Junos OS.
Table 21: Community
Aribute Regular Expression Operators
Operator Match Denion
{
m,n
} At least
m
and at most
n
repeons of
term
. Both
m
and
n
must be posive integers, and
m
must be
smaller than
n
.
518
Table 21: Community Aribute Regular Expression Operators
(Connued)
Operator Match Denion
{
m
} Exactly
m
repeons of
term
.
m
must be a posive
integer.
{
m
,}
m
or more repeons of
term
.
m
must be a posive
integer.
* Zero or more repeons of
term
. This is
equivalent to {0,}.
+ One or more repeons of
term
. This is equivalent
to {1,}.
? Zero or one repeon of
term
. This is equivalent
to {0,1}.
|
One of the two terms on either side of the pipe.
–
Between a starng and ending range, inclusive.
^
Character at the beginning of a community
aribute regular expression.
$
Character at the end of a community aribute
regular expression.
[ ]
Set of characters. One character from the set can
match. To specify the start and end of a range,
use a hyphen (-). To specify a set of characters
that do not match, use the caret (^) as the rst
character aer the opening square bracket ([).
519
Table 21: Community Aribute Regular Expression Operators
(Connued)
Operator Match Denion
( )
Group of terms that are enclosed in parentheses.
If enclosed in quotaon marks with no
intervening space ("()" ), indicates a null.
Intervening space between the parentheses and
the terms is ignored.
“ ”
Characters (such as space, tab, queson mark,
and bracket) that are enclosed within quotaon
marks in a community aribute regular
expression indicate special characters.
Table 22: Examples of Community Aribute Regular Expressions
Community Aribute to Match Regular
Expression
Sample
Matches
AS number is 56 or 78. Community value is any number. ^((56) | (78)):(.*)
$
56:1000
78:64500
AS number is 56. Community value is any number that starts with 2. ^56:(2.*)$ 56:2
56:222
56:234
AS number is any number. Community value is any number that ends with 5, 7,
or 9.
^(.*):(.*[579])$ 1234:5
78:2357
34:64509
AS number is 56 or 78. Community value is any number that starts with 2 and
ends with 2 through 8.
^((56) | (78)):
(2.*[2–8])$
56:22
56:21197
78:2678
520
Dening BGP Extended Communies for Use in Roung Policy Match Condions
To create a named BGP community and dene the community members, include the community statement:
[edit policy-options]
community
name
{
members [
community-ids
];
}
name
idenes the community. It can contain leers, numbers, and hyphens (-) and can be up to
255 characters long. To include spaces in the name, enclose the enre name in quotaon marks (“ ”).
community-ids
idenes one or more members of the community. Each community ID consists of three
components, which you specify in the following format:
type
:
administrator
:
assigned-number
type
is the type of extended community and can be either the 16-bit numerical idener of a specic
BGP extended community or one of these types:
• bandwidth—Sets up the bandwidth extended community. Specifying link bandwidth allows you to
distribute trac unequally among dierent BGP paths.
NOTE: The link bandwidth aribute does not work concurrently with per-prex load
balancing.
• domain-id—Idenes the OSPF domain from which the route originated.
• origin—Idenes where the route originated.
• rt-import—Idenes the route to install in the roung table.
NOTE: You must idenfy the route by an IP address, not an AS number.
•
src-as—Idenes the AS from which the route originated. You must specify an AS number, not an IP
address.
NOTE: You must idenfy the AS by an AS number, not an IP address.
521
• target—Idenes the desnaon to which the route is going.
NOTE: For an import policy for a VPN roung and forwarding (VRF) instance, you must
include at least one route target. Addionally, you cannot use wildcard characters or regular
expressions in the route target for a VRF import policy. Each value you congure for a route
target for a VRF import policy must be a single value.
administrator
is the administrator. It is either an AS number or an IP version 4 (IPv4) address prex,
depending on the type of extended community.
assigned-number
idenes the local provider.
In Junos OS Release 9.1 and later, you can specify 4-byte AS numbers as dened in RFC 4893,
BGP
Support for Four-octet AS Number Space
, as well as the 2-byte AS numbers that are supported in earlier
releases of the Junos OS. In plain-number format, you can congure a value in the range from 1
through 4,294,967,295. To congure a target or origin extended community that includes a 4-byte AS
number in the plain-number format, append the leer “L” to the end of number. For example, a target
community with the 4-byte AS number 334,324 and an assigned number of 132 is represented as
target:334324L:132.
NOTE: 4-byte ASes can be specied only as a part of extended communies and hence the leer
‘L’ is not allowed in a base BGP regular expression community. For example, to allow matches
against an extended community, use extended community expressions like origin:334324L:* and
target:334324L:* instead of 334324L:*
In Junos OS Release 9.2 and later, you can also use AS-dot notaon when dening a 4-byte AS number
for the target and origin extended communies. Specify two integers joined by a period:
16-bit high-
order value in decimal
.
16-bit low-order value in decimal
. For example, the 4-byte AS number
represented in plain-number format as 65546 is represented in AS-dot notaon as 1.10.
Examples: Dening BGP Extended Communies
Congure a target community with an administrave eld of 10458 and an assigned number of 20:
[edit policy-options]
community test-a members [ target:10458:20 ];
522
Congure a target community with an administrave eld of 10.1.1.1 and an assigned number of 20:
[edit policy-options]
community test-a members [ target:10.1.1.1:20 ];
Congure an origin community with an administrave eld of 10.1.1.1 and an assigned number of 20:
[edit policy-options]
community test-a members [ origin:10.1.1.1:20 ];
Congure a target community with a 4-byte AS number in the administrave eld of 100000 and an
assigned number of 130:
[edit policy-options]
community test-b members [ target:100000L:130 ];
RELATED DOCUMENTATION
Example: Conguring Communies in a Roung Policy | 530
Example: Conguring Extended Communies in a Roung Policy | 550
How BGP Communies and Extended Communies Are Evaluated in
Roung Policy Match Condions
IN THIS SECTION
Mulple Matches | 525
Inverng Community Matches | 527
Extended Community Type | 527
Mulple Communies Are Matched with Ex-OR Logic | 528
Including BGP Communies and Extended Communies in Roung Policy Match Condions | 529
523
When you use BGP communies and extended communies as match condions in a roung policy, the
policy framework soware evaluates them as follows:
• Each route is evaluated against each named community in a roung policy from statement. If a route
matches one of the named communies in the from statement, the evaluaon of the current term
connues. If a route does not match, the evaluaon of the current term ends.
• The route is evaluated against each member of a named community. The evaluaon of all members
must be successful for the named community evaluaon to be successful.
• Each member in a named community is idened by either a literal community value or a regular
expression. Each member is evaluated against each community associated with the route.
(Communies are an unordered property of a route. For example, 1:2 3:4 is the same as 3:4 1:2.)
Only one community from the route is required to match for the member evaluaon to be successful.
• Community regular expressions are evaluated on a character-by-character basis. For example, if a
route contains community 1234:5678, the regular expressions see nine discrete characters, including
the colon (:), instead of two sets of numbers (1234 and 5678) separated by a colon. For example:
[edit]
policy-options {
policy-statement one {
from {
community [comm-one comm-two];
}
}
community comm-one members [ 1:2 "^4:(5|6)$" ];
community comm-two members [ 7:8 9:10 ];
}
If a community member is a regular expression, a string match is made rather than a numeric match.
For example:
community example1 members 100:100
community example2 members 100:1..
Given a route with a community value of 1100:100, this route matches community example2 but not
example1.
•
To match roung policy one, the route must match either comm-one or comm-two.
• To match comm-one, the route must have a community that matches 1:2 and a community that matches
4:5 or 4:6.
524
• To match comm-two, the route must have a community that matches 7:8 and a community that matches
9:10.
Mulple Matches
When mulple matches are found, label aggregaon does not happen. Consider the following
conguraon:
family inet-vpn {
unicast {
aggregate-label {
community community-name;
}
}
}
family inet-vpn {
labeled-unicast {
aggregate-label {
community community-name;
}
}
}
Suppose, for instance, that two routes are received with community aributes target:65000:1000
origin:65200:2000 and that the community name is "5...:.*". In this case, both the extended community
aributes, target:65000:1000 and origin:65200:2000 match the regular expression of the community name. In
this case, label aggregaon does not occur. In the following example, the Label operation eld shows that
the labels are not aggregated.
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101056
Push 101056
Communities: target:65000:1000 origin:65200:2000
525
You can resolve this issue in either of the following ways:
• Be more specic in the regular expression if the site-of-origin extended community aribute does
not overlap with the target one.
• Specify the site of origin in the community name.
Both methods are shown in the following examples.
Be More Specic in the Regular Expression
user@host# set policy-options community community-name members "52..:.*"
user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
Specify the Site of Origin in the Community Name
user@host# set policy-options community community-name members "origin:65...:.*"
user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
526
Inverng Community Matches
The community match condion denes a regular expression and if it matches the community aribute of
the received prex, Junos OS returns a TRUE result. If not, Junos OS returns a FALSE result. The invert-
match statement makes Junos OS behave to the contrary. If there is a match, Junos OS returns a FALSE
result. If there is no match, Junos OS returns a TRUE result. To invert the results of the community
expression matching, include the invert-match statement in the community conguraon.
[edit policy-options community
name
]
invert-match;
Extended Community Type
The extended community type is not taken into account by regular expressions. Consider, for instance,
the following community aributes and community name.
Communies:
• 5200:1000
• target:65000:1000
• origin:65200:2000
Community aribute:
• community-name members "5...:.*"
In this case, both extended community aribute, 5200:1000 and the extended community aribute,
origin:65200:2000, match the regular expression of the community name. Therefore, the label aggregaon
does not occur, as shown here:
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: 5200:1000 target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101056
Push 101056
Communities: 5200:1000 target:65000:1000 origin:65200:2000
527
You can resolve this issue by using a more specic regular expression. For example, you can use the
anchor character (^) to bind the locaon of the digits, as shown here:
user@host# set policy-options community community-name members "^5...:.*"
user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: 5200:1000 target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: 5200:1000 target:65000:1000 origin:65200:2000
NOTE: With the implementaon of the large community feature in release 17.3, Junos OS
checks to prevent the matching of extended or large communies against base BGP or base BGP
regular expression communies. In other words, a received community can only be matched
against the appropriate wild community paern, like normal communies against simple-wild,
extended communies against extended-wild and large communies against large-wild paerns.
For example, to allow the adversement of routes carrying the origin extended community, use
the origin:*:65020 expression.
Mulple Communies Are Matched with Ex-OR Logic
This diers from the AND matching logic used for non-extended communies in BGP.
If, for instance, four routes are received with two sets of community aributes, the regular expression
might match both community aributes. Consider the following example:
• Communies—5200:1000 target:65000:1000
• Communies—target:65000:1000 origin:65200:2000
• Community aribute—community community-name member [ "^5...:.*" origin:65.*:.* ]
528
Both labels are aggregated, as shown here:
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.16/30 (1 entry, 1 announced)
Label operation: Push 121104
Push 101104
Communities: 5200:1000 target:65000:1000
10.1.1.20/30 (1 entry, 1 announced)
Label operation: Push 121104
Push 101104
Communities: 5200:1000 target:65000:1000
A more complete example of community values is shown here:
user@host> show policy-options community community-name
members [ "(^1...:*)|(^3...:*)|(^4...:*)" origin:2.*:* origin:3.*:* origin:6.*:* ]
This regular expression matches community values starng with 1, 3, or 4, and matches extended
community values of type origin whose administrave value starts with 2, 3, or 6.
Including BGP Communies and Extended Communies in Roung Policy Match
Condions
To include a BGP community or extended community in a roung policy match condion, include the
community condion in the from statement of a policy term:
from {
community [
names
];
}
529
Addionally, you can explicitly exclude BGP community informaon with a stac route by using the none
opon. Include this opon when conguring an individual route in the route poron to override a
community opon specied in the defaults poron.
You can include the names of mulple communies in the community match condion. If you do this, only
one community needs to match for a match to occur (matching is eecvely a logical OR operaon).
RELATED DOCUMENTATION
Using UNIX Regular Expressions in Community Names | 518
Example: Conguring Communies in a Roung Policy | 530
Example: Conguring Extended Communies in a Roung Policy | 550
Example: Conguring a Roung Policy That Removes BGP Communies | 585
Example: Conguring a Roung Policy Based on the Number of BGP Communies | 574
Example: Conguring Communies in a Roung Policy
IN THIS SECTION
Requirements | 530
Overview | 531
Conguraon | 533
Vericaon | 545
A community is a route aribute used by BGP to administravely group routes with similar properes.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
• Updated and revalidated using vMX on Junos OS Release 21.1R1.
530
Overview
IN THIS SECTION
Topology | 532
One main role of the community aribute is to be an administrave tag value used to associate routes
together. Generally, these routes share some common properes, but that is not required. Communies
are a exible tool within BGP. An individual community value can be assigned to a single route or
mulple routes. A route can be assigned a single community value or mulple values. Networks use the
community aribute to assist in implemenng administrave roung policies. A route’s assigned value
can allow it to be accepted into the network, or rejected from the network, or allow it to modify
aributes.
Figure 32 on page 532 shows device R1, device R2, and device R3 as internal BGP (IBGP) peers in
autonomous system (AS) 64510. Device R4 is adversing the 172.16.0.0/21 address space from AS
64511.
531
Topology
Figure 32: Topology for Regular BGP Communies
The
specic routes received by device R1 from device R4 are as follows:
user@R1> show route receive-protocol bgp 10.0.0.13
inet.0: 24 destinations, 28 routes (24 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.0.0/24 10.0.0.13 64511 I
* 172.16.1.0/24 10.0.0.13 64511 I
* 172.16.2.0/24 10.0.0.13 64511 I
* 172.16.3.0/24 10.0.0.13 64511 I
172.16.4.0/24 10.0.0.13 64511 I
172.16.5.0/24 10.0.0.13 64511 I
172.16.6.0/24 10.0.0.13 64511 I
172.16.7.0/24 10.0.0.13 64511 I
The administrators of AS 64511 want to receive certain user trac from device R1, and other user
trac from device R3. To accomplish this administrave goal, device R4 aaches the community value
532
of 64511:1 to some routes that it sends and aaches the community value 64511:3 to other routes that
it sends. Roung policies within AS 64510 are congured using a community match criterion to change
the local preference of the received routes to new values that alter the BGP route selecon algorithm.
The route with the highest local preference value is preferred.
On device R1, routes with the 64511:1 community value are assigned a local preference of 200, and
routes with the 64511:3 community value are assigned a local preference of 50. On device R3, the
reverse is done so that routes with the 64511:3 community value are assigned a local preference of 200,
and routes with the 64511:1 community value are assigned a local preference of 50. This informaon is
then communicated through IBGP by both device R1 and device R3 to device R2.
"CLI Quick Conguraon" on page 533 shows the conguraon for all of the devices in Figure 32 on
page 532.
The secon "Step By Step Conguraon" on page 536 describes the conguraon steps on devices R1
and R4.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 533
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30
set interfaces ge-0/0/1 unit 0 family inet address 10.1.0.5/30
set interfaces ge-0/0/2 unit 0 family inet address 10.0.0.14/30
set interfaces lo0 unit 0 family inet address 192.168.0.1/32
set policy-options policy-statement change-local-preference term find-R1-routes from community
R1_PREFERRED
set policy-options policy-statement change-local-preference term find-R1-routes then local-
preference 200
set policy-options policy-statement change-local-preference term find-R3-routes from community
533
R3_PREFERRED
set policy-options policy-statement change-local-preference term find-R3-routes then local-
preference 50
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 from route-filter 10.0.0.12/30 exact
set policy-options policy-statement send-direct term 1 then accept
set policy-options community R3_PREFERRED members 64511:3
set policy-options community R1_PREFERRED members 64511:1
set protocols bgp group int type internal
set protocols bgp group int local-address 192.168.0.1
set protocols bgp group int export send-direct
set protocols bgp group int neighbor 192.168.0.2
set protocols bgp group int neighbor 192.168.0.3
set protocols bgp group ext type external
set protocols bgp group ext import change-local-preference
set protocols bgp group ext peer-as 64511
set protocols bgp group ext neighbor 10.0.0.13
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 64510
Device R2
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/30
set interfaces ge-0/0/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
set protocols bgp group int neighbor 192.168.0.3
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-options router-id 192.168.0.2
set routing-options autonomous-system 64510
534
Device R3
set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.6/30
set interfaces ge-0/0/1 unit 0 family inet address 10.1.0.2/30
set interfaces ge-0/0/2 unit 0 family inet address 10.0.0.10/30
set interfaces lo0 unit 0 family inet address 192.168.0.3/32
set policy-options policy-statement change-local-preference term find-R3-routes from community
R3_PREFERRED
set policy-options policy-statement change-local-preference term find-R3-routes then local-
preference 200
set policy-options policy-statement change-local-preference term find-R1-routes from community
R1_PREFERRED
set policy-options policy-statement change-local-preference term find-R1-routes then local-
preference 50
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 from route-filter 10.0.0.8/30 exact
set policy-options policy-statement send-direct term 1 then accept
set policy-options community R1_PREFERRED members 64511:1
set policy-options community R3_PREFERRED members 64511:3
set protocols bgp group int type internal
set protocols bgp group int local-address 192.168.0.3
set protocols bgp group int export send-direct
set protocols bgp group int neighbor 192.168.0.1
set protocols bgp group int neighbor 192.168.0.2
set protocols bgp group ext type external
set protocols bgp group ext import change-local-preference
set protocols bgp group ext peer-as 64511
set protocols bgp group ext neighbor 10.0.0.9
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-options router-id 192.168.0.3
set routing-options autonomous-system 64510
Device R4
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.13/30
set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.9/30
set interfaces lo0 unit 0 family inet address 192.168.0.4/32
535
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 from route-filter 172.16.0.0/24 exact
set policy-options policy-statement send-static term 1 from route-filter 172.16.1.0/24 exact
set policy-options policy-statement send-static term 1 from route-filter 172.16.2.0/24 exact
set policy-options policy-statement send-static term 1 from route-filter 172.16.3.0/24 exact
set policy-options policy-statement send-static term 1 then community add R1_PREFERRED
set policy-options policy-statement send-static term 1 then accept
set policy-options policy-statement send-static term 2 from protocol static
set policy-options policy-statement send-static term 2 from route-filter 172.16.4.0/24 exact
set policy-options policy-statement send-static term 2 from route-filter 172.16.5.0/24 exact
set policy-options policy-statement send-static term 2 from route-filter 172.16.6.0/24 exact
set policy-options policy-statement send-static term 2 from route-filter 172.16.7.0/24 exact
set policy-options policy-statement send-static term 2 then community add R3_PREFERRED
set policy-options policy-statement send-static term 2 then accept
set policy-options policy-statement send-static term 3 then reject
set policy-options community R3_PREFERRED members 64511:3
set policy-options community R1_PREFERRED members 64511:1
set protocols bgp group to-R1 type external
set protocols bgp group to-R1 export send-static
set protocols bgp group to-R1 peer-as 64510
set protocols bgp group to-R1 neighbor 10.0.0.14
set protocols bgp group to-R3 type external
set protocols bgp group to-R3 export send-static
set protocols bgp group to-R3 peer-as 64510
set protocols bgp group to-R3 neighbor 10.0.0.10
set routing-options router-id 192.168.0.4
set routing-options autonomous-system 64511
set routing-options static route 172.16.0.0/24 reject
set routing-options static route 172.16.1.0/24 reject
set routing-options static route 172.16.2.0/24 reject
set routing-options static route 172.16.3.0/24 reject
set routing-options static route 172.16.4.0/24 reject
set routing-options static route 172.16.5.0/24 reject
set routing-options static route 172.16.6.0/24 reject
set routing-options static route 172.16.7.0/24 reject
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in
the Junos OS CLI User Guide.
536
To congure device R1:
1. Congure the interfaces.
[edit interfaces]
user@R1# set ge-0/0/0 unit 0 family inet address 10.0.0.1/30
user@R1# set ge-0/0/1 unit 0 family inet address 10.1.0.5/30
user@R1# set ge-0/0/2 unit 0 family inet address 10.0.0.14/30
user@R1# set lo0 unit 0 family inet address 192.168.0.1/32
2. Congure internal gateway protocol (IGP) connecons to devices R2 and R3.
[edit protocols ospf area 0.0.0.0]
user@R1# set interface ge-0/0/0.0
user@R1# set interface ge-0/0/1.0
user@R1# set interface lo0.0 passive
3. Congure the IBGP connecons to devices R2 and R3.
[edit protocols bgp group int]
user@R1# set type internal
user@R1# set local-address 192.168.0.1
user@R1# set export send-direct
user@R1# set neighbor 192.168.0.2
user@R1# set neighbor 192.168.0.3
4. Congure the EBGP connecon to device R4.
[edit protocols bgp group ext]
user@R1# set type external
user@R1# set import change-local-preference
user@R1# set peer-as 64511
user@R1# set neighbor 10.0.0.13
5. Congure the policy send-direct.
537
This policy is referenced in the IBGP conguraon and enables device R2 to have external
reachability. An alternave is to congure a next-hop self policy on device R1 and device R3.
[edit policy-options policy-statement send-direct term 1]
user@R1# set from protocol direct
user@R1# set from route-filter 10.0.0.12/30 exact
user@R1# set then accept
6. Congure the policy that changes the local preference for routes with specied community tags.
[edit policy-options ]
user@R1# set policy-statement change-local-preference term find-R1-routes from community
R1_PREFERRED
user@R1# set policy-statement change-local-preference term find-R1-routes then local-
preference 200
user@R1# set policy-statement change-local-preference term find-R3-routes from community
R3_PREFERRED
user@R1# set policy-statement change-local-preference term find-R3-routes then local-
preference 50
user@R1# set community R3_PREFERRED members 64511:3
user@R1# set community R1_PREFERRED members 64511:1
7. Congure the autonomous system (AS) number and router ID.
[edit routing-options]
user@R1# set router-id 192.168.0.1
user@R1# set autonomous-system 64510
To congure device R4:
1. Congure the interfaces.
[edit interfaces]
user@R4# set ge-0/0/0 unit 0 family inet address 10.0.0.13/30
user@R4# set ge-0/0/1 unit 0 family inet address 10.0.0.9/30
user@R4# set lo0 unit 0 family inet address 192.168.0.4/32
538
2. Congure the EBGP connecon to device R1 and device R3.
[edit protocols bgp]
user@R4# set group to-R1 type external
user@R4# set group to-R1 export send-static
user@R4# set group to-R1 peer-as 64510
user@R4# set group to-R1 neighbor 10.0.0.14
user@R4# set group to-R3 type external
user@R4# set group to-R3 export send-static
user@R4# set group to-R3 peer-as 64510
user@R4# set group to-R3 neighbor 10.0.0.10
3. Congure the community tags.
[edit policy-options ]
user@R4# set community R3_PREFERRED members 64511:3
user@R4# set community R1_PREFERRED members 64511:1
4. Congure the policy send-static.
This policy is referenced in the EBGP connecons to device R1 and device R3. The policy aaches
the 64511:1 (PREFERRED) community to some routes and the 64511:3 (NOT_PREFERRED)
community to other routes.
[edit policy-options]
user@R4# set policy-statement send-static term 1 from protocol static
user@R4# set policy-statement send-static term 1 from route-filter 172.16.0.0/24 exact
user@R4# set policy-statement send-static term 1 from route-filter 172.16.1.0/24 exact
user@R4# set policy-statement send-static term 1 from route-filter 172.16.2.0/24 exact
user@R4# set policy-statement send-static term 1 from route-filter 172.16.3.0/24 exact
user@R4# set policy-statement send-static term 1 then community add R1_PREFERRED
user@R4# set policy-statement send-static term 1 then accept
user@R4# set policy-statement send-static term 2 from protocol static
user@R4# set policy-statement send-static term 2 from route-filter 172.16.4.0/24 exact
user@R4# set policy-statement send-static term 2 from route-filter 172.16.5.0/24 exact
user@R4# set policy-statement send-static term 2 from route-filter 172.16.6.0/24 exact
user@R4# set policy-statement send-static term 2 from route-filter 172.16.7.0/24 exact
user@R4# set policy-statement send-static term 2 then community add R3_PREFERRED
user@R4# set policy-statement send-static term 2 then accept
user@R4# set policy-statement send-static term 3 then reject
539
5. Congure the stac routes.
[edit routing-options static]
user@R4# set route 172.16.0.0/24 reject
user@R4# set route 172.16.1.0/24 reject
user@R4# set route 172.16.2.0/24 reject
user@R4# set route 172.16.3.0/24 reject
user@R4# set route 172.16.4.0/24 reject
user@R4# set route 172.16.5.0/24 reject
user@R4# set route 172.16.6.0/24 reject
user@R4# set route 172.16.7.0/24 reject
6. Congure the autonomous system (AS) number and router ID.
[edit routing-options]
user@R4# set router-id 192.168.0.4
user@R4# set autonomous-system 64511
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
Device R1
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.0.1/30;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.1.0.5/30;
}
}
540
}
ge-0/0/2 {
unit 0 {
family inet {
address 10.0.0.14/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 send-direct;
neighbor 192.168.0.2;
neighbor 192.168.0.3;
}
group ext {
type external;
import change-local-preference;
peer-as 64511;
neighbor 10.0.0.13;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface lo0.0 {
passive;
}
541
}
}
user@R1# show policy-options
policy-statement change-local-preference {
term find-R1-routes {
from community R1_PREFERRED;
then {
local-preference 200;
}
}
term find-R3-routes {
from community R3_PREFERRED;
then {
local-preference 50;
}
}
}
policy-statement send-direct {
term 1 {
from {
protocol direct;
route-filter 10.0.0.12/30 exact;
}
then accept;
}
}
community R3_PREFERRED members 64511:3;
community R1_PREFERRED members 64511:1;
user@R1# show routing-options
router-id 192.168.0.1;
autonomous-system 64510;
Device R4
user@R4# show interfaces
ge-0/0/0 {
unit 0 {
542
family inet {
address 10.0.0.13/30;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.0.0.9/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.4/32;
}
}
}
user@R4# show protocols
bgp {
group to-R1 {
type external;
export send-static;
peer-as 64510;
neighbor 10.0.0.14;
}
group to-R3 {
type external;
export send-static;
peer-as 64510;
neighbor 10.0.0.10;
}
}
user@R4# show policy-options
policy-statement send-static {
term 1 {
from {
543
protocol static;
route-filter 172.16.0.0/24 exact;
route-filter 172.16.1.0/24 exact;
route-filter 172.16.2.0/24 exact;
route-filter 172.16.3.0/24 exact;
}
then {
community add R1_PREFERRED;
accept;
}
}
term 2 {
from {
protocol static;
route-filter 172.16.4.0/24 exact;
route-filter 172.16.5.0/24 exact;
route-filter 172.16.6.0/24 exact;
route-filter 172.16.7.0/24 exact;
}
then {
community add R3_PREFERRED;
accept;
}
}
term 3 {
then reject;
}
}
community R3_PREFERRED members 64511:3;
community R1_PREFERRED members 64511:1;
user@R4# show routing-options
router-id 192.168.0.4;
autonomous-system 64511;
static {
route 172.16.0.0/24 reject;
route 172.16.1.0/24 reject;
route 172.16.2.0/24 reject;
route 172.16.3.0/24 reject;
route 172.16.4.0/24 reject;
route 172.16.5.0/24 reject;
544
route 172.16.6.0/24 reject;
route 172.16.7.0/24 reject;
}
If you are done conguring the devices, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Routes Sent on Device R4 | 545
Verifying the Routes Received on Device R2 | 548
Conrm that the conguraon is working properly.
Verifying the Routes Sent on Device R4
Purpose
On device R4, check the routes sent to device R1 and device R3.
Acon
user@R4> show route advertising-protocol bgp 10.0.0.14 extensive
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
* 172.16.0.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
* 172.16.1.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
545
* 172.16.2.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
* 172.16.3.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
* 172.16.4.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
* 172.16.5.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
* 172.16.6.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
* 172.16.7.0/24 (1 entry, 1 announced)
BGP group to-R1 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
user@R4> show route advertising-protocol bgp 10.0.0.10 extensive
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
546
* 172.16.0.0/24 (1 entry, 1 announced)
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
* 172.16.1.0/24 (1 entry, 1 announced)
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
* 172.16.2.0/24 (1 entry, 1 announced)
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
* 172.16.3.0/24 (1 entry, 1 announced)
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:1
* 172.16.4.0/24 (1 entry, 1 announced)
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
* 172.16.5.0/24 (1 entry, 1 announced)
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
* 172.16.6.0/24 (1 entry, 1 announced)
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
* 172.16.7.0/24 (1 entry, 1 announced)
547
BGP group to-R3 type External
Nexthop: Self
AS path: [64511] I
Communities: 64511:3
Meaning
Device R4 has tagged the routes with the communies 64511:1 and 64511:3 and sent them to device
R1 and R3.
Verifying the Routes Received on Device R2
Purpose
On device R2, check the routes received from device R1 and device R3.
Acon
user@R2> show route receive-protocol bgp 192.168.0.1
inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.12/30 192.168.0.1 100 I
* 172.16.0.0/24 10.0.0.13 200 64511 I
* 172.16.1.0/24 10.0.0.13 200 64511 I
* 172.16.2.0/24 10.0.0.13 200 64511 I
* 172.16.3.0/24 10.0.0.13 200 64511 I
user@R2> show route receive-protocol bgp 192.168.0.3
inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.8/30 192.168.0.3 100 I
* 172.16.4.0/24 10.0.0.9 200 64511 I
* 172.16.5.0/24 10.0.0.9 200 64511 I
548
* 172.16.6.0/24 10.0.0.9 200 64511 I
* 172.16.7.0/24 10.0.0.9 200 64511 I
user@R2> show route match-prefix 172.16.*
inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/24 *[BGP/170] 1w3d 00:02:11, localpref 200, from 192.168.0.1
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via ge-0/0/0.0
172.16.1.0/24 *[BGP/170] 1w3d 00:02:11, localpref 200, from 192.168.0.1
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via ge-0/0/0.0
172.16.2.0/24 *[BGP/170] 1w3d 00:02:11, localpref 200, from 192.168.0.1
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via ge-0/0/0.0
172.16.3.0/24 *[BGP/170] 1w3d 00:02:11, localpref 200, from 192.168.0.1
AS path: 64511 I, validation-state: unverified
> to 10.0.0.1 via ge-0/0/0.0
172.16.4.0/24 *[BGP/170] 1w3d 00:01:50, localpref 200, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.1.0.2 via ge-0/0/1.0
172.16.5.0/24 *[BGP/170] 1w3d 00:01:50, localpref 200, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.1.0.2 via ge-0/0/1.0
172.16.6.0/24 *[BGP/170] 1w3d 00:01:50, localpref 200, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.1.0.2 via ge-0/0/1.0
172.16.7.0/24 *[BGP/170] 1w3d 00:01:50, localpref 200, from 192.168.0.3
AS path: 64511 I, validation-state: unverified
> to 10.1.0.2 via ge-0/0/1.0
Meaning
Device R2 has the routes with the expected local preferences and the expected acve routes, as
designated by the asterisks (*).
Example: Conguring a Roung Policy Based on the Number of BGP Communies
549
RELATED DOCUMENTATION
Example: Conguring Extended Communies in a Roung Policy | 550
No Link Title
No Link Title
Example: Conguring a Roung Policy to Redistribute BGP Routes with a Specic Community Tag
into IS-IS
Example: Conguring Extended Communies in a Roung Policy
IN THIS SECTION
Requirements | 550
Overview | 550
Conguraon | 552
Vericaon | 557
An extended community is similar in most ways to a regular community. Some networking
implementaons, such as virtual private networks (VPNs), use extended communies because the 4-
octet regular community value does not provide enough expansion and exibility. An extended
community is an eight-octet value divided into two main secons.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 551
In this example, Device R1 and Device R2 are OSPF neighbors in autonomous system (AS) 64510.
Device R3 has an external BGP (EBGP) connecon to Device R1. Device R2 has customer networks in
550
the 172.16/16 address space, simulated with addresses on its loopback interface (lo0). Device R1 has
stac routes to several 172.16.
x
/24 networks, and aaches regular community values to these routes.
Device R1 then uses an export policy to adverse the routes to Device R3. Device R3 receives these
routes and uses an import policy to add extended community values to the routes.
NOTE: For a list of supported extended communies,
see Understanding BGP Communies, Extended Communies, and Large Communies as
Roung Policy Match Condions.
Topology
Figure 33 on page 551 shows the sample network.
Figure 33: Topology for Extended BGP Communies
551
"CLI Quick Conguraon" on page 552 shows the conguraon for all of the devices in Figure 33 on
page 551.
The secon "No Link Title" on page 554 describes the steps on Device R3.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 552
Procedure | 554
CLI Quick
Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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 fe-1/2/3 unit 0 family inet address 10.0.0.14/30
set interfaces lo0 unit 0 family inet address 192.168.0.1/32 primary
set protocols bgp group ext type external
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 64511
set protocols bgp group ext neighbor 10.0.0.13
set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 172.16.1.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.1.0/24 community 64510:1
set routing-options static route 172.16.2.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.2.0/24 community 64510:2
set routing-options static route 172.16.3.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.3.0/24 community 64510:3
set routing-options static route 172.16.4.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.4.0/24 community 64510:4
552
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 family inet address 10.0.0.2/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set interfaces lo0 unit 0 family inet address 172.16.1.1/32
set interfaces lo0 unit 0 family inet address 172.16.2.2/32
set interfaces lo0 unit 0 family inet address 172.16.3.3/32
set interfaces lo0 unit 0 family inet address 172.16.4.4/32
set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-options router-id 192.168.0.2
set routing-options autonomous-system 64510
Device R3
set interfaces fe-1/2/3 unit 0 family inet address 10.0.0.13/30
set interfaces lo0 unit 0 family inet address 192.168.0.3/32
set protocols bgp group to-R1 type external
set protocols bgp group to-R1 import set-ext-comms
set protocols bgp group to-R1 peer-as 64510
set protocols bgp group to-R1 neighbor 10.0.0.14
set policy-options policy-statement set-ext-comms term route-1 from route-filter 172.16.1.0/24
exact
set policy-options policy-statement set-ext-comms term route-1 then community add target-as
set policy-options policy-statement set-ext-comms term route-1 then accept
set policy-options policy-statement set-ext-comms term route-2 from route-filter 172.16.2.0/24
exact
set policy-options policy-statement set-ext-comms term route-2 then community add target-ip
set policy-options policy-statement set-ext-comms term route-2 then accept
set policy-options policy-statement set-ext-comms term route-3 from route-filter 172.16.3.0/24
exact
set policy-options policy-statement set-ext-comms term route-3 then community add origin-as
set policy-options policy-statement set-ext-comms term route-3 then accept
set policy-options policy-statement set-ext-comms term route-4 from route-filter 172.16.4.0/24
exact
set policy-options policy-statement set-ext-comms term route-4 then community add origin-ip
set policy-options policy-statement set-ext-comms term route-4 then accept
set policy-options community origin-as members origin:64511:3
553
set policy-options community origin-ip members origin:172.16.7.7:4
set policy-options community target-as members target:64511:1
set policy-options community target-ip members target:172.16.7.7:2
set routing-options router-id 192.168.0.3
set routing-options autonomous-system 64511
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in
the Junos OS CLI User Guide.
To congure Device R3:
1. Congure the interfaces.
[edit interfaces]
user@R3# set fe-1/2/3 unit 0 family inet address 10.0.0.13/30
user@R3# set lo0 unit 0 family inet address 192.168.0.3/32
2. Congure the EBGP connecon to Device R1.
[edit protocols bgp group to-R1]
user@R3# set type external
user@R3# set import set-ext-comms
user@R3# set peer-as 64510
user@R3# set neighbor 10.0.0.14
3. Congure the policy that adds extended community values to the routes received from Device R1.
An extended community uses a notaon of
type
:
administrator
:
assigned-number
.
The specic community values can be anything that accomplishes your administrave goals, within
certain parameters, as explained in
community (Policy Opons)
.
[edit policy-options policy-statement set-ext-comms]
user@R3# set term route-1 from route-filter 172.16.1.0/24 exact
user@R3# set term route-1 then community add target-as
user@R3# set term route-1 then accept
554
user@R3# set term route-2 from route-filter 172.16.2.0/24 exact
user@R3# set term route-2 then community add target-ip
user@R3# set term route-2 then accept
user@R3# set term route-3 from route-filter 172.16.3.0/24 exact
user@R3# set term route-3 then community add origin-as
user@R3# set term route-3 then accept
user@R3# set term route-4 from route-filter 172.16.4.0/24 exact
user@R3# set term route-4 then community add origin-ip
user@R3# set term route-4 then accept
[edit policy-options]
user@R3# set community origin-as members origin:64511:3
user@R3# set community origin-ip members origin:172.16.7.7:4
user@R3# set community target-as members target:64511:1
user@R3# set community target-ip members target:172.16.7.7:2
4. Congure the autonomous system (AS) number and router ID.
[edit routing-options]
user@R3# set router-id 192.168.0.3
user@R3# set autonomous-system 64511
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R3# show interfaces
fe-1/2/3 {
unit 0 {
family inet {
address 10.0.0.13/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.3/32;
}
555
}
}
user@R3# show protocols
bgp {
group to-R1 {
type external;
import set-ext-comms;
peer-as 64510;
neighbor 10.0.0.14;
}
}
user@R3# show policy-options
policy-statement set-ext-comms {
term route-1 {
from {
route-filter 172.16.1.0/24 exact;
}
then {
community add target-as;
accept;
}
}
term route-2 {
from {
route-filter 172.16.2.0/24 exact;
}
then {
community add target-ip;
accept;
}
}
term route-3 {
from {
route-filter 172.16.3.0/24 exact;
}
then {
community add origin-as;
accept;
556
}
}
term route-4 {
from {
route-filter 172.16.4.0/24 exact;
}
then {
community add origin-ip;
accept;
}
}
}
community origin-as members origin:64511:3;
community origin-ip members origin:172.16.7.7:4;
community target-as members target:64511:1;
community target-ip members target:172.16.7.7:2;
user@R3# show routing-options
router-id 192.168.0.3;
autonomous-system 64511;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the Routes on Device R1 | 557
Verifying the Routes on Device R3 | 559
Conrm that the conguraon is working properly.
Verifying the Routes on Device R1
Purpose
On Device R1, check the 172.16. routes in the roung table.
557
Acon
user@R1> show route protocol static match-prefix 172.16.* detail
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
172.16.1.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 835
Address: 0x9260250
Next-hop reference count: 19
Next hop: 10.0.0.2 via fe-1/2/0.0, selected
State: <Active Int Ext>
Local AS: 64510
Age: 2:06:08
Task: RT
Announcement bits (2): 2-KRT 3-BGP_RT_Background
AS path: I
Communities: 64510:1
172.16.2.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 835
Address: 0x9260250
Next-hop reference count: 19
Next hop: 10.0.0.2 via fe-1/2/0.0, selected
State: <Active Int Ext>
Local AS: 64510
Age: 2:06:08
Task: RT
Announcement bits (2): 2-KRT 3-BGP_RT_Background
AS path: I
Communities: 64510:2
172.16.3.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 835
Address: 0x9260250
Next-hop reference count: 19
Next hop: 10.0.0.2 via fe-1/2/0.0, selected
State: <Active Int Ext>
Local AS: 64510
Age: 2:06:08
558
Task: RT
Announcement bits (2): 2-KRT 3-BGP_RT_Background
AS path: I
Communities: 64510:3
172.16.4.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 835
Address: 0x9260250
Next-hop reference count: 19
Next hop: 10.0.0.2 via fe-1/2/0.0, selected
State: <Active Int Ext>
Local AS: 64510
Age: 2:06:08
Task: RT
Announcement bits (2): 2-KRT 3-BGP_RT_Background
AS path: I
Communities: 64510:4
Meaning
The output shows that the regular community values are aached to the routes.
NOTE: The communies are aached to stac routes, thus demonstrang that communies can
be aached to non-BGP routes.
Verifying the Routes on Device R3
Purpose
On Device R3, check the 172.16. routes in the roung table.
Acon
user@R3> show route protocol bgp match-prefix 172.16.* detail
betsy@tp5# run show route protocol bgp match-prefix 172.16.* detail logical-system R3
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
172.16.1.0/24 (1 entry, 1 announced)
559
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 611
Address: 0x9260130
Next-hop reference count: 8
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
State: <Active Ext>
Local AS: 64511 Peer AS: 64510
Age: 1:57:27
Task: BGP_64510.10.0.0.14+54618
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:1 target:64511:1
Accepted
Localpref: 100
Router ID: 192.168.0.1
172.16.2.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 611
Address: 0x9260130
Next-hop reference count: 8
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
State: <Active Ext>
Local AS: 64511 Peer AS: 64510
Age: 1:57:27
Task: BGP_64510.10.0.0.14+54618
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:2 target:172.16.7.7:2
Accepted
Localpref: 100
Router ID: 192.168.0.1
172.16.3.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 611
Address: 0x9260130
Next-hop reference count: 8
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
State: <Active Ext>
560
Local AS: 64511 Peer AS: 64510
Age: 1:57:27
Task: BGP_64510.10.0.0.14+54618
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:3 origin:64511:3
Accepted
Localpref: 100
Router ID: 192.168.0.1
172.16.4.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 611
Address: 0x9260130
Next-hop reference count: 8
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
State: <Active Ext>
Local AS: 64511 Peer AS: 64510
Age: 1:57:27
Task: BGP_64510.10.0.0.14+54618
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:4 origin:172.16.7.7:4
Accepted
Localpref: 100
Router ID: 192.168.0.1
Meaning
The output shows that the regular community values remain aached to the routes, and the extended
community values are added.
RELATED DOCUMENTATION
Example: Conguring Communies in a Roung Policy | 530
No Link Title
No Link Title
Example: Conguring a Roung Policy to Redistribute BGP Routes with a Specic Community Tag
into IS-IS
561
Example: Conguring BGP Large Communies
IN THIS SECTION
Requirements | 562
Overview | 562
Conguraon | 563
Vericaon | 569
This example shows you to congure oponal transive path aribute - a 12-byte BGP large community
that provides the most signicant 4-byte value to encode autonomous system number as the global
administrator and the remaining two 4-byte assigned numbers to encode the local values as dened in
RFC 8092. You can congure BGP large community at [edit policy-options community
community-name
members]
and [edit routing-options static route
ip-address
community] hierarchy levels. The BGP large community
aributes format has four elds: large:
global administrator
:
assigned number
:
assigned number
.
Requirements
This example uses the following hardware and soware components:
• Three MX Series routers
• Junos OS Release 17.3 or later running on all devices
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 563
In this example, Device R1 and Device R2 are OSPF neighbors in autonomous system (AS) 64510.
Device R3 has an external BGP (EBGP) connecon to Device R1. Device R2 has customer networks in
the 172.16/16 address space, simulated with addresses on its loopback interface (lo0). Device R1 has
stac routes to several 172.16.x/24 networks, and aaches regular community values to these routes.
562
Device R1 then uses an export policy to adverse the routes to Device R3. Device R3 receives these
routes and uses an import policy to add large community values to the routes.
Topology
Figure 1 shows the sample network.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 564
Procedure | 565
Results | 567
563
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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 fe-1/2/3 unit 0 family inet address 10.0.0.14/30
set interfaces lo0 unit 0 family inet address 192.168.0.1/32 primary
set routing-options static route 172.16.1.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.1.0/24 community 64510:1
set routing-options static route 172.16.1.0/24 community large:64510:100:1
set routing-options static route 172.16.2.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.2.0/24 community 64510:2
set routing-options static route 172.16.2.0/24 community large:64510:200:2
set routing-options static route 172.16.3.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.3.0/24 community 64510:3
set routing-options static route 172.16.4.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.4.0/24 community 64510:4
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 64510
set protocols bgp group ext type external
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 64511
set protocols bgp group ext neighbor 10.0.0.13
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
Device R2
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set interfaces lo0 unit 0 family inet address 172.16.1.1/32
set interfaces lo0 unit 0 family inet address 172.16.2.2/32
set interfaces lo0 unit 0 family inet address 172.16.3.3/32
set interfaces lo0 unit 0 family inet address 172.16.4.4/32
set routing-options router-id 192.168.0.2
564
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
Device R3
set interfaces fe-1/2/3 unit 0 family inet address 10.0.0.13/30
set interfaces lo0 unit 0 family inet address 192.168.0.3/32
set routing-options router-id 192.168.0.3
set routing-options autonomous-system 64511
set protocols bgp group to-R1 type external
set protocols bgp group to-R1 import set-large-comms
set protocols bgp group to-R1 peer-as 64510
set protocols bgp group to-R1 neighbor 10.0.0.14
set policy-options policy-statement set-large-comms term route-1 from route-filter 172.16.1.0/24
exact
set policy-options policy-statement set-large-comms term route-1 then community add large2-as
set policy-options policy-statement set-large-comms term route-1 then accept
set policy-options policy-statement set-large-comms term route-2 from route-filter 172.16.2.0/24
exact
set policy-options policy-statement set-large-comms term route-2 then community add large2-ip
set policy-options policy-statement set-large-comms term route-2 then accept
set policy-options policy-statement set-large-comms term route-3 from route-filter 172.16.3.0/24
exact
set policy-options policy-statement set-large-comms term route-3 then community add large1-as
set policy-options policy-statement set-large-comms term route-3 then accept
set policy-options policy-statement set-large-comms term route-4 from route-filter 172.16.4.0/24
exact
set policy-options policy-statement set-large-comms term route-4 then community add large1-ip
set policy-options policy-statement set-large-comms term route-4 then accept
set policy-options community large1-as members large:64511:3:1
set policy-options community large1-ip members large:7777:4:1
set policy-options community large2-as members large:64511:1:1
set policy-options community large2-ip members large:7777:2:1
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in
the Junos OS CLI User Guide.
565
To congure Device R3:
1. Congure the interfaces.
[edit interfaces]
set fe-1/2/3 unit 0 family inet address 10.0.0.13/30
set lo0 unit 0 family inet address 192.168.0.3/32
2. Congure the autonomous system (AS) number and router ID.
[edit routing-options]
set router-id 192.168.0.3
set autonomous-system 64511
3. Congure the EBGP connecon to Device R1.
[edit protocols bgp group to-R1]
set type external
set import set-large-comms
set peer-as 64510
set neighbor 10.0.0.14
4. Congure the policy that adds large community values to the routes received from Device R1.
A large community uses a notaon of large:
global administrator
:
assigned number
:
assigned number
. The
specic community values can be anything that accomplishes your administrave goals, within
certain parameters.
[edit policy-options policy-statement set-large-comms]
set term route-1 from route-filter 172.16.1.0/24 exact
set term route-1 then community add large2-as
set term route-1 then accept
set term route-2 from route-filter 172.16.2.0/24 exact
set term route-2 then community add large2-ip
set term route-2 then accept
set term route-3 from route-filter 172.16.3.0/24 exact
set term route-3 then community add large1-as
set term route-3 then accept
set term route-4 from route-filter 172.16.4.0/24 exact
566
set term route-4 then community add large1-ip
set term route-4 then accept
[edit policy-options ]
set community large1-as members large:64511:3:1
set community large1-ip members large:7777:4:1
set community large2-as members large:64511:1:1
set community large2-ip members large:7777:2:1
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R3# show interfaces
fe-1/2/3 {
unit 0 {
family inet {
address 10.0.0.13/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.3/32;
}
}
}
user@R3# show protocols
bgp {
group to-R1 {
type external;
import set-large-comms;
peer-as 64510;
neighbor 10.0.0.14;
567
}
}
user@R3# show policy-options
policy-statement set-large-comms {
term route-1 {
from {
route-filter 172.16.1.0/24 exact;
}
then {
community add large2-as;
accept;
}
}
term route-2 {
from {
route-filter 172.16.2.0/24 exact;
}
then {
community add large2-ip;
accept;
}
}
term route-3 {
from {
route-filter 172.16.3.0/24 exact;
}
then {
community add large1-as;
accept;
}
}
term route-4 {
from {
route-filter 172.16.4.0/24 exact;
}
then {
community add large1-ip;
accept;
}
}
568
}
community large1-as members large:64511:3:1;
community large1-ip members large:7777:4:1;
community large2-as members large:64511:1:1;
community large2-ip members large:7777:2:1;
user@R3# show routing-options
router-id 192.168.0.3;
autonomous-system 64511;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying R1 | 569
Verifying R3 | 571
Conrm that the conguraon is working properly.
Verifying R1
Purpose
On Device R1, check the 172.16. routes in the roung table.
Acon
user@R1> show route protocol static match-prefix 172.16.* detail
inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
172.16.1.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 580
Address: 0xb7a1270
Next-hop reference count: 9
Next hop: 10.0.0.2 via fe-1/2/0.0, selected
569
Session Id: 0x140
State: < Active Int Ext >
Local AS: 64510
Age: 4d 19:02:23
Validation State: unverified
Task: RT
Announcement bits (2): 0-KRT 4-BGP_RT_Background
AS path: I
Communities: 64510:1 large:64510:100:1
172.16.2.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 580
Address: 0xb7a1270
Next-hop reference count: 9
Next hop: 10.0.0.2 via fe-1/2/0.0.0, selected
Session Id: 0x140
State: < Active Int Ext >
Local AS: 64510
Age: 4d 19:02:23
Validation State: unverified
Task: RT
Announcement bits (2): 0-KRT 4-BGP_RT_Background
AS path: I
Communities: 64510:2 large:64510:200:2
172.16.3.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 580
Address: 0xb7a1270
Next-hop reference count: 9
Next hop: 10.0.0.2 via fe-1/2/0.0.0, selected
Session Id: 0x140
State: < Active Int Ext >
Local AS: 64510
Age: 4d 22:17:12
Validation State: unverified
Task: RT
Announcement bits (2): 0-KRT 4-BGP_RT_Background
AS path: I
Communities: 64510:3
172.16.4.0/24 (1 entry, 1 announced)
570
*Static Preference: 5
Next hop type: Router, Next hop index: 580
Address: 0xb7a1270
Next-hop reference count: 9
Next hop: 10.0.0.2 via fe-1/2/0.0.0, selected
Session Id: 0x140
State: < Active Int Ext >
Local AS: 64510
Age: 4d 22:17:12
Validation State: unverified
Task: RT
Announcement bits (2): 0-KRT 4-BGP_RT_Background
AS path: I
Communities: 64510:4
. . .
Meaning
The output shows that the regular community and large community values are aached to the routes.
NOTE: The communies are aached to stac routes, thus demonstrang that both regular and
large communies can be aached to stac routes.
Verifying R3
Purpose
On Device R3, check the 172.16. routes in the roung table.
Acon
user@R3> show route protocol bgp match-prefix 172.16.* detail
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
172.16.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 581
Address: 0xb7a10f0
Next-hop reference count: 8
571
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
Session Id: 0x140
State: < Active Ext >
Local AS: 64511 Peer AS: 64510
Age: 3d 16:36:18
Validation State: unverified
Task: BGP_64510.10.0.0.14
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:1 large:64510:100:1 large:64511:1:1
Accepted
Localpref: 100
Router ID: 192.168.0.1
172.16.2.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 581
Address: 0xb7a10f0
Next-hop reference count: 8
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
Session Id: 0x140
State: < Active Ext >
Local AS: 64511 Peer AS: 64510
Age: 3d 16:36:18
Validation State: unverified
Task: BGP_64510.10.0.0.14
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:2 large:7777:2:1 large:64510:200:2
Accepted
Localpref: 100
Router ID: 192.168.0.1
172.16.3.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 581
Address: 0xb7a10f0
Next-hop reference count: 8
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
Session Id: 0x140
572
State: < Active Ext >
Local AS: 64511 Peer AS: 64510
Age: 3d 16:36:18
Validation State: unverified
Task: BGP_64510.10.0.0.14
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:3 large:64511:3:1
Accepted
Localpref: 100
Router ID: 192.168.0.1
172.16.4.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 581
Address: 0xb7a10f0
Next-hop reference count: 8
Source: 10.0.0.14
Next hop: 10.0.0.14 via fe-1/2/3.0, selected
Session Id: 0x140
State: < Active Ext >
Local AS: 64511 Peer AS: 64510
Age: 3d 16:36:18
Validation State: unverified
Task: BGP_64510.10.0.0.14
Announcement bits (1): 0-KRT
AS path: 64510 I
Communities: 64510:4 large:7777:4:1
Accepted
Localpref: 100
Router ID: 192.168.0.1
. . .
Meaning
The output shows that the adversed regular and large community values remain aached to the routes,
and that the new large community values are added when received by R3.
RELATED DOCUMENTATION
Understanding How to Dene BGP Communies and Extended Communies | 515
573
community
Example: Conguring a Roung Policy Based on the Number of BGP
Communies
IN THIS SECTION
Requirements | 574
Overview | 574
Conguraon | 575
Vericaon | 582
This example shows how to create a policy that accepts BGP routes based on the number of BGP
communies.
Requirements
No special conguraon beyond device inializaon is required before you congure this example.
Overview
IN THIS SECTION
Topology | 575
This example shows two roung devices with an external BGP (EBGP) connecon between them.
Device R2 uses the BGP session to send two stac routes to Device R1. On Device R1, an import policy
species that the BGP-received routes can contain up to ve communies to be considered a match. For
example, if a route contains three communies, it is considered a match and is accepted. If a route
contains six or more communies, it is considered a nonmatch and is rejected.
It is important to remember that the default policy for EBGP is to accept all routes. To ensure that the
nonmatching routes are rejected, you must include a then reject acon at the end of the policy denion.
574
Topology
Figure 34 on page 575 shows the sample network.
Figure 34: BGP Policy with a Limit on the Number of Communies Accepted
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 575
Procedure | 577
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces fe-1/1/0 unit 0 description to-R2
set interfaces fe-1/1/0 unit 0 family inet address 10.0.0.1/30
set interfaces lo0 unit 0 family inet address 192.168.0.1/32
575
set protocols bgp group external-peers type external
set protocols bgp group external-peers peer-as 2
set protocols bgp group external-peers neighbor 10.0.0.2 import import-communities
set policy-options policy-statement import-communities term 1 from protocol bgp
set policy-options policy-statement import-communities term 1 from community-count 5 orlower
set policy-options policy-statement import-communities term 1 then accept
set policy-options policy-statement import-communities term 2 then reject
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 1
Device R2
set interfaces fe-1/1/0 unit 0 description to-R1
set interfaces fe-1/1/0 unit 0 family inet address 10.0.0.2/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp group external-peers type external
set protocols bgp group external-peers export statics
set protocols bgp group external-peers peer-as 1
set protocols bgp group external-peers neighbor 10.0.0.1
set policy-options policy-statement statics from protocol static
set policy-options policy-statement statics then community add 1
set policy-options policy-statement statics then accept
set policy-options community 1 members 2:1
set policy-options community 1 members 2:2
set policy-options community 1 members 2:3
set policy-options community 1 members 2:4
set policy-options community 1 members 2:5
set policy-options community 1 members 2:6
set policy-options community 1 members 2:7
set policy-options community 1 members 2:8
set policy-options community 1 members 2:9
set policy-options community 1 members 2:10
set routing-options static route 10.2.0.0/16 reject
set routing-options static route 10.2.0.0/16 install
set routing-options static route 10.3.0.0/16 reject
set routing-options static route 10.3.0.0/16 install
set routing-options router-id 192.168.0.3
set routing-options autonomous-system 2
576
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R1:
1. Congure the interfaces.
[edit interfaces]
user@R1# set fe-1/1/0 unit 0 description to-R2
user@R1# set fe-1/1/0 unit 0 family inet address 10.0.0.1/30
user@R1# set lo0 unit 0 family inet address 192.168.0.1/32
2. Congure BGP.
Apply the import policy to the BGP peering session with Device R2.
[edit protocols bgp group external-peers]
user@R1# set type external
user@R1# set peer-as 2
user@R1# set neighbor 10.0.0.2 import import-communities
3. Congure the roung policy that sends direct routes.
[edit policy-options policy-statement import-communities]
user@R1# set term 1 from protocol bgp
user@R1# set term 1 from community-count 5 orlower
user@R1# set term 1 then accept
user@R1# set term 2 then reject
4. Congure the autonomous system (AS) number and the router ID.
[edit routing-options ]
user@R1# set router-id 192.168.0.1
user@R1# set autonomous-system 1
577
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R2:
1. Congure the interfaces.
[edit interfaces]
user@R2# set fe-1/1/0 unit 0 description to-R1
user@R2# set fe-1/1/0 unit 0 family inet address 10.0.0.2/30
user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure the router ID and the autonomous system (AS) number.
[edit routing-options]
user@R2# set router-id 192.168.0.3
user@R2# set autonomous-system 2
3. Congure BGP.
[edit protocols bgp group external-peers]
user@R2# set type external
user@R2# set peer-as 1
user@R2# set neighbor 10.0.0.1
4. Congure mulple communies, or congure a single community with mulple members.
[edit policy-options community 1]
user@R2# set members 2:1
user@R2# set members 2:2
user@R2# set members 2:3
user@R2# set members 2:4
user@R2# set members 2:5
user@R2# set members 2:6
user@R2# set members 2:7
user@R2# set members 2:8
578
user@R2# set members 2:9
user@R2# set members 2:10
5. Congure the stac routes.
[edit routing-options static]
user@R2# set route 10.2.0.0/16 reject
user@R2# set route 10.2.0.0/16 install
user@R2# set route 10.3.0.0/16 reject
user@R2# set route 10.3.0.0/16 install
6. Congure a roung policy that adverses stac routes into BGP and adds the BGP community to the
routes.
[edit policy-options policy-statement statics]
user@R2# set from protocol static
user@R2# set then community add 1
user@R2# set then accept
7. Apply the export policy.
[edit protocols bgp group external-peers]
user@R2# set export statics
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
Device R1
user@R1# show interfaces
fe-1/1/0 {
unit 0{
description to-R2;
family inet {
address 10.0.0.1/30;
}
579
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
user@R1# show protocols
bgp {
group external-peers {
type external;
peer-as 2;
neighbor 10.0.0.2 {
import import-communities;
}
}
}
user@R1# show policy-options
policy-statement import-communities {
term 1 {
from {
protocol bgp;
community-count 5 orlower;
}
then accept;
}
term 2 {
then reject;
580
}
}
user@R1# show routing-options
router-id 192.168.0.1;
autonomous-system 1;
Device R2
user@R2# show interfaces
fe-1/1/0 {
unit 0 {
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group external-peers {
type external;
export statics;
peer-as 1;
neighbor 10.0.0.1;
}
}
user@R2# show policy-options
policy-statement statics {
581
from protocol static;
then {
community add 1;
accept;
}
}
community 1 members [ 2:1 2:2 2:3 2:4 2:5 2:6 2:7 2:8 2:9 2:10 ];
user@R2# show routing-options
static {
route 10.2.0.0/16 {
reject;
install;
}
route 10.3.0.0/16 {
reject;
install;
}
}
router-id 192.168.0.3;
autonomous-system 2;
If you are done conguring the devices, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the BGP Routes | 582
Conrm that the conguraon is working properly.
Verifying the BGP Routes
Purpose
Make sure that the roung table on Device R1 contains the expected BGP routes.
582
Acon
1. On Device R1, run the show route protocols bgp command.
user@R1> show route protocols bgp
inet.0: 5 destinations, 5 routes (3 active, 0 holddown, 2 hidden)
2. On Device R1, change the community-count conguraon in the import policy.
[edit policy-options policy-statement import-communities term 1]
user@R1# set from community-count 5 orhigher
user@R1# commit
3. On Device R1, run the show route protocols bgp command.
user@R1> show route protocols bgp
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.0.0/16 *[BGP/170] 18:29:53, localpref 100
AS path: 2 I, validation-state: unverified
> to 10.0.0.2 via fe-1/1/0.0
10.3.0.0/16 *[BGP/170] 18:29:53, localpref 100
AS path: 2 I, validation-state: unverified
> to 10.0.0.2 via fe-1/1/0.0
4. On Device R1, run the show route protocols bgp extensive command to view the adversed
communies.
user@R1> show route protocols bgp extensive
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
10.2.0.0/16 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.2.0.0/16 -> {10.0.0.2}
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 671
Address: 0x9458270
583
Next-hop reference count: 4
Source: 10.0.0.2
Next hop: 10.0.0.2 via fe-1/1/0.0, selected
Session Id: 0x100001
State: <Active Ext>
Local AS: 1 Peer AS: 2
Age: 18:56:10
Validation State: unverified
Task: BGP_2.10.0.0.2+179
Announcement bits (1): 0-KRT
AS path: 2 I
Communities: 2:1 2:2 2:3 2:4 2:5 2:6 2:7 2:8 2:9 2:10
Accepted
Localpref: 100
Router ID: 192.168.0.3
10.3.0.0/16 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.3.0.0/16 -> {10.0.0.2}
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 671
Address: 0x9458270
Next-hop reference count: 4
Source: 10.0.0.2
Next hop: 10.0.0.2 via fe-1/1/0.0, selected
Session Id: 0x100001
State: <Active Ext>
Local AS: 1 Peer AS: 2
Age: 18:56:10
Validation State: unverified
Task: BGP_2.10.0.0.2+179
Announcement bits (1): 0-KRT
AS path: 2 I
Communities: 2:1 2:2 2:3 2:4 2:5 2:6 2:7 2:8 2:9 2:10
Accepted
Localpref: 100
Router ID: 192.168.0.3
584
Meaning
The output shows that in Device R1’s roung table, the BGP routes sent from Device R2 are hidden.
When the community-count seng in Device R1’s import policy is modied, the BGP routes are no longer
hidden.
RELATED DOCUMENTATION
Example: Conguring a Roung Policy to Redistribute BGP Routes with a Specic Community Tag
into IS-IS
Understanding External BGP Peering Sessions
Example: Conguring a Roung Policy That Removes BGP Communies
IN THIS SECTION
Requirements | 585
Overview | 585
Conguraon | 587
Vericaon | 594
This example shows how to create a policy that accepts BGP routes, but removes BGP communies
from the routes.
Requirements
No special conguraon beyond device inializaon is required before you congure this example.
Overview
IN THIS SECTION
Topology | 586
585
This example shows two roung devices with an external BGP (EBGP) connecon between them.
Device R2 uses the BGP session to send two stac routes to Device R1. On Device R1, an import policy
species that all BGP communies must be removed from the routes.
By default, when communies are congured on EBGP peers, they are sent and accepted. To suppress
the acceptance of communies received from a neighbor, you can remove all communies or a specied
set of communies. When the result of a policy is an empty set of communies, the community
aribute is not included. To remove all communies, rst dene a wildcard set of communies (here, the
community is named wild):
[edit policy-options]
community wild members "* : *";
Then, in the roung policy statement, specify the community delete acon:
[edit policy-options]
policy-statement
policy-name
{
term
term-name
{
then community delete wild;
}
}
To suppress a parcular community from any autonomous system (AS), dene the community as
community wild members "*:
community-value
".
Topology
Figure 35 on page 587 shows the sample network.
586
Figure 35: BGP Policy That Removes Communies
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 587
Procedure | 589
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces fe-1/1/0 unit 0 description to-R2
set interfaces fe-1/1/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 external-peers type external
set protocols bgp group external-peers peer-as 2
set protocols bgp group external-peers neighbor 10.0.0.2 import remove-communities
set policy-options policy-statement remove-communities term 1 from protocol bgp
set policy-options policy-statement remove-communities term 1 then community delete wild
587
set policy-options policy-statement remove-communities term 1 then accept
set policy-options policy-statement remove-communities term 2 then reject
set policy-options community wild members *:*
set routing-options router-id 192.168.0.1
set routing-options autonomous-system 1
Device R2
set interfaces fe-1/1/0 unit 0 description to-R1
set interfaces fe-1/1/0 unit 0 family inet address 10.0.0.2/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp group external-peers type external
set protocols bgp group external-peers export statics
set protocols bgp group external-peers peer-as 1
set protocols bgp group external-peers neighbor 10.0.0.1
set policy-options policy-statement statics from protocol static
set policy-options policy-statement statics then community add 1
set policy-options policy-statement statics then accept
set policy-options community 1 members 2:1
set policy-options community 1 members 2:2
set policy-options community 1 members 2:3
set policy-options community 1 members 2:4
set policy-options community 1 members 2:5
set policy-options community 1 members 2:6
set policy-options community 1 members 2:7
set policy-options community 1 members 2:8
set policy-options community 1 members 2:9
set policy-options community 1 members 2:10
set routing-options static route 10.2.0.0/16 reject
set routing-options static route 10.2.0.0/16 install
set routing-options static route 10.3.0.0/16 reject
set routing-options static route 10.3.0.0/16 install
set routing-options router-id 192.168.0.3
set routing-options autonomous-system 2
588
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R1:
1. Congure the interfaces.
[edit interfaces]
user@R1# set fe-1/1/0 unit 0 description to-R2
user@R1# set fe-1/1/0 unit 0 family inet address 10.0.0.1/30
user@R1# set lo0 unit 0 family inet address 192.168.0.1/32
2. Congure BGP.
Apply the import policy to the BGP peering session with Device R2.
[edit protocols bgp group external-peers]
user@R1# set type external
user@R1# set peer-as 2
user@R1# set neighbor 10.0.0.2 import remove-communities
3. Congure the roung policy that deletes communies.
[edit policy-options policy-statement remove-communities]
user@R1# set term 1 from protocol bgp
user@R1# set term 1 then community delete wild
user@R1# set term 1 then accept
user@R1# set term 2 then reject
4. Congure the autonomous system (AS) number and the router ID.
[edit routing-options ]
user@R1# set router-id 192.168.0.1
user@R1# set autonomous-system 1
589
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R2:
1. Congure the interfaces.
[edit interfaces]
user@R2# set fe-1/1/0 unit 0 description to-R1
user@R2# set fe-1/1/0 unit 0 family inet address 10.0.0.2/30
user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure the router ID and the autonomous system (AS) number.
[edit routing-options]
user@R2# set router-id 192.168.0.3
user@R2# set autonomous-system 2
3. Congure BGP.
[edit protocols bgp group external-peers]
user@R2# set type external
user@R2# set peer-as 1
user@R2# set neighbor 10.0.0.1
4. Congure mulple communies, or congure a single community with mulple members.
[edit policy-options community 1]
user@R2# set members 2:1
user@R2# set members 2:2
user@R2# set members 2:3
user@R2# set members 2:4
user@R2# set members 2:5
user@R2# set members 2:6
user@R2# set members 2:7
user@R2# set members 2:8
590
user@R2# set members 2:9
user@R2# set members 2:10
5. Congure the stac routes.
[edit routing-options static]
user@R2# set route 10.2.0.0/16 reject
user@R2# set route 10.2.0.0/16 install
user@R2# set route 10.3.0.0/16 reject
user@R2# set route 10.3.0.0/16 install
6. Congure a roung policy that adverses stac routes into BGP and adds the BGP community to the
routes.
[edit policy-options policy-statement statics]
user@R2# set from protocol static
user@R2# set then community add 1
user@R2# set then accept
7. Apply the export policy.
[edit protocols bgp group external-peers]
user@R2# set export statics
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
Device R1
user@R1# show interfaces
fe-1/1/0 {
unit 0{
description to-R2;
family inet {
address 10.0.0.1/30;
}
591
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
user@R1# show protocols
bgp {
group external-peers {
type external;
peer-as 2;
neighbor 10.0.0.2 {
import remove-communities;
}
}
}
user@R1# show policy-options
policy-statement remove-communities {
term 1 {
from protocol bgp;
then {
community delete wild;
accept;
}
}
term 2 {
then reject;
}
592
}
community wild members *:*;
user@R1# show routing-options
router-id 192.168.0.1;
autonomous-system 1;
Device R2
user@R2# show interfaces
fe-1/1/0 {
unit 0 {
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group external-peers {
type external;
export statics;
peer-as 1;
neighbor 10.0.0.1;
}
}
user@R2# show policy-options
policy-statement statics {
593
from protocol static;
then {
community add 1;
accept;
}
}
community 1 members [ 2:1 2:2 2:3 2:4 2:5 2:6 2:7 2:8 2:9 2:10 ];
user@R2# show routing-options
static {
route 10.2.0.0/16 {
reject;
install;
}
route 10.3.0.0/16 {
reject;
install;
}
}
router-id 192.168.0.3;
autonomous-system 2;
If you are done conguring the devices, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the BGP Routes | 594
Conrm that the conguraon is working properly.
Verifying the BGP Routes
Purpose
Make sure that the roung table on Device R1 does not contain BGP communies.
594
Acon
1. On Device R1, run the show route protocols bgp extensive command.
user@R1> show route protocols bgp extensive
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
10.2.0.0/16 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.2.0.0/16 -> {10.0.0.2}
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 671
Address: 0x9458270
Next-hop reference count: 4
Source: 10.0.0.2
Next hop: 10.0.0.2 via lt-1/1/0.5, selected
Session Id: 0x100001
State: <Active Ext>
Local AS: 1 Peer AS: 2
Age: 20:39:01
Validation State: unverified
Task: BGP_2.10.0.0.2+179
Announcement bits (1): 0-KRT
AS path: 2 I
Accepted
Localpref: 100
Router ID: 192.168.0.3
10.3.0.0/16 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.3.0.0/16 -> {10.0.0.2}
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 671
Address: 0x9458270
Next-hop reference count: 4
Source: 10.0.0.2
Next hop: 10.0.0.2 via lt-1/1/0.5, selected
Session Id: 0x100001
State: <Active Ext>
Local AS: 1 Peer AS: 2
Age: 20:39:01
Validation State: unverified
595
Task: BGP_2.10.0.0.2+179
Announcement bits (1): 0-KRT
AS path: 2 I
Accepted
Localpref: 100
Router ID: 192.168.0.3
2. On Device R1, deacvate the community remove conguraon in the import policy.
[edit policy-options policy-statement remove-communities term 1]
user@R1# deactivate then community delete wild
user@R1# commit
3. On Device R1, run the show route protocols bgp extensive command to view the adversed
communies.
user@R1> show route protocols bgp extensive
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
10.2.0.0/16 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.2.0.0/16 -> {10.0.0.2}
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 671
Address: 0x9458270
Next-hop reference count: 4
Source: 10.0.0.2
Next hop: 10.0.0.2 via lt-1/1/0.5, selected
Session Id: 0x100001
State: <Active Ext>
Local AS: 1 Peer AS: 2
Age: 20:40:53
Validation State: unverified
Task: BGP_2.10.0.0.2+179
Announcement bits (1): 0-KRT
AS path: 2 I
Communities: 2:1 2:2 2:3 2:4 2:5 2:6 2:7 2:8 2:9 2:10
Accepted
Localpref: 100
Router ID: 192.168.0.3
10.3.0.0/16 (1 entry, 1 announced)
596
TSI:
KRT in-kernel 10.3.0.0/16 -> {10.0.0.2}
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 671
Address: 0x9458270
Next-hop reference count: 4
Source: 10.0.0.2
Next hop: 10.0.0.2 via lt-1/1/0.5, selected
Session Id: 0x100001
State: <Active Ext>
Local AS: 1 Peer AS: 2
Age: 20:40:53
Validation State: unverified
Task: BGP_2.10.0.0.2+179
Announcement bits (1): 0-KRT
AS path: 2 I
Communities: 2:1 2:2 2:3 2:4 2:5 2:6 2:7 2:8 2:9 2:10
Accepted
Localpref: 100
Router ID: 192.168.0.3
Meaning
The output shows that in Device R1’s roung table, the communies are suppressed in the BGP routes
sent from Device R2. When the community remove seng in Device R1’s import policy is deacvated, the
communies are no longer suppressed.
RELATED DOCUMENTATION
Example: Conguring a Roung Policy to Redistribute BGP Routes with a Specic Community Tag
into IS-IS
Understanding External BGP Peering Sessions
597
CHAPTER 7
Increasing Network Stability with BGP Route
Flapping Acons
IN THIS CHAPTER
Understanding Damping Parameters | 598
Using Roung Policies to Damp BGP Route Flapping | 600
Example: Conguring BGP Route Flap Damping Parameters | 606
Example: Conguring BGP Route Flap Damping Based on the MBGP MVPN Address Family | 621
Understanding Damping Parameters
BGP
route apping
describes the situaon in which BGP systems send an excessive number of update
messages to adverse network reachability informaon. BGP
ap damping
is a method of reducing the
number of update messages sent between BGP peers, thereby reducing the load on these peers,
without adversely aecng the route convergence me for stable routes.
Flap damping reduces the number of update messages by marking routes as ineligible for selecon as
the acve or preferable route. Marking routes in this way leads to some delay, or
suppression
, in the
propagaon of route informaon, but the result is increased network stability. You typically apply ap
damping to external BGP (EBGP) routes (routes in dierent ASs). You can also apply ap damping within
a confederaon, between confederaon member ASs. Because roung consistency within an AS is
important, do not apply ap damping to internal BGP (IBGP) routes. (If you do, it is ignored.)
There is an excepon that rule. Starng in Junos OS Release 12.2, you can apply ap damping at the
address family level. In a Junos OS Release 12.2 or later installaon, when you apply ap damping at the
address family level, it works for both IBGP and EBGP.
By default, route ap damping is not enabled. Damping is applied to external peers and to peers at
confederaon boundaries.
When you enable damping, default parameters are applied, as summarized in Table 23 on page 599.
598
Table 23: Damping Parameters
Damping
Parameter
Descripon Default Value Possible Values
half-life
minutes
Decay half-life—Number of minutes aer which an
arbitrary value is halved if a route stays stable.
15 (minutes) 1 through 45
max-suppress
minutes
Maximum hold-down me for a route, in minutes. 60 (minutes) 1 through 720
reuse Reuse threshold—Arbitrary value below which a
suppressed route can be used again.
750 1 through 20,000
suppress Cuto (suppression) threshold—Arbitrary value above
which a route can no longer be used or included in
adversements.
3000 1 through 20,000
To change the default BGP ap damping values, you dene acons by creang a named set of damping
parameters and including it in a roung policy with the damping acon. For the damping roung policy
to work, you also must enable BGP route ap damping.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
12.2 Starng in Junos OS Release 12.2, you can apply ap damping at the address family level.
RELATED DOCUMENTATION
Understanding Roung Policies
599
Using Roung Policies to Damp BGP Route Flapping
IN THIS SECTION
Conguring BGP Flap Damping Parameters | 600
Specifying BGP Flap Damping as the Acon in Roung Policy Terms | 603
Disabling Damping for Specic Address Prexes | 604
Conguring BGP Flap Damping | 604
BGP
route apping
describes the situaon in which BGP systems send an excessive number of update
messages to adverse network reachability informaon. BGP
ap damping
is a way to reduce the
number of update messages sent between BGP peers, thereby reducing the load on these peers without
adversely aecng the route convergence me.
Flap damping reduces the number of update messages by marking routes as ineligible for selecon as
the acve or preferable route. Doing this leads to some delay, or
suppression
, in the propagaon of
route informaon, but the result is increased network stability. You typically apply ap damping to
external BGP (EBGP) routes (that is, to routes in dierent ASs). You can also apply it within a
confederaon, between confederaon member ASs. Because roung consistency within an AS is
important, do not apply ap damping to IBGP routes. (If you do, it is ignored.)
BGP ap damping is dened in RFC 2439,
BGP Route Flap Damping.
To eect changes to the default BGP ap damping values, you dene acons by creang a named set of
damping parameters and including it in a roung policy with the damping acon (described in "Conguring
Acons That Manipulate Route Characteriscs" on page 77). For the damping roung policy to work,
you also must enable BGP route ap damping.
The following secons discuss the following topics:
Conguring BGP Flap Damping Parameters
To dene damping parameters, include the damping statement:
[edit policy-options]
damping
name
{
disable;
half-life
minutes
;
max-suppress
minutes
;
600
reuse
number
;
suppress
number
;
}
The name idenes the group of damping parameters. It can contain leers, numbers, and hyphens (-)
and can be up to 255 characters. To include spaces in the name, enclose the enre name in quotaon
marks (“ ”).
You can specify one or more of the damping parameters described in Table 24 on page 601.
Table 24: Damping Parameters
Damping Parameter Descripon Default Possible Values
half-life
minutes
Decay half-life, in minutes 15 minutes 1 through 45 minutes
max-suppress
minutes
Maximum hold-down me, in
minutes
60 minutes 1 through 720 minutes
reuse
Reuse threshold 750 (unitless) 1 through 20,000 (unitless)
suppress
Cuto (suppression) threshold 3000 (unitless) 1 through 20,000 (unitless)
If you do not specify one or more of the damping parameters, the default value of the parameter is used.
To understand how to congure these parameters, you need to understand how damping suppresses
routes. How long a route can be suppressed is based on a
gure of merit
, which is a value that correlates
to the probability of future instability of a route. Routes with higher gure-of-merit values are
suppressed for longer periods of me. The gure-of-merit value decays exponenally over me.
A gure-of-merit value of zero is assigned to each new route. The value is increased each me the route
is withdrawn or readversed, or when one of its path aributes changes. With each incident of
instability, the value increases as follows:
• Route is withdrawn—1000
• Route is readversed—1000
• Route’s path aributes change—500
601
NOTE: Other vendors’ implementaons for gure-of-merit increase the value only when a
route is withdrawn. The Junos OS implementaon for gure-of-merit increases the value for
both route withdrawal and route readversement. To accommodate other implementaons
for gure-of-merit, mulply the reuse and suppress threshold values by 2.
When a route’s gure-of-merit value reaches a parcular level, called the
cuto
or
suppression
threshold
, the route is suppressed. If a route is suppressed, the roung table no longer installs the route
into the forwarding table and no longer exports this route to any of the roung protocols. By default, a
route is suppressed when its gure-of-merit value reaches 3000. To modify this default, include the
suppress opon at the [edit policy-options damping
name
] hierarchy level.
If a route has apped, but then becomes stable so that none of the incidents listed previously occur
within a congurable amount of me, the gure-of-merit value for the route decays exponenally. The
default half-life is 15 minutes. For example, for a route with a gure-of-merit value of 1500, if no
incidents occur, its gure-of-merit value is reduced to 750 aer 15 minutes and to 375 aer another
15 minutes. To modify the default half-life, include the half-life opon at the [edit policy-options damping
name
] hierarchy level.
NOTE: For the half-life, congure a value that is less than the max-suppress. If you do not, the
conguraon is rejected.
A suppressed route becomes reusable when its gure-of-merit value decays to a value below a
reuse
threshold
, thus allowing routes that experience transient instability to once again be considered valid.
The default reuse threshold is 750. When the gure-of-merit value passes below the reuse threshold,
the route once again is considered usable and can be installed in the forwarding table and exported from
the roung table. To modify the default reuse threshold, include the reuse opon at the [edit policy-
options damping
name
] hierarchy level.
The maximum suppression me provides an upper bound on the me that a route can remain
suppressed. The default maximum suppression me is 60 minutes. To modify the default, include the
max-suppress opon at the [edit policy-options damping
name
] hierarchy level.
NOTE: For the max-suppress, congure a value that is greater than the half-life. If you do not, the
conguraon is rejected.
A route’s gure-of-merit value stops increasing when it reaches a maximum suppression threshold,
which is determined based on the route’s suppression threshold level, half-life, reuse threshold, and
maximum hold-down me.
602
The merit ceiling, ε
c
, which is the maximum merit that a apping route can collect, is calculated using the
following formula:
ε
c
≤ ε
r
e
(t/λ) (ln 2)
ε
r
is the gure-of-merit reuse threshold, t is the maximum hold-down me in minutes, and λ is the half-
life in minutes. For example, if you use the default gure-of-merit values in this formula, but use a half-
life of 30 minutes, the calculaon is as follows:
ε
c
≤ 750 e
(120/30) (ln 2)
ε
c
≤ 12000
NOTE: The cuto threshold, which you congure using the suppress opon, must be less than or
equal to the merit ceiling, ε
c
. If the congured cuto threshold or the default cuto threshold is
greater than the merit ceiling, the route is never suppressed and damping never occurs.
To display gure-of-merit informaon, use the show policy damping command.
A route that has been assigned a gure of merit is considered to have a damping state. To display the
current damping informaon on the roung device, use the show route detail command.
Specifying BGP Flap Damping as the Acon in Roung Policy Terms
To BGP ap damping as the acon in a roung policy term, include the damping statement and the name
of the congured damping parameters either as an opon of the route-filter statement at the [edit
policy-options policy-statement
policy-name
term
term-name
from] hierarchy level:
[edit policy-options policy-statement
policy-name
term
term-name
from]
route-filter
destination-prefix
match-type
{
damping
damping-parameters
;
}
or at the [edit policy-options policy-statement
policy-name
term
term-name
then] hierarchy level:
[edit policy-options policy-statement
policy-name
term
term-name
then]
damping
damping-parameters
;
603
Disabling Damping for Specic Address Prexes
Normally, you enable or disable damping on a per-peer basis. However, you can disable damping for a
specic prex received from a peer by including the disable opon:
[edit policy-options damping
name
]
disable;
Disabling Damping for a Specic Address Prex
In this roung policy example, although damping is enabled for the peer, the damping none statement
species that damping be disabled for prex 10.0.0.0/8 in Policy-A. This route is not damped because the
roung policy statement named Policy-A lters on the prex 10.0.0.0/8 and the acon points to the
damping statement named none. The remaining prexes are damped using the default parameters.
[edit]
policy-options {
policy-statement Policy-A {
from {
route-filter 10.0.0.0/8 exact;
}
then damping none;
}
damping none {
disable;
}
}
Conguring BGP Flap Damping
Enable BGP ap damping and congure damping parameters:
[edit]
routing-options {
autonomous-system 666;
}
protocols {
bgp {
damping;
604
group group1 {
traceoptions {
file bgp-log size 1m files 10;
flag damping;
}
import damp;
type external;
peer-as 10458;
neighbor 192.168.2.30;
}
}
}
policy-options {
policy-statement damp {
from {
route-filter 192.168.0.0/32 exact {
damping high;
accept;
}
route-filter 172.16.0.0/32 exact {
damping medium;
accept;
}
route-filter 10.0.0.0/8 exact {
damping none;
accept;
}
}
}
damping high {
half-life 30;
suppress 3000;
reuse 750;
max-suppress 60;
}
damping medium {
half-life 15;
suppress 3000;
reuse 750;
max-suppress 45;
}
damping none {
disable;
605
}
}
To display damping parameters for this conguraon, use the show policy damping command:
user@host> show policy damping
Damping information for "high":
Halflife: 30 minutes
Reuse merit: 750 Suppress/cutoff merit: 3000
Maximum suppress time: 60 minutes
Computed values:
Merit ceiling: 3008
Maximum decay: 24933
Damping information for "medium":
Halflife: 15 minutes
Reuse merit: 750 Suppress/cutoff merit: 3000
Maximum suppress time: 45 minutes
Computed values:
Merit ceiling: 6024
Maximum decay: 12449
Damping information for "none":
Damping disabled
RELATED DOCUMENTATION
Example: Conguring BGP Route Flap Damping Parameters | 606
Example: Conguring BGP Route Flap Damping Based on the MBGP MVPN Address Family | 621
Example: Conguring BGP Route Flap Damping Parameters
IN THIS SECTION
Requirements | 607
Overview | 607
Conguraon | 608
606
Vericaon | 614
This example shows how to congure damping parameters.
Requirements
Before you begin, congure router interfaces and congure roung protocols.
Overview
This example has three roung devices. Device R2 has external BGP (EBGP) connecons with Device R1
and Device R3.
Device R1 and Device R3 have some stac routes congured for tesng purposes, and these stac
routes are adversed through BGP to Device R2.
Device R2 damps routes received from Device R1 and Device R3 according to these criteria:
• Damp all prexes with a mask length equal to or greater than 17 more aggressively than routes with
a mask length between 9 and 16.
• Damp routes with a mask length between 0 and 8, inclusive, less than routes with a mask length
greater than 8.
• Do not damp the 10.128.0.0/9 prex at all.
The roung policy is evaluated when routes are being exported from the roung table into the
forwarding table. Only the acve routes are exported from the roung table.
Figure 36 on page 607 shows the sample network.
Figure 36: BGP Flap Damping Topology
607
"CLI Quick Conguraon" on page 608 shows the conguraon for all of the devices in Figure 36 on
page 607.
The secon "No Link Title" on page 610 describes the steps on Device R2.
Conguraon
IN THIS SECTION
Procedure | 608
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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 export send-direct-and-static
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.0.0.2
set policy-options policy-statement send-direct-and-static term 1 from protocol direct
set policy-options policy-statement send-direct-and-static term 1 from protocol static
set policy-options policy-statement send-direct-and-static term 1 then accept
set routing-options static route 172.16.0.0/16 reject
set routing-options static route 172.16.128.0/17 reject
set routing-options static route 172.16.192.0/20 reject
set routing-options static route 10.0.0.0/9 reject
set routing-options static route 172.16.233.0/7 reject
set routing-options static route 10.224.0.0/11 reject
set routing-options static route 0.0.0.0/0 reject
set routing-options autonomous-system 100
608
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 lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp damping
set protocols bgp group ext type external
set protocols bgp group ext import damp
set protocols bgp group ext export send-direct
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 damp term 1 from route-filter 10.128.0.0/9 exact damping dry
set policy-options policy-statement damp term 1 from route-filter 0.0.0.0/0 prefix-length-
range /0-/8 damping timid
set policy-options policy-statement damp term 1 from route-filter 0.0.0.0/0 prefix-length-
range /17-/32 damping aggressive
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set policy-options damping aggressive half-life 30
set policy-options damping aggressive suppress 2500
set policy-options damping timid half-life 5
set policy-options damping dry disable
set routing-options autonomous-system 200
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 protocols bgp group ext type external
set protocols bgp group ext export send-direct-and-static
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.1.0.1
set policy-options policy-statement send-direct-and-static term 1 from protocol direct
set policy-options policy-statement send-direct-and-static term 1 from protocol static
set policy-options policy-statement send-direct-and-static term 1 then accept
set routing-options static route 10.128.0.0/9 reject
set routing-options autonomous-system 300
609
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure damping parameters:
1. Congure the interfaces.
[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
2. Congure the BGP neighbors.
[edit protocols bgp group ext]
user@R2# set type external
user@R2# set neighbor 10.0.0.1 peer-as 100
user@R2# set neighbor 10.1.0.2 peer-as 300
3. Create and congure the damping parameter groups.
[edit policy-options]
user@R2# set damping aggressive half-life 30
user@R2# set damping aggressive suppress 2500
user@R2# set damping timid half-life 5
user@R2# set damping dry disable
4. Congure the damping policy.
[edit policy-options policy-statement damp term 1]
user@R2# set from route-filter 10.128.0.0/9 exact damping dry
user@R2# set from route-filter 0.0.0.0/0 prefix-length-range /0-/8 damping timid
user@R2# set from route-filter 0.0.0.0/0 prefix-length-range /17-/32 damping aggressive
610
5. Enable damping for BGP.
[edit protocols bgp]
user@R2# set damping
6. Apply the policy as an import policy for the BGP neighbor.
[edit protocols bgp group ext]
user@R2# set import damp
NOTE: You can refer to the same roung policy one or more mes in the same or dierent
import statements.
7. Congure an export policy.
[edit policy-options policy-statement send-direct term 1]
user@R2# set from protocol direct
user@R2# set then accept
8. Apply the export policy.
[edit protocols bgp group ext]
user@R2# set export send-direct
9. Congure the autonomous system (AS) number.
[edit routing-options]
user@R2# set autonomous-system 200
611
Results
From conguraon mode, conrm your conguraon by issuing the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
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;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
damping;
group ext {
type external;
import damp;
export send-direct;
neighbor 10.0.0.1 {
peer-as 100;
}
neighbor 10.1.0.2 {
peer-as 300;
612
}
}
}
user@R2# show policy-options
policy-statement damp {
term 1 {
from {
route-filter 10.128.0.0/9 exact damping dry;
route-filter 0.0.0.0/0 prefix-length-range /0-/8 damping timid;
route-filter 0.0.0.0/0 prefix-length-range /17-/32 damping aggressive;
}
}
}
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
damping aggressive {
half-life 30;
suppress 2500;
}
damping timid {
half-life 5;
}
damping dry {
disable;
}
user@R2# show routing-options
autonomous-system 200;
If you are done conguring the device, enter commit from conguraon mode.
613
Vericaon
IN THIS SECTION
Causing Some Routes to Flap | 614
Checking the Route Flaps | 615
Verifying Route Flap Damping | 616
Displaying the Details of a Damped Route | 617
Verifying That Default Damping Parameters Are in Eect | 618
Filtering the Damping Informaon | 619
Conrm that the conguraon is working properly.
Causing Some Routes to Flap
Purpose
To verify your route ap damping policy, some routes must ap. Having a live Internet feed almost
guarantees that a certain number of route aps will be present. If you have control over a remote system
that is adversing the routes, you can modify the adversing router's policy to eect the adversement
and withdrawal of all routes or of a given prex. In a test environment, you can cause routes to ap by
clearing the BGP neighbors or by restarng the roung process on the BGP neighbors, as shown here.
Acon
From operaonal mode on Device R1 and Device R3, enter the restart routing command.
614
CAUTION: Use this command cauously in a producon network.
user@R1> restart routing
R1 started, pid 10474
user@R3> restart routing
R3 started, pid 10478
Meaning
On Device R2, all of the routes from the neighbors are withdrawn and re-adversed.
Checking the Route Flaps
Purpose
View the number of neighbor aps.
Acon
From operaonal mode, enter the show bgp summary command.
user@R2> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
12 1 11 0 11 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Accepted/Damped...
10.0.0.1 100 10 10 0 4 2:50
0/9/0/9 0/0/0/0
615
10.1.0.2 300 10 10 0 4 2:53
1/3/1/2 0/0/0/0
Meaning
This output was captured aer the roung process was restarted on Device R2’s neighbors four mes.
Verifying Route Flap Damping
Purpose
Verify that routes are being hidden due to damping.
Acon
From operaonal mode, enter the show route damping suppressed command.
user@R2> show route damping suppressed
inet.0: 15 destinations, 17 routes (6 active, 0 holddown, 11 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
10.0.0.0/9 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
10.0.0.0/30 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
10.1.0.0/30 [BGP ] 00:00:15, localpref 100
AS path: 300 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
10.224.0.0/11 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.0.0/16 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.128.0/17 [BGP ] 00:00:12, localpref 100
616
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
172.16.192.0/20 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
192.168.0.1/32 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
192.168.0.3/32 [BGP ] 00:00:15, localpref 100
AS path: 300 I, validation-state: unverified
> to 10.1.0.2 via fe-1/2/1.0
172.16.233.0/7 [BGP ] 00:00:12, localpref 100
AS path: 100 I, validation-state: unverified
> to 10.0.0.1 via fe-1/2/0.0
Meaning
The output shows some roung instability. Eleven routes are hidden due to damping.
Displaying the Details of a Damped Route
Purpose
Display the details of damped routes.
Acon
From operaonal mode, enter the show route damping suppressed 172.16.192.0/20 detail command.
user@R2> show route damping suppressed 172.16.192.0/20 detail
inet.0: 15 destinations, 17 routes (6 active, 0 holddown, 11 hidden)
172.16.192.0/20 (1 entry, 0 announced)
BGP /-101
Next hop type: Router, Next hop index: 758
Address: 0x9414484
Next-hop reference count: 9
Source: 10.0.0.1
Next hop: 10.0.0.1 via fe-1/2/0.0, selected
Session Id: 0x100201
State: <Hidden Ext>
617
Local AS: 200 Peer AS: 100
Age: 52
Validation State: unverified
Task: BGP_100.10.0.0.1+55922
AS path: 100 I
Localpref: 100
Router ID: 192.168.0.1
Merit (last update/now): 4278/4196
damping-parameters: aggressive
Last update: 00:00:52 First update: 01:01:55
Flaps: 8
Suppressed. Reusable in: 01:14:40
Preference will be: 170
Meaning
This output indicates that the displayed route has a mask length that is equal to or greater than /17, and
conrms that it has been correctly mapped to the aggressive damping prole. You can also see the
route’s current (and last) gure of merit value, and when the route is expected to become acve if it
remains stable.
Verifying That Default Damping Parameters Are in Eect
Purpose
Locang a damped route with a /16 mask conrms that the default parameters are in eect.
Acon
From operaonal mode, enter the show route damping suppressed detail | match 0/16 command.
user@R2> show route damping suppressed detail | match 0/16
172.16.0.0/16 (1 entry, 0 announced)
user@R2> show route damping suppressed 172.16.0.0/16 detail
inet.0: 15 destinations, 17 routes (6 active, 0 holddown, 11 hidden)
172.16.0.0/16 (1 entry, 0 announced)
618
BGP /-101
Next hop type: Router, Next hop index: 758
Address: 0x9414484
Next-hop reference count: 9
Source: 10.0.0.1
Next hop: 10.0.0.1 via fe-1/2/0.0, selected
Session Id: 0x100201
State: <Hidden Ext>
Local AS: 200 Peer AS: 100
Age: 1:58
Validation State: unverified
Task: BGP_100.10.0.0.1+55922
AS path: 100 I
Localpref: 100
Router ID: 192.168.0.1
Merit (last update/now): 3486/3202
Default damping parameters used
Last update: 00:01:58 First update: 01:03:01
Flaps: 8
Suppressed. Reusable in: 00:31:40
Preference will be: 170
Meaning
Routes with a /16 mask are not impacted by the custom damping rules. Therefore, the default damping
rules are in eect.
To repeat, the custom rules are as follows:
• Damp all prexes with a mask length equal to or greater than 17 more aggressively than routes with
a mask length between 9 and 16.
• Damp routes with a mask length between 0 and 8, inclusive, less than routes with a mask length
greater than 8.
• Do not damp the 10.128.0.0/9 prex at all.
Filtering the Damping Informaon
Purpose
Use OR groupings or cascaded piping to simplify the determinaon of what damping prole is being
used for routes with a given mask length.
619
Acon
From operaonal mode, enter the show route damping suppressed command.
user@R2> show route damping suppressed detail | match "0 announced | damp"
0.0.0.0/0 (1 entry, 0 announced)
damping-parameters: timid
10.0.0.0/9 (1 entry, 0 announced)
Default damping parameters used
damping-parameters: aggressive
damping-parameters: aggressive
10.224.0.0/11 (1 entry, 0 announced)
Default damping parameters used
172.16.0.0/16 (1 entry, 0 announced)
Default damping parameters used
172.16.128.0/17 (1 entry, 0 announced)
damping-parameters: aggressive
172.16.192.0/20 (1 entry, 0 announced)
damping-parameters: aggressive
192.168.0.1/32 (1 entry, 0 announced)
damping-parameters: aggressive
192.168.0.3/32 (1 entry, 0 announced)
damping-parameters: aggressive
172.16.233.0/7 (1 entry, 0 announced)
damping-parameters: timid
Meaning
When you are sased that your EBGP routes are correctly associated with a damping prole, you can
issue the clear bgp damping operaonal mode command to restore an acve status to your damped routes,
which will return your connecvity to normal operaon.
RELATED DOCUMENTATION
Understanding Damping Parameters
Using Roung Policies to Damp BGP Route Flapping | 600
620
Example: Conguring BGP Route Flap Damping Based on the MBGP
MVPN Address Family
IN THIS SECTION
Requirements | 621
Overview | 621
Conguraon | 622
Vericaon | 634
This example shows how to
congure an mulprotocol BGP mulcast VPN (also called Next-Generaon
MVPN) with BGP route ap damping.
Requirements
This example uses Junos OS Release 12.2. BGP route ap damping support for MBGP MVPN,
specically, and on an address family basis, in general, is introduced in Junos OS Release 12.2.
Overview
IN THIS SECTION
Topology | 621
BGP route ap damping helps to diminish route instability caused by routes being repeatedly withdrawn
and readversed when a link is intermiently failing.
This example uses the default damping parameters and demonstrates an MBGP MVPN scenario with
three provider edge (PE) roung devices, three customer edge (CE) roung devices, and one provider (P)
roung device.
Topology
Figure 37 on page 622 shows the topology used in this example.
621
Figure 37: MBGP MVPN with BGP Route Flap Damping
On PE Device R4, BGP route ap damping is congured for address family inet-mvpn. A roung policy
called dampPolicy uses the nlri-route-type match condion to damp only MVPN route types 3, 4, and 5. All
other MVPN route types are not damped.
This example shows the full conguraon on all devices in the "CLI Quick Conguraon" on page 622
secon. The "Conguring Device R4" on page 627 secon shows the step-by-step conguraon for PE
Device R4.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 622
Conguring Device R4 | 627
Results | 630
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
622
Device R1
set interfaces ge-1/2/0 unit 1 family inet address 10.1.1.1/30
set interfaces ge-1/2/0 unit 1 family mpls
set interfaces lo0 unit 1 family inet address 172.16.1.1/32
set protocols ospf area 0.0.0.0 interface lo0.1 passive
set protocols ospf area 0.0.0.0 interface ge-1/2/0.1
set protocols pim rp static address 172.16.100.1
set protocols pim interface all
set routing-options router-id 172.16.1.1
Device R2
set interfaces ge-1/2/0 unit 2 family inet address 10.1.1.2/30
set interfaces ge-1/2/0 unit 2 family mpls
set interfaces ge-1/2/1 unit 5 family inet address 10.1.1.5/30
set interfaces ge-1/2/1 unit 5 family mpls
set interfaces vt-1/2/0 unit 2 family inet
set interfaces lo0 unit 2 family inet address 172.16.1.2/32
set interfaces lo0 unit 102 family inet address 172.16.100.1/32
set protocols mpls interface ge-1/2/1.5
set protocols bgp group ibgp type internal
set protocols bgp group ibgp local-address 172.16.1.2
set protocols bgp group ibgp family inet-vpn any
set protocols bgp group ibgp family inet-mvpn signaling
set protocols bgp group ibgp neighbor 172.16.1.4
set protocols bgp group ibgp neighbor 172.16.1.5
set protocols ospf area 0.0.0.0 interface lo0.2 passive
set protocols ospf area 0.0.0.0 interface ge-1/2/1.5
set protocols ldp interface ge-1/2/1.5
set protocols ldp p2mp
set policy-options policy-statement parent_vpn_routes from protocol bgp
set policy-options policy-statement parent_vpn_routes then accept
set routing-instances vpn-1 instance-type vrf
set routing-instances vpn-1 interface ge-1/2/0.2
set routing-instances vpn-1 interface vt-1/2/0.2
set routing-instances vpn-1 interface lo0.102
set routing-instances vpn-1 route-distinguisher 100:100
set routing-instances vpn-1 provider-tunnel ldp-p2mp
set routing-instances vpn-1 vrf-target target:1:1
set routing-instances vpn-1 protocols ospf export parent_vpn_routes
623
set routing-instances vpn-1 protocols ospf area 0.0.0.0 interface lo0.102 passive
set routing-instances vpn-1 protocols ospf area 0.0.0.0 interface ge-1/2/0.2
set routing-instances vpn-1 protocols pim rp static address 172.16.1.2 with 172.16.4.1100.1
set routing-instances vpn-1 protocols pim interface ge-1/2/0.2 mode sparse
set routing-instances vpn-1 protocols mvpn
set routing-options router-id 172.16.1.2
set routing-options autonomous-system 1001
Device R3
set interfaces ge-1/2/0 unit 6 family inet address 10.1.1.6/30
set interfaces ge-1/2/0 unit 6 family mpls
set interfaces ge-1/2/1 unit 9 family inet address 10.1.1.9/30
set interfaces ge-1/2/1 unit 9 family mpls
set interfaces ge-1/2/2 unit 13 family inet address 10.1.1.13/30
set interfaces ge-1/2/2 unit 13 family mpls
set interfaces lo0 unit 3 family inet address 172.16.1.3/32
set protocols mpls interface ge-1/2/0.6
set protocols mpls interface ge-1/2/1.9
set protocols mpls interface ge-1/2/2.13
set protocols ospf area 0.0.0.0 interface lo0.3 passive
set protocols ospf area 0.0.0.0 interface ge-1/2/0.6
set protocols ospf area 0.0.0.0 interface ge-1/2/1.9
set protocols ospf area 0.0.0.0 interface ge-1/2/2.13
set protocols ldp interface ge-1/2/0.6
set protocols ldp interface ge-1/2/1.9
set protocols ldp interface ge-1/2/2.13
set protocols ldp p2mp
set routing-options router-id 172.16.1.3
Device R4
set interfaces ge-1/2/0 unit 10 family inet address 10.1.1.10/30
set interfaces ge-1/2/0 unit 10 family mpls
set interfaces ge-1/2/1 unit 17 family inet address 10.1.1.17/30
set interfaces ge-1/2/1 unit 17 family mpls
set interfaces vt-1/2/0 unit 4 family inet
set interfaces lo0 unit 4 family inet address 172.16.1.4/32
set interfaces lo0 unit 104 family inet address 172.16.100.1/32
set protocols rsvp interface all aggregate
set protocols mpls interface all
624
set protocols mpls interface ge-1/2/0.10
set protocols bgp group ibgp type internal
set protocols bgp group ibgp local-address 172.16.1.4
set protocols bgp group ibgp family inet-vpn unicast
set protocols bgp group ibgp family inet-vpn any
set protocols bgp group ibgp family inet-mvpn signaling damping
set protocols bgp group ibgp neighbor 172.16.1.2 import dampPolicy
set protocols bgp group ibgp neighbor 172.16.1.5
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface lo0.4 passive
set protocols ospf area 0.0.0.0 interface ge-1/2/0.10
set protocols ldp interface ge-1/2/0.10
set protocols ldp p2mp
set policy-options policy-statement dampPolicy term term1 from family inet-mvpn
set policy-options policy-statement dampPolicy term term1 from nlri-route-type 3
set policy-options policy-statement dampPolicy term term1 from nlri-route-type 4
set policy-options policy-statement dampPolicy term term1 from nlri-route-type 5
set policy-options policy-statement dampPolicy term term1 then accept
set policy-options policy-statement dampPolicy then damping no-damp
set policy-options policy-statement dampPolicy then accept
set policy-options policy-statement parent_vpn_routes from protocol bgp
set policy-options policy-statement parent_vpn_routes then accept
set policy-options damping no-damp disable
set routing-instances vpn-1 instance-type vrf
set routing-instances vpn-1 interface vt-1/2/0.4
set routing-instances vpn-1 interface ge-1/2/1.17
set routing-instances vpn-1 interface lo0.104
set routing-instances vpn-1 route-distinguisher 100:100
set routing-instances vpn-1 vrf-target target:1:1
set routing-instances vpn-1 protocols ospf export parent_vpn_routes
set routing-instances vpn-1 protocols ospf area 0.0.0.0 interface lo0.104 passive
set routing-instances vpn-1 protocols ospf area 0.0.0.0 interface ge-1/2/1.17
set routing-instances vpn-1 protocols pim rp static address 172.16.100.1
set routing-instances vpn-1 protocols pim interface ge-1/2/1.17 mode sparse
set routing-instances vpn-1 protocols mvpn
set routing-options router-id 172.16.1.4
set routing-options autonomous-system 64501
625
Device R5
set interfaces ge-1/2/0 unit 14 family inet address 10.1.1.14/30
set interfaces ge-1/2/0 unit 14 family mpls
set interfaces ge-1/2/1 unit 21 family inet address 10.1.1.21/30
set interfaces ge-1/2/1 unit 21 family mpls
set interfaces vt-1/2/0 unit 5 family inet
set interfaces lo0 unit 5 family inet address 172.16.1.5/32
set interfaces lo0 unit 105 family inet address 172.16.100.5/32
set protocols mpls interface ge-1/2/0.14
set protocols bgp group ibgp type internal
set protocols bgp group ibgp local-address 172.16.1.5
set protocols bgp group ibgp family inet-vpn any
set protocols bgp group ibgp family inet-mvpn signaling
set protocols bgp group ibgp neighbor 172.16.1.2
set protocols bgp group ibgp neighbor 172.16.1.4
set protocols ospf area 0.0.0.0 interface lo0.5 passive
set protocols ospf area 0.0.0.0 interface ge-1/2/0.14
set protocols ldp interface ge-1/2/0.14
set protocols ldp p2mp
set policy-options policy-statement parent_vpn_routes from protocol bgp
set policy-options policy-statement parent_vpn_routes then accept
set routing-instances vpn-1 instance-type vrf
set routing-instances vpn-1 interface vt-1/2/0.5
set routing-instances vpn-1 interface ge-1/2/1.21
set routing-instances vpn-1 interface lo0.105
set routing-instances vpn-1 route-distinguisher 100:100
set routing-instances vpn-1 vrf-target target:1:1
set routing-instances vpn-1 protocols ospf export parent_vpn_routes
set routing-instances vpn-1 protocols ospf area 0.0.0.0 interface lo0.105 passive
set routing-instances vpn-1 protocols ospf area 0.0.0.0 interface ge-1/2/1.21
set routing-instances vpn-1 protocols pim rp static address 172.16.100.2
set routing-instances vpn-1 protocols pim interface ge-1/2/1.21 mode sparse
set routing-instances vpn-1 protocols mvpn
set routing-options router-id 172.16.1.5
set routing-options autonomous-system 1001
Device R6
set interfaces ge-1/2/0 unit 18 family inet address 10.1.1.18/30
set interfaces ge-1/2/0 unit 18 family mpls
626
set interfaces lo0 unit 6 family inet address 172.16.1.6/32
set protocols sap listen 233.1.1.1
set protocols ospf area 0.0.0.0 interface lo0.6 passive
set protocols ospf area 0.0.0.0 interface ge-1/2/0.18
set protocols pim rp static address 172.16.100.2
set protocols pim interface all
set routing-options router-id 172.16.1.6
Device R7
set interfaces ge-1/2/0 unit 22 family inet address 10.1.1.22/30
set interfaces ge-1/2/0 unit 22 family mpls
set interfaces lo0 unit 7 family inet address 172.16.1.7/32
set protocols ospf area 0.0.0.0 interface lo0.7 passive
set protocols ospf area 0.0.0.0 interface ge-1/2/0.22
set protocols pim rp static address 172.16.100.2
set protocols pim interface all
set routing-options router-id 172.16.1.7
Conguring Device R4
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R4:
1. Congure the interfaces.
[edit interfaces]
user@R4# set ge-1/2/0 unit 10 family inet address 10.1.1.10/30
user@R4# set ge-1/2/0 unit 10 family mpls
user@R4# set ge-1/2/1 unit 17 family inet address 10.1.1.17/30
user@R4# set ge-1/2/1 unit 17 family mpls
user@R4# set vt-1/2/0 unit 4 family inet
user@R4# set lo0 unit 4 family inet address 172.16.1.4/32
user@R4# set lo0 unit 104 family inet address 172.16.100.4/32
627
2. Congure MPLS and the signaling protocols on the interfaces.
[edit protocols]
user@R4# set mpls interface all
user@R4# set mpls interface ge-1/2/0.10
user@R4# set rsvp interface all aggregate
user@R4# set ldp interface ge-1/2/0.10
user@R4# set ldp p2mp
3. Congure BGP.
The BGP conguraon enables BGP route ap damping for the inet-mvpn address family. The BGP
conguraon also imports into the roung table the roung policy called dampPolicy. This policy is
applied to neighbor PE Device R2.
[edit protocols bgp group ibgp]
user@R4# set type internal
user@R4# set local-address 172.16.1.4
user@R4# set family inet-vpn unicast
user@R4# set family inet-vpn any
user@R4# set family inet-mvpn signaling damping
user@R4# set neighbor 172.16.1.2 import dampPolicy
user@R4# set neighbor 172.16.1.5
4. Congure an interior gateway protocol.
[edit protocols ospf]
user@R4# set traffic-engineering
[edit protocols ospf area 0.0.0.0]
user@R4# set interface all
user@R4# set interface lo0.4 passive
user@R4# set interface ge-1/2/0.10
5.
Congure a damping policy that uses the nlri-route-type match condion to damp only MVPN route
types 3, 4, and 5.
[edit policy-options policy-statement dampPolicy term term1]
user@R4# set from family inet-mvpn
user@R4# set from nlri-route-type 3
628
user@R4# set from nlri-route-type 4
user@R4# set from nlri-route-type 5
user@R4# set then accept
6. Congure the damping policy to disable BGP route ap damping.
The no-damp policy (damping no-damp disable) causes any damping state that is present in the roung
table to be deleted. The then damping no-damp statement applies the no-damp policy as an acon and has
no from match condions. Therefore, all routes that are not matched by term1 are matched by this
term, with the result that all other MVPN route types are not damped.
[edit policy-options policy-statement dampPolicy]
user@R4# set then damping no-damp
user@R4# set then accept
[edit policy-options]
user@R4# set damping no-damp disable
7. Congure the parent_vpn_routes to accept all other BGP routes that are not from the inet-mvpn address
family.
This policy is applied as an OSPF export policy in the roung instance.
[edit policy-options policy-statement parent_vpn_routes]
user@R4# set from protocol bgp
user@R4# set then accept
8. Congure the VPN roung and forwarding (VRF) instance.
[edit routing-instances vpn-1]
user@R4# set instance-type vrf
user@R4# set interface vt-1/2/0.4
user@R4# set interface ge-1/2/1.17
user@R4# set interface lo0.104
user@R4# set route-distinguisher 100:100
user@R4# set vrf-target target:1:1
user@R4# set protocols ospf export parent_vpn_routes
user@R4# set protocols ospf area 0.0.0.0 interface lo0.104 passive
user@R4# set protocols ospf area 0.0.0.0 interface ge-1/2/1.17
user@R4# set protocols pim rp static address 172.16.100.2
629
user@R4# set protocols pim interface ge-1/2/1.17 mode sparse
user@R4# set protocols mvpn
9. Congure the router ID and the autonomous system (AS) number.
[edit routing-options]
user@R4# set router-id 172.16.1.4
user@R4# set autonomous-system 1001
10. If you are done conguring the device, commit the conguraon.
user@R4# commit
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, show routing-instances, and show routing-options commands. If the output does not display the
intended conguraon, repeat the instrucons in this example to correct the conguraon.
user@R4# show interfaces
ge-1/2/0 {
unit 10 {
family inet {
address 10.1.1.10/30;
}
family mpls;
}
}
ge-1/2/1 {
unit 17 {
family inet {
address 10.1.1.17/30;
}
family mpls;
}
}
vt-1/2/0 {
unit 4 {
family inet;
630
}
}
lo0 {
unit 4 {
family inet {
address 172.16.1.4/32;
}
}
unit 104 {
family inet {
address 172.16.100.4/32;
}
}
}
user@R4# show protocols
rsvp {
interface all {
aggregate;
}
}
mpls {
interface all;
interface ge-1/2/0.10;
}
bgp {
group ibgp {
type internal;
local-address 172.16.1.4;
family inet-vpn {
unicast;
any;
}
family inet-mvpn {
signaling {
damping;
}
}
neighbor 172.16.1.2 {
import dampPolicy;
}
631
neighbor 172.16.1.5;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface all;
interface lo0.4 {
passive;
}
interface ge-1/2/0.10;
}
}
ldp {
interface ge-1/2/0.10;
p2mp;
}
user@R4# show policy-options
policy-statement dampPolicy {
term term1 {
from {
family inet-mvpn;
nlri-route-type [ 3 4 5 ];
}
then accept;
}
then {
damping no-damp;
accept;
}
}
policy-statement parent_vpn_routes {
from protocol bgp;
then accept;
}
damping no-damp {
632
disable;
}
user@R4# show routing-instances
vpn-1 {
instance-type vrf;
interface vt-1/2/0.4;
interface ge-1/2/1.17;
interface lo0.104;
route-distinguisher 100:100;
vrf-target target:1:1;
protocols {
ospf {
export parent_vpn_routes;
area 0.0.0.0 {
interface lo0.104 {
passive;
}
interface ge-1/2/1.17;
}
}
pim {
rp {
static {
address 172.16.100.2;
}
}
interface ge-1/2/1.17 {
mode sparse;
}
}
mvpn;
}
}
user@R4# show routing-optons
router-id 172.16.1.4;
autonomous-system 1001;
633
Vericaon
IN THIS SECTION
Verifying That Route Flap Damping Is Disabled | 634
Verifying Route Flap Damping | 635
Conrm that the conguraon is working properly.
Verifying That Route Flap Damping Is Disabled
Purpose
Verify the presence of the no-damp policy, which disables damping for MVPN route types other than 3, 4,
and 5.
Acon
From operaonal mode, enter the show policy damping command.
user@R4> show policy damping
Default damping information:
Halflife: 15 minutes
Reuse merit: 750 Suppress/cutoff merit: 3000
Maximum suppress time: 60 minutes
Computed values:
Merit ceiling: 12110
Maximum decay: 6193
Damping information for "no-damp":
Damping disabled
Meaning
The output shows that the default damping parameters are in eect and that the no-damp policy is also in
eect for the specied route types.
634
Verifying Route Flap Damping
Purpose
Check whether BGP routes have been damped.
Acon
From operaonal mode, enter the show bgp summary command.
user@R4> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l3vpn.0
6 6 0 0 0 0
bgp.l3vpn.2
0 0 0 0 0 0
bgp.mvpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Accepted/Damped...
172.16.1.2 1001 3159 3155 0 0 23:43:47 Establ
bgp.l3vpn.0: 3/3/3/0
bgp.l3vpn.2: 0/0/0/0
bgp.mvpn.0: 1/1/1/0
vpn-1.inet.0: 3/3/3/0
vpn-1.mvpn.0: 1/1/1/0
172.16.1.5 1001 3157 3154 0 0 23:43:40 Establ
bgp.l3vpn.0: 3/3/3/0
bgp.l3vpn.2: 0/0/0/0
bgp.mvpn.0: 1/1/1/0
vpn-1.inet.0: 3/3/3/0
vpn-1.mvpn.0: 1/1/1/0
Meaning
The Damp State eld shows that zero routes in the bgp.mvpn.0 roung table have been damped.
Further down, the last number in the State eld shows that zero routes have been damped for BGP peer
172.16.1.2.
635
RELATED DOCUMENTATION
Understanding Damping Parameters
Using Roung Policies to Damp BGP Route Flapping | 600
Example: Conguring BGP Route Flap Damping Parameters
636
CHAPTER 8
Tracking Trac Usage with Source Class Usage and
Desnaon Class Usage Acons
IN THIS CHAPTER
Understanding Source Class Usage and Desnaon Class Usage Opons | 637
Source Class Usage Overview | 639
Guidelines for Conguring SCU | 640
System Requirements for SCU | 641
Terms and Acronyms for SCU | 642
Roadmap for Conguring SCU | 643
Roadmap for Conguring SCU with Layer 3 VPNs | 644
Conguring Route Filters and Source Classes in a Roung Policy | 644
Applying the Policy to the Forwarding Table | 646
Enabling Accounng on Inbound and Outbound Interfaces | 646
Conguring Input SCU on the vt Interface of the Egress PE Router | 647
Mapping the SCU-Enabled vt Interface to the VRF Instance | 648
Conguring SCU on the Output Interface | 649
Associang an Accounng Prole with SCU Classes | 650
Verifying Your SCU Accounng Prole | 651
SCU Conguraon | 652
SCU with Layer 3 VPNs Conguraon | 663
Example: Grouping Source and Desnaon Prexes into a Forwarding Class | 673
Understanding Source Class Usage and Desnaon Class Usage Opons
You can maintain packet counts based on the entry and exit points for trac passing through your
network. Entry and exit points are idened by source and desnaon prexes grouped into disjoint
637
sets dened as source classes and
desnaon classes
. You can dene classes based on a variety of
parameters, such as roung neighbors, autonomous systems, and route lters.
Source class usage (SCU) counts packets sent to customers by performing lookups on the IP source
address and the IP desnaon address. SCU makes it possible to track trac originang from specic
prexes on the provider core and desned for specic prexes on the customer edge. You must enable
SCU accounng on both the inbound and outbound physical interfaces.
Desnaon class usage (DCU) counts packets from customers by performing lookups of the
IP desnaon address. DCU makes it possible to track trac originang from the customer edge and
desned for specic prexes on the provider core router.
On T Series Core Routers and M320 Mulservice Edge Routers, the source class and desnaon classes
are not carried across the plaorm fabric. The implicaons of this are as follows:
• On T Series and M320 routers, SCU and DCU accounng is performed before the packet enters the
fabric.
• On T Series and M320 routers, DCU is performed before output lters are evaluated.
• On M Series plaorms, DCU is performed aer output lters are evaluated.
• If an output lter drops trac on M Series devices, the dropped packets are excluded from DCU
stascs.
• If an output lter drops trac on T Series and M320 routers, the dropped packets are included in
DCU stascs.
NOTE: For PTX Series routers with FPC3, and PTX1000 routers, to support SCU and DCU, you
must congure enhanced-mode on the chassis.
On MX Series plaorms with MPC/MIC interfaces, SCU and DCU are performed aer output lters are
evaluated. Packets dropped by output lters are not included in SCU or DCU stascs.
On MX Series plaorms with non-MPC/MIC interfaces, SCU and DCU are performed before output
lters are evaluated. Packets dropped by output lters are included in SCU and DCU stascs.
On PTX Series plaorms, SCU and DCU accounng is performed before output lters are evaluated.
Packets dropped by output lters are included in SCU and DCU stascs. On PTX10003, PTX10004,
PTX10008, PTX10001-36MR, and line card JNP10K-LC1201, the systems prexes with SCU and DCU
classes assigned occupy more space in the forwarding informaon base (FIB) tables than regular routes.
You must limit the number of prexes with non-default class assigned.
On Enhanced Scaling FPCs (T640-FPC1-ES, T640-FPC2-ES, T640-FPC3-ES, T640-FPC4-1P-ES , and
T1600-FPC4-ES), the source class accounng is performed at ingress. Starng with Junos OS Release
638
14.2, the SCU accounng is performed at ingress on a T4000 Type 5 FPC. The implicaons of this are as
follows:
• SCU accounng is performed when packets traverse from T4000 Type 5 FPC (ingress FPC) to
Enhanced Scaling FPCs (egress FPC).
• SCU accounng is performed when packets traverse from Enhanced Scaling FPCs (ingress FPC) to
T4000 Type 5 FPC (egress FPC).
NOTE: When the interface stascs are cleared and then the roung engine is replaced, the SCU
and DCU stascs will not match the stascs of the previous roung engine.
For more informaon about source class usage, see the Roung Policies, Firewall Filters, and Trac
Policers User Guide and the Junos OS Network Interfaces Library for Roung Devices.
Source Class Usage Overview
Source class usage (SCU) is a logical extension of the desnaon class usage (DCU) concept. DCU was
created so that Juniper Networks customers could count on a per-interface basis how much trac was
sent to specied prexes. Figure 38 on page 639 shows a service provider edge (PE) router diagram.
Figure 38: DCU/SCU Concept
The Fast Ethernet interfaces contain inbound trac from customers, and the SONET/SDH interfaces are
connected to outbound public network prexes. With DCU congured on the Fast Ethernet interfaces,
you can track how much trac is sent to a specic prex in the core of the network originang from one
of the specied interfaces (in this case, the Fast Ethernet interfaces).
However, DCU limits your ability to keep track of trac moving in the reverse direcon. It can account
for all trac that arrives on a core interface and heads toward a specic customer, but it cannot count
trac that arrives on a core interface from a specic prex. For example, DCU can process cumulave
639
trac headed toward interface fe-0/0/0, but cannot dierenate between trac coming only from
10.3.0.0/16 and trac coming from all prexes.
You can track source-based trac by using SCU, which allows you to monitor the amount of trac
originang from a specic prex. With this feature, usage can be tracked and customers can be billed for
the trac they receive.
RELATED DOCUMENTATION
System Requirements for SCU | 641
Roadmap for Conguring SCU | 643
Roadmap for Conguring SCU with Layer 3 VPNs | 644
SCU Conguraon | 652
SCU with Layer 3 VPNs Conguraon | 663
Guidelines for Conguring SCU
When you enable SCU or DCU, keep the following informaon in mind:
• In Junos OS Release 5.6 and later for M Series routers only, you can use a source class or a
desnaon class as a match condion in a
rewall lter
. To congure, include the desnaon-class or
source-class statement at the [edit firewall filter
firewall-name
term
term-name
from] hierarchy level. For
more informaon about rewall lters, see the
Junos Policy Framework Conguraon Guide
.
• You can assign up to 126 source classes and 126 desnaon classes.
• When conguring policy acon statements, you can congure only one source class for each
matching route. In other words, more than one source class cannot be applied to the same route.
• A source or desnaon class is applied to a packet only once during the roung table lookup. When a
network prex matches a class-usage policy, SCU is assigned to packets rst; DCU is assigned only if
SCU has not been assigned. Be careful when using both class types, since misconguraon can result
in uncounted packets. The following example explores one potenal mishap:
A packet arrives on a router interface congured for both SCU and DCU. The packet's source address
matches an SCU class, and its desnaon matches a DCU class. Consequently, the packet is
subjected to a source lookup and is marked with the SCU class. The DCU class is ignored. As a result,
the packet is forwarded to the outbound interface with only the SCU class sll intact.
However, the outbound interface lacks an SCU conguraon. When the packet is ready to leave the
router, the router detects that the output interface is not congured for SCU and the packet is not
640
counted by SCU. Likewise, even though the prex matched the DCU prex, the DCU counters do not
increment because DCU was superseded by SCU at the inbound interface.
To solve this problem, make sure you congure both the inbound and outbound interfaces completely or
congure only one class type per interface per direcon.
• Classes cannot be mapped to directly connected prexes congured on local interfaces. This is true
for DCU and SCU classes.
• If you use mulple terms within a single policy, you only need to congure the policy name and apply
it to the forwarding table once. This makes it easier to change opons within your terms without
having to recongure the main policy.
• Execute command line interface (CLI) show commands and accounng proles at the desired
outbound interface to track SCU trac. SCU counters increment at the SCU output interface.
• Apply your classes to the inbound and outbound interfaces by means of the input and output SCU
interface parameters.
• On M320 and T Series routers, the source and desnaon classes are not carried across the plaorm
fabric. For these routers, SCU and DCU accounng is performed before the packet enters the fabric
and DCU is performed before output lters are evaluated.
• If an output lter drops trac on M Series routers other than the M120 router and M320 router, the
dropped packets are excluded from DCU stascs. If an output lter drops trac on M320 and T
Series routers, the dropped packets are included in DCU stascs.
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU | 643
SCU Conguraon | 652
System Requirements for SCU
To implement SCU, your system must meet these requirements:
• Junos OS Release 8.2 or later for M120 and MX Series router support
• Junos OS Release 6.2 or later for IPv6 SCU
641
• Junos OS Release 5.6 or later to use a source class or a desnaon class as a match condion in a
rewall lter
• Junos OS Release 5.4 or later for IPv4 SCU
• Three Juniper Networks M Series, MX Series, or T Series routers for basic SCU and ve routers for
SCU with Layer 3 VPNs. One router acts as a source class usage transit router, and the other routers
are used to generate trac or parcipate in the Layer 3 VPN.
• For M Series and T Series routers, a Tunnel Services PIC for SCU with Layer 3 VPNs
RELATED DOCUMENTATION
Source Class Usage Overview | 639
Roadmap for Conguring SCU | 643
Roadmap for Conguring SCU with Layer 3 VPNs | 644
SCU Conguraon | 652
SCU with Layer 3 VPNs Conguraon | 663
Terms and Acronyms for SCU
IN THIS SECTION
desnaon class usage (DCU) | 642
source class usage (SCU) | 643
source address (SA) | 643
desnaon address (DA) | 643
desnaon class usage (DCU)
A method of grouping certain types of trac and monitoring these groups through CLI show commands,
accounng proles, or SNMP. DCU uses a desnaon address lookup when determining group
membership. For more informaon about DCU, see the
Junos Policy Framework Conguraon Guide
.
642
source class usage (SCU)
A method of grouping certain types of trac and monitoring these groups through CLI show commands,
accounng proles, or SNMP. SCU uses a source address lookup when determining group membership.
For more informaon about SCU, see the
Junos Policy Framework Conguraon Guide
.
source address (SA)
The IP address of a device sending a packet. This address is included in the IP header and is analyzed by
the router for a variety of services, including source-based ltering, policing, class of service (CoS), and
SCU.
desnaon address (DA)
The IP address of a device intended as the receiver for a packet. This address is included in the IP header
and is the main address analyzed by the router during roung table lookups and DCU.
Roadmap for Conguring SCU
To congure source class usage (SCU), you must:
1. Create a roung policy that includes prex route lters that indicate the IPv4 or IPv6 source
addresses to monitor. See "Conguring Route Filters and Source Classes in a Roung Policy" on page
644.
2. Apply the lters to the forwarding table. See "Applying the Policy to the Forwarding Table" on page
646.
3. Enable accounng on the inbound and outbound interfaces. See "Enabling Accounng on Inbound
and Outbound Interfaces" on page 646.
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
SCU Conguraon | 652
643
Roadmap for Conguring SCU with Layer 3 VPNs
SCU can be implemented over regular interfaces; it is also used in combinaon with Layer 3 VPNs.
When you view SCU trac on an ingress provider edge (PE) router, use the standard procedure outlined
in "Roadmap for Conguring SCU" on page 643. However, when you enable packet counng for Layer 3
VPNs at the egress point of the MPLS tunnel, you need to take some addional steps, as follows:
1. Congure SCU on the virtual loopback tunnel (vt) interface of the egress PE router. See "Conguring
Input SCU on the vt Interface of the Egress PE Router" on page 647.
2. Map the SCU-enabled input interface of that router to the virtual roung and forwarding (VRF)
instance. See "Mapping the SCU-Enabled vt Interface to the VRF Instance" on page 648.
3. Congure SCU on the output interface of the egress router. See "Conguring SCU on the Output
Interface" on page 649.
4. Congure an accounng prole and associate the source class with that accounng prole. You can
also specify the lename for the data capture, a class usage prole name, and an interval indicang
how oen you want the SCU informaon to be saved. See "Associang an Accounng Prole with
SCU Classes" on page 650.
NOTE: SCU is not supported over Layer 2 VPNs.
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
SCU with Layer 3 VPNs Conguraon | 663
Conguring Route Filters and Source Classes in a Roung Policy
Begin conguring SCU by creang prex route lters in a policy statement. These prexes indicate the
IPv4 or IPv6 source addresses to monitor. Within the policy statement, you must dene and name the
source classes aached to the lters.
[edit policy-options]
policy-statement
policy-name
{
644
term
term-name
{
from {
route-filter
address
/
prefix
;
}
then source-class
class-name
;
}
}
NOTE: When conguring policy acon statements, you can congure only one source class for
each matching route. In other words, more than one source class cannot be applied to the same
route.
An alternate conguraon method, using the forwarding-class policy acon, is even more exible. It
allows your IPv4 or IPv6 route lters to apply to an SCU prole, a DCU prole, or both simultaneously.
Addionally, if you have only one term, you can implement the from and then statements at the [edit
policy-options policy-statement
policy-name
] hierarchy level.
[edit policy-options]
policy-statement
policy-name
{
from {
route-filter 105.15.0.0/16 orlonger;
}
then forwarding-class
class-name
;
}
A third opon is the exisng DCU parameter of desnaon-class. For more informaon on DCU, see the
Junos Policy Framework Conguraon Guide
.
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU | 643
SCU Conguraon | 652
645
Applying the Policy to the Forwarding Table
Next, apply the policy you created to the forwarding table. When you apply the policy, the network
prexes you dened are marked with the appropriate source class.
[edit routing-options]
forwarding-table {
export
policy-name
;
}
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU | 643
SCU Conguraon | 652
Enabling Accounng on Inbound and Outbound Interfaces
Unlike DCU, which only requires implementaon on a single interface, accounng for SCU must be
enabled on two interfaces: the inbound and outbound physical or logical interfaces traversed by the
source class. You must dene explicitly the two interfaces on which SCU monitored trac is expected to
arrive and depart. This is because SCU performs two lookups in the roung table: a source address (SA)
and a desnaon address (DA) lookup. In contrast, DCU only has a single desnaon address lookup. By
specifying the addresses involved in the addional SCU SA lookup, you minimize the performance
impact on your router.
An individual SCU interface can be congured as an input interface, an output interface, or both. SCU
can be enabled in an IPv4 (family inet) or IPv6 (family inet6) network. To congure SCU accounng,
include the source-class-usage statement at the [edit interfaces
interface-name
unit
logical-unit-number
family
(inet | inet 6) accounting] hierarchy level:
[edit]
interfaces {
interface-name
{
unit
unit-number
{
family (inet | inet6) {
646
accounting {
source-class-usage {
(input | output | input output);
}
destination-class-usage;
}
}
}
}
}
Aer the full SCU conguraon is enabled, every packet arriving on an SCU input interface is subjected
to an SA-based lookup and then a DA-based lookup. In addion, an individual set of counters for every
congured SCU class is maintained by the router on a per-interface and per-protocol family basis.
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU | 643
SCU Conguraon | 652
Conguring Input SCU on the vt Interface of the Egress PE Router
To enable SCU in a Layer 3 VPN, congure source class usage on the virtual loopback tunnel (vt)
interface of the egress PE router that is either congured for or equipped with a Tunnel PIC. The
interface is equivalent to the inbound SCU interface, so use the input statement at the [edit interfaces
vt-
interface-number
unit 0 family inet accounting source-class-usage] hierarchy level:
[edit]
interfaces {
vt-0/3/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
input;
}
647
}
}
}
}
}
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU with Layer 3 VPNs | 644
SCU with Layer 3 VPNs Conguraon | 663
Mapping the SCU-Enabled vt Interface to the VRF Instance
Next, include the VPN loopback tunnel interface in the desired VRF instance at the [edit routing-instances
routing-instance-name
] hierarchy level:
[edit]
routing-instances {
routing-instance-name
{
instance-type vrf;
interface at-2/1/1.0;
interface vt-0/3/0.0;
route-distinguisher 10.250.14.225:100;
vrf-import import-policy-name;
vrf-export export-policy-name;
protocols {
bgp {
group to-r4 {
local-address 10.20.253.1;
peer-as 400;
neighbor 10.20.253.2;
}
}
}
648
}
}
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU with Layer 3 VPNs | 644
SCU with Layer 3 VPNs Conguraon | 663
Conguring SCU on the Output Interface
Since VPN trac enters the egress router through the VPN loopback tunnel interface, you sll need to
determine the exit interface for this trac. To complete your SCU conguraon, congure the output
version of source class usage on the exit interface of your egress router:
[edit interfaces]
at-1/1/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
output;
}
}
}
}
}
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU with Layer 3 VPNs | 644
SCU with Layer 3 VPNs Conguraon | 663
649
Associang an Accounng Prole with SCU Classes
Once your source classes are dened, implemented on the inbound and outbound interfaces, and
applied to the forwarding table, you are ready to associate the source class with an accounng prole.
Congure the accounng prole at the [edit accounting-options class-usage-profile] hierarchy level. You can
associate either an SCU source class or a DCU desnaon class with the accounng prole. You can also
specify the lename for the data capture, a class usage prole name, and an interval (in minutes)
indicang how oen you want the SCU informaon to be saved to the le.
[edit]
accounting-options {
file
filename
;
class-usage-profile
profile-name
{
file
filename
;
interval
minutes
;
source-classes {
source-class-name
;
}
destination-classes {
destination-class-name
;
}
}
}
NOTE: SCU accounng occurs on the outbound interface before output lter processing. If an
SCU-marked packet is discarded in the router, the SCU counters can indicate more trac than
actually exists. You must use lter counters or traceopons logs to ensure that all packets
dropped by the SCU lter are recorded. If logged, you can subtract the discarded packets from
the SCU counter tallies and calculate the true trac prole.
Because DCU accounng occurs aer the ltering process, DCU is unaected by this disclaimer.
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU with Layer 3 VPNs | 644
SCU with Layer 3 VPNs Conguraon | 663
650
Verifying Your SCU Accounng Prole
IN THIS SECTION
Purpose | 651
Acon | 651
Purpose
To view the results of the SCU accounng prole you created.
Acon
Navigate to the /var/log directory of your router. It should contain the designated class usage prole log.
The layout of an SCU prole looks like this:
profile_name,epoch-timestamp,interface-name,source-class-name,packet-count,
byte-count
An example of the actual output from a prole looks like this:
scu_profile,980313078,ge-1/0/0.0,gold,82,6888
scu_profile,980313078,ge-1/0/0.0,silver,164,13776
scu_profile,980313078,ge-1/0/0.0,bronze,0,0
scu_profile,980313678,ge-1/0/0.0,gold,82,6888
scu_profile,980313678,ge-1/0/0.0,silver,246,20664
scu_profile,980313678,ge-1/0/0.0,bronze,0,0
To view the parameters of your SCU accounng prole, you can use the show accounting-options class-
usage-profile
scu-profile-name
command.
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
651
Associang an Accounng Prole with SCU Classes | 650
SCU Conguraon
IN THIS SECTION
Conguring SCU | 652
Verifying Your Work | 656
Conguring SCU
Figure 39: SCU Topology Diagram
Figure 39 on page 652 shows a basic SCU conguraon with three routers. Source routers A and B use
loopback addresses as the prexes to be monitored. Most of the conguraon tasks and actual
monitoring occurs on transit Router SCU.
Begin your conguraon on Router A. The loopback address on Router A contains the origin of the
prex that is to be assigned to source class A on Router SCU. However, no SCU processing happens on
this router. Therefore, congure Router A for basic OSPF roung and include your loopback interface
and interface so-0/0/2 in the OSPF process.
Router A:
[edit]
interfaces {
so-0/0/2 {
unit 0 {
652
family inet {
address 10.255.50.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.255.192.10/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface so-0/0/2.0;
interface lo0.0;
}
}
}
Router SCU handles the bulk of the acvity in this example. On Router SCU, enable source class usage
on the inbound and outbound interfaces at the [edit interfaces
interface-name
unit
unit-number
family inet
accounting] hierarchy level. Make sure you specify the expected trac: input, output, or, in this case,
both.
Next, congure a route lter policy statement that matches the prexes of the loopback addresses from
routers A and B. Include statements in the policy that classify packets from Router A in one group
named scu-class-a and packets from Router B in a second class named scu-class-b. Noce the ecient use
of a single policy containing mulple terms.
Last, apply the policy to the forwarding table.
Router SCU
[edit]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
accounting {
source-class-usage {
653
input;
output;
}
}
address 10.255.50.1/24;
}
}
}
so-0/0/3 {
unit 0 {
family inet {
accounting {
source-class-usage {
input;
output;
}
}
address 10.255.10.3/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.255.6.111/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface so-0/0/1.0;
interface so-0/0/3.0;
}
}
}
routing-options {
forwarding-table {
export scu-policy;
}
}
policy-options {
654
policy-statement scu-policy {
term 0 {
from {
route-filter 10.255.192.0/24 orlonger;
}
then source-class scu-class-a;
}
term 1 {
from {
route-filter 10.255.165.0/24 orlonger;
}
then source-class scu-class-b;
}
}
}
Complete the conguraon tasks on Router B. Just as Router A provides a source prex, Router B’s
loopback address matches the prex assigned to scu-class-b on Router SCU. Again, no SCU processing
happens on this router, so congure Router B for basic OSPF roung and include your loopback
interface and interface so-0/0/4 in the OSPF process.
Router B:
[edit]
interfaces {
so-0/0/4 {
unit 0 {
family inet {
address 10.255.10.4/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.255.165.226/32;
}
}
}
}
protocols {
ospf {
655
area 0.0.0.0 {
interface so-0/0/4.0;
interface lo0.0;
}
}
}
Verifying Your Work
To verify that SCU is funconing properly, use the following commands:
• show interfaces
interface-name
statistics
• show interfaces
interface-name
(extensive | detail)
• show route (extensive | detail)
• show interfaces source-class
source-class-name interface-name
• clear interface
interface-name
statistics
You should always verify SCU stascs at the outbound SCU interface on which you congured the
output statement. You can perform the following three steps to check the funconality of SCU:
1. Clear all counters on your SCU-enabled router and verify that they are empty.
2. Send a ping from one edge router to another edge router to generate SCU trac across the SCU-
enabled router.
3. Verify that the counters are incremenng correctly on the outbound interface.
The following secon shows the output of these commands as used with the conguraon example.
user@scu> clear interfaces statistics all
user@scu> show interfaces so-0/0/1.0 statistics
Logical interface so-0/0/1.0 (Index 4) (SNMP ifIndex 119)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Source class Packets Bytes
scu-class-a 0 0
scu-class-b 0 0
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.50/24, Local: 10.255.50.1
656
user@scu> show interfaces so-0/0/3.0 statistics
Logical interface so-0/0/3.0 (Index 6) (SNMP ifIndex 113)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Source class Packets Bytes
scu-class-a 0 0
scu-class-b 0 0
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.10/24, Local: 10.255.10.3
user@scu> show interfaces source-class scu-class-a so-0/0/3.0
Protocol inet
Source class Packets Bytes
scu-class-a 0 0
user@scu> show interfaces source-class scu-class-b so-0/0/1.0
Protocol inet
Source class Packets Bytes
scu-class-b 0 0
user@routerB> ping 10.255.192.10 source 10.255.165.226 rapid 10000
user@routerA> ping 10.255.165.226 source 10.255.192.10 rapid 10000
user@scu> show interfaces source-class scu-class-a so-0/0/3.0
Protocol inet
Source class Packets Bytes
scu-class-a 20000 1680000
user@scu> show interfaces source-class scu-class-a so-0/0/1.0
Protocol inet
Source class Packets Bytes
scu-class-b 20000 1680000
user@scu> show interfaces so-0/0/3.0 statistics
Logical interface so-0/0/3.0 (Index 6) (SNMP ifIndex 113)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Source class Packets Bytes
scu-class-a 20000 1680000
scu-class-b 0 0
Addresses, Flags: Is-Preferred Is-Primary
657
Destination: 10.255.10/24, Local: 10.255.10.3
user@scu> show interfaces so-0/0/1.0 statistics
Logical interface so-0/0/1.0 (Index 4) (SNMP ifIndex 119)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Source class Packets Bytes
scu-class-a 0 0
scu-class-b 20000 1680000
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.50/24, Local: 10.255.50.1
user@scu> show route extensive 10.255.192.0
inet.0: 26 destinations, 28 routes (25 active, 0 holddown, 1 hidden)
10.255.192.0/18 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.255.192.0/18 -> {so-0/0/1.0}
Source class: scu-class-a
*OSPF Preference: 150
Next hop: via so-0/0/1.0, selected
State: <Active Int Ext>
Age: 2:49:31 Metric: 0 Tag: 0
Task: OSPF
Announcement bits (1): 0-KRT
AS path: I
user@scu> show route extensive 10.255.165.0
inet.0: 26 destinations, 28 routes (25 active, 0 holddown, 1 hidden)
10.255.165.0/20 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.255.165.0/20 -> {so-0/0/3.0}
Source class: scu-class-b
*OSPF Preference: 150
Next hop: via so-0/0/3.0, selected
State: <Active Int Ext>
Age: 2:49:31 Metric: 0 Tag: 0
658
Task: OSPF
Announcement bits (1): 0-KRT
AS path: I
user@scu> show interfaces so-0/0/1 detail
Physical interface: so-0/0/1, Enabled, Physical link is Up
Interface index: 12, SNMP ifIndex: 17, Generation: 11
Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3,
Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : Keepalives
Hold-times : Up 0 ms, Down 0 ms
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive statistics:
Input : 46 (last seen 00:00:01 ago)
Output: 45 (last sent 00:00:00 ago)
LCP state: Opened
NCP state: inet: Opened, inet6: Not-configured, iso: Not-configured, mpls:
Not-configured
CHAP state: Not-configured
Last flapped : 2002-04-19 11:49:22 PDT (03:10:09 ago)
Statistics last cleared: 2002-04-19 14:52:04 PDT (00:07:27 ago)
Traffic statistics:
Input bytes : 1689276 40 bps
Output bytes : 1689747 48 bps
Input packets: 20197 0 pps
Output packets: 20200 0 pps
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 20053 20053 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 146 146 0
SONET alarms : None
SONET defects : None
Logical interface so-0/0/1.0 (Index 4) (SNMP ifIndex 119) (Generation 3)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Flags: SCU-in, SCU-out
Generation: 6 Route table: 0
659
Source class Packets Bytes
scu-class-a 0 0
scu-class-b 20000 1680000
Filters: Input: icmp-so-0/0/1.0-i, Output: icmp-so-0/0/1.0-o
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.50/24, Local: 10.255.50.1, Broadcast: Unspecified,
Generation: 8
user@scu> show interfaces so-0/0/1 extensive
Physical interface: so-0/0/1, Enabled, Physical link is Up
Interface index: 12, SNMP ifIndex: 17, Generation: 11
Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3,
Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : Keepalives
Hold-times : Up 0 ms, Down 0 ms
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive statistics:
Input : 51 (last seen 00:00:04 ago)
Output: 50 (last sent 00:00:05 ago)
LCP state: Opened
NCP state: inet: Opened, inet6: Not-configured, iso: Not-configured, mpls:
Not-configured
CHAP state: Not-configured
Last flapped : 2002-04-19 11:49:22 PDT (03:11:05 ago)
Statistics last cleared: 2002-04-19 14:52:04 PDT (00:08:23 ago)
Traffic statistics:
Input bytes : 1689884 264 bps
Output bytes : 1690388 280 bps
Input packets: 20215 0 pps
Output packets: 20217 0 pps
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0,
Bucket drops: 0, Policed discards: 0, L3 incompletes: 0,
L2 channel errors: 0, L2 mismatch timeouts: 0, HS link CRC errors: 0,
HS link FIFO overflows: 0
Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, Aged packets: 0,
HS link FIFO underflows: 0
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 20053 20053 0
1 expedited-fo 0 0 0
660
2 assured-forw 0 0 0
3 network-cont 164 164 0
SONET alarms : None
SONET defects : None
SONET PHY: Seconds Count State
PLL Lock 0 0 OK
PHY Light 0 0 OK
SONET section:
BIP-B1 0 0
SEF 0 0 OK
LOS 0 0 OK
LOF 0 0 OK
ES-S 0
SES-S 0
SEFS-S 0
SONET line:
BIP-B2 0 0
REI-L 0 0
RDI-L 0 0 OK
AIS-L 0 0 OK
BERR-SF 0 0 OK
BERR-SD 0 0 OK
ES-L 0
SES-L 0
UAS-L 0
ES-LFE 0
SES-LFE 0
UAS-LFE 0
SONET path:
BIP-B3 0 0
REI-P 0 0
LOP-P 0 0 OK
AIS-P 0 0 OK
RDI-P 0 0 OK
UNEQ-P 0 0 OK
PLM-P 0 0 OK
ES-P 0
SES-P 0
UAS-P 0
ES-PFE 0
SES-PFE 0
UAS-PFE 0
Received SONET overhead:
661
F1 : 0x00, J0 : 0x00, K1 : 0x00, K2 : 0x00
S1 : 0x00, C2 : 0xcf, C2(cmp) : 0xcf, F2 : 0x00
Z3 : 0x00, Z4 : 0x00, S1(cmp) : 0x00, V5 : 0x00
V5(cmp) : 0x00
Transmitted SONET overhead:
F1 : 0x00, J0 : 0x01, K1 : 0x00, K2 : 0x00
S1 : 0x00, C2 : 0xcf, F2 : 0x00, Z3 : 0x00
Z4 : 0x00, V5 : 0x00
Received path trace: e so-0/0/1
65 20 73 6f 2d 30 2f 30 2f 31 00 00 00 00 00 00 e so-0/0/1......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 0a ................
Transmitted path trace: scu so-0/0/1
67 68 62 20 73 6f 2d 30 2f 30 2f 31 00 00 00 00 scu so-0/0/1....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
HDLC configuration:
Policing bucket: Disabled
Shaping bucket : Disabled
Giant threshold: 4484, Runt threshold: 3
Packet Forwarding Engine configuration:
Destination slot: 0, PLP byte: 1 (0x00)
CoS transmit queue Bandwidth Buffer Priority Limit
% bps % bytes
0 best-effort 0 0 0 0 low none
1 expedited-forwarding 0 0 0 0 low none
2 assured-forwarding 0 0 0 0 low none
3 network-control 0 0 0 0 low none
Logical interface so-0/0/1.0 (Index 4) (SNMP ifIndex 119) (Generation 3)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Flags: SCU-in, SCU-out
Generation: 6 Route table: 0
Source class Packets Bytes
scu-class-a 0 0
scu-class-b 20000 1680000
Filters: Input: icmp-so-0/0/1.0-i, Output: icmp-so-0/0/1.0-o
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.50/24, Local: 10.255.50.1, Broadcast: Unspecified,
Generation: 8
662
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Roadmap for Conguring SCU | 643
SCU with Layer 3 VPNs Conguraon
IN THIS SECTION
Conguring SCU in a Layer 3 VPN | 663
Verifying Your Work | 672
Conguring SCU in a Layer 3 VPN
Figure 40: SCU in a Layer 3 VPN Topology Diagram
Figure 40 on page 663 displays a Layer 3 VPN topology. CE1 and CE2 are customer edge (CE) routers
connected by a VPN through provider routers PE1, P0, and PE2. EBGP is established between routers
CE1 and PE1, IBGP connects routers PE1 and PE2 over an IS-IS/MPLS/LDP core, and a second EBGP
connecon ows between routers PE2 and CE2.
On Router CE1, begin your VPN by seng up an EBGP connecon to PE1. Install a stac route of
10.114.1.0/24 and adverse this route to your EBGP neighbor.
663
Router CE1
[edit]
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.20.250.1/30;
}
}
}
}
routing-options {
static {
route 10.114.1.0/24 reject;
}
autonomous-system 100;
}
protocols {
bgp {
group to-pe1 {
local-address 10.20.250.1;
export inject-direct;
peer-as 300;
neighbor 10.20.250.2;
}
}
}
policy-options {
policy-statement inject-direct {
term 1 {
from {
protocol static;
route-filter 10.114.1.0/24 exact;
}
then accept;
}
term 2 {
from protocol direct;
then accept;
}
664
}
}
On PE1, complete the EBGP connecon to CE1 through a VRF roung instance. Set an export policy for
your VRF instance that puts BGP trac into a community, and an import policy that accepts like
community trac from your VPN neighbor. Lastly, congure an IBGP relaonship to Router PE2 that
runs over an IS-IS, MPLS, and LDP core.
Router PE1
[edit]
interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 10.20.250.2/30;
}
}
}
so-0/2/1 {
unit 0 {
family inet {
address 10.20.251.1/30;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.250.245.245/32;
}
family iso;
family mpls;
}
}
}
routing-options {
autonomous-system 300;
}
protocols {
665
mpls {
interface so-0/2/1;
}
bgp {
group ibgp {
type internal;
local-address 10.250.245.245;
family inet-vpn {
unicast;
}
neighbor 10.250.71.14;
}
}
isis {
interface so-0/2/1;
}
ldp {
interface so-0/2/1;
}
}
policy-options {
policy-statement red-import {
from {
protocol bgp;
community red-com;
}
then accept;
}
policy-statement red-export {
from protocol bgp;
then {
community add red-com;
accept;
}
}
community red-com members target:20:20;
}
routing-instances {
red {
instance-type vrf;
interface ge-0/0/1.0;
route-distinguisher 10.250.245.245:100;
vrf-import red-import;
666
vrf-export red-export;
protocols {
bgp {
group to-ce1 {
local-address 10.20.250.2;
peer-as 100;
neighbor 10.20.250.1;
}
}
}
}
}
On P0, connect the IBGP neighbors located at PE1 and PE2. Remember to include VPN-related
protocols (MPLS, LDP, and IGP) on all interfaces.
Router P0
[edit]
interfaces {
so-0/1/0 {
unit 0 {
family inet {
address 10.20.252.1/30;
}
family iso;
family mpls;
}
}
so-0/2/0 {
unit 0 {
family inet {
address 10.20.251.2/30;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.250.245.246/32;
667
}
family iso;
family mpls;
}
}
}
routing-options {
autonomous-system 300;
}
protocols {
mpls {
interface so-0/1/0;
interface so-0/2/0;
}
isis {
interface all;
}
ldp {
interface all;
}
}
On PE2, complete the IBGP relaonship to Router PE1. Establish an EBGP connecon to CE2 through a
VRF roung instance. Set an export policy for the VRF instance that places BGP trac into a
community, and an import policy that accepts like community trac from the VPN neighbor. Next,
establish a policy that adds the stac route from CE1 to a source class called GOLD1. Also, export this SCU
policy into the forwarding table. Finally, set your vt interface as the SCU input interface and establish the
CE-facing interface so-0/0/0 as the SCU output interface.
Router PE2
[edit]
interfaces {
so-0/1/1 {
unit 0 {
family inet {
address 10.20.252.2/30;
}
family iso;
family mpls;
}
}
668
so-0/0/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
output;
}
}
address 10.20.253.1/30;
}
}
}
vt-4/1/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
input;
}
}
address 10.250.71.14/32;
}
family iso;
family mpls;
}
}
}
routing-options {
autonomous-system 300;
forwarding-table {
export inject-customer2-dest-class;
}
}
protocols {
mpls {
interface so-0/1/1;
interface vt-4/1/0;
}
bgp {
group ibgp {
type internal;
local-address 10.250.71.14;
family inet-vpn {
669
unicast;
}
neighbor 10.250.245.245;
}
}
isis {
interface so-0/1/1;
}
ldp {
interface so-0/1/1;
}
}
routing-instances {
red {
instance-type vrf;
interface so-0/0/0.0;
interface vt-4/1/0.0;
route-distinguisher 10.250.71.14:100;
vrf-import red-import;
vrf-export red-export;
protocols {
bgp {
group to-ce2 {
local-address 10.20.253.1;
peer-as 400;
neighbor 10.20.253.2;
}
}
}
}
}
policy-options {
policy-statement red-import {
from {
protocol bgp;
community red-com;
}
then accept;
}
policy-statement red-export {
from protocol bgp;
then {
community add red-com;
670
accept;
}
}
policy-statement inject-customer2-dest-class {
term term-gold1-traffic {
from {
route-filter 10.114.1.0/24 exact;
}
then source-class GOLD1;
}
}
community red-com members target:20:20;
}
On Router CE2, complete the VPN path by nishing the EBGP connecon to PE2.
Router CE2
[edit]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.20.253.2/30;
}
}
}
}
routing-options {
autonomous-system 400;
}
protocols {
bgp {
group to-pe2 {
local-address 10.20.253.2;
export inject-direct;
peer-as 300;
neighbor 10.20.253.1;
}
}
}
policy-options {
671
policy-statement inject-direct {
from {
protocol direct;
}
then accept;
}
}
Verifying Your Work
To verify that SCU is funconing properly in the Layer 3 VPN, use the following commands:
• show interfaces
interface-name
statistics
• show interfaces source-class
source-class-name interface-name
• show interfaces
interface-name
(extensive | detail)
• show route (extensive | detail)
• clear interface
interface-name
statistics
You should always verify SCU stascs at the outbound SCU interface on which you congured the
output statement. To check SCU funconality, follow these steps:
1. Clear all counters on your SCU-enabled router and verify they are empty.
2. Send a ping from the ingress CE router to the second CE router to generate SCU trac across the
SCU-enabled VPN route.
3. Verify that the counters are incremenng correctly on the outbound interface.
The following secon shows the output of these commands used with the conguraon example.
user@pe2> clear interfaces statistics all
user@pe2> show interfaces so-0/0/0.0 statistics
Logical interface so-0/0/0.0 (Index 6) (SNMP ifIndex 113)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Source class Packets Bytes
GOLD1 0 0
Addresses, Flags: Is-Preferred Is-Primary
672
user@pe2> show interfaces source-class GOLD1 so-0/0/0.0
Protocol inet
Source class Packets Bytes
GOLD1 0 0
user@ce1> ping 10.20.253.2 source 10.114.1.1 rapid count 10000
user@scu> show interfaces source-class GOLD1 so-0/0/0.0
Protocol inet
Source class Packets Bytes
GOLD1 20000 1680000
user@scu> show interfaces so-0/0/0.0 statistics
Logical interface so-0/0/0.0 (Index 6) (SNMP ifIndex 113)
Flags: Point-To-Point SNMP-Traps Encapsulation: PPP
Protocol inet, MTU: 4470
Source class Packets Bytes
GOLD1 20000 1680000
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.20.253/24, Local: 10.20.253.1
RELATED DOCUMENTATION
Source Class Usage Overview | 639
System Requirements for SCU | 641
Example: Grouping Source and Desnaon Prexes into a Forwarding
Class
IN THIS SECTION
Requirements | 674
Overview | 674
Conguraon | 677
Vericaon | 684
673
This example shows how to group source and desnaon prexes into a forwarding class.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
This example uses three roung devices: a customer edge (CE) device, a provider edge (PE) device, and a
provider core (P) device.
Figure 41 on page 674 shows the sample network.
Figure 41: SCU and DCU Sample Network
Source class usage (SCU) counts packets sent to the customer edge by performing lookup on the IP
source address and the IP desnaon address. SCU makes it possible to track trac originang from
specic prexes on the provider core and desned for specic prexes on the customer edge.
DCU counts packets from customers by performing a lookup of the IP desnaon address. DCU makes
it possible to track trac originang from the customer edge and desned for specic prexes on the
provider core router.
On Device PE’s fe-1/2/1 interface, facing the provider core (represented by Device P), SCU input is
congured with the
source-class-usage input
statement to track trac originang at Device P and desned
674
to Device CE. On this same interface, the destination-class-usage input statement is congured to track
trac originang at Device CE desned to the provider core.
user@PE# show interfaces fe-1/2/1 unit 0 family inet
accounting {
source-class-usage {
input; # tracks traffic destined to customer edge
}
destination-class-usage; # tracks traffic destined to provider core
}
address 10.1.0.1/30;
Unlike desnaon class usage (DCU), which only requires implementaon on a single interface,
accounng for SCU must be enabled on two interfaces: the inbound and outbound interfaces traversed
by the source class. You must dene explicitly the two interfaces on which SCU monitored trac is
expected to arrive and depart. This is because SCU performs two lookups in the roung table: a source
address (SA) and a desnaon address (DA) lookup. In contrast, DCU only has a single desnaon
address lookup.
On Device PE’s fe-1/2/0 interface, facing Device CE, SCU output is congured with the source-class-
usage output statement.
user@PE# show interfaces fe-1/2/0 unit 0 family inet
accounting {
source-class-usage {
output;
}
}
address 10.0.0.2/30;
To account for trac desned to the customer, the policy called scu_class uses route lters to place
trac into the gold1, gold2, and gold3 classes.
user@PE# show policy-options
policy-statement scu_class {
term gold1 {
from {
route-filter 172.16.2.0/24 orlonger;
}
then source-class gold1;
}
675
term gold2 {
from {
route-filter 172.16.3.0/24 orlonger;
}
then source-class gold2;
}
term gold3 {
from {
route-filter 172.16.4.0/24 orlonger;
}
then source-class gold3;
}
}
To account for trac desned to the provider, the policy called dcu_class uses route lters to place
trac into the silver1, silver2, and silver3 classes.
user@PE# show policy-options
policy-statement dcu_class {
term silver1 {
from {
route-filter 172.16.5.0/24 orlonger;
}
then destination-class silver1;
}
term silver2 {
from {
route-filter 172.16.6.0/24 orlonger;
}
then destination-class silver2;
}
term silver3 {
from {
route-filter 172.16.7.0/24 orlonger;
}
then destination-class silver3;
}
}
676
The policies are then applied to the forwarding table.
forwarding-table {
export [ dcu_class scu_class ];
}
The example uses stac routes to provide connecvity and loopback interface addresses for tesng the
operaon.
"CLI Quick Conguraon" on page 677 shows the conguraon for all of the devices in Figure 41 on
page 674.
The secon "No Link Title" on page 680 describes the steps on Device PE.
Conguraon
IN THIS SECTION
Procedure | 677
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device CE
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 interfaces lo0 unit 0 family inet address 172.16.0.1/32
set interfaces lo0 unit 0 family inet address 172.16.0.1/32
set interfaces lo0 unit 0 family inet address 172.16.0.1/32
set interfaces lo0 unit 0 family inet address 172.16.0.1/32
set interfaces lo0 unit 0 family inet address 172.16.0.1/32
set interfaces lo0 unit 0 family inet address 172.16.0.1/32
set protocols bgp group ext type external
677
set protocols bgp group ext export send-direct
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.0.0.2
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.1.0.0/30 next-hop 10.0.0.2
set routing-options autonomous-system 100
Device PE
set interfaces fe-1/2/0 unit 0 family inet accounting source-class-usage output
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 accounting source-class-usage input
set interfaces fe-1/2/1 unit 0 family inet accounting destination-class-usage
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 ext type external
set protocols bgp group ext export send-direct
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 dcu_class term silver1 from route-filter 172.16.5.0/24
orlonger
set policy-options policy-statement dcu_class term silver1 then destination-class silver1
set policy-options policy-statement dcu_class term silver2 from route-filter 172.16.6.0/24
orlonger
set policy-options policy-statement dcu_class term silver2 then destination-class silver2
set policy-options policy-statement dcu_class term silver3 from route-filter 172.16.7.0/24
orlonger
set policy-options policy-statement dcu_class term silver3 then destination-class silver3
set policy-options policy-statement scu_class term gold1 from route-filter 172.16.2.0/24 orlonger
set policy-options policy-statement scu_class term gold1 then source-class gold1
set policy-options policy-statement scu_class term gold2 from route-filter 172.16.3.0/24 orlonger
set policy-options policy-statement scu_class term gold2 then source-class gold2
set policy-options policy-statement scu_class term gold3 from route-filter 172.16.4.0/24 orlonger
set policy-options policy-statement scu_class term gold3 then source-class gold3
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options autonomous-system 200
678
set routing-options forwarding-table export dcu_class
set routing-options forwarding-table export scu_class
Device P
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 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.1.0.1
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.0.0.0/30 next-hop 10.1.0.1
set routing-options static route 172.16.2.0/24 discard
set routing-options static route 172.16.3.0/24 discard
set routing-options static route 172.16.4.0/24 discard
set routing-options static route 172.16.5.0/24 discard
set routing-options static route 172.16.6.0/24 discard
set routing-options static route 172.16.7.0/24 discard
set routing-options autonomous-system 300
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To group source and desnaon prexes in a forwarding class:
679
1. Create the router interfaces.
[edit interfaces]
user@PE# set fe-1/2/0 unit 0 family inet accounting source-class-usage output
user@PE# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30
user@PE# set fe-1/2/1 unit 0 family inet accounting source-class-usage input
user@PE# set fe-1/2/1 unit 0 family inet accounting destination-class-usage
user@PE# set fe-1/2/1 unit 0 family inet address 10.1.0.1/30
user@PE# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure BGP.
[edit protocols bgp group ext]
user@PE# set type external
user@PE# set export send-direct
user@PE# set neighbor 10.0.0.1 peer-as 100
user@PE# set neighbor 10.1.0.2 peer-as 300
3. Congure the DCU policy.
[edit policy-options policy-statement dcu_class]
user@PE# set term silver1 from route-filter 172.16.5.0/24 orlonger
user@PE# set term silver1 then destination-class silver1
user@PE# set term silver2 from route-filter 172.16.6.0/24 orlonger
user@PE# set term silver2 then destination-class silver2
user@PE# set term silver3 from route-filter 172.16.7.0/24 orlonger
user@PE# set term silver3 then destination-class silver3
4. Congure the SCU policy.
[edit policy-options policy-statement scu_class]
user@PE# set term gold1 from route-filter 172.16.2.0/24 orlonger
user@PE# set term gold1 then source-class gold1
user@PE# set term gold2 from route-filter 172.16.3.0/24 orlonger
user@PE# set term gold2 then source-class gold2
user@PE# set term gold3 from route-filter 172.16.4.0/24 orlonger
user@PE# set term gold3 then source-class gold3
680
5. Apply the policies to the forwarding table.
[edit routing-options forwarding-table]
user@PE# set export dcu_class
user@PE# set export scu_class
NOTE: You can refer to the same roung policy one or more mes in the same or dierent
export statement.
6. (Oponal) Congure a roung policy that adverses direct routes.
[edit policy-options policy-statement send-direct term 1]
user@PE# set from protocol direct
user@PE# set then accept
7. Congure the autonomous system (AS) number.
[edit routing-options]
user@PE# set autonomous-system 200
Results
From conguraon mode, conrm your conguraon by issuing the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@PE# show interfaces
fe-1/2/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
output;
}
}
address 10.0.0.2/30;
}
681
}
}
fe-1/2/1 {
unit 0 {
family inet {
accounting {
source-class-usage {
input;
}
destination-class-usage;
}
address 10.1.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@PE# show protocols
bgp {
group ext {
type external;
export send-direct;
neighbor 10.0.0.1 {
peer-as 100;
}
neighbor 10.1.0.2 {
peer-as 300;
}
}
}
user@PE# show policy-options
policy-statement dcu_class {
term silver1 {
682
from {
route-filter 172.16.5.0/24 orlonger;
}
then destination-class silver1;
}
term silver2 {
from {
route-filter 172.16.6.0/24 orlonger;
}
then destination-class silver2;
}
term silver3 {
from {
route-filter 172.16.7.0/24 orlonger;
}
then destination-class silver3;
}
}
policy-statement scu_class {
term gold1 {
from {
route-filter 172.16.2.0/24 orlonger;
}
then source-class gold1;
}
term gold2 {
from {
route-filter 172.16.3.0/24 orlonger;
}
then source-class gold2;
}
term gold3 {
from {
route-filter 172.16.4.0/24 orlonger;
}
then source-class gold3;
}
}
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
683
}
}
user@PE# show routing-options
autonomous-system 200;
forwarding-table {
export [ dcu_class scu_class ];
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Making Sure That the DCU Policy Is Working | 684
Making Sure That the SCU Policy Is Working | 685
Conrm that the conguraon is working properly.
Making Sure That the DCU Policy Is Working
Purpose
Verify that trac sent from the provider core into the customer network is causing the DCU policy
counters to increment.
Acon
1. From Device P, ping an address in the customer network.
user@P> ping rapid count 10000000 172.16.0.1
PING 172.16.0.1 (6.0.0.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!
684
2. On Device PE, check the interface stascs on the interface facing the provider core.
user@PE> show interfaces statistics fe-1/2/1.0
Logical interface fe-1/2/1.0 (Index 108) (SNMP ifIndex 546)
Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
Input packets : 251956
Output packets: 251961
Protocol inet, MTU: 1500
Flags: Sendbcast-pkt-to-re, DCU, SCU-in
Packets Bytes
Destination class (packet-per-second) (bits-per-second)
silver1 7460 626640
( 0) ( 0)
silver2 22440 2401416
( 256) ( 171963)
silver3 9004 756336
( 0) ( 0)
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.1.0.0/30, Local: 10.1.0.1, Broadcast: 10.1.0.3
Meaning
Packet and bit rates are displayed with packet and byte counters.
Alternavely, you can use the show interfaces destination-class all command to display the same
informaon.
Making Sure That the SCU Policy Is Working
Purpose
Verify that trac sent from the customer network into the provider core is causing the SCU policy
counters to increment.
685
Acon
1. From Device CE, ping an address in the customer network.
user@CE> ping rapid count 10000000 172.16.0.1
PING 172.16.0.1 (6.0.0.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
2. On Device PE, check the interface stascs on the interface facing the customer network.
user@PE> show interfaces statistics fe-1/2/0.0
Logical interface fe-1/2/0.0 (Index 93) (SNMP ifIndex 554)
Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
Input packets : 32246
Output packets: 32245
Protocol inet, MTU: 1500
Flags: Sendbcast-pkt-to-re, Is-Primary, SCU-out
Packets Bytes
Source class (packet-per-second) (bits-per-second)
gold1 8871 745164
( 259) ( 174497)
gold2 1812 152208
( 0) ( 0)
gold3 5711 479724
( 0) ( 0)
686
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.0.0.0/30, Local: 10.0.0.2, Broadcast: 10.0.0.3
Meaning
Packet and bit rates are displayed with packet and byte counters.
Alternavely, you can use the show interfaces source-class all command to display the same informaon.
RELATED DOCUMENTATION
Route Filter Match Condions | 72
Understanding Source Class Usage and Desnaon Class Usage Opons
687
CHAPTER 9
Avoiding Trac Roung Threats with Condional
Roung Policies
IN THIS CHAPTER
Condional Adversement and Import Policy (Roung Table) with certain match condions | 688
Condional Adversement Enabling Condional Installaon of Prexes Use Cases | 691
Example: Conguring a Roung Policy for Condional Adversement Enabling Condional Installaon of
Prexes in a Roung Table | 693
Condional Adversement and Import Policy (Roung Table) with certain
match condions
BGP accepts all non-looped routes learned from neighbors and imports them into the RIB-In table. If
these routes are accepted by the BGP import policy, they are then imported into the inet.0 roung table.
In cases where only certain routes are required to be imported, provisions can be made such that the
peer roung device exports routes based on a condion or a set of condions.
The condion for exporng a route can be based on:
• The peer the route was learned from
• The interface the route was learned on
• Some other required aribute
For example:
[edit]
policy-options {
condition
condition-name
{
if-route-exists address table
table-name
;
688
}
}
This is known as condional installaon of prexes and is described in
Example: Conguring a Roung
Policy for Condional Adversement Enabling Condional Installaon of Prexes in a Roung Table
.
Condions in roung policies can be congured irrespecve of whether they are a part of the export or
import policies or both. The export policy supports these condions inherited from the roung policy
based on the existence of another route in the roung policy. However, the import policy doesn't
support these condions, and the condions are not executed even if they are present.
Figure 42 on page 689 illustrates where BGP import and export policies are applied. An import policy is
applied to inbound routes that are visible in the output of the show route receive-protocol bgp
neighbor-
address
command. An export policy is applied to outbound routes that are visible in the output of the show
route advertising-protocol bgp
neighbor-address
command.
Figure 42: BGP Import and Export Policies
To enable condional installaon of prexes, an export policy must be congured on the device where
the prex export has to take place. The export policy evaluates each route to verify that it sases all
the match condions under the from statement. It also searches for the existence of the route dened
under the condition statement (also congured under the from statement).
If the route does not match the enre set of required condions dened in the policy, or if the route
dened under the condition statement does not exist in the roung table, the route is not exported to its
BGP peers. Thus, a condional export policy matches the routes for the desired route or prex you want
installed in the peers’ roung table.
To congure the condional installaon of prexes with the help of an export policy:
689
1. Create a condition statement to check prexes.
[edit]
policy-options {
condition
condition-name
{
if-route-exists address table
table-name
;
}
}
2. Create an export policy with the newly created condion using the condition statement.
[edit]
policy-options {
policy-statement
policy-name
{
term 1 {
from {
protocols bgp;
condition
condition-name
;
}
then {
accept;
}
}
}
}
3. Apply the export policy to the device that requires only selected prexes to be exported from the
roung table.
[edit]
protocols bgp {
group
group-name
{
export
policy-name
;
}
}
690
RELATED DOCUMENTATION
Condional Adversement Enabling Condional Installaon of Prexes Use Cases
Condional Adversement Enabling Condional Installaon of Prexes
Use Cases
Networks are usually subdivided into smaller, more-manageable units called autonomous systems (ASs).
When BGP is used by routers to form peer relaonships in the same AS, it is referred to as internal BGP
(IBGP). When BGP is used by routers to form peer relaonships in dierent ASs, it is referred to as
external BGP (EBGP).
Aer performing route sanity checks, a BGP router accepts the routes received from its peers and
installs them into the roung table. By default, all routers in IBGP and EBGP sessions follow the
standard BGP adversement rules. While a router in an IBGP session adverses only the routes learned
from its direct peers, a router in an EBGP session adverses all routes learned from its direct and
indirect peers (peers of peers). Hence, in a typical network congured with EBGP, a router adds all
routes received from an EBGP peer into its roung table and adverses nearly all routes to all EBGP
peers.
A service provider exchanging BGP routes with both customers and peers on the Internet is at risk of
malicious and unintended threats that can compromise the proper roung of trac, as well as the
operaon of the routers.
This has several disadvantages:
• Non-aggregated route adversements—A customer could erroneously adverse all its prexes to the
ISP rather than an aggregate of its address space. Given the size of the Internet roung table, this
must be carefully controlled. An edge router might also need only a default route out toward the
Internet and instead be receiving the enre BGP roung table from its upstream peer.
• BGP route manipulaon—If a malicious administrator alters the contents of the BGP roung table, it
could prevent trac from reaching its intended desnaon.
• BGP route hijacking—A rogue administrator of a BGP peer could maliciously announce a network’s
prexes in an aempt to reroute the trac intended for the vicm network to the administrator’s
network to either gain access to the contents of trac or to block the vicm’s online services.
• BGP denial of service (DoS)—If a malicious administrator sends unexpected or undesirable BGP
trac to a router in an aempt to use all of the router’s available BGP resources, it might result in
impairing the router’s ability to process valid BGP route informaon.
Condional installaon of prexes can be used to address all the problems previously menoned. If a
customer requires access to remote networks, it is possible to install a specic route in the roung table
691
of the router that is connected with the remote network. This does not happen in a typical EBGP
network and hence, condional installaon of prexes becomes essenal.
ASs are not only bound by physical relaonships but by business or other organizaonal relaonships.
An AS can provide services to another organizaon, or act as a transit AS between two other ASs. These
transit ASs are bound by contractual agreements between the pares that include parameters on how to
connect to each other and most importantly, the type and quanty of trac they carry for each other.
Therefore, for both legal and nancial reasons, service providers must implement policies that control
how BGP routes are exchanged with neighbors, which routes are accepted from those neighbors, and
how those routes aect the trac between the ASs.
There are many dierent opons available to lter routes received from a BGP peer to both enforce
inter-AS policies and migate the risks of receiving potenally harmful routes. Convenonal route
ltering examines the aributes of a route and accepts or rejects the route based on such aributes. A
policy or lter can examine the contents of the AS-Path, the next-hop value, a community value, a list of
prexes, the address family of the route, and so on.
In some cases, the standard “acceptance condion” of matching a parcular aribute value is not
enough. The service provider might need to use another condion outside of the route itself, for
example, another route in the roung table. As an example, it might be desirable to install a default route
received from an upstream peer, only if it can be veried that this peer has reachability to other
networks further upstream. This condional route installaon avoids installing a default route that is
used to send trac toward this peer, when the peer might have lost its routes upstream, leading to
black-holed trac. To achieve this, the router can be congured to search for the presence of a
parcular route in the roung table, and based on this knowledge accept or reject another prex.
Example: Conguring a Roung Policy for Condional Adversement Enabling Condional Installaon
of Prexes in a Roung Table
explains how the condional installaon of prexes can be congured and
veried.
RELATED DOCUMENTATION
Example: Conguring a Roung Policy for Condional Adversement Enabling Condional
Installaon of Prexes in a Roung Table
692
Example: Conguring a Roung Policy for Condional Adversement
Enabling Condional Installaon of Prexes in a Roung Table
IN THIS SECTION
Requirements | 693
Overview | 693
Conguraon | 697
Vericaon | 707
This example shows how to
congure condional installaon of prexes in a roung table using BGP
export policy.
Requirements
This example uses the following hardware and soware components:
• M Series Mulservice Edge Routers, MX Series 5G Universal Roung Plaorms, or T Series Core
Routers
• Junos OS Release 9.0 or later
Overview
IN THIS SECTION
Topology | 697
In this example, three routers in three dierent autonomous systems (ASs) are connected and congured
with the BGP protocol. The router labeled Internet, which is the upstream router, has ve addresses
congured on its lo0.0 loopback interface (172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32,
172.16.14.1/32, and 172.16.15.1/32), and an extra loopback address (192.168.9.1/32) is congured as
the router ID. These six addresses are exported into BGP to emulate the contents of a BGP roung table
of a router connected to the Internet, and adversed to North.
693
The North and South routers use the 10.0.89.12/30 and 10.0.78.12/30 networks, respecvely, and use
192.168.7.1 and 192.168.8.1 for their respecve loopback addresses.
Figure 43 on page 694 shows the topology used in this example.
Figure 43: Condional Installaon of Prexes
Router North exports the 172.16.0.0/16 BGP routes it learns from Router Internet to Router South.
These routes might represent the routes owned by the Internet router's domain. In addion, when the
specic 172.16.11.1/32 route is present, Router North also adverses a default route. The 172.16.11.1
route might represent the Internet router's link to a er 1 transit peering provider that provides full
internet connecvity.
Router South receives all six routes, but should only install the default route and one other specic route
(172.16.11.1/32) in its roung table.
To summarize, the example meets the following requirements:
• On North, send all 172.16/16 prexes. In addion, also send 0/0 to South only if a parcular route is
present in the inet.0 roung table (in this example 172.16.11.1/32).
• On South, accept and install the default route and the 172.16.11.1/32 route in the roung and
forwarding tables. Drop all other routes. Consider that South might be a lower-end device that
cannot accept a full Internet roung table. As a result the operator only wants South to have the
default route and one other specic prex.
694
The rst requirement is met with an export policy on North:
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 172.16.0.0/16 orlonger;
}
then accept;
}
term conditional-default {
from {
route-filter 0.0.0.0/0 exact;
condition prefix_11;
}
then accept;
}
term others {
then reject;
}
}
condition prefix_11 {
if-route-exists {
172.16.11.1/32;
table inet.0;
}
}
The logic of the condional export policy can be summarized as follows: If 0/0 is present, and if
172.16.11.1/32 is present, then send the 0/0 prex. This implies that if 172.16.11.1/32 is not present,
then do not send 0/0.
The second requirement is met with an import policy on South:
user@South# show policy-options
policy-statement import-selected-routes {
term 1 {
from {
rib inet.0;
neighbor 10.0.78.14;
route-filter 0.0.0.0/0 exact;
695
route-filter 172.16.11.1/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
In this example, four routes are dropped as a result of the import policy on South. This is because the
export policy on North leaks all of the routes received from Internet, and the import policy on South
excludes some of these routes.
It is important to understand that in Junos OS, although an import policy (inbound route lter) might
reject a route, not use it for trac forwarding, and not include it in an adversement to other peers, the
router retains these routes as hidden routes. These hidden routes are not available for policy or roung
purposes. However, they do occupy memory space on the router. A service provider ltering routes to
control the amount of informaon being kept in memory and processed by a router might want the
router to enrely drop the routes being rejected by the import policy.
Hidden routes can be viewed by using the show route receive-protocol bgp
neighbor-address
hidden command.
The hidden routes can then be retained or dropped from the roung table by conguring the keep all |
none statement at the [edit protocols bgp] or [edit protocols bgp group
group-name
] hierarchy level.
The rules of BGP route retenon are as follows:
• By default, all routes learned from BGP are retained, except those where the AS path is looped. (The
AS path includes the local AS.)
• By conguring the keep all statement, all routes learned from BGP are retained, even those with the
local AS in the AS path.
• By conguring the keep none statement, BGP discards routes that were received from a peer and that
were rejected by import policy or other sanity checking. When this statement is congured and the
inbound policy changes, Junos OS re-adverses all the routes adversed by the peer.
When you congure keep all or keep none and the peers support route refresh, the local speaker sends a
refresh message and performs an import evaluaon. For these peers, the sessions do not restart. To
determine if a peer supports refresh, check for Peer supports Refresh capability in the output of the show bgp
neighbor command.
CAUTION: If you congure keep all or keep none and the peer does not support session
restart, the associated BGP sessions are restarted (apped).
696
Topology
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 697
Conguring Condional Installaon of Prexes | 699
Results | 703
CLI Quick
Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Router Internet
set interfaces lo0 unit 0 family inet address 172.16.11.1/32
set interfaces lo0 unit 0 family inet address 172.16.12.1/32
set interfaces lo0 unit 0 family inet address 172.16.13.1/32
set interfaces lo0 unit 0 family inet address 172.16.14.1/32
set interfaces lo0 unit 0 family inet address 172.16.15.1/32
set interfaces lo0 unit 0 family inet address 192.168.9.1/32
set interfaces fe-0/1/3 unit 0 family inet address 10.0.89.14/30
set protocols bgp group toNorth local-address 10.0.89.14
set protocols bgp group toNorth peer-as 65200
set protocols bgp group toNorth neighbor 10.0.89.13
set protocols bgp group toNorth export into-bgp
set policy-options policy-statement into-bgp term 1 from interface lo0.0
set policy-options policy-statement into-bgp term 1 then accept
set routing-options router-id 192.168.9.1
set routing-options autonomous-system 65300
697
Router North
set interfaces fe-1/3/1 unit 0 family inet address 10.0.78.14/30
set interfaces fe-1/3/0 unit 0 family inet address 10.0.89.13/30
set interfaces lo0 unit 0 family inet address 192.168.8.1/32
set protocols bgp group toInternet local-address 10.0.89.13
set protocols bgp group toInternet peer-as 65300
set protocols bgp group toInternet neighbor 10.0.89.14
set protocols bgp group toSouth local-address 10.0.78.14
set protocols bgp group toSouth export conditional-export-bgp
set protocols bgp group toSouth peer-as 65100
set protocols bgp group toSouth neighbor 10.0.78.13
set policy-options policy-statement conditional-export-bgp term prefix_11 from protocol bgp
set policy-options policy-statement conditional-export-bgp term prefix_11 from route-filter
172.16.0.0/16 orlonger
set policy-options policy-statement conditional-export-bgp term prefix_11 then accept
set policy-options policy-statement conditional-export-bgp term conditional-default from route-
filter 0.0.0.0/0 exact
set policy-options policy-statement conditional-export-bgp term conditional-default from
condition prefix_11
set policy-options policy-statement conditional-export-bgp term conditional-default then accept
set policy-options policy-statement conditional-export-bgp term others then reject
set policy-options condition prefix_11 if-route-exists 172.16.11.1/32
set policy-options condition prefix_11 if-route-exists table inet.0
set routing-options static route 0/0 reject
set routing-options router-id 192.168.8.1
set routing-options autonomous-system 65200
Router South
set interfaces fe-0/1/2 unit 0 family inet address 10.0.78.13/30
set interfaces lo0 unit 0 family inet address 192.168.7.1/32
set protocols bgp group toNorth local-address 10.0.78.13
set protocols bgp group toNorth import import-selected-routes
set protocols bgp group toNorth peer-as 65200
set protocols bgp group toNorth neighbor 10.0.78.14
set policy-options policy-statement import-selected-routes term 1 from neighbor 10.0.78.14
set policy-options policy-statement import-selected-routes term 1 from route-filter
172.16.11.1/32 exact
set policy-options policy-statement import-selected-routes term 1 from route-filter 0.0.0.0/0
exact
698
set policy-options policy-statement import-selected-routes term 1 then accept
set policy-options policy-statement import-selected-routes term 2 then reject
set routing-options router-id 192.168.7.1
set routing-options autonomous-system 65100
Conguring Condional Installaon of Prexes
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure condional installaon of prexes:
1. Congure the router interfaces forming the links between the three routers.
Router Internet
[edit interfaces]
user@Internet# set fe-0/1/3 unit 0 family inet address 10.0.89.14/30
Router North
[edit interfaces]
user@North# set fe-1/3/1 unit 0 family inet address 10.0.78.14/30
user@North# set fe-1/3/0 unit 0 family inet address 10.0.89.13/30
Router South
[edit interfaces]
user@South# set fe-0/1/2 unit 0 family inet address 10.0.78.13/30
2. Congure ve loopback interface addresses on Router Internet to emulate BGP routes learned from
the Internet that are to be imported into the roung table of Router South, and congure an
addional address (192.168.9.1/32) that will be congured as the router ID.
Router Internet
[edit interfaces lo0 unit 0 family inet]
user@Internet# set address 172.16.11.1/32
user@Internet# set address 172.16.12.1/32
699
user@Internet# set address 172.16.13.1/32
user@Internet# set address 172.16.14.1/32
user@Internet# set address 172.16.15.1/32
user@Internet# set address 192.168.9.1/32
Also, congure the loopback interface addresses on Routers North and South.
Router North
[edit interfaces lo0 unit 0 family inet]
user@North# set address 192.168.8.1/32
Router South
[edit interfaces lo0 unit 0 family inet]
user@South# set address 192.168.7.1/32
3. Congure the stac default route on Router North to be adversed to Router South.
[edit routing-options]
user@North# set static route 0/0 reject
4. Dene the condion for exporng prexes from the roung table on Router North.
[edit policy-options condition prefix_11]
user@North# set if-route-exists 172.16.11.1/32
user@North# set if-route-exists table inet.0
5. Dene export policies (into-bgp and conditional-export-bgp ) on Routers Internet and North respecvely,
to adverse routes to BGP.
NOTE: Ensure that you reference the condion, prefix_11 (congured in Step "4" on page 700),
in the export policy.
Router Internet
[edit policy-options policy-statement into-bgp ]
700
user@Internet# set term 1 from interface lo0.0
user@Internet# set term 1 then accept
Router North
[edit policy-options policy-statement conditional-export-bgp]
user@North# set term prefix_11 from protocol bgp
user@North# set term prefix_11 from route-filter 172,16.0.0/16 orlonger
user@North# set term prefix_11 then accept
user@North# set term conditional-default from route-filter 0.0.0.0/0 exact
user@North# set term conditional-default from condition prefix_11
user@North# set term conditional-default then accept
user@North# set term others then reject
6. Dene an import policy (import-selected-routes) on Router South to import some of the routes
adversed by Router North into its roung table.
[edit policy-options policy-statement import-selected-routes ]
user@South# set term 1 from neighbor 10.0.78.14
user@South# set term 1 from route-filter 172.16.11.1/32 exact
user@South# set term 1 from route-filter 0.0.0.0/0 exact
user@South# set term 1 then accept
user@South# set term 2 then reject
7. Congure BGP on all three routers to enable the ow of prexes between the autonomous systems.
NOTE: Ensure that you apply the dened import and export policies to the respecve BGP
groups for prex adversement to take place.
Router Internet
[edit protocols bgp group toNorth]
user@Internet# set local-address 10.0.89.14
user@Internet# set peer-as 65200
701
user@Internet# set neighbor 10.0.89.13
user@Internet# set export into-bgp
Router North
[edit protocols bgp group toInternet]
user@North# set local-address 10.0.89.13
user@North# set peer-as 65300
user@North# set neighbor 10.0.89.14
[edit protocols bgp group toSouth]
user@North# set local-address 10.0.78.14
user@North# set peer-as 65100
user@North# set neighbor 10.0.78.13
user@North# set export conditional-export-bgp
Router South
[edit protocols bgp group toNorth]
user@South# set local-address 10.0.78.13
user@South# set peer-as 65200
user@South# set neighbor 10.0.78.14
user@South# set import import-selected-routes
8. Congure the router ID and autonomous system number for all three routers.
NOTE: In this example, the router ID is congured based on the IP address congured on the
lo0.0 interface of the router.
Router Internet
[edit routing options]
user@Internet# set router-id 192.168.9.1
user@Internet# set autonomous-system 65300
Router North
[edit routing options]
702
user@North# set router-id 192.168.8.1
user@North# set autonomous-system 65200
Router South
[edit routing options]
user@South# set router-id 192.168.7.1
user@South# set autonomous-system 65100
Results
From conguraon mode, conrm your conguraon by issuing the show interfaces, show protocols bgp, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
Device Internet
user@Internet# show interfaces
fe-0/1/3 {
unit 0 {
family inet {
address 10.0.89.14/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.11.1/32;
address 172.16.12.1/32;
address 172.16.13.1/32;
address 172.16.14.1/32;
address 172.16.15.1/32;
address 192.168.9.1/32;
}
}
}
user@Internet# show protocols bgp
group toNorth {
703
local-address 10.0.89.14;
export into-bgp;
peer-as 65200;
neighbor 10.0.89.13;
}
user@Internet# show policy-options
policy-statement into-bgp {
term 1 {
from interface lo0.0;
then accept;
}
}
user@Internet# show routing-options
router-id 192.168.9.1;
autonomous-system 65300;
Device North
user@North# show interfaces
fe-1/3/1 {
unit 0 {
family inet {
address 10.0.78.14/30;
}
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.0.89.13/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.8.1/32;
704
}
}
}
user@North# show protocols bgp
group toInternet {
local-address 10.0.89.13;
peer-as 65300;
neighbor 10.0.89.14;
}
group toSouth {
local-address 10.0.78.14;
export conditional-export-bgp;
peer-as 65100;
neighbor 10.0.78.13;
}
user@North# show policy-options
policy-statement conditional-export-bgp {
term prefix_11 {
from {
protocol bgp;
route-filter 172.16.0.0/16 orlonger;
}
then accept;
}
term conditional-default {
from {
route-filter 0.0.0.0/0 exact;
condition prefix_11;
}
then accept;
}
term others {
then reject;
}
}
condition prefix_11 {
if-route-exists {
172.16.11.1/32;
705
table inet.0;
}
}
user@North# show routing-options
static {
route 0.0.0.0/0 reject;
}
router-id 192.168.8.1;
autonomous-system 65200;
Device South
user@South# show interfaces
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.78.13/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.7.1/32;
}
}
}
user@South# show protocols bgp
bgp {
group toNorth {
local-address 10.0.78.13;
import import-selected-routes;
peer-as 65200;
neighbor 10.0.78.14;
706
}
}
user@South# show policy-options
policy-statement import-selected-routes {
term 1 {
from {
neighbor 10.0.78.14;
route-filter 172.16.11.1 exact;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 2 {
then reject;
}
}
user@South# show routing-options
router-id 192.168.7.1;
autonomous-system 65100;
If you are done conguring the routers, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying BGP | 708
Verifying Prex Adversement from Router Internet to Router North | 710
Verifying Prex Adversement from Router North to Router South | 711
Verifying BGP Import Policy for Installaon of Prexes | 712
Verifying Condional Export from Router North to Router South | 713
Verifying the Presence of Routes Hidden by Policy (Oponal) | 714
Conrm that the conguraon is working properly.
707
Verifying BGP
Purpose
Verify that BGP sessions have been established between the three routers.
Acon
From operaonal mode, run the show bgp neighbor
neighbor-address
command.
1. Check the BGP session on Router Internet to verify that Router North is a neighbor.
user@Internet> show bgp neighbor 10.0.89.13
Peer: 10.0.89.13+179 AS 65200 Local: 10.0.89.14+56187 AS 65300
Type: External State: Established Flags: [ImportEval Sync]
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ into-bgp ]
Options: [Preference LocalAddress PeerAS Refresh]
Local Address: 10.0.89.14 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.8.1 Local ID: 192.168.9.1 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 0
BFD: disabled, down
Local Interface: fe-0/1/3.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 65200)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
708
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 9 Sent 18 Checked 28
Input messages: Total 12 Updates 1 Refreshes 0 Octets 232
Output messages: Total 14 Updates 1 Refreshes 0 Octets 383
Output Queue[0]: 0
2. Check the BGP session on Router North to verify that Router Internet is a neighbor.
user@North> show bgp neighbor 10.0.89.14
Peer: 10.0.89.14+56187 AS 65300 Local: 10.0.89.13+179 AS 65200
Type: External State: Established Flags: [ImportEval Sync]
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: [Preference LocalAddress PeerAS Refresh]
Local Address: 10.0.89.13 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.9.1 Local ID: 192.168.8.1 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 0
BFD: disabled, down
Local Interface: fe-1/3/0.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 65300)
Peer does not support Addpath
Table inet.0 Bit: 10001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 6
Received prefixes: 6
Accepted prefixes: 6
Suppressed due to damping: 0
Advertised prefixes: 0
Last traffic (seconds): Received 14 Sent 3 Checked 3
Input messages: Total 16 Updates 2 Refreshes 0 Octets 402
709
Output messages: Total 15 Updates 0 Refreshes 0 Octets 348
Output Queue[0]: 0
Check the following elds in these outputs to verify that BGP sessions have been established:
• Peer—Check if the peer AS number is listed.
• Local—Check if the local AS number is listed.
• State—Ensure that the value is Established. If not, check the conguraon again and see show bgp
neighbor for more details on the output elds.
Similarly, verify that Routers North and South form peer relaonships with each other.
Meaning
BGP sessions are established between the three routers.
Verifying Prex Adversement from Router Internet to Router North
Purpose
Verify that the routes sent from Router Internet are received by Router North.
Acon
1. From operaonal mode on Router Internet, run the show route advertising-protocol bgp
neighbor-address
command.
user@Internet> show route advertising-protocol bgp 10.0.89.13
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.11.1/32 Self I
* 172.16.12.1/32 Self I
* 172.16.13.1/32 Self I
* 172.16.14.1/32 Self I
* 172.16.15.1/32 Self I
* 192.168.9.1/32 Self I
The output veries that Router Internet adverses the routes 172.16.11.1/32, 172.16.12.1/32,
172.16.13.1/32, 172.16.14.1/32, 172.16.15.1/32, and 192.168.9.1/32 (the loopback address used
as router ID) to Router North.
710
2. From operaonal mode on Router North, run the show route receive-protocol bgp
neighbor-address
command.
user@North> show route receive-protocol bgp 10.0.89.14
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.11.1/32 10.0.89.14 65300 I
* 172.16.12.1/32 10.0.89.14 65300 I
* 172.16.13.1/32 10.0.89.14 65300 I
* 172.16.14.1/32 10.0.89.14 65300 I
* 172.16.15.1/32 10.0.89.14 65300 I
* 192.168.9.1/32 10.0.89.14 65300 I
The output veries that Router North has received all the routes adversed by Router Internet.
Meaning
Prexes sent by Router Internet have been successfully installed into the roung table on Router North.
Verifying Prex Adversement from Router North to Router South
Purpose
Verify that the routes received from Router Internet and the stac default route are adversed by
Router North to Router South.
Acon
1. From operaonal mode on Router North, run the show route 0/0 exact command.
user@North> show route 0/0 exact
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:10:22
Reject
The output veries the presence of the stac default route (0.0.0.0/0) in the roung table on Router
North.
711
2. From operaonal mode on Router North, run the show route advertising-protocol bgp
neighbor-address
command.
user@North> show route advertising-protocol bgp 10.0.78.13
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 Self I
* 172.16.11.1/32 Self 65300 I
* 172.16.12.1/32 Self 65300 I
* 172.16.13.1/32 Self 65300 I
* 172.16.14.1/32 Self 65300 I
* 172.16.15.1/32 Self 65300 I
The output veries that Router North is adversing the stac route and the 172.16.11.1/32 route
received from Router Internet, as well as many other routes, to Router South.
Verifying BGP Import Policy for Installaon of Prexes
Purpose
Verify that the BGP import policy successfully installs the required prexes.
Acon
See if the import policy on Router South is operaonal by checking if only the stac default route from
Router North and the 172.16.11.1/32 route from Router South are installed in the roung table.
From operaonal mode, run the show route receive-protocol bgp
neighbor-address
command.
user@South> show route receive-protocol bgp 10.0.78.14
inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 10.0.78.14 65200 I
* 172.16.11.1/32 10.0.78.14 65200 65300 I
The output veries that the BGP import policy is operaonal on Router South, and only the stac
default route of 0.0.0.0/0 from Router North and the 172.16.11.1/32 route from Router Internet have
leaked into the roung table on Router South.
712
Meaning
The installaon of prexes is successful because of the congured BGP import policy.
Verifying Condional Export from Router North to Router South
Purpose
Verify that when Device Internet stops sending the 172.16.11.1/32 route, Device North stops sending
the default 0/0 route.
Acon
1. Cause Device Internet to stop sending the 172.16.11.1/32 route by deacvang the 172.16.11.1/32
address on the loopback interface.
[edit interfaces lo0 unit 0 family inet]
user@Internet# deactivate address 172.16.11.1/32
user@Internet# commit
2. From operaonal mode on Router North, run the show route advertising-protocol bgp
neighbor-address
command.
user@North> show route advertising-protocol bgp 10.0.78.13
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.12.1/32 Self 65300 I
* 172.16.13.1/32 Self 65300 I
* 172.16.14.1/32 Self 65300 I
* 172.16.15.1/32 Self 65300 I
The output veries that Router North is not adversing the default route to Router South. This is the
expected behavior when the 172.16.11.1/32 route is not present.
3. Reacvate the 172.16.11.1/32 address on Device Internet’s loopback interface.
[edit interfaces lo0 unit 0 family inet]
user@Internet# activate address 172.16.11.1/32
user@Internet# commit
713
Verifying the Presence of Routes Hidden by Policy (Oponal)
Purpose
Verify the presence of routes hidden by the import policy congured on Router South.
NOTE: This secon demonstrates the eects of various changes you can make to the
conguraon depending on your needs.
Acon
View routes hidden from the roung table of Router South by:
• Using the hidden opon for the show route receive-protocol bgp
neighbor-address
command.
• Deacvang the import policy.
1. From operaonal mode, run the show route receive-protocol bgp
neighbor-address
hidden command to view
hidden routes.
user@South> show route receive-protocol bgp 10.0.78.14 hidden
inet.0: 10 destinations, 11 routes (6 active, 0 holddown, 4 hidden)
Prefix Nexthop MED Lclpref AS path
172.16.12.1/32 10.0.78.14 65200 65300 I
172.16.13.1/32 10.0.78.14 65200 65300 I
172.16.14.1/32 10.0.78.14 65200 65300 I
172.16.15.1/32 10.0.78.14 65200 65300 I
The output veries the presence of routes hidden by the import policy (172.16.12.1/32,
172.16.13.1/32, 172.16.14.1/32, and 172.16.15.1/32) on Router South.
2. Deacvate the BGP import policy by conguring the deactivate import statement at the [edit protocols
bgp group
group-name
] hierarchy level.
[edit protocols bgp group toNorth]
user@South# deactivate import
user@South# commit
714
3. Run the show route receive-protocol bgp
neighbor-address
operaonal mode command to check the routes
aer deacvang the import policy.
user@South> show route receive-protocol bgp 10.0.78.14
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 10.0.78.14 65200 I
* 172.16.11.1/32 10.0.78.14 65200 65300 I
* 172.16.12.1/32 10.0.78.14 65200 65300 I
* 172.16.13.1/32 10.0.78.14 65200 65300 I
* 172.16.14.1/32 10.0.78.14 65200 65300 I
* 172.16.15.1/32 10.0.78.14 65200 65300 I
The output veries the presence of previously hidden routes (172.16.12.1/32, 172.16.13.1/32,
172.16.14.1/32, and 172.16.15.1/32).
4. Acvate the BGP import policy and remove the hidden routes from the roung table by conguring
the activate import and keep none statements respecvely at the [edit protocols bgp group
group-name
]
hierarchy level.
[edit protocols bgp group toNorth]
user@South# activate import
user@South# set keep none
user@South# commit
5. From operaonal mode, run the show route receive-protocol bgp
neighbor-address
hidden command to
check the routes aer acvang the import policy and conguring the keep none statement.
user@South> show route receive-protocol bgp 10.0.78.14 hidden
inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
The output veries that the hidden routes are not maintained in the roung table because of the
congured keep none statement.
RELATED DOCUMENTATION
Condional Adversement Enabling Condional Installaon of Prexes Use Cases
Condional Adversement and Import Policy (Roung Table) with certain match condions
715
CHAPTER 10
Protecng Against DoS Aacks by Forwarding
Trac to the Discard Interface
IN THIS CHAPTER
Assigning Forwarding Classes and Loss Priority | 716
Understanding Forwarding Packets to the Discard Interface | 718
Example: Forwarding Packets to the Discard Interface | 720
Assigning Forwarding Classes and Loss Priority
You can congure rewall lters to assign packet loss priority (PLP) and forwarding classes so that if
congeson occurs, the marked packets can be dropped according to the priority you set. The valid
match condions are one or more of the six packet header elds: desnaon address, source address, IP
protocol, source port, desnaon port, and DSCP. In other words, you can set the forwarding class and
the PLP for each packet entering or an interface with a specic desnaon address, source address, IP
protocol, source port, desnaon port, or DSCP.
NOTE: Junos OS assigns forwarding classes and PLP on ingress only. Do not use a lter that
assigns forwarding classes or PLP as an egress lter.
When tricolor marking is enabled, a switch supports four PLP designaons: low, medium-low, medium-high, and
high. You can also specify any of the forwarding classes listed in Table 25 on page 716
Table 25: Unicast Forwarding Classes
Unicast Forwarding Class For CoS Trac Type
be
Best-eort trac
716
Table 25: Unicast Forwarding Classes
(Connued)
Unicast Forwarding Class For CoS Trac Type
no-loss
Guaranteed delivery for TCP trac
fcoe
Guaranteed delivery for Fibre Channel over Ethernet (FCoE) trac
nc
Network-control trac
To assign forwarding classes in rewall lters:
1. Congure the family address type and lter name:
[edit]
user@switch# edit firewall family inetfilter ingress-filter
2. Congure the terms of the lter as appropriate, including the forwarding-class and loss-priority acon
modiers. For example, each of the following terms in the lter examines various packet header elds
and assigns the appropriate forwarding class and packet loss priority:
• The term corp-traffic matches all IPv4 packets with a 10.1.1.0/24 source address and assigns the
packets to forwarding class no-loss with a loss priority of low:
[edit firewall family inet filter ingress-filter]
user@switch# set term corp-traffic from source-address 10.1.1.0/24;
user@switch# set term corp-traffic then forwarding-class no-loss
user@switch# set term corp-traffic then loss-priority low
• The term data-traffic matches all IPv4 packets with a 10.1.2.0/24 source address and assigns the
packets to forwarding class be (best eort) with a loss priority of medium-high:
[edit firewall family inet filter ingress-filter]
user@switch# set term data-traffic from source-address 10.1.2.0/24;
user@switch# set term data-traffic then forwarding-class be
user@switch# set term data-traffic then loss-priority medium-high
717
• The last term accept-traffic matches any packets that did not match on any of the preceding terms
and assigns the packets to forwarding class be with a loss priority of high:
[edit firewall family inet filter ingress-filter]
user@switch# set term accept-traffic then forwarding-class be
user@switch# set term accept-traffic then loss-priority high
3. Apply the lter ingress-filter to a Layer 3 interface. For informaon about applying the lter, see
"Conguring Firewall Filters" on page 1829. (Assigning forwarding classes and PLP is supported only
on ingress lters.)
RELATED DOCUMENTATION
Monitoring Firewall Filter Trac | 829
Overview of Policers | 2202
Understanding CoS Classiers
Understanding CoS Forwarding Classes
Understanding Forwarding Packets to the Discard Interface
The discard (dsc) interface is a virtual interface that can silently discard forwarded packets as they are
received (no ICMP message is sent). It is useful in the case of a denial-of-service (DoS) aacks. Once you
know the IP address that is being targeted, you can congure a policy to forward all packets received on
that interface to the discard interface, where they will be dropped. Likewise, silently discarding packets
that have no valid route in the associated forwarding table can prevent the device from becoming a
distributed denial-of-service (DDoS) reector, in which a spoofed source IP address is used to trigger a
ood of ICMP error messages from the device.
The dsc interface can be only be congured on unit 0 of the given physical interface, and only one dsc
instance per device is supported.
Congure an input lter if, for example, you want to take an acon such as logging the discard to beer
understand the nature of the aack.
[edit interfaces
interface-name
]
dsc {
unit 0 {
family inet {
718
filter {
output
filter-name
;
}
}
}
}
You can congure an input policy to associate a BGP community with the discard interface. To congure
an input policy to associate a community with the discard interface:
[edit]
policy-options {
community
community-name
members [
community-id
];
policy-statement
statement-name
{
term
term-name
{
from community
community-name
;
then {
next-hop
address
; # Remote end of the point-to-point interface
accept;
}
}
}
}
Congure an output policy to set up the community on the routes injected into the network:
[edit]
policy-options {
policy-statement
statement-name
{
term
term-name
{
from prefix-list
name
;
then community (set | add | delete)
community-name
;
}
}
}
RELATED DOCUMENTATION
Example: Forwarding Packets to the Discard Interface | 720
719
Example: Forwarding Packets to the Discard Interface
IN THIS SECTION
Requirements | 720
Overview | 720
Conguraon | 724
Vericaon | 729
This example shows how to use discard roung to migate denial of service (DoS) aacks, protect vital
network resources from outside aack, provide protecon services for customers so that each customer
can iniate its own protecon, and log and track DoS aempts.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In discard roung, routers are congured with rules that disallow millions of requests in a short period of
me from being sent to the same address. If too many requests are received in a short period of me,
the router simply discards the requests without forwarding them. The requests are sent to a router that
does not forward the packets. The problemac routes are somemes referred to as discard routes or
black-holed routes. The types of routes that should be discarded are idened as aacks to customers
from peers or other customers, aacks from customers to peers or other customers, aack controllers,
which are hosts providing aack instrucons, and unallocated address spaces, known as bogons or
invalid IP addresses.
Aer the aack aempt is idened, operators can put a conguraon in place to migate the aack.
One way to congure discard roung in Junos OS is to create a discard stac route for each next hop
used for discard routes. A discard stac route uses the discard opon.
For example:
user@host# show routing-options
static {
route 192.0.2.101/32 discard;
route 192.0.2.103/32 discard;
720
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 roung 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 congure mulple 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
721
192.0.2.104 --> 192.0.2.103
192.0.2.106 --> 192.0.2.105
The advantage of using a discard interface instead of using discard stac routes is that the discard
interface allows you to congure and assign lters to the interface for counng, logging, and sampling
the trac. This is demonstrated in this example.
To actually discard packets requires a roung policy aached to the BGP sessions. To locate discard-
eligible routes, you can use a route lter, an access list, or a BGP community value.
For example, here is how you would use a route lter:
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 44 on page 723 shows the sample network.
722
Figure 44: Discard Interface Sample Network
The example includes three routers with external BGP (EBGP) sessions established.
Device R1 represents the aacking device. Device R3 represents the router closest to the device that is
being aacked. Device R2 migates the aack by forwarding packets to the discard interface.
The example shows an outbound lter applied to the discard interface.
NOTE: An issue with using a single null route lter is visibility. All discard packets increment the
same counter. To see which categories of packets are being discarded, use desnaon class
usage (DCU), and associate a user-dened class with each null route community. Then reference
the DCU classes in a rewall lter. For related examples, see "Example: Grouping Source and
Desnaon Prexes into a Forwarding Class" on page 673 and "Example: Conguring a Rate-
Liming Filter Based on Desnaon Class" on page 1212.
Compared to using route lters and access lists, using a community value is the least administravely
dicult 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 mulhop feature to be congured on the EBGP sessions.
"CLI Quick Conguraon" on page 724 shows the conguraon for all of the devices in Figure 44 on
page 723.
The secon "No Link Title" on page 725 describes the steps on Device R2.
723
Conguraon
IN THIS SECTION
Procedure | 724
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, 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
724
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 conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure Device R2:
1. Create the router interfaces.
[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
725
2. Congure a rewall lter that matches all packets and counts and logs the packets.
[edit firewall filter log-discard term one]
user@R2# set then count counter
user@R2# set then log
3. Create a discard interface and apply the output rewall lter.
Input rewall lters have no impact in this context.
[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
4. Congure a stac route that sends the next hop to the desnaon address that is specied in the
discard interface.
[edit routing-options static]
user@R2# set route 192.0.2.102/32 next-hop 192.0.2.101
5. Congure BGP peering.
[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
6. Congure the roung policies.
[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
726
[edit policy-options community blackhole-all-routers]
user@R2# set members 100:5555
7. Apply the roung policies.
[edit protocols bgp ]
user@R2# set import blackhole-policy
user@R2# set group ext export dsc-export
8. Congure the autonomous system (AS) number.
[edit routing-options]
user@R2# set autonomous-system 200
Results
From conguraon mode, conrm your conguraon 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 conguraon, repeat the instrucons in this example to correct the conguraon.
[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 {
727
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;
}
728
}
}
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 conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Clearing the Firewall Counters | 730
Pinging the 192.0.2.101 Address | 730
729
Checking the Output Filter | 731
Checking the Community Aribute | 732
Conrm that the conguraon is working properly.
Clearing the Firewall Counters
Purpose
Clear the counters to make sure you are starng from a known zero (0) state.
Acon
1.
From Device R2, run the clear firewall command.
user@R2> clear firewall filter log-discard
2. From Device R2, run the show firewall command.
user@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 desnaon address.
730
Acon
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 rewall lter is funconing properly.
Acon
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.
NOTE: The ping packet carries an addional 20 bytes of IP overhead as well as 8 bytes of ICMP
header.
731
Checking the Community Aribute
Purpose
Verify that the route is being tagged with the community aribute.
Acon
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 adverses the 192.0.2.101 route to Device R1, Device R2 adds the
100:5555 community tag.
732
RELATED DOCUMENTATION
Understanding Forwarding Packets to the Discard Interface | 718
Example: Conguring Roung Policy Prex Lists | 398
733
CHAPTER 11
Improving Commit Times with Dynamic Roung
Policies
IN THIS CHAPTER
Understanding Dynamic Roung Policies | 734
Example: Conguring Dynamic Roung Policies | 739
Understanding Dynamic Roung Policies
IN THIS SECTION
Conguring Roung Policies and Policy Objects in the Dynamic Database | 735
Conguring Roung Policies Based on Dynamic Database Conguraon | 736
Applying Dynamic Roung Policies to BGP | 737
Prevenng Reestablishment of BGP Peering Sessions Aer NSR Roung Engine Switchover | 738
The vericaon process required to commit conguraon changes can entail a signicant amount of
overhead and me. For example, changing a prex in one line of a roung policy that is 20,000 lines long
can take up to 20 seconds to commit. It can be useful to be able to commit roung policy changes much
more quickly.
In Junos OS Release 9.5 and later, you can congure roung policies and certain roung policy objects in
a dynamic database that is not subject to the same vericaon required in the standard conguraon
database. As a result, the me it takes to commit changes to the dynamic database is much shorter than
for the standard conguraon database. You can then reference these policies and policy objects in
roung policies you congure in the standard database. BGP is the only protocol to which you can apply
roung policies that reference policies and policy objects congured in the dynamic database. Aer you
734
congure and commit a roung policy based on the objects congured in the dynamic database, you can
quickly update any exisng roung policy by making changes to the dynamic database conguraon.
CAUTION: Because the Junos OS does not validate conguraon changes to the
dynamic database, when you use this feature, you should test and verify all
conguraon changes before comming them.
Conguring Roung Policies and Policy Objects in the Dynamic Database
Junos OS Release 9.5 and later support a conguraon database, the
dynamic database
, which can be
edited in a similar way to the standard conguraon database but which is not subject to the same
vericaon process to commit conguraon changes. As a result, the me it takes to commit a
conguraon change is much faster. The policies and policy objects dened in the dynamic database can
then be referenced in roung policies congured in the standard conguraon. The dynamic database is
stored in the /var/run/db/juniper.dyn directory.
To congure the dynamic database, enter the configure dynamic command to enter the conguraon mode
for the dynamic database:
user@host> configure dynamic
Entering configuration mode
[edit dynamic]
user@host#
In this dynamic conguraon database, you can congure the following statements at the [edit policy-
options] hierarchy level:
• as-path
name
• as-path-group
group-name
• community
community-name
• condition
condition-name
•
prefix-list
prefix-list-name
• policy-statement
policy-statement-name
NOTE: No other conguraon is supported at the [edit dynamic] hierarchy level.
735
Use the policy-statement
policy-statement-name
statement to congure roung policies as you would in the
standard conguraon database.
To exit conguraon mode for the dynamic database, issue the exit configuration-mode command from any
level within the [edit dynamic] hierarchy, or use the exit command from the top level.
Conguring Roung Policies Based on Dynamic Database Conguraon
In the standard conguraon mode, you can congure roung policies that reference policies and policy
objects congured at the [edit dynamic] hierarchy level in the dynamic database. To dene a roung
policy that references the dynamic database conguraon, include the dynamic-db statement at the [edit
policy-options policy-statement
policy-statement-name
] hierarchy level:
[edit policy-options]
policy-statement
policy-statement-name
{
dynamic-db;
}
You can also dene specic policy objects based on the conguraon of these objects in the dynamic
database. To dene a policy object based on the dynamic database, include the dynamic-db statement with
the following statements at the [edit policy-options] hierarchy level:
• as-path
name
• as-path-group
group-name
• community
community-name
• condition
condition-name
• prefix-list
prefix-list-name
In the standard conguraon, you can also dene a roung policy that references any policy object you
have congured in the standard conguraon that references an object congured in the dynamic
database.
For example, in standard conguraon mode, you congure a prex list prefix-list pl2 that references a
prex list, also named prefix-list pl2, that has been congured in the dynamic database:
[edit policy-options]
prefix-list pl2 {
dynamic-db; # Reference a prefix list configured in the dynamic database.
}
736
You then congure a roung policy in the standard conguraon that includes prefix-list pl2:
[edit policy-options]
policy-statement one {
term term1 {
from {
prefix-list pl2; # Include the prefix list configured in the standard configuration
# database, but which references a prefix list configured in the dynamic database.
}
then accept;
}
then reject;
}
If you need to update the conguraon of prefix-list pl2, you do so in the dynamic database
conguraon using the [edit dynamic] hierarchy level. This enables you to make commit conguraon
changes to the prex list more quickly than you can in the standard conguraon database.
NOTE: If you are downgrading the Junos OS to Junos OS Release 9.4 or earlier, you must rst
delete any roung policies that reference the dynamic database. That is, you must delete any
roung policies or policy objects congured with the dynamic-db statement.
Applying Dynamic Roung Policies to BGP
BGP is the only roung protocol to which you can apply roung policies that reference the dynamic
database conguraon. You must apply these policies in the standard conguraon. Dynamic policies
can be applied to BGP export or import policy. They can also be applied at the global, group, or neighbor
hierarchy level.
To apply a BGP export policy, include the export [
policy-names
] statement at the [edit protocols bgp], [edit
protocols bgp group
group-name
], or [edit protocols bgp group
group-name
neighbor
address
] hierarchy level.
[edit]
protocols
bgp {
export [
policy-names
];
}
}
737
To apply a BGP import policy, include the import [
policy-names
] statement at the [edit protocols bgp], [edit
protocols bgp group
group-name
], or [edit protocols bgp group
group-name
neighbor
address
] hierarchy level.
[edit]
protocols
bgp {
import [
policy-names
];
}
}
Include one or more policy names congured in that standard conguraon at the [edit policy-options
policy-statement
] hierarchy level that reference policies congured in the dynamic database.
Prevenng Reestablishment of BGP Peering Sessions Aer NSR Roung Engine
Switchover
If you have acve nonstop roung (NSR) enabled, the dynamic database is not synchronized with the
backup Roung Engine. As a result, if a switchover to a backup Roung Engine occurs, import and
export policies running on the primary Roung Engine at the me of the switchover might no longer be
available. Therefore, you might want to prevent a BGP peering session from automacally being
reestablished as soon as a switchover occurs.
You can congure the router not to reestablish a BGP peering session aer an acve nonstop roung
switchover either for a specied period or unl you manually reestablish the session. Include the idle-
after-switch-over (
seconds
| forever) statement at the [edit protocols bgp], [edit protocols bgp group
group-
name
], or [edit protocols bgp group
group-name
neighbor
address
] hierarchy level:
[edit]
bgp {
protocols {
idle-after-switch-over (
seconds
| never);
}
}
For
seconds
, specify a value from 1 through 4,294,967,295 (2
32
– 1). The BGP peering session is not
reestablished unl aer the specied period. If you specify the forever opon, the BGP peering session is
not established unl you issue the clear bgp neighbor command.
738
RELATED DOCUMENTATION
Example: Conguring Dynamic Roung Policies | 739
Junos OS High Availability User Guide
Example: Conguring Dynamic Roung Policies
IN THIS SECTION
Requirements | 739
Overview | 739
Conguraon | 741
Vericaon | 752
This example shows how to congure roung policy objects in a dynamic database that is not subject to
the same vericaon required in the standard conguraon database.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
The vericaon process required to commit conguraon changes can entail a signicant amount of
overhead and me.
The me it takes to commit changes to the dynamic database is much shorter than for the standard
conguraon database. You can reference these policies and policy objects in roung policies you
congure in the standard database. BGP is the only protocol to which you can apply roung policies that
reference policies and policy objects congured in the dynamic database. Aer you congure and
commit a roung policy based on the objects congured in the dynamic database, you can quickly
update any exisng roung policy by making changes to the dynamic database conguraon.
CAUTION: Because Junos OS does not validate conguraon changes to the dynamic
database, when you use this feature, you should test and verify all conguraon
changes before comming them.
739
Figure 45 on page 740 shows the sample network.
Figure 45: Dynamic Roung Policy Sample Network
The example includes three routers with external BGP (EBGP) sessions established. Only Device R1
makes use of the dynamic database.
On Device R0’s fe-1/2/1 interface, mulple IPv4 interfaces are congured, and a roung policy injects
these prexes into BGP, using the from interface fe-1/2/1.0 policy condion as a shorthand method for
specifying all of the IP addresses congured on Device R0’s fe-1/2/1 interface.
Likewise, on Device R2’s fe-1/2/3 interface, mulple IPv4 addresses are congured, and a roung policy
injects these prexes into BGP. Device R2’s conguraon is slightly dierent from Device R0’s in that
Device R2’s conguraon demonstrates the use of a prex list.
On Device R1, in the dynamic database, two prex lists are dened, one for the interface addresses
learned from Device R0 and another for the interface addresses learned from Device R2. Device R1’s
standard database contains roung policies with prex lists that are similar to those dened in the
dynamic database.
In its peer session with Device R0, Device R1 has the stac-database policies applied. In contrast, in its
peer session with Device R2, Device R1’s conguraon references the dynamic database.
The results of these dierent conguraons are analyzed in the "Vericaon" on page 752 secon.
"CLI Quick Conguraon" on page 741 shows the conguraon for all of the devices in Figure 45 on
page 740.
The secon "No Link Title" on page 744 describes the steps on Device R1’s dynamic database.
The secon "No Link Title" on page 745 describes the steps on Device R1’s standard database.
740
Conguraon
IN THIS SECTION
Procedure | 741
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R0
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30
set interfaces fe-1/2/1 unit 0 family inet address 172.16.4.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.3.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.2.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.1.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.5.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.6.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.7.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.8.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.9.1/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.10.1/24
set interfaces lo0 unit 0 family inet address 10.255.14.151/32
set protocols bgp group ext type external
set protocols bgp group ext neighbor 10.0.0.2 export t2
set protocols bgp group ext neighbor 10.0.0.2 peer-as 200
set policy-options policy-statement t2 from interface fe-1/2/0.0
set policy-options policy-statement t2 from interface fe-1/2/1.0
set policy-options policy-statement t2 then accept
set routing-options router-id 10.255.14.151
set routing-options autonomous-system 100
741
Device R1 Dynamic Database
[edit dynamic]
set policy-options prefix-list dyn_prfx1 172.16.1.0/24
set policy-options prefix-list dyn_prfx1 172.16.2.0/24
set policy-options prefix-list dyn_prfx1 172.16.3.0/24
set policy-options prefix-list dyn_prfx1 172.16.4.0/24
set policy-options prefix-list dyn_prfx1 172.16.5.0/24
set policy-options prefix-list dyn_prfx1 172.16.6.0/24
set policy-options prefix-list dyn_prfx1 172.16.7.0/24
set policy-options prefix-list dyn_prfx1 172.16.8.0/24
set policy-options prefix-list dyn_prfx2 172.16.2.0/24
set policy-options prefix-list dyn_prfx2 172.16.3.0/24
set policy-options prefix-list dyn_prfx2 172.16.4.0/24
set policy-options prefix-list dyn_prfx2 172.16.5.0/24
set policy-options prefix-list dyn_prfx2 172.16.6.0/24
set policy-options policy-statement dyn_policy1 term t1 from prefix-list dyn_prfx1
set policy-options policy-statement dyn_policy1 term t1 then accept
set policy-options policy-statement dyn_policy1 term t2 then reject
set policy-options policy-statement dyn_policy2 term t1 from prefix-list dyn_prfx2
set policy-options policy-statement dyn_policy2 term t1 then accept
set policy-options policy-statement dyn_policy2 term t2 then reject
Device R1 Standard Database
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30
set interfaces fe-1/2/2 unit 0 family inet address 10.1.0.1/30
set interfaces fe-1/2/1 unit 0 family inet address 172.16.4.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.3.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.2.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.1.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.5.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.6.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.7.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.8.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.9.2/24
set interfaces fe-1/2/1 unit 0 family inet address 172.16.10.2/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.22.2/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.23.2/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.24.2/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.25.2/24
742
set interfaces fe-1/2/3 unit 0 family inet address 172.16.26.2/24
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp group to_r0 idle-after-switch-over 300
set protocols bgp group to_r0 neighbor 10.0.0.1 import dyn_policy1
set protocols bgp group to_r0 neighbor 10.0.0.1 export dyn_policy2
set protocols bgp group to_r0 neighbor 10.0.0.1 peer-as 100
set protocols bgp group to_R2 import static_policy1
set protocols bgp group to_R2 export static_policy2
set protocols bgp group to_R2 idle-after-switch-over 300
set protocols bgp group to_R2 neighbor 10.1.0.2 peer-as 300
set policy-options prefix-list static_prfx1 172.16.22.0/24
set policy-options prefix-list static_prfx1 172.16.23.0/24
set policy-options prefix-list static_prfx1 172.16.24.0/24
set policy-options prefix-list static_prfx1 172.16.25.0/24
set policy-options prefix-list static_prfx2 172.16.1.0/24
set policy-options prefix-list static_prfx2 172.16.2.0/24
set policy-options prefix-list static_prfx2 172.16.3.0/24
set policy-options prefix-list static_prfx2 172.16.4.0/24
set policy-options policy-statement dyn_policy1 dynamic-db
set policy-options policy-statement dyn_policy2 dynamic-db
set policy-options policy-statement static_policy1 term t1 from prefix-list static_prfx1
set policy-options policy-statement static_policy1 term t1 then accept
set policy-options policy-statement static_policy1 term t2 then reject
set policy-options policy-statement static_policy2 term t1 from prefix-list static_prfx2
set policy-options policy-statement static_policy2 term t1 then accept
set policy-options policy-statement static_policy2 term t2 then reject
set routing-options autonomous-system 200
Device R2
set interfaces fe-1/2/2 unit 0 family inet address 10.1.0.2/30
set interfaces fe-1/2/3 unit 0 family inet address 172.16.22.1/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.23.1/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.24.1/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.25.1/24
set interfaces fe-1/2/3 unit 0 family inet address 172.16.26.1/24
set interfaces lo0 unit 0 family inet address 192.168.0.3/32
set protocols bgp group to_vin neighbor 10.1.0.1 export p1
set protocols bgp group to_vin neighbor 10.1.0.1 peer-as 200
set policy-options prefix-list ppx1 172.16.22.0/24
set policy-options prefix-list ppx1 172.16.23.0/24
set policy-options prefix-list ppx1 172.16.24.0/24
743
set policy-options prefix-list ppx1 172.16.25.0/24
set policy-options prefix-list ppx1 172.16.26.0/24
set policy-options policy-statement p1 term t1 from family inet
set policy-options policy-statement p1 term t1 from prefix-list ppx1
set policy-options policy-statement p1 term t1 then accept
set routing-options autonomous-system 300
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure Device R1’s dynamic database:
1. Enter conguraon mode for the dynamic database.
user@R1> configure dynamic
Entering configuration mode
[edit dynamic]
2. Create a prex list for the interface addresses learned from Device R0.
[edit dynamic policy-options prefix-list dyn_prfx1]
user@R1# set 172.16.1.0/24
user@R1# set 172.16.2.0/24
user@R1# set 172.16.3.0/24
user@R1# set 172.16.4.0/24
user@R1# set 172.16.5.0/24
user@R1# set 172.16.6.0/24
user@R1# set 172.16.7.0/24
user@R1# set 172.16.8.0/24
3. Create a prex list for the interface addresses learned from Device R2.
[edit dynamic policy-options prefix-list dyn_prfx2]
user@R1# set 172.16.2.0/24
user@R1# set 172.16.3.0/24
user@R1# set 172.16.4.0/24
744
user@R1# set 172.16.5.0/24
user@R1# set 172.16.6.0/24
4. Congure the roung policies.
[edit dynamic policy-options policy-statement dyn_policy1]
user@R1# set term t1 from prefix-list dyn_prfx1
user@R1# set term t1 then accept
user@R1# set term t2 then reject
user@R1# set term t1 from prefix-list dyn_prfx2
user@R1# set term t1 then accept
user@R1# set term t2 then reject
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure Device R1’s standard database:
1. Create the router interfaces.
[edit interfaces]
user@R1# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30
user@R1# set fe-1/2/2 unit 0 family inet address 10.1.0.1/30
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.4.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.3.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.2.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.1.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.5.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.6.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.7.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.8.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.9.2/24
user@R1# set fe-1/2/1 unit 0 family inet address 172.16.10.2/24
user@R1# set fe-1/2/3 unit 0 family inet address 172.16.2.2/24
user@R1# set fe-1/2/3 unit 0 family inet address 172.16.3.2/24
user@R1# set fe-1/2/3 unit 0 family inet address 172.16.4.2/24
user@R1# set fe-1/2/3 unit 0 family inet address 172.16.5.2/24
745
user@R1# set fe-1/2/3 unit 0 family inet address 172.16.6.2/24
user@R1# set lo0 unit 0 family inet address 192.168.0.2/32
2. Create roung policies that reference the policies in the dynamic database.
[edit policy-options]
user@R1# set policy-statement dyn_policy1 dynamic-db
user@R1# set policy-statement dyn_policy2 dynamic-db
3. Congure BGP peering with Device R0.
[edit protocols bgp group to_r0]
user@R1# set neighbor 10.0.0.1 peer-as 100
4. Apply the dynamic database policies to the BGP peering with Device R0.
[edit protocols bgp group to_r0]
user@R1# set neighbor 10.0.0.1 import dyn_policy1
user@R1# set neighbor 10.0.0.1 export dyn_policy2
5. Congure a prex list for prexes learned from Device R0.
[edit policy-options prefix-list static_prfx2]
user@R1# set 172.16.1.0/24
user@R1# set 172.16.2.0/24
user@R1# set 172.16.3.0/24
user@R1# set 172.16.4.0/24
6. Congure a prex list for prexes learned from Device R2.
[edit policy-options prefix-list static_prfx1]
user@R1# set 172.16.2.0/24
user@R1# set 172.16.3.0/24
user@R1# set 172.16.4.0/24
user@R1# set 172.16.5.0/24
746
7. Congure the stac database policies.
[edit policy-options policy-statement static_policy1]
user@R1# set term t1 from prefix-list static_prfx1
user@R1# set term t1 then accept
user@R1# set term t2 then reject
[edit policy-options policy-statement static_policy2]
user@R1# set term t1 from prefix-list static_prfx2
user@R1# set term t1 then accept
user@R1# set term t2 then reject
8. Congure BGP peering with Device R2.
[edit protocols bgp group to_R2]
user@R1# set neighbor 10.1.0.2 peer-as 300
9. Apply the stac database policies to the BGP peering with Device R2.
[edit protocols bgp group to_R2]
user@R1# set import static_policy1
user@R1# set export static_policy2
10. (Oponal) Congure the router not to reestablish the BGP peering sessions aer an acve nonstop
roung switchover either for a specied period or unl you manually reestablish the session.
This statement is parcularly useful with dynamic roung policies because the dynamic database is
not synchronized with the backup Roung Engine when nonstop acve roung (NSR) is enabled. As
a result, if a switchover to a backup Roung Engine occurs, import and export policies running on
the primary Roung Engine at the me of the switchover might no longer be available. Therefore,
you might want to prevent a BGP peering session from automacally being reestablished as soon as
a switchover occurs.
[edit protocols bgp]
user@R1# set group to_r0 idle-after-switch-over 300
user@R1# set group to_R2 idle-after-switch-over 300
747
11. Congure the autonomous system (AS) number.
[edit routing-options]
user@R1# set routing-options autonomous-system 200
Results
Conrm your conguraon by entering the show command from conguraon mode in the dynamic
database, and the show interfaces, show protocols, show policy-options and show routing-options commands from
conguraon mode in the standard database. If the output does not display the intended conguraon,
repeat the instrucons in this example to correct the conguraon.
Device R1 Dynamic
[edit dynamic]
user@R1# show
policy-options {
prefix-list dyn_prfx1 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
172.16.6.0/24;
172.16.7.0/24;
172.16.8.0/24;
}
prefix-list dyn_prfx2 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
172.16.6.0/24;
}
policy-statement dyn_policy1 {
term t1 {
from {
prefix-list dyn_prfx1;
}
then accept;
}
748
term t2 {
then reject;
}
}
policy-statement dyn_policy2 {
term t1 {
from {
prefix-list dyn_prfx2;
}
then accept;
}
term t2 {
then reject;
}
}
}
Device R1 Standard
[edit]
user@R1# 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 172.16.4.2/24;
address 172.16.3.2/24;
address 172.16.2.2/24;
address 172.16.1.2/24;
address 172.16.5.2/24;
address 172.16.6.2/24;
address 172.16.7.2/24;
address 172.16.8.2/24;
address 172.16.9.2/24;
address 172.16.10.2/24;
}
749
}
}
fe-1/2/2 {
unit 0 {
family inet {
address 10.1.0.1/30;
}
}
}
fe-1/2/3 {
unit 0 {
family inet {
address 172.16.2.2/24;
address 172.16.3.2/24;
address 172.16.4.2/24;
address 172.16.5.2/24;
address 172.16.6.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R1# show protocols
bgp {
group to_r0 {
idle-after-switch-over 300;
neighbor 10.0.0.1 {
import dyn_policy1;
export dyn_policy2;
peer-as 100;
}
}
group to_R2 {
import static_policy1;
export static_policy2;
750
idle-after-switch-over 300;
neighbor 10.1.0.2 {
peer-as 300;
}
}
}
user@R1# show policy-options
prefix-list static_prfx1 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
}
prefix-list static_prfx2 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
}
policy-statement dyn_policy1 {
dynamic-db;
}
policy-statement dyn_policy2 {
dynamic-db;
}
policy-statement static_policy1 {
term t1 {
from {
prefix-list static_prfx1;
}
then accept;
}
term t2 {
then reject;
}
}
policy-statement static_policy2 {
term t1 {
from {
prefix-list static_prfx2;
751
}
then accept;
}
term t2 {
then reject;
}
}
user@R1# show routing-options
autonomous-system 200;
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Checking the Congured Policies on Device R1 | 752
Checking the Routes Adversed from Device R0 to Device R1 | 754
Checking the Routes That Device R1 Is Receiving from Device R0 | 755
Checking the Routes Adversed from Device R2 to Device R1 | 756
Checking the Routes That Device R1 Is Receiving from Device R2 | 756
Checking the Routes That Device R1 Is Adversing to Device R0 | 757
Checking the Routes That Device R1 Is Adversing to Device R2 | 758
Conrm that the conguraon is working properly.
Checking the Congured Policies on Device R1
Purpose
Verify that Device R1 has the dynamic and stac policies in eect.
752
Acon
From Device R1, enter the show policy command.
user@R1> show policy
Configured policies:
dyn_policy1
dyn_policy2
static_policy1
static_policy2
dyn_policy1
dyn_policy2
Meaning
The dynamic policies are listed two mes because they are congured two mes, the rst and central
conguraon in the dynamic database. The secondary conguraon is in the stac database, where the
dynamic database is referenced, as shown here:
Congured in the Dynamic Database
policy-statement dyn_policy1 {
term t1 {
from {
prefix-list dyn_prfx1;
}
then accept;
}
term t2 {
then reject;
}
}
policy-statement dyn_policy2 {
term t1 {
from {
prefix-list dyn_prfx2;
}
then accept;
}
term t2 {
then reject;
753
}
}
Referenced from the Stac Database
policy-statement dyn_policy1 {
dynamic-db;
}
policy-statement dyn_policy2 {
dynamic-db;
}
Checking the Routes Adversed from Device R0 to Device R1
Purpose
Verify that Device R0’s roung policy is working.
Acon
From Device R0, enter the show route advertising-protocol bgp command, using the neighbor address for
Device R1.
user@R0> show route advertising-protocol bgp 10.0.0.2
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.1.0/24 Self I
* 172.16.2.0/24 Self I
* 172.16.3.0/24 Self I
* 172.16.4.0/24 Self I
* 172.16.5.0/24 Self I
* 172.16.6.0/24 Self I
* 172.16.7.0/24 Self I
* 172.16.8.0/24 Self I
* 172.16.9.0/24 Self I
* 172.16.10.0/24 Self I
* 10.0.0.0/30 Self I
754
Meaning
Device R0 is sending the expected routes to Device R1.
Checking the Routes That Device R1 Is Receiving from Device R0
Purpose
Verify that Device R1’s import roung policy is working.
Acon
From Device R1, enter the show route receive-protocol bgp command, using the neighbor address for
Device R0.
user@R1> show route receive-protocol bgp 10.0.0.1
inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden)
Prefix Nexthop MED Lclpref AS path
172.16.1.0/24 10.0.0.1 100 I
172.16.2.0/24 10.0.0.1 100 I
172.16.3.0/24 10.0.0.1 100 I
172.16.4.0/24 10.0.0.1 100 I
172.16.5.0/24 10.0.0.1 100 I
172.16.6.0/24 10.0.0.1 100 I
172.16.7.0/24 10.0.0.1 100 I
172.16.8.0/24 10.0.0.1 100 I
Meaning
Some of the routes that are sent by Device R0 are not received by Device R1. The routes 172.16.9.0/24,
172.16.10.0/24, and 10.0.0.0/30 are missing. This is because Device R1’s import policy, applied to the
BGP peering session with Device R0 using the import dyn_policy1 statement, specically denes a prex
list limited to the following routes:
prefix-list dyn_prfx1 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
755
172.16.6.0/24;
172.16.7.0/24;
172.16.8.0/24;
}
Checking the Routes Adversed from Device R2 to Device R1
Purpose
Verify that Device R2’s roung policy is working.
Acon
From Device R2, enter the show route advertising-protocol bgp command, using the neighbor address for
Device R1.
user@R2> show route advertising-protocol bgp 10.1.0.1
inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.2.0/24 Self I
* 172.16.3.0/24 Self I
* 172.16.4.0/24 Self I
* 172.16.5.0/24 Self I
* 172.16.6.0/24 Self I
Meaning
Device R2 is sending the expected routes to Device R1.
Checking the Routes That Device R1 Is Receiving from Device R2
Purpose
Verify that Device R1’s import roung policy is working.
756
Acon
From Device R1, enter the show route receive-protocol bgp command, using the neighbor address for
Device R0.
user@R1> show route receive-protocol bgp 10.1.0.2
inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden)
Prefix Nexthop MED Lclpref AS path
172.16.2.0/24 10.1.0.2 300 I
172.16.3.0/24 10.1.0.2 300 I
172.16.4.0/24 10.1.0.2 300 I
172.16.5.0/24 10.1.0.2 300 I
Meaning
One of the routes that is sent by Device R2 is not received by Device R1. The route 172.16.6.0/24 is
missing. This is because Device R1’s import policy, applied to the BGP peering session with Device R2
using the import static_policy1 statement, specically denes a prex list limited to the following routes:
prefix-list static_prfx1 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
}
Checking the Routes That Device R1 Is Adversing to Device R0
Purpose
Verify that Device R1’s export roung policy is working.
Acon
From Device R1, enter the show route advertising-protocol bgp command, using the neighbor address for
Device R0.
user@R1> show route advertising-protocol bgp 10.0.0.1
inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden)
757
Prefix Nexthop MED Lclpref AS path
* 172.16.2.0/24 Self I
* 172.16.3.0/24 Self I
* 172.16.4.0/24 Self I
* 172.16.5.0/24 Self I
* 172.16.6.0/24 Self I
Meaning
Perhaps unexpectedly, the route that Device R1 did not receive through BGP from Device R2
(172.16.6.0/24) is nonetheless being adversed by Device R1 through BGP to Device R0. This is
happening for two reasons. The rst reason is that route 172.16.6.0/24 is in Device R1’s roung table,
albeit as a direct route, as shown here:
user@R1> show route 172.16.6.0/24 protocol direct
inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[Direct/0] 2d 22:51:41
> via fe-1/2/3.0
The second reason is that Device R1’s export policy, applied to the BGP peering session with Device R0
using the export dyn_policy2 statement, specically denes a prex list limited to the following routes:
prefix-list dyn_prfx2 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
172.16.6.0/24;
}
Note the inclusion of 172.16.6.0/24.
Checking the Routes That Device R1 Is Adversing to Device R2
Purpose
Verify that Device R1’s export roung policy is working.
758
Acon
From Device R1, enter the show route advertising-protocol bgp command, using the neighbor address for
Device R2.
user@R1> show route advertising-protocol bgp 10.1.0.2
inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.1.0/24 Self I
* 172.16.2.0/24 Self I
* 172.16.3.0/24 Self I
* 172.16.4.0/24 Self I
Meaning
Device R1 is sending the expected routes to Device R2. Device R1’s export policy, applied to the BGP
peering session with Device R2 using the export static_policy2 statement, specically denes a prex list
limited to the following routes:
prefix-list static_prfx2 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
}
RELATED DOCUMENTATION
Understanding Dynamic Roung Policies | 734
Example: Conguring Roung Policy Prex Lists | 398
759
CHAPTER 12
Tesng Before Applying Roung Policies
IN THIS CHAPTER
Understanding Roung Policy Tests | 760
Example: Tesng a Roung Policy with Complex Regular Expressions | 762
Understanding
Roung Policy Tests
IN THIS SECTION
Example: Tesng a Roung Policy | 761
Roung policy tests provide a method for verifying the eecveness of your policies before applying
them on the roung device. Before applying a roung policy, you can issue the test policy command to
ensure that the policy produces the results that you expect:
user@host> test policy
policy-name
prefix
Keep in mind that dierent protocols have dierent default policies that get applied if the prex does
not match the congured policy. For BGP this is accept, but for RIP it is reject. The test policy command
always uses accept as the default policy, so unless you explicitly reject all routes that you do not want to
match you might see more routes matching than you want.
The default policy of the test policy command accepts all routes from all protocols. Test output can be
misleading when you are evaluang protocol-specic condions. For example, if you dene a policy for
BGP that accepts routes of a specied prex and apply it to BGP as an export policy, BGP routes that
match the prex are adversed to BGP peers. However, if you test the same policy using the test policy
command, the test output might indicate that non-BGP routes have been accepted.
760
Example: Tesng a Roung Policy
Test the following policy, which looks for unwanted routes and rejects them:
[edit policy-options]
policy-statement reject-unwanted-routes {
term drop-these-routes {
from {
route-filter 0/0 exact;
route-filter 10/8 orlonger;
route-filter 172.16/12 orlonger;
route-filter 192.168/16 orlonger;
route-filter 224/3 orlonger;
}
then reject;
}
}
Test this policy against all routes in the roung table:
user@host> test policy reject-unwanted-routes 0/0
Test this policy against a specic set of routes:
user@host> test policy reject-unwanted-routes 10.49.0.0/16
RELATED DOCUMENTATION
Example: Tesng a Roung Policy with Complex Regular Expressions | 762
761
Example: Tesng a Roung Policy with Complex Regular Expressions
IN THIS SECTION
Requirements | 762
Overview | 762
Conguraon | 765
Vericaon | 771
This example shows how to test a roung policy using the test policy command to ensure that the policy
produces the results that you expect before you apply it in a producon environment. Regular
expressions, especially complex ones, can be tricky to get right. This example shows how to use the test
policy command to make sure that your regular expressions have the intended eect.
Requirements
No special conguraon beyond device inializaon is required before you congure this example.
Overview
IN THIS SECTION
Topology | 764
This example shows two roung devices with an external BGP (EBGP) connecon between them.
Device R2 uses the BGP session to send customer routes to Device R1. These stac routes have
mulple community values aached.
user@R2> show route match-prefix 172.16.* detail
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
172.16.1.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Reject
Address: 0x8fd0dc4
762
Next-hop reference count: 8
State: <Active Int Ext>
Local AS: 64511
Age: 21:32:13
Validation State: unverified
Task: RT
Announcement bits (1): 0-KRT
AS path: I
Communities: 64510:1 64510:10 64510:11 64510:100 64510:111
172.16.2.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Reject
Address: 0x8fd0dc4
Next-hop reference count: 8
State: <Active Int Ext>
Local AS: 64511
Age: 21:32:13
Validation State: unverified
Task: RT
Announcement bits (1): 0-KRT
AS path: I
Communities: 64510:2 64510:20 64510:22 64510:200 64510:222
172.16.3.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Reject
Address: 0x8fd0dc4
Next-hop reference count: 8
State: <Active Int Ext>
Local AS: 64511
Age: 21:32:13
Validation State: unverified
Task: RT
Announcement bits (1): 0-KRT
AS path: I
Communities: 64510:3 64510:30 64510:33 64510:300 64510:333
172.16.4.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Reject
Address: 0x8fd0dc4
Next-hop reference count: 8
763
State: <Active Int Ext>
Local AS: 64511
Age: 21:32:13
Validation State: unverified
Task: RT
Announcement bits (1): 0-KRT
AS path: I
Communities: 64510:4 64510:40 64510:44 64510:400 64510:444
To test a complex regular expression, Device R2 has a policy called test-regex that locates routes. The
policy is congured like this:
policy-statement test-regex {
term find-routes {
from community complex-regex;
then accept;
}
term reject-the-rest {
then reject;
}
}
community complex-regex members "^64510:[13].*$";
This regular expression matches community values beginning with either 1 or 3.
Topology
Figure 46 on page 765 shows the sample network.
764
Figure 46: Roung Policy Test for Complex Regular Expressions
"CLI Quick Conguraon" on page 765 shows the conguraon for all of the devices in Figure 46 on
page 765.
The secon "No Link Title" on page 767 describes the steps on Device R2.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 765
Procedure | 767
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
765
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 64511
set protocols bgp group ext neighbor 10.0.0.2
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 family inet address 10.0.0.2/30
set interfaces lo0 unit 0 family inet address 192.168.0.2/32
set protocols bgp group ext type external
set protocols bgp group ext peer-as 64510
set protocols bgp group ext neighbor 10.0.0.1
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set policy-options policy-statement send-static term 2 then reject
set policy-options policy-statement test-regex term find-routes from community complex-regex
set policy-options policy-statement test-regex term find-routes then accept
set policy-options policy-statement test-regex term reject-the-rest then reject
set policy-options community complex-regex members "^64510:[13].*$"
set routing-options static route 172.16.1.0/24 reject
set routing-options static route 172.16.1.0/24 community 64510:1
set routing-options static route 172.16.1.0/24 community 64510:10
set routing-options static route 172.16.1.0/24 community 64510:11
set routing-options static route 172.16.1.0/24 community 64510:100
set routing-options static route 172.16.1.0/24 community 64510:111
set routing-options static route 172.16.2.0/24 reject
set routing-options static route 172.16.2.0/24 community 64510:2
set routing-options static route 172.16.2.0/24 community 64510:20
set routing-options static route 172.16.2.0/24 community 64510:22
set routing-options static route 172.16.2.0/24 community 64510:200
set routing-options static route 172.16.2.0/24 community 64510:222
set routing-options static route 172.16.3.0/24 reject
set routing-options static route 172.16.3.0/24 community 64510:3
set routing-options static route 172.16.3.0/24 community 64510:30
set routing-options static route 172.16.3.0/24 community 64510:33
set routing-options static route 172.16.3.0/24 community 64510:300
766
set routing-options static route 172.16.3.0/24 community 64510:333
set routing-options static route 172.16.4.0/24 reject
set routing-options static route 172.16.4.0/24 community 64510:4
set routing-options static route 172.16.4.0/24 community 64510:40
set routing-options static route 172.16.4.0/24 community 64510:44
set routing-options static route 172.16.4.0/24 community 64510:400
set routing-options static route 172.16.4.0/24 community 64510:444
set routing-options router-id 192.168.0.2
set routing-options autonomous-system 64511
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure Device R2:
1. Congure the interfaces.
[edit interfaces]
user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30
user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure BGP.
Apply the import policy to the BGP peering session with Device R2.
[edit protocols bgp group ext]
user@R2# set type external
user@R2# set peer-as 64510
user@R2# set neighbor 10.0.0.1
3. Congure the roung policy that sends stac routes.
[edit policy-options policy-statement send-static]
user@R2# set term 1 from protocol static
767
user@R2# set term 1 then accept
user@R2# set term 2 then reject
4. Congure the roung policy that tests a regular expression.
[edit policy-options policy-statement test-regex]
user@R2# set term find-routes from community complex-regex
user@R2# set term find-routes then accept
user@R2# set term reject-the-rest then reject
[edit policy-options community]
user@R2# set complex-regex members "^64510:[13].*$"
5. Congure the stac routes and aaches community values.
[edit routing-options static route 172.16.1.0/24]
user@R2# set reject
user@R2# set community [ 64510:1 64510:10 64510:11 64510:100 64510:111 ]
[edit routing-options static route 172.16.2.0/24]
user@R2# set reject
user@R2# set community [ 64510:2 64510:20 64510:22 64510:200 64510:222 ]
[edit routing-options static route 172.16.3.0/24]
user@R2# set reject
user@R2# set community [ 64510:3 64510:30 64510:33 64510:300 64510:333 ]
[edit routing-options static route 172.16.4.0/24]
user@R2# set reject
user@R2# set community [ 64510:4 64510:40 64510:44 64510:400 64510:444 ]
6. Congure the autonomous system (AS) number and the router ID.
This aects Device R2’s roung table, and as no impact on Device R1 and Device R3.
[edit routing-options ]
user@R2# set router-id 192.168.0.2
user@R2# set autonomous-system 64511
768
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show protocols, show
policy-options, and show routing-options commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@R2# show interfaces
fe-1/2/0 {
unit 0 {
family inet {
address 10.0.0.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
type external;
peer-as 64510;
neighbor 10.0.0.1;
}
}
user@R2# show policy-options
policy-statement send-static {
term 1 {
from protocol static;
then accept;
}
term 2 {
then reject;
769
}
}
policy-statement test-regex {
term find-routes {
from community complex-regex;
then accept;
}
term reject-the-rest {
then reject;
}
}
community complex-regex members "^64510:[13].*$";
user@R2# show routing-options
static {
route 172.16.1.0/24 {
reject;
community [ 64510:1 64510:10 64510:11 64510:100 64510:111 ];
}
route 172.16.2.0/24 {
reject;
community [ 64510:2 64510:20 64510:22 64510:200 64510:222 ];
}
route 172.16.3.0/24 {
reject;
community [ 64510:3 64510:30 64510:33 64510:300 64510:333 ];
}
route 172.16.4.0/24 {
reject;
community [ 64510:4 64510:40 64510:44 64510:400 64510:444 ];
}
}
router-id 192.168.0.2;
autonomous-system 64511;
If you are done conguring the device, enter commit from conguraon mode.
770
Vericaon
IN THIS SECTION
Test to See Which Communies Match the Regular Expression | 771
Conrm that the conguraon is working properly.
Test to See Which Communies Match the Regular Expression
Purpose
You can test the regular expression and its policy by using the test policy
policy-name
command.
Acon
1. On Device R2, run the test policy test-regex 0/0 command.
user@R2> test policy test-regex 0/0
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/24 *[Static/5] 1d 00:32:50
Reject
172.16.3.0/24 *[Static/5] 1d 00:32:50
Reject
Policy test-regex: 2 prefix accepted, 5 prefix rejected
2. On Device R2, change the regular expression to match a community value containing any number of
instances of the digit 2.
[edit policy-options community complex-regex]
user@R2# delete members "^64510:[13].*$"
771
user@R2# set members "^65020:2+$"
user@R2# commit
3. On Device R2, rerun the test policy test-regex 0/0 command.
user@R2> test policy test-regex 0/0
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/24 *[Static/5] 1d 00:31:36
Reject
Policy test-regex: 1 prefix accepted, 6 prefix rejected
Meaning
The 172.16.1.0 /24 and 172.16.3.0/24 routes both have communies aached that match the ^64510:
[13].*$ expression. The 172.16.2.0/24 route has communies that match the ^65020:2+$ expression.
772
2
PART
Conguring Firewall Filters
Understanding How Firewall Filters Protect Your Network | 774
Firewall Filter Match Condions and Acons | 847
Applying Firewall Filters to Roung Engine Trac | 1061
Applying Firewall Filters to Transit Trac | 1142
Conguring Firewall Filters in Logical Systems | 1217
Conguring Firewall Filter Accounng and Logging | 1281
Aaching Mulple Firewall Filters to a Single Interface | 1304
Aaching a Single Firewall Filter to Mulple Interfaces | 1372
Conguring Filter-Based Tunneling Across IP Networks | 1398
Conguring Service Filters | 1435
Conguring Simple Filters | 1467
Conguring Layer 2 Firewall Filters | 1483
Conguring Firewall Filters for Forwarding, Fragments, and Policing | 1497
Conguring Firewall Filters (EX Series Switches) | 1538
Conguring Firewall Filters (QFX Series Switches, EX4600 Switches, PTX Series
Routers) | 1719
Conguring Firewall Filter Accounng and Logging (EX9200 Switches) | 1886
CHAPTER 13
Understanding How Firewall Filters Protect Your
Network
IN THIS CHAPTER
Firewall Filters Overview | 774
Router Data Flow Overview | 775
Stateless Firewall Filter Overview | 778
Understanding How to Use Standard Firewall Filters | 780
Understanding How Firewall Filters Control Packet Flows | 781
Stateless Firewall Filter Components | 783
Stateless Firewall Filter Applicaon Points | 790
How Standard Firewall Filters Evaluate Packets | 795
Understanding Firewall Filter Fast Lookup Filter | 800
Understanding Egress Firewall Filters with PVLANs | 801
Selecve Class-based Filtering on PTX Routers | 802
Guidelines for Conguring Firewall Filters | 816
Guidelines for Applying Standard Firewall Filters | 823
Supported Standards for Filtering | 828
Monitoring Firewall Filter Trac | 829
Troubleshoong Firewall Filters | 832
Firewall Filters Overview
Firewall lters provide a means of protecng your router (and switch) from excessive trac transing
the router (and switch) to a network desnaon or desned for the Roung Engine. Firewall lters that
control local packets can also protect your router (and switch) from external incidents.
You can congure a
rewall lter
to do the following:
774
• Restrict trac desned for the Roung Engine based on its source, protocol, and applicaon.
• Limit the trac rate of packets desned for the Roung Engine to protect against ood, or denial-of-
service (DoS) aacks.
• Address special circumstances associated with fragmented packets desned for the Roung Engine.
Because the device evaluates every packet against a rewall lter (including fragments), you must
congure the lter to accommodate fragments that do not contain packet header informaon.
Otherwise, the lter discards all but the rst fragment of a fragmented packet.
RELATED DOCUMENTATION
Stateless Firewall Filter Types
Guidelines for Conguring Firewall Filters | 816
Guidelines for Applying Standard Firewall Filters | 823
Understanding How to Use Standard Firewall Filters | 780
Router Data Flow Overview
IN THIS SECTION
Flow of Roung Informaon | 775
Flow of Data Packets | 776
Flow of Local Packets | 776
Interdependent Flows of Roung Informaon and Packets | 777
Stateless and Stateful Firewall Filters | 777
The Junos® operang system (Junos OS) provides a
policy framework
, which is a collecon of Junos OS
policies that enable you to control ows of roung informaon and packets within the router.
Flow of Roung Informaon
Roung informaon
is the informaon about routes learned by the roung protocols from a router’s
neighbors. This informaon is stored in roung tables. The roung protocols adverse acve routes only
775
from the roung tables. An
acve route
is a route that is chosen from all routes in the roung table to
reach a desnaon.
To control which routes the roung protocols place in the roung tables and which routes the roung
protocols adverse from the roung tables, you can congure
roung policies
, which are sets of rules
that the policy framework uses to preempt default roung policies.
The Roung Engine, which runs the router's control plane soware, handles the ow of roung
informaon between the roung protocols and the roung tables and between the roung tables and
the forwarding table. The Roung Engine runs the Junos OS and roung policies and stores the acve
router conguraon, the master roung table, and the master forwarding table,
Flow of Data Packets
Data packets
are chunks of data that transit the router as they are being forwarded from a source to a
desnaon. When a router receives a data packet on an interface, it determines where to forward the
packet by looking in the forwarding table for the best route to a desnaon. The router then forwards
the data packet toward its desnaon through the appropriate interface.
The Packet Forwarding Engine, which is the central processing element of the router’s forwarding plane,
handles the ow of data packets in and out of the router’s physical interfaces. Although the Packet
Forwarding Engine contains Layer 3 and Layer 4 header informaon, it does not contain the packet data
itself (the packet's payload).
To control the ow of data packets transing the device as the packets are being forwarded from a
source to a desnaon, you can apply stateless rewall lters to the input or output of the router’s or
switch’s physical interfaces.
To enforce a specied bandwidth and maximum burst size for trac sent or received on an interface,
you can congure policers. Policers are a specialized type of stateless rewall lter and a primary
component of the Junos OS class-of-service (CoS).
Flow of Local Packets
Local packets
are chunks of data that are desned for or sent by the router. Local packets usually
contain roung protocol data, data for IP services such as Telnet or SSH, and data for administrave
protocols such as the Internet Control Message Protocol (ICMP). When the Roung Engine receives a
local packet, it forwards the packet to the appropriate process or to the kernel, which are both part of
the Roung Engine, or to the Packet Forwarding Engine.
The Roung Engine handles the ow of local packets from the router’s physical interfaces and to the
Roung Engine.
776
To control the ow of local packets between the physical interfaces and the Roung Engine, you can
apply stateless rewall lters to the input or output of the loopback interface. The loopback interface
(lo0) is the interface to the Roung Engine and carries no data packets.
Interdependent Flows of Roung Informaon and Packets
Figure 47 on page 777 illustrates the ow of data through a router. Although roung informaon ows
and packet ows are very dierent from one another, they are also interdependent.
Figure 47: Flows of Roung Informaon and Packets
Roung policies determine which routes the Roung Engine places in the forwarding table. The
forwarding table, in turn, has an integral role in determining the appropriate physical interface through
which to forward a packet.
Stateless and Stateful Firewall Filters
A stateless rewall lter, also known as an access control list (ACL), does not statefully inspect trac.
Instead, it evaluates packet contents stacally and does not keep track of the state of network
connecons. In contrast, a stateful rewall lter uses connecon state informaon derived from other
applicaons and past communicaons in the data ow to make dynamic control decisions.
The basic purpose of a stateless rewall lter is to enhance security through the use of packet ltering.
Packet ltering enables you to inspect the components of incoming or outgoing packets and then
perform the acons you specify on packets that match the criteria you specify. The typical use of a
stateless rewall lter is to protect the Roung Engine processes and resources from malicious or
untrusted packets.
RELATED DOCUMENTATION
Stateless Firewall Filter Components | 783
Understanding Firewall Filter Processing Points for Bridged and Routed Packets | 1856
Understanding How Firewall Filters Are Evaluated | 856
777
Conguring Firewall Filters | 1829
Understanding Route Preference Values (Administrave Distance)
Understanding Roung Policies | 22
Stateless Firewall Filter Overview
IN THIS SECTION
Packet Flow Control | 778
Stateless and Stateful Firewall Filters | 779
Purpose of Stateless Firewall Filters | 779
Packet Flow Control
To inuence which packets are allowed to transit the system and to apply special acons to packets as
necessary, you can congure
stateless rewall lters
. A stateless rewall species a sequence of one or
more packet-ltering rules, called
lter terms
. A lter term species
match condions
to use to
determine a match and
acons
to take on a matched packet. A stateless
rewall lter
enables you to
manipulate any packet of a parcular protocol family, including fragmented packets, based on evaluaon
of Layer 3 and Layer 4 header elds. You typically apply a stateless rewall lter to one or more
interfaces that have been congured with protocol family features. You can apply a stateless rewall
lter to an ingress interface, an egress interface, or both.
Data Packet Flow Control
To control the ow of data packets transing the device as the packets are being forwarded from a
source to a desnaon, you can apply stateless rewall lters to the input or output of the router’s or
switch’s physical interfaces.
To enforce a specied bandwidth and maximum burst size for trac sent or received on an interface,
you can congure
policers
. Policers are a specialized type of stateless rewall lter and a primary
component of the Junos OS
class-of-service
(CoS).
778
Local Packet Flow Control
To control the ow of local packets between the physical interfaces and the Roung Engine, you can
apply stateless rewall lters to the input or output of the
loopback interface
. The loopback interface
(lo0) is the interface to the Roung Engine and carries no data packets.
Junos OS Evolved Local Packet Flow Control
In Junos OS Evolved, you can have two dierent lters: one for network control trac (loopback trac)
and one for management trac. With two lters, you have more exibility. For example, you can
congure a stricter lter on management interface trac than on network control trac.
Management ltering uses Roung Engine lters based on netlters, a framework provided by the Linux
kernel. This dierence results in only certain matches and acons being supported. Refer Roung Engine
Firewall Filters to read more.
NOTE: You must explicitly add the lter on the management interface as for Junos OS Evolved,
the lo lter no longer applies on the management trac, as is the case for Junos OS.
Stateless and Stateful Firewall Filters
A stateless rewall lter, also known as an
access control list
(ACL), does not statefully inspect trac.
Instead, it evaluates packet contents stacally and does not keep track of the state of network
connecons. In contrast, a
stateful rewall lter
uses connecon state informaon derived from other
applicaons and past communicaons in the data ow to make dynamic control decisions.
The Roung Policies, Firewall Filters, and Trac Policers User Guide describes
stateless rewall lters
.
Purpose of Stateless Firewall Filters
The basic purpose of a stateless rewall lter is to enhance security through the use of packet ltering.
Packet ltering enables you to inspect the components of incoming or outgoing packets and then
perform the acons you specify on packets that match the criteria you specify. The typical use of a
stateless rewall lter is to protect the Roung Engine processes and resources from malicious or
untrusted packets.
RELATED DOCUMENTATION
Router Data Flow Overview | 775
Stateless Firewall Filter Types
779
Controlling Network Access Using Trac Policing Overview | 1920
Packet Flow Through the Junos OS CoS Process Overview
Understanding How to Use Standard Firewall Filters
IN THIS SECTION
Using Standard Firewall Filters to Aect Local Packets | 780
Using Standard Firewall Filters to Aect Data Packets | 781
Using Standard Firewall Filters to Aect Local Packets
On a router, you can congure one physical loopback interface, lo0, and one or more addresses on the
interface. The loopback interface is the interface to the Roung Engine, which runs and monitors all the
control protocols. The loopback interface carries local packets only. Standard rewall lters applied to
the loopback interface aect the local packets desned for or transmied from the Roung Engine.
NOTE: When you create an addional loopback interface, it is important to apply a lter to it so
the Roung Engine is protected. We recommend that when you apply a lter to the loopback
interface, you include the apply-groups statement. Doing so ensures that the lter is
automacally inherited on every loopback interface, including lo0 and other loopback interfaces.
Trusted Sources
The typical use of a standard stateless
rewall lter
is to protect the Roung Engine processes and
resources from malicious or untrusted packets. To protect the processes and resources owned by the
Roung Engine, you can use a standard stateless rewall lter that species which protocols and
services, or applicaons, are allowed to reach the Roung Engine. Applying this type of lter to the
loopback interface ensures that the local packets are from a trusted source and protects the processes
running on the Roung Engine from an external aack.
780
Flood Prevenon
You can create standard stateless rewall lters that limit certain TCP and ICMP trac desned for the
Roung Engine. A router without this kind of protecon is vulnerable to TCP and ICMP ood aacks,
which are also called denial-of-service (DoS) aacks. For example:
• A TCP ood aack of SYN packets iniang connecon requests can overwhelm the device unl it
can no longer process legimate connecon requests, resulng in denial of service.
• An ICMP ood can overload the device with so many echo requests (ping requests) that it expends all
its resources responding and can no longer process valid network trac, also resulng in denial of
service.
Applying the appropriate rewall lters to the Roung Engine protects against these types of aacks.
Using Standard Firewall Filters to Aect Data Packets
Standard rewall lters that you apply to your router’s transit interfaces evaluate only the user data
packets that transit the router from one interface directly to another as they are being forwarded from a
source to a desnaon. To protect the network as a whole from unauthorized access and other threats
at specic interfaces, you can apply rewall lters router transit interfaces .
RELATED DOCUMENTATION
How Standard Firewall Filters Evaluate Packets
Guidelines for Conguring Firewall Filters
Guidelines for Applying Standard Firewall Filters
Understanding How Firewall Filters Control Packet Flows
A switch supports rewall lters that allow you to control ows of data packets and local packets.
Data
packets
transit a switch as they are forwarded from a source to a desnaon.
Local packets
are desned
for or sent by a Roung Engine (they do not transit a switch). Local packets usually contain roung
protocol data, data for IP services such as Telnet or SSH, or data for administrave protocols such as the
Internet Control Message Protocol (ICMP).
Firewall lters aect packet ows entering into or exing from a switch as follows:
• Ingress rewall lters aect the ow of data packets that are received on switch interfaces. When a
switch receives a data packet, the Packet Forwarding Engine in the system that contains the ingress
interface determines where to forward the packet by looking in its Layer 2 or Layer 3 forwarding
781
table for the best route to the desnaon. Data packets are forwarded to an egress interface. Locally
desned packets are forwarded to the Roung Engine.
• Egress rewall lters aect data packets that are transing a switch but do not aect packets sent by
the Roung Engine. These lters are applied by the Packet Forwarding Engine in the system that
contains the egress interface.
NOTE: On some QFX plaorms which use PTX codebase, such as QFX10002-60C for example,
there is support for rewall lter inspecon of RE-based outgoing trac.
Figure 48 on page 782 illustrates the applicaon of ingress and egress rewall lters to control the
ow of packets through a switch:
1. Ingress
rewall lter
applied to locally desned packets that are received on switch interfaces and are
desned for the Roung Engine.
2. Ingress rewall lter applied to data packets that are received on switch interfaces and will transit the
switch.
3. Egress rewall lter applied to data packets that are transing the switch.
Figure 48: Applicaon of Firewall Filters to Control Packet Flow
782
Stateless Firewall Filter Components
IN THIS SECTION
Protocol Family | 783
Filter Type | 784
Terms | 786
Match Condions | 787
Acons | 788
This topic covers the following informaon:
Protocol Family
Under the firewall statement, you can specify the protocol family for which you want to lter trac.
Table 26 on page 783 describes the
rewall lter
protocol families.
Table 26: Firewall Filter Protocol Families
Type of Trac to Be Filtered Conguraon Statement Comments
Protocol Independent
family any
All protocol families congured on a
logical interface
.
Internet Protocol version 4 (IPv4)
family inet The family inet statement is oponal for
IPv4.
Internet Protocol version 6 (IPv6)
family inet6
MPLS
family mpls
MPLS-tagged IPv4
family mpls
Supports matching on IP addresses and
ports, up to ve MPLS stacked labels.
783
Table 26: Firewall Filter Protocol Families
(Connued)
Type of Trac to Be Filtered Conguraon Statement Comments
MPLS-tagged IPv6
family mpls
Supports matching on IP addresses and
ports, up to ve MPLS stacked labels.
Virtual private LAN service (VPLS)
family vpls
Layer 2 Circuit Cross-Connecon
family ccc
Layer 2 Bridging
family bridge (for MX
Series routers) and
family ethernet-
switching (for EX Series
switches)
MX Series routers and EX Series
switches only.
Filter Type
Under the family
family-name
statement, you can specify the type and name of the lter you want to
congure.
Table 27 on page 785 describes the rewall lter types.
784
Table 27: Filter Types
Filter Type Conguraon Statement Descripon
Standard
Firewall Filter
filter
filter-name
Filters the following trac types:
• Protocol independent
• IPv4
• IPv6
• MPLS
•
MPLS-tagged IPv4
•
MPLS-tagged IPv6
•
VPLS
•
Layer 2 CCC
•
Layer 2 bridging (MX Series routers and EX Series
switches only)
Service Filter
service-filter
service-
filter-name
Denes packet-ltering to be applied to ingress or egress before it
is accepted for service processing or applied to returning service
trac aer service processing has completed.
Filters the following trac types:
• IPv4
• IPv6
Supported at logical interfaces congured on the following
hardware only:
•
Adapve Services (AS) PICs on M Series and T Series routers
•
Mulservices (MS) PICs on M Series and T Series routers
•
Mulservices (MS) DPCs on MX Series routers (and EX Series
switches)
785
Table 27: Filter Types
(Connued)
Filter Type Conguraon Statement Descripon
Simple Filter
simple-filter
simple-
filter-name
Denes packet ltering to be applied to ingress trac only.
Filters the following trac type:
• IPv4
Supported at logical interfaces congured on the following
hardware only:
• Gigabit Ethernet Intelligent Queuing (IQ2) PICs installed on
M120, M320, or T Series routers
•
Enhanced Queuing Dense Port Concentrators (EQ DPCs)
installed on MX Series routers (and EX Series switches)
Terms
Under the filter, service-filter, or simple-filter statement, you must congure at least one rewall lter
term
. A term is a named structure in which match condions and acons are dened. Within a rewall
lter, you must congure a unique name for each term.
TIP: For each protocol family on an interface, you can apply no more than one lter in each
direcon. If you try to apply addional lters for the same protocol family in the same direcon,
the last lter overwrites the previous lter. You can, however, apply lters from the same
protocol family to the input and output direcon of the same interface.
All stateless rewall lters contain one or more terms, and each term consists of two components—
match condions and acons. The match condions dene the values or elds that the packet must
contain to be considered a match. If a packet is a match, the corresponding acon is taken. By default, a
packet that does not match a rewall lter is discarded.
If a packet arrives on an interface for which no rewall lter is applied for the incoming trac on that
interface, the packet is accepted by default.
NOTE: A rewall lter with a large number of terms can adversely aect both the conguraon
commit me and the performance of the Roung Engine.
786
Addionally, you can congure a stateless rewall lter within the term of another lter. This method
enables you to add common terms to mulple lters without having to modify all lter denions. You
can congure one lter with the desired common terms, and congure this lter as a term in other
lters. Consequently, to make a change in these common terms, you need to modify only one lter that
contains the common terms, instead of mulple lters.
Match Condions
A rewall lter term must contain at least one packet-ltering criteria, called a
match condion
, to
specify the eld or value that a packet must contain in order to be considered a match for the rewall
lter term. For a match to occur, the packet must match all the condions in the term. If a packet
matches a rewall lter term, the router (or switch) takes the congured acon on the packet.
If a rewall lter term contains mulple match condions, a packet must meet
all
match condions to be
considered a match for the rewall lter term.
If a single match condion is congured with mulple values, such as a range of values, a packet must
match only
one
of the values to be considered a match for the rewall lter term.
The scope of match condions you can specify in a rewall lter term depends on the protocol family
under which the rewall lter is congured. You can dene various match condions, including the IP
source address eld, IP desnaon address eld, TCP or UDP source port eld, IP protocol eld, Internet
Control Message Protocol (ICMP) packet type, IP opons, TCP ags, incoming logical or physical
interface, and outgoing logical or physical interface. These are pre-dened, or xed, match condions.
On MX Series 3D Universal Edge Routers with MPCs or MICs, it is possible to build exible match
condions for IPv4, IPv6, Layer 2 bridge, CCC, and VPLS protocol families. These exible match
condions allow a user to specify start locaon, byte oset, match length, and other parameters within
the packet.
Each protocol family supports a dierent set of match condions, and some match condions are
supported only on certain roung devices. For example, a number of match condions for VPLS trac
are supported only on the MX Series 3D Universal Edge Routers.
In the from statement in a rewall lter term, you specify characteriscs that the packet must have for
the acon in the subsequent then statement to be performed. The characteriscs are referred to as
match condions
. The packet must match all condions in the from statement for the acon to be
performed, which also means that the order of the condions in the from statement is not important.
If an individual match condion can specify a list of values (such as mulple source and desnaon
addresses) or a range of numeric values, a match occurs if any of the values matches the packet.
If a lter term does not specify match condions, the term accepts all packets and the acons specied
in the term’s then statement are oponal.
787
NOTE: Some of the numeric range and bit-eld match condions allow you to specify a text
synonym. For a complete list of synonyms:
• If you are using the J-Web interface, select the synonym from the appropriate list.
• If you are using the CLI, type a queson mark (?) aer the from statement.
Acons
The acons specied in a rewall lter term dene the acons to take for any packet that matches the
condions specied in the term.
Acons that are congured within a single term are all taken on trac that matches the condions
congured.
BEST PRACTICE: We strongly recommend that you explicitly congure one or more acons
per rewall lter term. Any packet that matches all the condions of the term is automacally
accepted unless the term species other or addional acons.
Firewall lter acons fall into the following categories:
Filter-Terminang Acons
A lter-terminang acon halts all evaluaon of a rewall lter for a specic packet. The router (or
switch) performs the specied acon, and no addional terms are examined.
Nonterminang Acons
Nonterminang acons are used to perform other funcons on a packet, such as incremenng a
counter, logging informaon about the packet header, sampling the packet data, or sending informaon
to a remote host using the system log funconality.
The presence of a nonterminang acon, such as count, log, or syslog, without an explicit terminang
acon, such as accept, discard, or reject, results in a default terminang acon of accept. If you do not want
the rewall lter acon to terminate, use the next term acon aer the nonterminang acon.
788
NOTE: On Junos OS Evolved, next term cannot appear as the last term of the acon. A lter term
where next term is specied as an acon but without any match condions congured is not
supported.
In this example, term 2 is never evaluated, because term 1 has the implicit default accept terminang
acon.
[edit firewall filter test]
term 1 {
from {
source-address {
0.0.0.0/0;
}
}
then {
log;
<accept> #By default if not specified
}
}
term 2 {
then {
reject;
}
}
In this example, term 2 is evaluated, because term 1 has the explicit next term ow control acon.
[edit firewall filter test]
term 1 {
from {
source-address {
0.0.0.0/0;
}
}
then {
log;
next term;
}
}
789
term 2 {
then {
reject;
}
}
Flow Control Acon
For standard stateless rewall lters only, the acon next term enables the router (or switch) to perform
congured acons on the packet and then evaluate the following term in the lter, rather than
terminang the lter.
A maximum of 1024 next term acons are supported per standard stateless rewall lter conguraon. If
you congure a standard lter that exceeds this limit, your candidate conguraon results in a commit
error.
RELATED DOCUMENTATION
Stateless Firewall Filter Types
Firewall Filter Flexible Match Condions | 864
Inserng a New Idener in a Junos OS Conguraon
Junos OS CLI User Guide
Stateless Firewall Filter Applicaon Points
Aer you dene the
rewall lter
, you must apply it to an applicaon point. These applicaon points
include logical interfaces, physical interfaces, roung interfaces, and roung instances.
In most cases, you can apply a rewall lter as an
input
lter or an
output
lter, or both at the same
me. Input lters take acon on packets being received on the specied interface, whereas output lters
take acon on packets that are transmied through the specied interface.
You typically apply one lter with mulple terms to a single
logical interface
, to incoming trac,
outbound trac, or both. However, there are mes when you might want to chain together mulple
rewall lters (with single or mulple terms) and apply them to an interface. You use an
input list
to
apply mulple rewall lters to the incoming trac on an interface. You use an
output list
to apply
mulple rewall lters to the outbound trac on an interface. You can include up to 16 lters in an
input list or an output list.
790
There is no limit to the number of lters and counters you can set, but there are some praccal
consideraons. More counters require more terms, and a large number of terms can take a long me to
process during a commit operaon. However, lters with more than 4000 terms and counters have been
implemented successfully.
Table 28 on page 791 describes each point to which you can apply a rewall lter. For each applicaon
point, the table describes the types of rewall lters supported at that point, the router (or switch)
hierarchy level at which the lter can be applied, and any plaorm-specic limitaons.
Table 28: Stateless Firewall Filter Conguraon and Applicaon Summary
Filter Type Applicaon Point Restricons
Stateless rewall lter
Congure by including the filte
r
filter-name
statement the
[edit firewall] hierarchy level:
filter
filter-name
;
NOTE: If you do not include the
family statement, the rewall
lter processes IPv4 trac by
default.
Logical interface
Apply at the [edit interfaces
interface-name
unit
unit-
number
family inet] hierarchy
level by including the input
filter-name
or output
filter-
name
statements:
filter {
input
filter-name
;
output
filter-name
;
}
NOTE: A lter congured with
the implicit inet protocol
family cannot be included in
an input lter list or an output
lter list.
NOTE: On T4000 Type 5
FPCs, a lter aached at the
Layer 2 applicaon point (that
is, at the logical interface level)
is unable to match with the
forwarding class of a packet
that is set by a Layer 3
classier such as DSCP, DSCP
V6, inet-precedence, and mpls-
exp.
Supported on the following routers:
• T Series routers
• M320 routers
• M7i routers with the enhanced CFEB (C
FEB-e)
• M10i routers with the enhanced CFEB-e
Also supported on the following Modular
Port Concentrators (MPCs) on MX Series
routers:
•
10-Gigabit Ethernet MPC
•
60-Gigabit Ethernet Queuing MPC
•
60-Gigabit Ethernet Enhanced Queuing
MPC
• 100-Gigabit Ethernet MPC
• Also supported on EX Series switches
791
Table 28: Stateless Firewall Filter Conguraon and Applicaon Summary
(Connued)
Filter Type Applicaon Point Restricons
Stateless rewall lter
Congure at the [edit firewall
family
family-name
] hierarchy
level by including the following
statement:
filter
filter-name
;
The
family-name
can be any of
the following protocol families:
• any
• bridge
• ethernet-switching
• ccc
• inet
• inet6
• mpls
• vpls
Protocol family on a logical
interface
Apply at the [edit interfaces
interface-name
unit
unit-
number
family
family-name
]
hierarchy level by, including
the input, input-list, output, or
output-list statements:
filter {
input
filter-name
;
input-list [
filter-
names
];
output
filter-name
;
output-list [
filter-
names
];
}
The protocol family bridge is supported only
on MX Series routers.
Stateless rewall lter Roung Engine loopback
interface
792
Table 28: Stateless Firewall Filter Conguraon and Applicaon Summary
(Connued)
Filter Type Applicaon Point Restricons
Service lter
Congure at the [edit firewall
family (inet | inet6)] hierarchy
level by including the following
statement:
service-filter
service-filter-
name
;
Family inet or inet6 on a
logical interface
Apply at the [edit interfaces
interface-name
unit
unit-
number
family (inet | inet6)]
hierarchy level by using the
service-set statement to apply
a service lter as an input or
output lter to a service set:
service {
input {
service-set
service-
set-name
service-filter
filter-name;
}
output {
service-set
service-
set-name
service-filter
filter-name;
}
}
Congure a service set at the
[edit services] hierarchy level
by including the following
statement:
service-set
service-set-name
;
Supported only on Adapve Services (AS)
and Mulservices (MS) PICs.
793
Table 28: Stateless Firewall Filter Conguraon and Applicaon Summary
(Connued)
Filter Type Applicaon Point Restricons
Postservice lter
Congure at the [edit firewall
family (inet | inet6)] hierarchy
level by including the following
statement:
service-filter
service-filter-
name
;
Family inet or inet6 on a
logical interface
Apply at the [edit interfaces
interface-name
unit
unit-
number
family (inet | inet6)]
hierarchy level by including
the post-service-filter
statement to apply a service
lter as an input lter:
service {
input {
post-service-filter
filter-name
;
}
}
A postservice lter is applied to trac
returning to the services interface aer
service processing. The lter is applied only
if a service set is congured and selected.
Simple lter
Congure at the [edit firewall
family inet] hierarchy level by
including the following
statement:
simple-filter
filter-name
Family inet on a logical
interface
Apply at the [edit interfaces
interface-name
unit
unit-
number
family inet] hierarchy
level by including the
following statement:
simple-filter
simple-filter-
name
;
Simple lters can only be applied as input
lters.
Supported on the following plaorms only:
• Gigabit Ethernet intelligent queuing
(IQ2) PICs on the M120, M320, and
T Series routers.
• Enhanced Queuing Dense Port
Concentrators (EQ DPC) on MX Series
routers (and EX Series switches).
794
Table 28: Stateless Firewall Filter Conguraon and Applicaon Summary
(Connued)
Filter Type Applicaon Point Restricons
Reverse packet forwarding (RPF)
check lter
Congured at the [edit firewall
family (inet | inet6)] hierarchy
level by including the following
statement:
filter
filter-name
;
Family inet or inet6 on a
logical interface
Apply at the [edit interfaces
interface-name
unit
unit-
number
family (inet | inet6)]
hierarchy level by including
the following statement:
rpf-check fail-filter
filter-
name
to apply the stateless rewall
lter as an RPF check lter.
rpf-check {
fail-filter
filter-name
;
mode loose;
}
Supported on MX Series routers and EX
Series switches only.
How Standard Firewall Filters Evaluate Packets
IN THIS SECTION
Firewall Filter Packet Evaluaon Overview | 796
Packet Evaluaon at a Single Firewall Filter | 797
Best Pracce: Explicitly Accept Any Trac That Is Not Specically Discarded | 798
Best Pracce: Explicitly Reject Any Trac That Is Not Specically Accepted | 799
Mulple Firewall Filters Aached to a Single Interface | 799
Single Firewall Filter Aached to Mulple Interfaces | 799
795
This topic covers the following informaon:
Firewall Filter Packet Evaluaon Overview
The following sequence describes how the device evaluates a packet entering or exing an interface if
the input or output trac at a device interface is associated with a
rewall lter
. Packet evaluaon
proceeds as follows:
1. The device evaluates the packet against the terms in the rewall lter sequenally, beginning with
the rst term in the lter.
• If the packet matches all the condions specied in a term, the device performs all the acons
specied in that term.
• If the packet does not match all the condions specied in a term, the device proceeds to the next
term in the lter (if a subsequent term exists) and evaluates the packet against that term.
• If the packet does not match any term in the rewall lter, the device implicitly discards the
packet.
2. Unlike service lters and simple lters, rewall lters support the next term acon, which is neither a
terminang acon nor a nonterminang acon but a ow control acon.
NOTE: On Junos and Junos OS Evolved, next term cannot appear as the last term of the acon.
A lter term where next term is specied as an acon but without any match condions
congured is not supported.
• If the matched term includes the next term acon, the device connues evaluaon of the packet at
the next term within the rewall lter.
• If the matched term does not include the next term acon, evaluaon of the packet against the
given rewall lter ends at this term. The device does not evaluate the packet against any
subsequent terms in this lter.
A maximum of 1024 next term acons are supported per rewall lter conguraon. If you congure a
rewall lter that exceeds this limit, your candidate conguraon results in a commit error.
3. The device stops evaluang a packet against a given rewall lter when either the packet matches a
term without the next term acon or the packet fails to match the last term in the rewall lter.
4. If a local packet arrives at a router interface that is associated with an ingress rewall lter, the lter
evaluates the packet twice. The rst evaluaon occurs in the Packet Forwarding Engine, which is the
central processing element of the router's forwarding plane, and the second evaluaon occurs in the
Roung Engine, which runs the router's control plane soware.
796
NOTE: Local packets--chunks of data that are desned for or sent by the router itself--usually
contain roung protocol data, data for IP services such as Telnet or SSH, and data for
administrave protocols such as the Internet Control Message Protocol (ICMP).
If the rst evaluaon of the rewall lter modies the incoming local packet or packet context values,
the second evaluaon of the rewall lter is based on the updated packet or packet context values.
For example, suppose that the lter includes a match condion based on the forwarding class or loss
priority value associated with the packet and that the lter includes an acon that modies the
forwarding class or loss priority value associated with the packet. If an ingress local packet arrives at
an associated interface and the lter evaluaon in the Packet Forwarding Engine modies (rather
than drops) the packet, then the lter evaluaon in the Roung Engine is based on the modied
packet context (rather than the original packet context).
Packet Evaluaon at a Single Firewall Filter
Table 29 on page 797 describes packet-ltering behaviors at a device interface associated with a single
rewall lter.
NOTE: On Junos OS Evolved, next term cannot appear as the last term of the acon. A lter term
where next term is specied as an acon but without any match condions congured is not
supported.
Table 29: Packet
Evaluaon at a Single Firewall Filter
Firewall Filter Event Acon Subsequent Acon
The rewall lter term does not
specify any match condions.
The term matches all packets by
default, and so the device performs
the acons specied by that term.
If the term acons include the
next term acon, the device
connues evaluaon of the
packet against the next term
within the rewall lter (if a
subsequent term exists).
797
Table 29: Packet Evaluaon at a Single Firewall Filter
(Connued)
Firewall Filter Event Acon Subsequent Acon
The packet matches all condions
specied by the rewall lter term.
The device performs the acons
specied by that term.
If the term acons include the
next term acon, the device
connues evaluaon of the
packet against the next term
within the rewall lter (if a
subsequent term exists).
The packet matches all condions
specied by the rewall lter term,
but the term does not specify any
acons.
The device implicitly accepts the
packet.
If the term acons include the
next term acon, the device
connues evaluaon of the
packet against the next term
within the rewall lter (if a
subsequent term exists).
The packet does not match all
condions specied by the rewall
lter term.
The device does not perform the
acons specied by that term.
The device connues evaluaon
of the packet against the next
term within the lter (if a
subsequent term exists).
The packet does not match any term
in the lter
The device implicitly discards the packet
Every rewall lter conguraon includes an implicit discard acon at
the end of the lter. This implicit terminang acon is equivalent to
including the following example term t_explicit_discard as the nal term
in the rewall lter:
term t_explicit_discard {
then discard;
}
Best Pracce: Explicitly Accept Any Trac That Is Not Specically Discarded
You might want a rewall lter to accept any trac that the lter does not specically discard. In this
case, we recommend that you congure the rewall lter with a nal term that species the accept
terminang acon.
798
In the following example snippet, conguring the t_allow_all_else term as the nal term in the rewall
lter explicitly congures the rewall lter to accept any trac that the lter did not specically discard :
term t_allow_all_else {
then accept;
}
Following this best pracce can simplify troubleshoong of the rewall lter.
Best Pracce: Explicitly Reject Any Trac That Is Not Specically Accepted
On the other hand, you might want a rewall lter to reject any trac that the rewall lter does not
specically accept. In this case, we recommend that you congure the rewall lter with a nal term that
species the reject terminang acon.
In the following example snippet, conguring the t_deny_all_else term as the nal term in the rewall
lter explicitly congures the rewall lter to reject any trac that the lter did not specically accept:
term t_deny_all_else {
then reject;
}
Following this best pracce can simplify troubleshoong of the rewall lter.
Mulple Firewall Filters Aached to a Single Interface
On supported device interfaces, you can aach mulple rewall lters to a single interface. For more
informaon, see "Understanding Mulple Firewall Filters Applied as a List" on page 1342.
NOTE: On supported interfaces, you can aach a protocol-independent (family any) rewall lter
and a protocol-specic (family inet or family inet6) rewall lter to the same interface. The
protocol-independent rewall lter executes rst. For more informaon, see "Guidelines for
Applying Standard Firewall Filters" on page 823.
Single Firewall Filter Aached to Mulple Interfaces
On supported interfaces, you can associate a single rewall lter with mulple interfaces, and Junos OS
creates an
interface-specic instance
of that rewall lter for each associated interface.
799
• Junos OS associates each interface-specic instanaon of a rewall lter with a system-generated,
interface-specic name.
• For any count acons in the lter terms, the Packet Forwarding Engine maintains separate, interface-
specic counters, and Junos OS associates each counter with a system-generated, interface-specic
name.
• For any policer acons in the lter terms, Junos OS creates separate, interface-specic instances of
the policer acons.
For more informaon, see "Interface-Specic Firewall Filter Instances Overview" on page 1375.
RELATED DOCUMENTATION
Firewall Filter Match Condions for Protocol-Independent Trac | 939
Firewall Filter Terminang Acons | 886
How Service Filters Evaluate Packets | 1437
How Simple Filters Evaluate Packets | 1468
Guidelines for Conguring Firewall Filters | 816
Understanding How to Use Standard Firewall Filters | 780
Understanding Firewall Filter Fast Lookup Filter
In order to enhance the speed at which specic rewall lters are processed, you can use the lter block
hardware available on certain modular port concentrators (MPCs). See the MX Series Interface Module
Reference manual for details.This hardware allows for an increase in the number of rewall lter
operaons per second that can be accomplished.
Using the fast-lookup-filter opon in environments with hundreds or thousands of terms per lter can
increase performance of those lters by ulizing the lter block hardware.
There are 4096 hardware lters available per MPC. The number of rewall lters that can be installed in
hardware depends on the number of terms in each lter. One hardware lter is needed for every group
of 255 terms in a rewall lter. The total number of terms supported per rewall lter is 8000. However,
aaching a given rewall lter with less than 256 terms to mulple interfaces will only result in one
instance of that rewall lter being installed in the lter block. This is true for interface-specic lters as
well as for lter lists.
You designate specic rewall lters to be processed in the lter block hardware by including the fast-
lookup-filter opon when conguring the rewall.
800
When this opon is used, rewall parameters are stored in the lter block hardware which accelerates
the lookup process. fast-lookup-filter is only available for the inet and inet6 protocol families. The match
condions are limited to 5-tuples: protocol, source-address, destination-address, source-port, and destination-
port.
Ranges, prex lists, and the except keyword are supported within the rewall lters and terms when
using this opon.
NOTE: Firewall lters that are congured using the fast-lookup-filter opon are not opmized by
the rewall compiler.
RELATED DOCUMENTATION
MX Series 5G Universal Roung Plaorm Interface Module Reference
fast-lookup-lter
Understanding Egress Firewall Filters with PVLANs
If you apply rewall lters to private VLANs in the output direcon, the behavior of the lters might be
unexpected. This topic explains how egress lters behave when applied to private VLANs.
If you apply a
rewall lter
in the output direcon to a primary VLAN, the lter also applies to the
secondary VLANs that are members of the primary VLAN when the trac egresses with the primary
VLAN tag or isolated VLAN tag, as listed below:
• Trac forwarded from a secondary VLAN trunk port to a promiscuous port (trunk or access)
• Trac forwarded from a secondary VLAN trunk port to a PVLAN trunk port.
• Trac forwarded from a promiscuous port (trunk or access) to a secondary VLAN trunk port
• Trac forwarded from a PVLAN trunk port. to a secondary VLAN trunk port
• Trac forwarded from a community port to a promiscuous port (trunk or access)
If you apply a rewall lter in the output direcon to a primary VLAN, the lter does
not
apply to trac
that egresses with a community VLAN tag, as listed below:
• Trac forwarded from a community trunk port to a PVLAN trunk port
• Trac forwarded from a promiscuous port (trunk or access) to a community trunk port
801
• Trac forwarded from a PVLAN trunk port. to a community trunk port
If you apply a rewall lter in the output direcon to a community VLAN, the following behaviors apply:
• The lter is applied to trac forwarded from a promiscuous port (trunk or access) to a community
trunk port (because the trac egresses with the community VLAN tag).
• The lter is applied to trac forwarded from a community port to a PVLAN trunk port (because the
trac egresses with the community VLAN tag).
• The lter is
not
applied to trac forwarded from a community port to a promiscuous port (because
the trac egresses with the primary VLAN tag or untagged).
RELATED DOCUMENTATION
Understanding Private VLANs
Creang a Private VLAN on a Single QFX Switch
Conguring VLANs on Switches
Creang a Private VLAN Spanning Mulple QFX Series Switches
Selecve Class-based Filtering on PTX Routers
SUMMARY
IN THIS SECTION
Selecve Class-based Filtering on PTX
Routers | 802
Understanding Class-based Filtering on PTX
Routers | 804
Example: Selecve Class Based Filtering (PTX
Routers) | 805
Selecve Class-based Filtering on PTX Routers
For supported PTX Series routers and line cards, you can lter IPv4 and IPv6 trac based on the source
or desnaon classicaon (Source Class Usage, SCU) and (Desnaon Class Usage, DCU). This is
useful because it means you can apply a lter selecvely, on a subset of packets in a class, rather than all
802
packets in the class. In addion, the packet ow through the packet forwarding engine (PFE) is
opmized, and the ltering is more ecient.
For service providers, class-based ltering allows you to provide advanced services such as:
• Per-hop behavior manipulaon by adjusng the forwarding class of the packet based on the source
or desnaon packet class and other lter criteria.
• Trac rate liming towards certain customer interfaces, with high volume of trac to drop (for
example, under DDoS aack). Normally, you would deploy an outgoing interface lter to rate limit
the trac. However, this may be inecient because trac sll crosses the fabric in distributed
systems and consumes limited fabric bandwidth. The ineciency becomes even more visible in a
Virtual Output Queueing system, like PTX, where admission into the egress queue is happening
before the output lter is executed and any subsequent drop acon in the output lter requires
compensaon – more trac needs to be admied into the queue, which requires more fabric
bandwidth and more egress on-chip buer space (which is a limited resource). Class-based lters are
executed in the ingress pipeline before admission of the packets into the egress queue. This
mechanism is recommended over regular output interface lters, if you expect to drop large volumes
of trac towards certain desnaons.
Class-based ltering is also eecve for "low-and-slow" DoS aacks that target applicaon and server
resources by mimicking normal trac paerns.
To support class-based ltering, two new bind points are introduced at the forwarding table for PTX
routers: source-class and destination-class.
The CLI hierarchy is shown here, where src-class-name or dest-class-name is the name of the lter you
dened in the corresponding policy.
routing-options forwarding-table source-class src-class-name family
[inet | inet6]
filter
<filter-name>
routing-options forwarding-table destination-class dest-class-name family
[inet | inet6]
filter
<filter-name>
You can also congure instance-specic lters across mulple SCU and DCU classes. By default, only
one set of counters and policers is instanated for a lter. In the instance-specic lter, separate set of
counters and policers is created for each lter aach point.
firewall family
[inet | inet6]
filter
<filter name>
instance-specific
803
Understanding Class-based Filtering on PTX Routers
Inially, Source Class Usage (SCU) feature was introduced to provide stascs breakdown of trac sent
towards specic interface per originang prex (idened by the source class). Desnaon Class Usage
(DCU) was originally introduced to provide stascs breakdown of trac received on an interface per
desnaon prex (idened by the desnaon class).
Both source or desnaon classes are assigned to the packet in the source or desnaon lookup
process. Therefore, source and desnaon lter match condions can be evaluated only if the lter is
executed aer the lookup.
Juniper routers support mulple lter bind points, those that may leverage the result of the source and
desnaon classicaon are listed below, with usage guidelines:
• Output interface lter (set interfaces <interface name> family inet lter <output>. Supported on any
PTX plaorm, but not recommended if it is expected to discard large volumes of trac in a steady
state (for example, when implemenng a DDoS aack migaon lter). Discarded DDoS aack
trac may not be compensated by other trac not matching DDoS aack criteria due to limited
fabric bandwidth and limited egress on-chip buer space.
• Filter aer forwarding table lter lookup (set forwarding-opons family inet lter <lter-name>
output). Supported on Express 2 (PE) and Express 3 (ZX) plaorms. However, the lters are
instanated in the egress pipeline, therefore the discard behavior is similar to the regular output
interface lter.
• Source or desnaon class specic bind point (set roung-opons forwarding-table source-class src-
class-name family [inet | inet6] lter <lter- name>). Supported on Express 2 (PE), Express 3 (ZX) and
Express 4 (BT) plaorms. This lter is instanated in the ingress pipeline. This is the recommended
opon to discard large volumes of trac. This opon is also recommended if you need to override
forwarding class and subsequently output queue assignment. In a Virtual Output Queueing system,
queue is selected in the ingress pipeline and any override must happen in the ingress pipeline too.
NOTE:
• Note, these lter acons are not supported in the lter bound to the source or desnaon
class specic bind point:
• roung-instance
• next-ip
• next-interface
804
• decapsulate
• encapsulate
• Selecve class-based lters cannot be applied on host-bound packets.
• Packets which fail uRPF lookups, but are restored by uRPF fail-lters are not subject to
SCU/DCU lookups. Hence, selecve class-based lters cannot be applied on such packets.
• Filters are applied only to packets ingressing on interfaces which have SCU/DCU feature
enabled. This means lters would be applied irrespecve of whether SCU is congured on
output interfaces or not.
• Packets for which selecve class-based lter needs to be applied may cause drop in
performance. Performance drop would be funcon of rate of incoming trac, average
packets size, and amount of trac subjected to the lters. However, packets on which
selecve class-based lters are not applied, do not aect performance.
• DCU accounng is applicable for packets dropped by lters.
• SCU output accounng is not applicable for packets dropped by lters.
• Selecve class-based lters cannot be used with interface-specic knob because this knob is
only applicable to interface-aached lters.
• Lists (input/output lists) of selecve class-based lters are not supported.
• Logical systems are not supported.
• Only IPv4 and IPv6 are the supported payload protocols. MPLS is not supported.
• If a packet matches both SCU and DCU selecve class-based lters then only the last lter
(i.e., DCU lter) is applied to the packet and but not both lters.
Example: Selecve Class Based Filtering (PTX Routers)
IN THIS SECTION
Requirements | 806
Overview | 806
Conguraon | 809
805
This example shows how to apply rewall acons (discard, reject, or police) to IPv4 and IPv6 trac ows
on the basis of source or desnaon classicaon. It applies to PTX10001-36MR, PTX10003-160C,
PTX10003-80C, PTX10004, and PTX10008 routers running Junos Evolved OS release 21.2, PTX10016
routers running JUNOS Evolved OS release 21.4, or PTX3000, PTX-5000, PTX1000, PTX10002,
PTX10008, PTX10016 routers running Junos OS release 21.2 or later soware.
Requirements
This example uses BGP because BGP can be used to exchange routes between devices in a network
topology consisng of customer edge, provider edge, and provider routers. Refer BGP Conguraon
Overview to read more.
Overview
This example uses three roung devices: a customer edge (CE) device, a provider edge (PE) device, and a
provider core (P) device. The conguraon for IPv4 trac is shown, and includes two sets of SCU and
DCU classes, plus the rewall lters. In the following gure, the /32 IP prexes represent hosts
connected to the customer edge (CE) and provider (P) routers respecvely.
Figure 49: Sample Network
In this example, we dene two classes of trac: scu-1 and scu-2, the rst one is assigned to prexes in
the subnet 172.16.2.0/24 and the second one is assigned to prexes in the subnet 172.16.3.0/24.
806
Other prexes do not have any class assignments. As shown in the following CLI snippet, roung policy
is dened on the PE router to assign prexes to source-class scu-1 and source-class scu-2.
show policy-options
policy-statement scu-class {
term gold {
from {
route-filter 172.16.2.0/24 orlonger;
}
then source-class scu-1;
accept;
term silver {
from {
route-filter 172.16.3.0/24 orlonger;
}
then source-class scu-2;
accept;
}
To account for trac ingressing PE's interfaces from CE, the policy called dcu-class dened on the PE
router uses route lters to place trac into dcu-1, other prexes have no class assignments.
show policy-options
policy-statement dcu-class {
term gold {
from {
route-filter 172.16.5.0/24 orlonger;
}
then destination-class dcu-1;
accept;
}
The policies are then applied to the forwarding table.
forwarding-table {
export [ dcu_class scu_class ];
}
807
In the next step we congure a lter on the PE router.
show firewall {
family inet {
filter f1 {
term t1 {
from {
protocol icmp;
}
then {
count c1;
}
}
}
}
}
And aach that lter to the specic source and desnaon class bind points on the PE router.
show routing-options forwarding-table
source-class scu-1 {
family inet {
filter {
f1;
}
}
}
destination-class dcu-1 {
family inet {
filter {
f1;
}
}
}
808
Conguraon
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI.
The example uses stac routes to provide connecvity and loopback interface addresses for tesng the
operaon.
Device CE
set interfaces et-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 interfaces lo0 unit 0 family inet address 172.16.0.1/32
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.0.0.2
set policy-options policy-statement send-direct term 1 from protocol direct set policy-options
policy-statement send-direct term 1 then accept
set policy-options policy-statement send-static term 1 from protocol static set policy-options
policy-statement send-static term 1 then accept
set routing-options static route 10.1.0.0/30 next-hop 10.0.0.2 set routing-options autonomous-
system 100
Device PE
set interfaces et-1/2/0 unit 0 family inet address 10.0.0.2/30
set interfaces et-1/2/1 unit 0 family inet accounting source-class-usage input
set interfaces et-1/2/1 unit 0 family inet accounting destination-class-usage
set interfaces et-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 ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext neighbor 10.0.0.1 peer-as 100
809
set protocols bgp group ext neighbor 10.1.0.2 peer-as 300
set policy-options policy-statement dcu_class term gold from route-filter 172.16.5.0/24 orlonger
set policy-options policy-statement dcu_class term gold then destination-class dcu-1
set policy-options policy-statement scu_class term gold from route-filter 172.16.2.0/24 orlonger
set policy-options policy-statement scu_class term gold then source-class scu-1
set policy-options policy-statement scu_class term silver from route-filter 172.16.3.0/24
orlonger
set policy-options policy-statement scu_class term silver then source-class scu-1
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set firewall family inet filter f1 term 0 from protocol icmp
set firewall family inet filter f1 term 0 then count c1
set firewall family inet filter f1 term 0 then accept
set routing-options autonomous-system 200
set routing-options forwarding-table export dcu_class
set routing-options forwarding-table export scu_class
Device P
set interfaces et-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 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set interfaces lo0 unit 0 family inet address 172.16.0.3/32
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext export send-static
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.1.0.1
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set policy-options policy-statement send-static term 1 from protocol static
set policy-options policy-statement send-static term 1 then accept
set routing-options static route 10.0.0.0/30 next-hop 10.1.0.1
set routing-options static route 172.16.2.0/24 discard
set routing-options static route 172.16.3.0/24 discard
set routing-options static route 172.16.4.0/24 discard set routing-options static route
810
172.16.5.0/24 discard set routing-options static route 172.16.6.0/24 discard set routing-options
static route 172.16.7.0/24 discard set routing-options autonomous-system 300
Step-by-Step Procedure
To group source and desnaon prexes in a forwarding class:
1. Create the router interfaces on the PE router.
[edit interfaces]
set et-1/2/0 unit 0 family inet accounting source-class-usage output
set et-1/2/0 unit 0 family inet address 10.0.0.2/30
set et-1/2/1 unit 0 family inet accounting source-class-usage input
set et-1/2/1 unit 0 family inet accounting destination-class-usage
set et-1/2/1 unit 0 family inet address 10.1.0.1/30
set lo0 unit 0 family inet address 192.168.0.2/32
2. Congure BGP on PE router.
[edit]
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
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
3. Congure the autonomous system (AS) number of the PE router.
[edit]
set routing-options autonomous-system 200
4. Congure the DCU policy on the PE router.
[edit]
set policy-options policy-statement dcu_class term class-1 from route-filter 172.16.5.0/24
811
orlonger
set policy-options policy-statement dcu_class term class-1 then destination-class dcu-1
5. Congure the SCU policy on the PE router.
[edit]
set policy-options policy-statement scu_class term class-1 from route-filter 172.16.2.0/24
orlonger
set policy-options policy-statement scu_class term class-1 then source-class scu-1
6. Apply the policies to the forwarding table on the PE router.
[edit]
set routing-options forwarding-table export dcu_class
set routing-options forwarding-table export scu_class
7. Create the lter on the PE router.
[edit]
set firewall family inet filter f1 from protocol icmp then count c1
8. Bind the lter to the source class and desnaon class bind points on the PE router.
Binding the lter to desnaon class usage.
[edit]
set routing-options forwarding-table destination-class dcu-1 family inet filter f1
Binding the lter to source class usage.
[edit]
set routing-options forwarding-table source-class scu-1 family inet filter f1
812
9. (Oponal) Congure a roung policy that adverses direct routes on the PE router.
[edit]
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
Results
From conguraon mode , conrm your conguraon by issuing the show interfaces, show protocols, show
policy-options, and show routing-options commands on the PE router. If the output does not display the
intended conguraon, repeat the instrucons in this example to correct the conguraon.
show interfaces
et-1/2/0 {
unit 0 {
family inet {
address 10.0.0.2/30;
}
}
}
et-1/2/1 {
unit 0 {
family inet {
accounting {
source-class-usage { input;
}
}
address 10.1.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
813
}
}
show interface statistics et-1/2/0
Physical interface: et-1/2/0:0, Enabled, Physical link is Up
Interface index: 1087, SNMP ifIndex: 622
Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, BPDU Error: None, Loop
Detect PDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Media type: Fiber Device flags :
Present Running
Interface flags: SNMP-Traps
CoS queues : 8 supported, 8 maximum usable queues
Current address: e4:5d:37:4e:e8:40, Hardware address: e4:5d:37:4e:e8:40 Last flapped :
2021-03-16 09:33:43 PDT (03:39:51 ago)
Statistics last cleared: 2021-03-16 13:13:01 PDT (00:00:33 ago) Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps) Input errors: 0, Output errors: 0 Active alarms : None
Active defects : None
PCS statistics Seconds
Bit errors 0
Errored blocks 0
PRBS Mode : Disabled
Interface transmit statistics: Disabled Link Degrade :
Link Monitoring : Disable
Logical interface et-1/2/0:0.0 (Index 1047) (SNMP ifIndex 673)
Flags: Up SNMP-Traps
Encapsulation: ENET2
Input packets : 14
Output packets: 6
Protocol inet, MTU: 1500
Flags: Sendbcast-pkt-to-re, SCU-out
Packets Bytes
Source class (packet-per-second) (bits-per-second)
scu-1 6 504
( 0)( 0)
Addresses, Flags: Is-Preferred Is-Primary
Destination: 44.4.4/24, Local: 44.4.4.4, Broadcast: 44.4.4.255
Protocol inet6, MTU: 1500
Flags: None, SCU-out
Packets Bytes
814
Source class (packet-per-second) (bits-per-second)
scu-1 0 0
( 0) ( 0)
Addresses, Flags: Is-Preferred Is-Primary
Destination: 4001::/64, Local: 4001::4001
Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::e65d:37ff:fe4e:e840
Protocol multiservice, MTU: Unlimited
Flags: None
show firewall
Filter: f1
Counters:
Name Bytes Packets
c1 0 0
Filter: v4_instance_new-scu-scu-1
Counters:
Name Bytes Packets
c_v4_instance_new-scu-scu-1 504 6
Filter: v6_instance_new-scu-scu-1
Counters:
Name Bytes Packets
c_v6_instance_new-scu-scu-1 0 0
show policy-options
policy-statement dcu_class {
term class-1 {
from {
route-filter 172.16.5.0/24 orlonger;
}
then destination-class dcu-1;
}
}
policy-statement scu_class {
term class-1 {
from {
route-filter 172.16.2.0/24 orlonger;
}
815
then source-class scu-1;
}
}
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
show routing-options
autonomous-system 200;
forwarding-table {
export [ dcu_class scu_class ];
}
If you are done conguring the device, enter commit from conguraon mode.
Guidelines for Conguring Firewall Filters
IN THIS SECTION
Statement Hierarchy for Conguring Firewall Filters | 817
Firewall Filter Protocol Families | 818
Firewall Filter Names and Opons | 819
Firewall Filter Terms | 819
Firewall Filter Match Condions | 820
Firewall Filter Acons | 822
This topic covers the following informaon:
816
Statement Hierarchy for Conguring Firewall Filters
To congure a standard rewall lter, you can include the following statements. For an IPv4 standard
rewall lter, the family inet statement is oponal. For an IPv6 standard rewall lter, the family inet6
statement is mandatory.
firewall {
family
family-name
{
filter
filter-name
{
accounting-profile
name
;
instance-shared;
interface-specific;
physical-interface-filter;
term
term-name
{
filter
filter-name
;
}
term
term-name
{
from {
match-conditions
;
ip-version
ip-version
{
match-conditions
;
protocol (tcp | udp) {
match conditions
;
}
}
}
then {
actions
;
}
}
}
}
}
You can include the rewall conguraon at one of the following hierarchy levels:
•
[edit]
• [edit logical-systems
logical-system-name
]
817
NOTE: For stateless rewall ltering, you must allow the output tunnel trac through the
rewall lter applied to input trac on the interface that is the next-hop interface toward the
tunnel desnaon. The rewall lter aects only the packets exing the router (or switch) by
way of the tunnel.
NOTE: On ACX7100 plaorms, VPLS rewall lters are congured under family ethernet-switching
and not under family VPLS. Management lters are congured at family inet or inet6 and the syntax
is of this form:
set interfaces re0:mgmt-0 unit
logical-unit-number
family family-name filter input
filter-name
.
Firewall Filter Protocol Families
A rewall lter conguraon is specic to a parcular protocol family. Under the firewall statement,
include one of the following statements to specify the protocol family for which you want to lter
trac:
• family any—To lter protocol-independent trac.
• family inet—To lter Internet Protocol version 4 (IPv4) trac.
• family inet6—To lter Internet Protocol version 6 (IPv6) trac.
• family mpls—To lter MPLS trac.
• family vpls—To lter virtual private LAN service (VPLS) trac.
• family ccc—To lter Layer 2 circuit cross-connecon (CCC) trac.
• family bridge—To lter Layer 2 bridging trac for MX Series 3D Universal Edge Routers only.
•
family ethernet-switching—To lter Layer 2 (Ethernet) trac.
The family
family-name
statement is required only to specify a protocol family other than IPv4. To
congure an IPv4 rewall lter, you can congure the lter at the [edit firewall] hierarchy level without
including the family inet statement, because the [edit firewall] and [edit firewall family inet] hierarchy
levels are equivalent.
818
NOTE: For bridge family lter, the
ip-protocol
match criteria is supported only for IPv4 and not
for IPv6. This is applicable for line cards that support the Junos Trio chipset such as the MX 3D
MPC line cards.
Firewall Filter Names and Opons
Under the family
family-name
statement, you can include filter
filter-name
statements to create and name
rewall lters. The lter name can contain leers, numbers, and hyphens (-) and be up to 64 characters
long. To include spaces in the name, enclose the enre name in quotaon marks (“ ”).
At the [edit firewall family
family-name
filter
filter-name
] hierarchy level, the following statements are
oponal:
• accounting-profile
• instance-shared (MX Series routers with Modular Port Concentrators (MPCS) only)
• interface-specific
• physical-interface-filter
Firewall Filter Terms
Under the filter
filter-name
statement, you can include term
term-name
statements to create and name
lter terms.
• You must congure at least one term in a rewall lter.
• You must specify a unique name for each term within a rewall lter. The term name can contain
leers, numbers, and hyphens (-) and can be up to 64 characters long. To include spaces in the name,
enclose the enre name in quotaon marks (“ ”).
• The order in which you specify terms within a rewall lter conguraon is important. Firewall lter
terms are evaluated in the order in which they are congured. By default, new terms are always
added to the end of the exisng lter. You can use the insert conguraon mode command to
reorder the terms of a rewall lter.
At the [edit firewall family
family-name
filter
filter-name
term
term-name
] hierarchy level, the filter
filter-
name
statement is not valid in the same term as from or then statements. When included at this hierarchy
level, the filter
filter-name
statement is used to
nest
rewall lters.
819
Firewall Filter Match Condions
Firewall lter match condions are specic to the type of trac being ltered.
With the excepon of MPLS-tagged IPv4 or IPv6 trac, you specify the term’s match condions under
the from statement. For MPLS-tagged IPv4 trac, you specify the term’s IPv4 address-specic match
condions under the ip-version ipv4 statement and the term’s IPv4 port-specic match condions under
the protocol (tcp | udp) statement.
For MPLS-tagged IPv6 trac, you specify the term’s IPv6 address-specic match condions under the
ip-version ipv6 statement and the term’s IPv6 port-specic match condions under the protocol (tcp |
udp) statement.
Table 30 on page 820 describes the types of trac for which you can congure rewall lters.
Table 30: Firewall Filter Match Condions by Protocol Family
Trac Type Hierarchy Level at Which Match Condions Are Specied
Protocol-independent
[edit firewall family any filter
filter-name
term
term-name
]
For the complete list of match condions, see "Firewall Filter Match Condions for
Protocol-Independent Trac" on page 939.
IPv4
[edit firewall family inet filter
filter-name
term
term-name
]
For the complete list of match condions, see "Firewall Filter Match Condions for IPv4
Trac" on page 942.
IPv6
[edit firewall family inet6 filter
filter-name
term
term-name
]
For the complete list of match condions, see " Firewall Filter Match Condions for
IPv6 Trac" on page 959.
MPLS
[edit firewall family mpls filter
filter-name
term
term-name
]
For the complete list of match condions, see "Firewall Filter Match Condions for
MPLS Trac" on page 1004.
IPv4 addresses
in MPLS ows
[edit firewall family mpls filter
filter-name
term
term-name
ip-version ipv4 ]
For the complete list of match condions, see "Firewall Filter Match Condions for
MPLS-Tagged IPv4 or IPv6 Trac" on page 1013.
820
Table 30: Firewall Filter Match Condions by Protocol Family
(Connued)
Trac Type Hierarchy Level at Which Match Condions Are Specied
IPv4 ports in MPLS o
ws
[edit firewall family mpls filter
filter-name
term
term-name
ip-version ipv4 protocol
(tcp | udp)]
For the complete list of match condions, see "Firewall Filter Match Condions for
MPLS-Tagged IPv4 or IPv6 Trac" on page 1013.
IPv6 addresses
in MPLS ows
[edit firewall family mpls filter
filter-name
term
term-name
ip-version ipv6 ]
For the complete list of match condions, see "Firewall Filter Match Condions for
MPLS-Tagged IPv4 or IPv6 Trac" on page 1013.
IPv6 ports in MPLS o
ws
[edit firewall family mpls filter
filter-name
term
term-name
ip-version ipv6 protocol
(tcp | udp)]
For the complete list of match condions, see "Firewall Filter Match Condions for
MPLS-Tagged IPv4 or IPv6 Trac" on page 1013.
VPLS
[edit firewall family vpls filter
filter-name
term
term-name
]
For the complete list of match condions, see "Firewall Filter Match Condions for
VPLS Trac" on page 1017.
Layer 2 CCC
[edit firewall family ccc filter
filter-name
term
term-name
]
For the complete list of match condions, see "Firewall Filter Match Condions for
Layer 2 CCC Trac" on page 1036.
Layer 2 Bridging
(MX Series routers
and EX Series
switches only)
[edit firewall family bridge filter
filter-name
term
term-name
]
[edit firewall family ethernet-switching filter
filter-name
term
term-name
] (for EX
Series switches only)
For the complete list of match condions, see "Firewall Filter Match Condions for
Layer 2 Bridging Trac" on page 1042.
If you specify an IPv6 address in a match condion (the address, destination-address, or source-address match
condions), use the syntax for text representaons described in RFC 4291,
IP Version 6 Addressing
Architecture
. For more informaon about IPv6 addresses, see IPv6 Overview and Supported IPv6
Standards.
821
Firewall Filter Acons
Under the then statement for a rewall lter term, you can specify the acons to be taken on a packet
that matches the term.
Table 31 on page 822 summarizes the types of acons you can specify in a rewall lter term.
Table 31: Firewall Filter Acon Categories
Type of Acon Descripon Comment
Terminang Halts all evaluaon of a rewall lter for a
specic packet. The router (or switch) performs
the specied acon, and no addional terms are
used to examine the packet.
You can specify only one
terminang acon
in a
rewall lter term. If you try to specify more than
one
terminang acon
within the lter term then
the latest
terminang acon
will replace the
exisng
terminang acon
. You can, however,
specify one terminang acon with one or more
nonterminang acons
in a single term. For
example, within a term, you can specify accept
with count and syslog. Regardless of the number
of terms that contain terminang acons, once
the system processes a terminang acon within
a term, processing of the enre rewall lter
halts.
See "Firewall Filter Terminang Acons"
on page 886.
Nonterminan
g
Performs other funcons on a packet (such as
incremenng a counter, logging informaon
about the packet header, sampling the packet
data, or sending informaon to a remote host
using the system log funconality), but any
addional terms are used to examine the packet.
All nonterminang acons include an
implicit accept acon. This accept acon is
carried out if no other terminang acon
is congured in the same term.
See "Firewall Filter Nonterminang
Acons" on page 873.
822
Table 31: Firewall Filter Acon Categories
(Connued)
Type of Acon Descripon Comment
Flow control
For standard rewall lters only, the next term
acon directs the router (or switch) to perform
congured acons on the packet and then, rather
than terminate the lter, use the next term in the
lter to evaluate the packet. If the next term
acon is included, the matching packet is
evaluated against the next term in the rewall
lter. Otherwise, the matching packet is not
evaluated against subsequent terms in the
rewall lter.
For example, when you congure a term with the
nonterminang acon count, the term’s acon
changes from an implicit discard to an implicit
accept. The next term acon forces the connued
evaluaon of the rewall lter.
You cannot congure the next term acon
with a terminang acon in the same lter
term. However, you can congure the next
term acon with another nonterminang
acon in the same lter term.
A maximum of 1024 next term acons are
supported per standard rewall lter
conguraon. If you congure a standard
rewall lter that exceeds this limit, your
candidate conguraon results in a
commit error.
NOTE: On Junos OS Evolved, next term
cannot appear as the last term of the
acon. A lter term where next term is
specied as an acon but without any
match condions congured is not
supported.
RELATED DOCUMENTATION
Guidelines for Applying Standard Firewall Filters | 823
Understanding How to Use Standard Firewall Filters | 780
Guidelines for Applying Standard Firewall Filters
IN THIS SECTION
Applying Firewall Filters Overview | 824
Statement Hierarchy for Applying Firewall Filters | 825
Restricons on Applying Firewall Filters | 827
823
Applying Firewall Filters Overview
You can apply a standard rewall lter to a loopback interface on the router or to a physical or logical
interface on the router. You can apply a rewall lter to a single interface or to mulple interfaces on the
router.Table 32 on page 824 summarizes the behavior of rewall lters based on the point to which
you aach the lter.
Table 32: Firewall Filter Behavior by Filter Aachment Point
Filter Aachment Point Filter Behavior
Loopback interface
The router’s loopback interface, lo0, is the interface to the Roung Engine and carries
no data packets. When you apply a rewall lter to the loopback interface, the lter
evaluates the local packets received or transmied by the Roung Engine.
NOTE:
• ACX5048 and ACX5096 routers do not support the evaluaon of packets
transmied by the Roung engine for loopback interface lter.
Physical interface or
logical interface
When you apply a lter to a physical interface on the router or to a logical interface (or
member of an aggregated Ethernet bundle dened on the interface), the lter
evaluates all data packet that pass through that interface.
Mulple interfaces You can use the same rewall lter one or more mes.
On M Series routers, except the M120 and M320 routers, if you apply a rewall lter
to mulple interfaces, the lter acts on the sum of trac entering or exing those
interfaces.
On T Series, M120, M320, and MX Series routers, interfaces are distributed among
mulple packet-forwarding components. On these routers, you can congure rewall
lters and service lters that, when applied to mulple interfaces, act on the individual
trac streams entering or exing each interface, regardless of the sum of trac on the
mulple interfaces.
For more informaon, see "Interface-Specic Firewall Filter Instances Overview" on
page 1375.
824
Table 32: Firewall Filter Behavior by Filter Aachment Point
(Connued)
Filter Aachment Point Filter Behavior
Single interface with
protocol-independent
and protocol-specic
rewall lters aached
For interfaces hosted on the following hardware only, you can aach a protocol-
independent (family any) rewall lter and a protocol-specic (family inet or
family inet6) rewall lter simultaneously. The protocol-independent rewall executes
rst.
• ACX Series Universal Metro Routers
• Flexible PIC Concentrators (FPCs) in M7i and M10i Mulservice Edge Routers
• Modular Interface Cards (MICs) and Modular Port Concentrators (MPCs) in MX
Series 5G Universal Roung Plaorms
•
T Series Core Routers
NOTE: Interfaces hosted on the following hardware do not support protocol-
independent rewall lters:
•
Forwarding Engine Boards (FEBs) in M120 routers
•
Enhanced III FPCs in M320 routers
• FPC2 and FPC3 modules in MX Series routers
• Dense Port Concentrators (DPCs) in MX Series routers
• PTX Series Packet Transport Routers
Statement Hierarchy for Applying Firewall Filters
To apply a standard rewall lter to a logical interface, congure the filter statement for the logical
interface dened under either the [edit] or [edit logical-systems
logical-system-name
] hierarchy level. Under
the filter statement, you can include one or more of the following statements: group
group-number
, input
filter-name
, input-list
filter-name
, output
filter-name
, or output-list
filter-name
. The hierarchy level at which
you aach the filter statement depends on the lter type and device type you are conguring.
825
Protocol-Independent Firewall Filters on MX Series Routers
To apply a protocol-independent rewall lter to a logical interface on an MX Series router, congure
the filter statement
directly
under the logical unit:
interfaces {
interface-name
{
unit
logical-unit-number
{
filter {
group
group-number
;
input
filter-name
;
input-list [
filter-names
];
output
filter-name
;
output-list [
filter-names
];
}
}
}
}
All Other Firewall Filters on Logical Interfaces
To apply a standard rewall lter to a logical interface for all cases
other than
a protocol-independent
lter on an MX Series router, congure the filter statement under the protocol family:
interfaces {
interface-name
{
unit
logical-unit-number
{
family
family-name
{
...
filter {
group
group-number
;
input
filter-name
;
input-list [
filter-names
];
output
filter-name
;
output-list [
filter-names
];
}
}
}
}
}
826
Restricons on Applying Firewall Filters
Number of Input and Output Filters Per Logical Interface
Input lters—Although you can use the same lter mulple mes, you can apply only one input lter or
one input lter list to an interface.
• To specify a single rewall lter to be used to evaluate packets received on the interface, include the
input
filter-name
statement in the filter stanza.
• To specify an ordered list of rewall lters to be used to evaluate packets received on the interface,
include the input-list [
filter-names
] statement in the filter stanza. You can specify up to 16 rewall
lters for the lter input list.
Output lters—Although you can use the same lter mulple mes, you can apply only one output lter
or one output lter list to an interface.
• To specify a single rewall lter to be used to evaluate packets transmied on the interface, include
the output
filter-name
statement in the filter stanza.
• To specify an ordered list of rewall lters to be used to evaluate packets transmied on the
interface, include the output-list [
filter-names
] statement in the filter stanza. You can specify up to
16 rewall lters in a lter output list.
MPLS and Layer 2 CCC Firewall Filters in Lists
The input-list
filter-names
and output-list
filter-names
statements for rewall lters for the ccc and mpls
protocol families are supported on all interfaces with the excepon of the following:
• Management interfaces and internal Ethernet interfaces (fxp or em0)
• Loopback interfaces (lo0)
• USB modem interfaces (umd)
Layer 2 CCC Firewall Filters on MX Series Routers and EX Series Switches
Only on MX Series routers and EX Series switches, you cannot apply a Layer 2 CCC stateless rewall
lter (a rewall lter congured at the [edit firewall filter family ccc] hierarchy level) as an output lter.
On MX Series routers and EX Series switches, rewall lters congured for the family ccc statement can
be applied only as input lters.
IPv6 Firewall Filters on PTX Series Packet Transport Routers
On PTX10001-20C routers, you cannot apply IPv6 rewall lters to:
827
• Tunnel interfaces
• IRB interfaces
• Egress interfaces
• Interface-specic lters, congured at the [edit firewall family inet6 filter filter-name] hierarchy level.
• Trac policers
• Junos Telemetry Interface
RELATED DOCUMENTATION
family (Firewall)
family (Interfaces)
lter (Applying to a Logical Interface)
lter (Conguring)
Guidelines for Conguring Firewall Filters | 816
Understanding How to Use Standard Firewall Filters | 780
Supported Standards for Filtering
The Junos OS supports the following RFCs related to ltering:
• RFC 792,
Internet Control Message Protocol
• RFC 2460,
Internet Protocol, Version 6 (IPv6)
• RFC 2474,
Denion of the Dierenated Services (DS) Field
• RFC 2475,
An Architecture for Dierenated Services
• RFC 2597,
Assured Forwarding PHB Group
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
• RFC 4291,
IP Version 6 Addressing Architecture
• RFC 4443,
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specicaon
828
NOTE: ACX Series routers do not support RFC 2460, RFC 4291, and RFC 4443 standards.
RELATED DOCUMENTATION
Firewall Filters Overview | 774
Service Filter Overview | 1435
Simple Filter Overview | 1467
Firewall Filters in Logical Systems Overview | 1217
Monitoring Firewall Filter Trac
IN THIS SECTION
Monitoring Trac for All Firewall Filters and Policers That Are Congured | 829
Monitoring Trac for a Specic Firewall Filter | 830
Monitoring Trac for a Specic Policer | 831
You can use operaonal mode commands to monitor rewall lter trac.
Monitoring Trac for All Firewall Filters and Policers That Are Congured
IN THIS SECTION
Purpose | 830
Acon | 830
Meaning | 830
829
Purpose
Monitor the number of packets and bytes that matched the rewall lters and monitor the number of
packets that exceeded policer rate limits:
Acon
Use the show firewall operaonal mode command:
user@switch> show firewall
Filter: egress-vlan-watch-employee
Counters:
Name Bytes Packets
counter-employee-web 3348 27
Filter: ingress-port-limit-tcp-icmp
Counters:
Name Bytes Packets
icmp-counter 560 10
Policers:
Name Packets
icmp-connection-policer 10
tcp-connection-policer 0
Filter: ingress-vlan-rogue-block
Filter: ingress-vlan-limit-guest
Meaning
The show firewall command displays the names of all rewall lters, counters, and policers that are
congured. For each counter that is specied in a lter conguraon, the output eld shows the byte
count and packet count for the term in which the counter is specied. For each policer that is specied
in a lter conguraon, the output eld shows the packet count for packets that exceed the specied
rate limits.
Monitoring Trac for a Specic Firewall Filter
IN THIS SECTION
Purpose | 831
830
Acon | 831
Meaning | 831
Purpose
Monitor the number of packets and bytes that matched a rewall lter and monitor the number of
packets that exceeded policer rate limits.
Acon
Use the show firewall filter
filter-name
operaonal mode command:
user@switch> show firewall filter ingress-port-limit-tcp-icmp
Filter: ingress-port-limit-tcp-icmp
Counters:
Name Bytes Packets
icmp-counter 560 10
Meaning
The show firewall filter
filter-name
command limits the display informaon to the counters and policers
that are dened for the specied lter.
Monitoring Trac for a Specic Policer
IN THIS SECTION
Purpose | 831
Acon | 832
Meaning | 832
Purpose
Monitor the number of packets that exceeded the rate limits of a policer:
831
Acon
Use the show firewall policer
policer-name
operaonal mode command:
user@switch> show firewall policer icmp-connection-policer
Filter: ingress-port-limit-tcp-icmp
Policers:
Name Packets
icmp-connection-policer 10
Meaning
The show firewall policer
policer-name
command displays the number of packets that exceeded the rate
limits for the specied policer.
RELATED DOCUMENTATION
Conguring Firewall Filters | 1829
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
Troubleshoong Firewall Filters
IN THIS SECTION
Troubleshoong QFX10000 Switches | 833
Troubleshoong Other Switches | 834
Use the following informaon to troubleshoot your rewall lter conguraon.
832
Troubleshoong QFX10000 Switches
IN THIS SECTION
Do Not Combine Match Condions for Dierent Layers | 833
Layer 2 Packets Cannot be Discarded with Firewall Filters | 833
Protect-RE (loopback) Firewall Filter Does Not Filter Packets Applied to EM0 Interfaces | 834
This secon describes issues specic to QFX10000 switches:
Do Not Combine Match Condions for Dierent Layers
On QFX10000 switches, do not combine match condions for Layer 2 and any other layer in a family
ethernet-switching lter. (For example, do not include condions that match MAC addresses and IP
addresses in the same lter.) If you do so, the lter will commit successfully but will not work. You will
also see the following log message: L2 filter
filter-name
doesn't support mixed L2 and L3/L4 match conditions.
Please re-config.
Layer 2 Packets Cannot be Discarded with Firewall Filters
IN THIS SECTION
Problem | 833
Soluon | 834
Problem
Descripon
Layer 2 (L2) control packets such as Link Layer Discovery Protocol (LLDP) and bridge protocol data unit
(BPDU) cannot be discarded with rewall lters.
833
Soluon
Congure distributed denial-of-service (DDoS) protecon on the L2 control packet and set the
aggregate policer bandwidth and burst values to the minimum value of 1. For example,
[edit system ddos-protection protocols
protocol name
]
user@host# set aggregate bandwidth 1
[edit system ddos-protection protocols
protocol name
]
user@host# set aggregate burst 1
Protect-RE (loopback) Firewall Filter Does Not Filter Packets Applied to EM0 Interfaces
IN THIS SECTION
Problem | 834
Soluon | 834
Problem
Descripon
On QFX10000 switches, the Protect-RE (loopback) rewall lter does not lter packets applied to EM0
interfaces including SNMP, Telnet, and other services.
Soluon
This is expected behavior.
Troubleshoong Other Switches
IN THIS SECTION
Firewall Filter Conguraon Returns a No Space Available in TCAM Message | 835
834
Filter Counts Previously Dropped Packet | 838
Matching Packets Not Counted | 839
Counter Reset When Eding Filter | 840
Cannot Include loss-priority and policer Acons in Same Term | 840
Cannot Egress Filter Certain Trac Originang on QFX Switch | 841
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling | 842
Egress Firewall Filters with Private VLANs | 842
Egress Filtering of L2PT Trac Not Supported | 844
Cannot Drop BGP Packets in Certain Circumstances | 844
Invalid Stascs for Policer | 845
Policers can Limit Egress Filters | 845
This secon describes issues specic to QFX switches other than QFX10000 switches. This informaon
also applies to OCX1100 switches and EX4600 switches.
Firewall Filter Conguraon Returns a No Space Available in TCAM Message
IN THIS SECTION
Problem | 835
Soluon | 836
Problem
Descripon
When a rewall lter conguraon exceeds the amount of available Ternary Content Addressable
Memory (TCAM) space, the system returns the following syslogd message:
No space available in tcam.
Rules for filter
filter-name
will not be installed.
835
A switch returns this message during the commit operaon if the rewall lter that has been applied to
a port, VLAN, or Layer 3 interface exceeds the amount of space available in the TCAM table. The lter is
not applied, but the commit operaon for the rewall lter conguraon is completed in the CLI
module.
Soluon
When a rewall lter conguraon exceeds the amount of available TCAM table space, you must
congure a new rewall lter with fewer lter terms so that the space requirements for the lter do not
exceed the available space in the TCAM table.
You can perform either of the following procedures to correct the problem:
To delete the lter and its binding and apply the new smaller rewall lter to the same binding:
1. Delete the lter and its binding to ports, VLANs, or Layer 3 interfaces. For example:
[edit]
user@switch# delete firewall family ethernet-switching filter ingress-vlan-rogue-block
user@switch# delete vlans employee-vlan description "filter to block rogue devices on
employee-vlan"
user@switch# delete vlans employee-vlan filter input ingress-vlan-rogue-block
2. Commit the changes:
[edit]
user@switch# commit
3. Congure a smaller lter with fewer terms that does not exceed the amount of available TCAM
space. For example:
[edit]
user@switch# set firewall family ethernet-switching filter new-ingress-vlan-rogue-block ...
4. Apply (bind) the new rewall lter to a port, VLAN , or Layer 3 interface. For example:
[edit]
user@switch# set vlans employee-vlan description "filter to block rogue devices on employee-
vlan"
user@switch# set vlans employee-vlan filter input new-ingress-vlan-rogue-block
836
5. Commit the changes:
[edit]
user@switch# commit
To apply a new rewall lter and overwrite the exisng binding but not delete the original lter:
1. Congure a rewall lter with fewer terms than the original lter:
[edit]
user@switch# set firewall family ethernet-switching filter new-ingress-vlan-rogue-block...
2. Apply the rewall lter to the port, VLAN, or Layer 3 interfaces to overwrite the binding of the
original lter—for example:
[edit]
user@switch# set vlans employee-vlan description "smaller filter to block rogue devices on
employee-vlan"
user@switch# set vlans employee-vlan filter input new-ingress-vlan-rogue-block
Because you can apply no more than one rewall lter per VLAN per direcon, the binding of the
original rewall lter to the VLAN is overwrien with the new rewall lter new-ingress-vlan-rogue-
block.
3. Commit the changes:
[edit]
user@switch# commit
NOTE: The original lter is not deleted and is sll available in the conguraon.
837
Filter Counts Previously Dropped Packet
IN THIS SECTION
Problem | 838
Soluon | 839
Problem
Descripon
If you congure two or more lters in the same direcon for a physical interface and one of the lters
includes a counter, the counter will be incorrect if the following circumstances apply:
• You congure the lter that is applied to packets rst to discard certain packets. For example,
imagine that you have a VLAN lter that accepts packets sent to 10.10.1.0/24 addresses and
implicitly discards packets sent to any other addresses. You apply the lter to the admin VLAN in the
output direcon, and interface xe-0/0/1 is a member of that VLAN.
• You congure a subsequent lter to accept and count packets that are dropped by the rst lter. In
this example, you have a port lter that accepts and counts packets sent to 192.168.1.0/24
addresses that is also applied to xe-0/0/1 in the output direcon.
The egress VLAN lter is applied rst and correctly discards packets sent to 192.168.1.0/24 addresses.
The egress port lter is applied next and counts the discarded packets as matched packets. The packets
are not forwarded, but the counter displayed by the egress port lter is incorrect.
Remember that the order in which lters are applied depends on the direcon in which they are applied,
as indicated here:
Ingress lters:
1. Port (Layer 2) lter
2. VLAN lter
3. Router (Layer 3) lter
Egress lters:
1. Router (Layer 3) lter
2. VLAN lter
838
3. Port (Layer 2) lter
Soluon
This is expected behavior.
Matching Packets Not Counted
IN THIS SECTION
Problem | 839
Soluon | 839
Problem
Descripon
If you congure two egress lters with counters for a physical interface and a packet matches both of
the lters, only one of the counters includes that packet.
For example:
• You congure an egress port lter with a counter for interface xe-0/0/1.
• You congure an egress VLAN lter with a counter for the adminVLAN, and interface xe-0/0/1 is a
member of that VLAN.
• A packet matches both lters.
In this case, the packet is counted by only one of the counters even though it matched both lters.
Soluon
This is expected behavior.
839
Counter Reset When Eding Filter
IN THIS SECTION
Problem | 840
Soluon | 840
Problem
Descripon
If you edit a rewall lter term, the value of any counter associated with any term in the same lter is set
to 0, including the implicit counter for any policer referenced by the lter. Consider the following
examples:
• Assume that your lter has term1, term2, and term3, and each term has a counter that has already
counted matching packets. If you edit any of the terms in any way, the counters for all the terms are
reset to 0.
• Assume that your lter has term1 and term2. Also assume that term2 has a policer acon modier and
the implicit counter of the policer has already counted 1000 matching packets. If you edit term1 or
term2 in any way, the counter for the policer referenced by term2 is reset to 0.
Soluon
This is expected behavior.
Cannot Include loss-priority and policer Acons in Same Term
IN THIS SECTION
Problem | 841
Soluon | 841
840
Problem
Descripon
You cannot include both of the following acons in the same rewall lter term in a QFX Series switch:
• loss-priority
• policer
If you do so, you see the following error message when you aempt to commit the conguraon:
“cannot support policer acon if loss-priority is congured.”
Soluon
This is expected behavior.
Cannot Egress Filter Certain Trac Originang on QFX Switch
IN THIS SECTION
Problem | 841
Soluon | 841
Problem
Descripon
On a QFX Series switch, you cannot lter certain trac with a rewall lter applied in the output
direcon if the trac originates on the QFX switch. This limitaon applies to control trac for protocols
such as ICMP (ping), STP, LACP, and so on.
Soluon
This is expected behavior.
841
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling
IN THIS SECTION
Problem | 842
Soluon | 842
Problem
Descripon
If you create a rewall lter that includes a match condion of dot1q-tag or dot1q-user-priority and apply
the lter on input to a trunk port that parcipates in a service VLAN, the match condion does not work
if the Q-in-Q EtherType is not 0x8100. (When Q-in-Q tunneling is enabled, trunk interfaces are assumed
to be part of the service provider or data center network and therefore parcipate in service VLANs.)
Soluon
This is expected behavior. To set the Q-in-Q EtherType to 0x8100, enter the set dot1q-tunneling
ethertype 0x8100 statement at the [edit ethernet-switching-options] hierarchy level. You must also
congure the other end of the link to use the same Ethertype.
Egress Firewall Filters with Private VLANs
IN THIS SECTION
Problem | 843
Soluon | 843
842
Problem
Descripon
If you apply a rewall lter in the output direcon to a primary VLAN, the lter also applies to the
secondary VLANs that are members of the primary VLAN when the trac egresses with the primary
VLAN tag or isolated VLAN tag, as listed below:
• Trac forwarded from a secondary VLAN trunk port to a promiscuous port (trunk or access)
• Trac forwarded from a secondary VLAN trunk port that carries an isolated VLAN to a PVLAN trunk
port.
• Trac forwarded from a promiscuous port (trunk or access) to a secondary VLAN trunk port
• Trac forwarded from a PVLAN trunk port. to a secondary VLAN trunk port
• Trac forwarded from a community port to a promiscuous port (trunk or access)
If you apply a rewall lter in the output direcon to a primary VLAN, the lter does
not
apply to trac
that egresses with a community VLAN tag, as listed below:
• Trac forwarded from a community trunk port to a PVLAN trunk port
• Trac forwarded from a secondary VLAN trunk port that carries a community VLAN to a PVLAN
trunk port
• Trac forwarded from a promiscuous port (trunk or access) to a community trunk port
• Trac forwarded from a PVLAN trunk port. to a community trunk port
If you apply a rewall lter in the output direcon to a community VLAN, the following behaviors apply:
• The lter is applied to trac forwarded from a promiscuous port (trunk or access) to a community
trunk port (because the trac egresses with the community VLAN tag).
• The lter is applied to trac forwarded from a community port to a PVLAN trunk port (because the
trac egresses with the community VLAN tag).
• The lter is
not
applied to trac forwarded from a community port to a promiscuous port (because
the trac egresses with the primary VLAN tag or untagged).
Soluon
These are expected behaviors. They occur only if you apply a rewall lter to a private VLAN in the
output direcon and do not occur if you apply a rewall lter to a private VLAN in the input direcon.
843
Egress Filtering of L2PT Trac Not Supported
IN THIS SECTION
Problem | 844
Soluon | 844
Problem
Descripon
Egress ltering of L2PT trac is not supported on the QFX3500 switch. That is, if you congure L2PT to
tunnel a protocol on an interface, you cannot also use a rewall lter to lter trac for that protocol on
that interface in the output direcon. If you commit a conguraon for this purpose, the rewall lter is
not applied to the L2PT-tunneled trac.
Soluon
This is expected behavior.
Cannot Drop BGP Packets in Certain Circumstances
IN THIS SECTION
Problem | 844
Soluon | 845
Problem
Descripon
BGP packets with a me-to-live (TTL) value greater than 1 cannot be discarded using a rewall lter
applied to a loopback interface or applied on input to a Layer 3 interface. BGP packets with TTL value of
1 or 0 can be discarded using a rewall lter applied to a loopback interface or applied on input to a
Layer 3 interface.
844
Soluon
This is expected behavior.
Invalid Stascs for Policer
IN THIS SECTION
Problem | 845
Soluon | 845
Problem
Descripon
If you apply a single-rate two-color policer in more than 128 terms in a rewall lter, the output of the
show firewall command displays incorrect data for the policer.
Soluon
This is expected behavior.
Policers can Limit Egress Filters
IN THIS SECTION
Problem | 845
Soluon | 846
Problem
Descripon
On some switches, the number of egress policers you congure can aect the total number of allowed
egress rewall lters. Every policer has two implicit counters that take up two entries in a 1024-entry
845
TCAM. These are used for counters, including counters that are congured as acon modiers in rewall
lter terms. (Policers consume two entries because one is used for green packets and one is used for
nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any
more egress rewall lters that have terms with counters. For example, if you congure and commit 512
egress policers (two-color, three-color, or a combinaon of both policer types), all of the memory entries
for counters get used up. If later in your conguraon le you insert addional egress rewall lters with
terms that also include counters,
none
of the terms in those lters are commied because there is no
available memory space for the counters.
Here are some addional examples:
• Assume that you congure egress lters that include a total of 512 policers and no counters. Later in
your conguraon le you include another egress lter with 10 terms, 1 of which has a counter
acon modier. None of the terms in this lter are commied because there is not enough TCAM
space for the counter.
• Assume that you congure egress lters that include a total of 500 policers, so 1000 TCAM entries
are occupied. Later in your conguraon le you include the following two egress lters:
• Filter A with 20 terms and 20 counters. All the terms in this lter are commied because there is
enough TCAM space for all the counters.
• Filter B comes aer Filter A and has ve terms and ve counters.
None
of the terms in this lter
are commied because there is not enough memory space for
all
the counters. (Five TCAM
entries are required but only four are available.)
Soluon
You can prevent this problem by ensuring that egress rewall lter terms with counter acons are placed
earlier in your conguraon le than terms that include policers. In this circumstance, Junos OS commits
policers even if there is not enough TCAM space for the implicit counters. For example, assume the
following:
• You have 1024 egress rewall lter terms with counter acons.
• Later in your conguraon le you have an egress lter with 10 terms. None of the terms have
counters but one has a policer acon modier.
You can successfully commit the lter with 10 terms even though there is not enough TCAM space for
the implicit counters of the policer. The policer is commied without the counters.
846
CHAPTER 14
Firewall Filter Match Condions and Acons
IN THIS CHAPTER
Overview of Firewall Filters (OCX Series) | 848
Understanding Firewall Filter Match Condions | 850
Understanding Firewall Filter Planning | 855
Understanding How Firewall Filters Are Evaluated | 856
Understanding Firewall Filter Match Condions | 858
Firewall Filter Flexible Match Condions | 864
Firewall Filter Nonterminang Acons | 873
Firewall Filter Terminang Acons | 886
Firewall Filter Match Condions and Acons (ACX Series Routers) | 911
Firewall Filter Match Condions for Protocol-Independent Trac | 939
Firewall Filter Match Condions for IPv4 Trac | 942
Firewall Filter Match Condions for IPv6 Trac | 959
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Fields | 986
Firewall Filter Match Condions Based on Address Classes | 996
Understanding IP-Based Filtering and Selecve Port Mirroring of MPLS Trac | 998
Firewall Filter Match Condions for MPLS Trac | 1004
Firewall Filter Match Condions for MPLS-Tagged IPv4 or IPv6 Trac | 1013
Firewall Filter Match Condions for VPLS Trac | 1017
Firewall Filter Match Condions for Layer 2 CCC Trac | 1036
Firewall Filter Match Condions for Layer 2 Bridging Trac | 1042
Firewall Filter Support on Loopback Interface | 1059
847
Overview of Firewall Filters (OCX Series)
IN THIS SECTION
Where You Can Apply Filters | 848
Firewall Filter Components | 849
Firewall Filter Processing | 850
Firewall lters provide rules that dene whether to accept or discard packets that are transing an
interface. If a packet is accepted, you can congure addional acons to perform on the packet, such as
class-of-service (CoS) marking (grouping similar types of trac together and treang each type of trac
as a class with its own level of service priority) and trac policing (controlling the maximum rate of
trac sent or received). You congure rewall lters to determine whether to accept or discard a packet
before it enters or exits a Layer 3 (routed) interface.
An
ingress
rewall lter
is applied to packets that are entering an interface, and an
egress
rewall lter is
applied to packets that are exing an interface .
NOTE: Firewall lters are somemes called
access control lists
(ACLs).
Where You Can Apply Filters
You can apply a router rewall lter in both ingress and egress direcons on IPv4 or IPv6 Layer 3
(routed) interfaces and a loopback interface, which lters trac sent to the switch itself or generated by
the switch.
You apply a lter to a loopback interface in the input direcon to protect the switch from unwanted
trac. You also might want to apply a lter to a loopback interface in the output direcon so that you
can set the forwarding class and DSCP bit value for packets that originate on the switch itself. This
feature gives you very ne control over the classicaon of CPU generated packets. For example, you
might want to assign dierent DSCP values and forwarding classes to trac generated by dierent
roung protocols so the trac for those protocols can be treated in a dierenated manner by other
devices.
848
NOTE: On QFX5220 switches, you can only apply a lter to a loopback interface in the ingress
direcon.
NOTE: If you apply ingress and egress lters to the same interface, the ingress lter is processed
rst.
To apply a rewall lter:
1. Congure the rewall lter.
2. Apply the rewall lter to a Layer 3 interface and specify the direcon. If you specify the input
direcon, trac is ltered on ingress. If you specify the output direcon, trac is ltered on egress.
NOTE: You can apply only one rewall lter to a Layer 3 interface for a given direcon. For
example, for a given family inet interface, you can apply one lter for input and one for output.
OCX switches support the maximum numbers of
rewall lter
terms per type of aachment point
shown in Table 33 on page 849.
Table 33: Supported Firewall Filter Numbers
Filter Type Maximum Number of Filters
Ingress 1536
Egress 1024
Firewall Filter Components
In a rewall lter, you rst dene the family address type (inet for IPv4 or inet6 for IPv6) and then dene
one or more terms that specify the ltering criteria and the acon to take if a match occurs.
Each term consists of the following components:
• Match condions—Specify values that a packet must contain to be considered a match.
849
• Acon—Species what to do if a packet matches the match condions. A lter can accept, discard, or
reject a matching packet and then perform addional acons, such as counng, classifying, and
policing. If no acon is specied for a term, the default is to accept the matching packet.
Firewall Filter Processing
If there are mulple terms in a lter, the order of the terms is important. If a packet matches the rst
term, the switch executes the acon dened by that term, and no other terms are evaluated. If the
switch does not nd a match between the packet and the rst term, it compares the packet to the next
term. If no match occurs between the packet and the second term, the system connues to compare the
packet to each successive term in the lter unl a match is found. If the packet does not match any
terms in the lter, the switch discards the packet by default.
RELATED DOCUMENTATION
Understanding Firewall Filter Planning | 855
Understanding How Firewall Filters Are Evaluated | 856
Understanding Firewall Filter Processing Points for Bridged and Routed Packets | 1856
Understanding Firewall Filter Match Condions | 850
Firewall Filter Match Condions and Acons (QFX and EX Series Switches) | 1734
Firewall Filter Match Condions and Acons (QFX10000 Switches) | 1783
Overview of Policers | 2202
Conguring Firewall Filters | 1829
Understanding Firewall Filter Match Condions
IN THIS SECTION
Filter Match Condions | 851
Numeric Filter Match Condions | 851
Interface Filter Match Condions | 852
IP Address Filter Match Condions | 853
Bit-Field Filter Match Condions | 853
850
Before you dene terms for rewall lters, you must understand how the condions in a term are
handled and how to specify interface, numeric, address, and bit-eld lter match condions to achieve
the desired lter results.
Filter Match Condions
In the from statement of a
rewall lter
term, you specify the condions that the packet must match for
the acon in the then statement to be taken. All condions must match for the acon to be
implemented. The order in which you specify match condions is not important, because a packet must
match all the condions in a term for a match to occur.
If you specify mulple values for the same condion, a match on any one of those values matches that
condion. For example, if you specify mulple IP source addresses using the source-address statement, a
packet that contains any one of those IP source addresses matches the condion. In some cases you can
specify mulple values for the same condion by enclosing the possible values in square brackets, as in:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set protocol (icmp | udp)
In other cases you must enter mulple statements, as in:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-address 10.1.1.1
user@switch# set source-address 10.1.1.2
If you specify no match condions in a term, that term matches all packets.
NOTE: Unlike tradional Junos OS rewall lters, you cannot use except in a condion statement
to negate the condion.
Numeric Filter Match Condions
You can specify numeric lter match condions that are idened by a numeric value, such as port and
protocol numbers. For numeric lter match condions, you specify the condion and a single value that
a eld in a packet must contain to be considered a match.
You can specify the numeric value in one of the following ways:
851
• Single number—A match occurs if the value of the eld matches the number. For example, to match
Telnet trac:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-port 23
• Text synonym for a single number—A match occurs if the value of the eld matches the number that
corresponds to the synonym. For example, to match Telnet trac:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-port telnet
• To specify mulple values for the same match condion in a lter term, enter each value in its own
match statement. For example, a match occurs in the following term if the value of the source port in
the packet is 22 or 23.
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-port 22
user@switch# set source-port 23
Interface Filter Match Condions
You can specify an interface lter match condion to match an interface on which a packet is received
or transmied. In this example, the nal character (0) species the logical unit. You can include the
wildcard (*) as part of the interface name. For example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set interface ge-0/*/6.0
user@switch# set interface ge-0/1/*.0
user@switch# set interface ge-0/0/6.*
Note that you must specify a value or a wildcard for the logical unit.
852
IP Address Filter Match Condions
You can specify an address lter match condion to match an IP source or desnaon address or prex
in a packet. Specify the address or prex type and the address or prex itself. For example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-address 10.2.1.0/24;
If you omit the prex length, it defaults to /32. For example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-address 10
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# show
destination-address {
10.0.0.0/32;
}
To specify more than one IP address or prex in a lter term, enter each address or prex in its own
match statement. For example, a match occurs in the following term if the source address of a packet
matches either of the following prexes:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-address 10.1.0.0/16
user@switch# set source-address 10.2.0.0/16
Bit-Field Filter Match Condions
You can specify bit-eld lter match condions to match parcular bits within certain elds in Ethernet
frames and IP, TCP, UDP, and ICMP headers. You usually specify the eld and the bit within the eld that
must be set in a packet to be considered a match.
In most cases you can use a keyword to specify the bit you want to match on. For example, to match on
a TCP SYN packet you can enter syn, as in:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags syn
853
You can also enter 0x02 because the SYN bit is the third least-signicant bit of the 8-bit tcp-ags eld:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags 0x02
To match mulple bit-eld values, use the logical operators, which are described in Table 34 on page
854. The operators are listed in order from highest precedence to lowest precedence. Operaons are
evaluated from le to right.
Table 34: Acons for Firewall Filters
Logical Operators Descripon
!
Negaon
&
Logical AND
|
Logical OR
If you use a logical operator, enclose the values in quotaon marks and do not include any spaces. For
example, the following statement matches the second packet of a TCP handshake:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "syn&ack"
To negate a match, precede the value with an exclamaon point. For example, the following statement
matches only the inial packet of a TCP handshake:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "syn&!ack"
You can use text synonyms to specify some common bit-eld matches. For example, the following
statement also matches the inial packet of a TCP handshake:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-initial
854
RELATED DOCUMENTATION
Understanding How a Firewall Filter Tests a Protocol | 1855
Firewall Filter Match Condions and Acons (QFX and EX Series Switches) | 1734
Conguring Firewall Filters | 1829
Understanding Firewall Filter Planning
Before you create a
rewall lter
and apply it, determine what you want the lter to accomplish and
how to use its match condions and acons to achieve your goals. It is important that you understand
how packets are matched, the default and congured acons of the rewall lter, and where to apply
the rewall lter.
You can apply no more than one rewall lter per router interface per direcon (input and output). For
example, for a given interface you can apply at most one lter in the input direcon and one lter in the
output direcon. You should try to be conservave in the number of terms (rules) that you include in
each rewall lter, because a large number of terms requires longer processing me during a commit
operaon and can make tesng and troubleshoong more dicult.
Before you congure and apply rewall lters, answer the following quesons for each of them:
1. What is the purpose of the lter?
For example, the system can drop packets based on header informaon, rate-limit trac, classify
packets into forwarding classes, log and count packets, or prevent denial-of-service aacks.
2. What are the appropriate match condions? Determine the packet header elds that the packet must
contain for a match. Possible elds include:
• Layer 3 header elds—Source and desnaon IP addresses, protocols, and IP opons (IP
precedence, IP fragmentaon ags, or TTL type).
• TCP header elds—Source and desnaon ports and ags.
• ICMP header elds—Packet type and code.
3. What are the appropriate acons to take if a match occurs?
The system can accept, discard, or reject packets.
4. What addional acon modiers might be required?
For example, you can congure the system to mirror (copy) packets to a specied port, count
matching packets, apply trac management, or police packets.
855
5. On what Layer 3 interface should the rewall lter be applied?
Before you choose the interface on which to apply a rewall lter, understand how that placement
can aect trac ow to other interfaces. In general, apply a lter close to the source device if the
lter matches on source or desnaon IP addresses, IP protocols, or protocol informaon—such as
ICMP message types, and TCP or UDP port numbers. However, you should apply a lter close to the
desnaon device if the lter matches
only
on a source IP address. When you apply a lter too close
to the source device, the lter could prevent that source device from accessing other services that
are available on the network.
6. In which direcon should the rewall lter be applied?
You typically congure dierent acons for trac entering an interface than you congure for trac
exing an interface.
7. How many lters should I create?
RELATED DOCUMENTATION
Overview of Policers | 2202
Understanding How Firewall Filters Are Evaluated | 856
Conguring Firewall Filters | 1829
Understanding How Firewall Filters Are Evaluated
A
rewall lter
consists of one or more terms, and the order of the terms within a lter is important.
Before you congure rewall lters, you should understand how switches evaluate the terms within a
lter and how packets are evaluated against the terms.
When a rewall lter consists of a single term, the lter is evaluated as follows:
• If the packet matches all the condions, the acon in the then statement is taken.
• If the packet matches all the condions, and no acon is specied in the then statement, the default
acon accept is taken.
• If the packet does not match all the condions, the switch discards it.
When a rewall lter consists of more than one term, the lter is evaluated sequenally:
1.
The packet is evaluated against the condions in the from statement in the rst term.
856
2. If the packet matches all the condions in the term, the acon in the then statement is taken and the
evaluaon ends. Subsequent terms in the lter are not evaluated.
3. If the packet does not match all the condions in the term, the packet is evaluated against the
condions in the from statement in the second term.
This process connues unl the packet matches all the condions in the from statement in one of the
subsequent terms or there are no more terms in the lter.
4. If a packet passes through all the terms in the lter without a match, the switch discards it.
NOTE: The order of condions in a from statement is not important because a packet must match
all the condions to be considered a match.
Figure 50 on page 857 shows how switches evaluate the terms within a rewall lter.
Figure 50: Evaluaon of Terms Within a Firewall Filter
If you do not include a from statement in a term, all packets will match the term and be processed by the
then statement. If a term does not contain a then statement or if an acon has not been congured in the
then statement, the term accepts any matching packets.
857
Every rewall lter contains an implicit deny statement at the end of the lter, which is equivalent to the
following explicit lter term:
term implicit-rule {
then discard;
}
Consequently, a packet that does not match any of the terms in a rewall lter is discarded. If you
congure a lter that has no terms, all packets that pass through the lter are discarded.
NOTE: Firewall ltering is supported on packets that are at least 64 bytes long.
RELATED DOCUMENTATION
Understanding Firewall Filter Match Condions | 858
Overview of Policers | 2202
Conguring Firewall Filters | 1829
Understanding Firewall Filter Match Condions
IN THIS SECTION
Filter Match Condions | 859
Numeric Filter Match Condions | 859
Interface Filter Match Condions | 860
IP Address Filter Match Condions | 861
MAC Address Filter Match Condions | 861
Bit-Field Filter Match Condions | 862
Before you dene terms for rewall lters, you must understand how the condions in a term are
handled and how to specify interface, numeric, address, and bit-eld lter match condions to achieve
the desired lter results.
858
Filter Match Condions
In the from statement of a
rewall lter
term, you specify the condions that the packet must match for
the acon in the then statement to be taken. All condions must match for the acon to be
implemented. The order in which you specify match condions is not important, because a packet must
match all the condions in a term for a match to occur.
If you specify mulple values for the same condion, a match on any one of those values matches that
condion. For example, if you specify mulple IP source addresses using the source-address statement, a
packet that contains any one of those IP source addresses matches the condion. In some cases you can
specify mulple values for the same condion by enclosing the possible values in square brackets, as in:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set protocol (icmp | udp)
In other cases you must enter mulple statements, as in:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-address 10.1.1.1
user@switch# set source-address 10.1.1.2
If you specify no match condions in a term, that term matches all packets.
NOTE: Unlike tradional Junos OS rewall lters, you cannot use except in a condion statement
to negate the condion.
Numeric Filter Match Condions
You can specify numeric lter match condions that are idened by a numeric value, such as port and
protocol numbers. For numeric lter match condions, you specify the condion and a single value that
a eld in a packet must contain to be considered a match.
You can specify the numeric value in one of the following ways:
• Single number—A match occurs if the value of the eld matches the number. For example, to match
Telnet trac:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-port 23
859
• Text synonym for a single number—A match occurs if the value of the eld matches the number that
corresponds to the synonym. For example, to match Telnet trac:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-port telnet
• To specify mulple values for the same match condion in a lter term, enter each value in its own
match statement. For example, a match occurs in the following term if the value of the source port in
the packet is 22 or 23.
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-port 22
user@switch# set source-port 23
Interface Filter Match Condions
You can specify an interface lter match condion to match an interface on which a packet is received
or transmied. For example, if you apply a lter to a VLAN you might want the lter to match on some
interfaces that parcipate in the VLAN and not match on other interfaces in the VLAN. When you
specify the name of the interface, you must include a logical unit.
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set interface ge-0/0/6.0
In this example, the nal character (0) species the logical unit. You can include the wildcard (*) as part of
the interface name. For example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set interface ge-0/*/6.0
user@switch# set interface ge-0/1/*.0
user@switch# set interface ge-0/0/6.*
Note that you must specify a value or a wildcard for the logical unit.
860
IP Address Filter Match Condions
You can specify an address lter match condion to match an IP source or desnaon address or prex
in a packet. Specify the address or prex type and the address or prex itself. For example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-address 10.2.1.0/24;
If you omit the prex length, it defaults to /32. For example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-address 10
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# show
destination-address {
10.0.0.0/32;
}
To specify more than one IP address or prex in a lter term, enter each address or prex in its own
match statement. For example, a match occurs in the following term if the source address of a packet
matches either of the following prexes:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-address 10.1.0.0/16
user@switch# set source-address 10.2.0.0/16
MAC Address Filter Match Condions
You can specify a MAC address lter match condion to match a source or desnaon MAC address.
You specify the address type and value that a packet must contain to be considered a match.
861
You can specify the MAC address as six hexadecimal bytes in any of the following formats:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-mac-address 00:11:22:33:44:55
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-mac-address 0011.2233.4455
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-mac-address 001122334455
Regardless of the formats you use, the system resolves the address to the standard format, in this case
00:11:22:33:44:55.
To specify more than one MAC address in a lter term, enter each MAC address in its own match
statement. For example, a match occurs in the following term if the value of the MAC source address
matches either of the following addresses:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-mac-address 00:11:22:33:44:55
user@switch# set source-mac-address 00:11:22:33:20:15
Bit-Field Filter Match Condions
You can specify bit-eld lter match condions to match parcular bits within certain elds in Ethernet
frames and IP, TCP, UDP, and ICMP headers. You usually specify the eld and the bit within the eld that
must be set in a packet to be considered a match.
In most cases you can use a keyword to specify the bit you want to match on. For example, to match on
a TCP SYN packet you can enter syn, as in:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags syn
862
You can also enter 0x02 because the SYN bit is the third least-signicant bit of the 8-bit tcp-ags eld:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags 0x02
To match mulple bit-eld values, use the logical operators, which are described in Table 35 on page
863. The operators are listed in order from highest precedence to lowest precedence. Operaons are
evaluated from le to right.
Table 35: Acons for Firewall Filters
Logical Operators Descripon
!
Negaon
&
Logical AND
|
Logical OR
If you use a logical operator, enclose the values in quotaon marks and do not include any spaces. For
example, the following statement matches the second packet of a TCP handshake:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "syn&ack"
To negate a match, precede the value with an exclamaon point. For example, the following statement
matches only the inial packet of a TCP handshake:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "syn&!ack"
You can use text synonyms to specify some common bit-eld matches. For example, the following
statement also matches the inial packet of a TCP handshake:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-initial
863
RELATED DOCUMENTATION
Understanding How a Firewall Filter Tests a Protocol | 1855
Firewall Filter Match Condions and Acons (EX4100, EX4100-F, EX4400, EX4600, EX4650,
QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, QFX5700) | 1735
Conguring Firewall Filters | 1829
Firewall Filter Flexible Match Condions
IN THIS SECTION
Statement Hierarchy | 865
Flexible Filter Match Types | 865
Flexible Filter Match Start Locaons | 867
Flexible Filter Match Examples | 868
Standard rewall lter match condions vary based on the protocol family of the trac being matched.
For example, the terms available for bridge protocol trac are dierent from those available for the inet
or inet6 protocol families. The elds available for matching within each protocol family are, however,
xed or pre-dened. This means that lters can match on paerns within those pre-dened elds only.
Using exible match condions, rewall lters can be constructed that start the match at layer-2,
layer-3, layer-4 or payload locaons. From there, addional oset criteria can be specied thereby
enabling paern matches at custom, user-dened locaons within a packet.
Flexible match lter terms are applied to MPC or MIC interfaces as either input or output lters just as
any other rewall lter terms. Flexible match lter terms can also be created as templates at the [edit
firewall] hierarchy level. These templates can then be referenced within a exible match term.
For MX series routers, exible match condions are only supported with MPCs or MICs. For
environments where FPCs, PICs, and or DPCs are installed along with MPCs or MICs, be sure to only
apply the exible match rewall lter criteria to the MPC or MIC interfaces.
NOTE: For MX Series routers with MPCs, you need to inialize the lter counter for Trio-only
match lters in the MIB by walking the corresponding SNMP MIB. For example, for any lter that
is congured or changed with respect to their Trio-only lters, you need to run a command such
864
as the following: show snmp mib walk
(ascii | decimal)
object-id. This forces Junos to learn the lter
counters and ensure that the lter stascs are displayed (this is because the rst poll to lter
stascs may not show all counters). Trio-only match lters are those that include at least one
match condion or acon that is only supported by the Trio chipset.
This guidance applies to all enhanced-mode rewall lters. It also applies to "Firewall Filter Match
Condions for IPv4 Trac" on page 942 with exible match lter terms for oset-range or
oset-mask, gre-key, and " Firewall Filter Match Condions for IPv6 Trac" on page 959 with
any of the following match condions: payload-protocol, extension headers, is_fragment. It also applies
to lters with either of the following "Firewall Filter Terminang Acons" on page 886:
encapsulate or decapsulate, or either of the following "Firewall Filter Nonterminang Acons" on
page 873: policy-map, and clear-policy-map.
Statement Hierarchy
Flexible match lter terms are available in three variaons as shown in Table 36 on page 865. The
flexible-match variaon is congured at the [edit firewall] hierarchy level. It is used to dene exible
match templates. The flexible-filter-match-mask and flexible-match-range are congured at the [edit firewall
family [inet|inet6|bridge|ethernet-switching|ccc|vpls] filter
<filter-name>
term
<term-name>
from] hierarchy. Use
the family ethernet-switching lter for EX9200 switches.
Flexible Filter Match Types
Table 36: Flexible Filter Match Types
Flexible Filter Match
Type
Available Aributes Descripon
flexible-match
<name>
Create a exible-match template named as the
<name>
aribute.
bit-length
Length of the data to be matched in bits, not needed for string
input (0..32)
For QFX5120 and EX4650 switches, 16 and 32 are the only
valid bit lengths.
bit-offset Bit oset aer the (match-start + byte) oset (0..7)
865
Table 36: Flexible Filter Match Types
(Connued)
Flexible Filter Match
Type
Available Aributes Descripon
byte-offset Byte oset aer the match start point
match-start Start point to match in packet
flexible-match-mask bit-length
Length of the data to be matched in bits, not needed for string
input (0..128)
bit-offset
Bit oset aer the (match-start + byte) oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-mask-name
Select a exible match from predened template eld. Required
unless match-start is congured.
mask-in-hex
Mask out bits in the packet data to be matched.
match-start Start point to match in packet. Required unless flexible-mask-
name is congured.
prefix
Value data/string to be matched.
flexible-match-range bit-length
Length of the data to be matched in bits. (0..32) Required
unless flexible-range-name is congured.
bit-offset
Bit oset aer the (match-start + byte) oset. (0..7)
byte-offset
Byte oset aer the match start point
flexible-range-name
Select a exible match from predened template.
866
Table 36: Flexible Filter Match Types
(Connued)
Flexible Filter Match
Type
Available Aributes Descripon
match-start Start point to match in packet. Required unless flexible-range-
name is congured.
range
Range of values to be matched.
range-except
Range of values to be not matched.
NOTE: flexible-match-range is not supported on EX2300, EX3400, EX4100 and EX4400.
Flexible Filter Match Start Locaons
Flexible match lter terms are constructed by giving a start locaon or anchor point within the packet.
The start locaons can be any of: layer-2, layer-3, layer-4 or payload, depending on the protocol family
in use. Table 37 on page 867 shows available exible lter match start locaons by protocol family. You
use these available start locaons as the match-start locaons for the exible match lter terms.
From these start locaons, specic byte and bit osets can be ulized to allow the lter to match
paerns at very specic locaons within the packet.
Table 37: Flexible Filter Match Start
Locaons
Protocol Family Available Start Locaons
inet layer-3, layer-4 and payload
For QFX5120 and EX4650 switches, support for layer-2 and layer-3 (only) exible match
lters was added in Junos Release 20.1R1.
inet6 layer-3, layer-4, payload
For QFX5120 and EX4650 switches, support for layer-2 and layer-3 (only) exible match
lters was added in Junos Release 20.1R1.
867
Table 37: Flexible Filter Match Start Locaons
(Connued)
Protocol Family Available Start Locaons
bridge layer-2, layer-3, layer-4 and payload
ccc layer-2, layer-3, layer-4 and payload
mpls layer-3 and payload
vpls layer-2, layer-3, layer-4 and payload
ethernet-switching (EX9200 switches) layer-2, layer-3, layer-4 and payload
For, QFX5120 and EX4650 switches, support for layer-2 and layer-3 (only) exible match
lters was added in Junos Release 20.1R1. An example of using a layer-2 packet oset and
match length can be found below.
Flexible Filter Match Examples
The following example illustrates the use and context for flexible-match-mask.
from {
flexible-match-mask {
flexible-mask-name <mask-name>;
mask-in-hex <mask>;
prefix <pattern>;
}
}
The
<mask-name>
species for
exible-mask-name
which predened template is used for the exible
match condion. Templates can be dened to specify at which place (posion) in the packet the exible
match condion should be executed.
The
<mask>
for
mask-in-hex
is in hexadecimal format. For example, a congured mask of 0xf0fc species
a match for the st four bits in rst byte (as referred by
<mask-name>
), and for the rst six bits in the
second byte. If the packet is IPv4 packet, and
<mask-name>
refers to rst two bytes in L3 header, the
search is for the IP version eld and DSCP eld. As another example, a congured mask 0xffc0 species a
868
search for enre rst byte and for two bits from the second byte. If the
<mask-name>
refers to rst two
bytes in L3 header, and the packet is IPv6 packet, this species the IP version eld and DSCP in the
Trac Class eld.
The
<paern>
specied for
prex
is an ASCII string. If rst two characters are 0x, then the string is
processed as a hexadecimal number encoding appropriate bits. For example, the congured prex 0x40c0
in combinaon with mask 0xf0fc and
<mask-name>
referring rst two bytes in L3 header, indicates a
search for 0100 in the rst four bits (version eld is equal to 4) and 1100 00 in IPv4 DSCP eld (DSCP is
equal to cs6). Or, using the congured prex 0x6c00 in combinaon with mask 0xffc0 and
<mask-name>
referring rst two bytes in L3 header, species a search for for 0110 in the rst four bits (version eld is
equal to 6), and 1100 00 in IPv6 DSCP eld (DSCP is equal to cs6).
The rst example denes a mask template that selects rst two bytes (16 bits) from L3 header for
exible match:
firewall {
flexible-match FM-FIRST-TWO-L3-BYTES {
match-start layer-3;
byte-offset 0;
bit-offset 0;
bit-length 16;
}
}
The next example denes a mask template that selects the third through sixth byte (32 bits) of the
packet payload for exible match:
firewall {
flexible-match FM-FOUR-PAYLOAD-BYTES {
match-start payload;
byte-offset 2;
bit-offset 0;
bit-length 32;
}
}
869
This example shows an ASCII character match for the string
JNPR
(ASCII characters: 0x4a, 0x4e, 0x50, 0x52)
in the third through sixth byte of the packet payload. The lter uses the FM-FOUR-PAYLOAD-BYTES mask
template dened in the previous example.
firewall {
family ccc filter FF-COUNT-JNPR-PACKETS {
term JNPR-STRING {
from {
flexible-match-mask {
mask-in-hex 0xffffffff;
prefix JNPR;
flexible-mask-name FM-FOUR-PAYLOAD-BYTES;
}
}
then {
count CNT-JNPR-YES
accept;
}
}
term DEAFULT {
then {
count CNT-JNPR-NO
accept;
}
}
}
}
This example shows a family ccc lter looking for DSCP equal to cs6 and DSCP ef, regardless whether
the encapsulated packets are IPv4 or IPv6. It uses the the FM-FIRST-TWO-L3-BYTES mask template dened in
the rst example.
firewall {
family ccc filter FF-DSCP-CLASSIFY {
term ROUTING-IPV4 {
from {
flexible-match-mask {
mask-in-hex 0xf0fc;
prefix 0x40c0; # DSCP=cs6 in IPv4 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
870
}
then {
count ROUTING-IPV4;
accept;
}
}
term ROUTING-IPV6 {
from {
flexible-match-mask {
mask-in-hex 0xffc0;
prefix 0x6c00; # DSCP=cs6 in IPv6 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
}
then {
count ROUTING-IPV6;
accept;
}
}
term VOICE-IPV4 {
from {
flexible-match-mask {
mask-in-hex 0xf0fc;
prefix 0x40b8; # DSCP=ef in IPv4 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
}
then {
count VOICE-IPV4;
accept;
}
}
term VOICE-IPV6 {
from {
flexible-match-mask {
mask-in-hex 0xffc0;
prefix 0x6b80; # DSCP=ef in IPv6 header
flexible-mask-name FM-FIRST-TWO-L3-BYTES;
}
}
then {
count VOICE-IPV6;
accept;
871
}
}
term DEFAULT {
then {
accept;
}
}
}
}
This example shows how to use a match length, starng from a layer-2 packet oset, in a rewall lter
for a QFX5120-32C, QFX5120-48Y, or EX4650 device running Junos Release 20.1R1. Here, we use a
bit-length of 32 bits and the ethernet-switching family (inet and inet6 are also supported, as is using a
layer-3 oset).
user@device# show firewall family ethernet-switching
filter udf_eth {
term t1 {
from {
flexible-match-mask {
match-start layer-2;
byte-offset 8;
bit-length 32;
prefix 168430090;
}
}
then count c1;
}
}
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
23.2R1 From Junos OS Release 23.2R1, we support layer-2 and layer-3 (only) exible match lters on the
EX4100-24P, EX4100-24T, EX4100-24MP, EX4100-48P, EX4100-48T, EX4400-24T, EX4400-24X, and
EX4400-48F switches.
20.1R1 For, QFX5120 and EX4650 switches, support for layer-2 and layer-3 (only) exible match lters was
added in Junos Release 20.1R1.
872
RELATED DOCUMENTATION
Firewall Filter Match Condions for IPv4 Trac | 942
Firewall Filter Match Condions for IPv6 Trac | 959
Firewall Filter Match Condions for Layer 2 CCC Trac | 1036
Firewall Filter Match Condions for VPLS Trac | 1017
Firewall Filter Nonterminang Acons
Firewall lters support dierent sets of nonterminang acons for each protocol family, which include
an implicit accept acon. In this context,
nonterminang
means that other acons can follow these
acons whereas no other acons can follow a
terminang
acon. As such, you cannot congure the
next term acon with a
terminang
acon in the same lter term. You can, however, congure the
next term acon with another
nonterminang
acon in the same lter term.
NOTE: On Junos OS and Junos OS Evolved, next term cannot appear as the last term of the
acon. A lter term where next term is specied as an acon but without any match condions
congured is not supported.
Table 38 on page 874 describes the nonterminang acons you can congure for a rewall lter term.
873
Table 38: Nonterminang Acons for Firewall Filters
Nonterminang
Acon Descripon Protocol Families
bgp-output-queue-
priority priority
(expedited |
(1-16))
Assign the packet to one of the 17 priorized BGP output queues.
• family evpn
• family inet
• family inet-mdt
• family inet-mvpn
• family inet-vpn
• family inet6
• family inet6-
mvpn
• family inet6-vpn
• family iso-vpn
• family l2vpn
• family route-
target
• family traffic-
engineering
count
counter-name
Count the packet in the named counter.
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
874
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
dont-fragment (set
| clear)
Congure the value of the Don’t Fragment bit (ag) in the IPv4
header to specify whether the datagram can be fragmented:
• set—Change the ag value to one, prevenng fragmentaon.
• clear—Change the ag value to zero, allowing fragmentaon.
NOTE: The dont-fragment (set | clear) acons are supported only
on MPCs.
family inet
875
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
dscp
value
Set the IPv4 Dierenated Services code point (DSCP) bit. You can
specify a numerical value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in
binary form, include b as a prex.
The default DSCP value is be (best eort), or 0.
You can also specify one of the following text synonyms:
• af11—Assured forwarding class 1, low drop precedence (1)
• af12—Assured forwarding class 1, medium drop precedence (2)
• af13—Assured forwarding class 1, high drop precedence (3); and
so on through af43, Assured forwarding class 4, high drop
precedence
• be—Best eort
• cs0—Class selector 0; and so on through cs7, Class selector 0
• ef—Expedited forwarding
NOTE: This acon is not supported on PTX series routers.
NOTE: MPC line cards running on MX series routers support any
value (from 0 to 63) in conjuncon with the set dscp rewall lter
acon.
NOTE: The acons dscp 0 and dscp be are supported only on T320,
T640, T1600, TX Matrix, TX Matrix Plus, and M320 routers and on
10-Gigabit Ethernet Modular Port Concentrators (MPC). However,
these acons are not supported on Enhanced III Flexible PIC
Concentrators (FPCs) on M320 routers. On T4000 routers, the dscp
0 acon is not supported during the inter-operaon between a
T1600 Enhanced Scaling Type 4 FPC and a T4000 Type 5 FPC.
family inet
876
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
enhanced-
hierarchical-
policer
Police the packets of a trac priority using the specied enhanced
hierarchical policer.
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family VPLS
force-premium
By default, a hierarchical policer processes the trac it receives
according to the trac’s forwarding class. Premium, expedited-
forwarding trac, has priority for bandwidth over aggregate, best-
eort trac. The force-premium lter ensures that trac matching
the term is treated as premium trac by a subsequent hierarchical
policer, regardless of its forwarding class. This trac is given
preference over any aggregate trac received by that policer.
NOTE: The force-premium lter opon is supported only on MPCs.
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family VPLS
forwarding-class
class-name
Classify the packet to the named forwarding class:
•
forwarding-class-name
• assured-forwarding
• best-effort
• expedited-forwarding
• network-control
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
877
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
hierarchical-
policer
Police the packet using the specied hierarchical policer
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
ipsec-sa
ipsec-sa
Use the specied IPsec security associaon.
NOTE: This acon is not supported on MX Series routers, Type 5
FPCs on T4000 routers, and PTX Series Packet Transport Routers.
family inet
load-balance
group-name
Use the specied load-balancing group.
NOTE: This acon is not supported on MX Series routers or PTX
Series Packet Transport Routers.
family inet
log
Log the packet header informaon in a buer within the Packet
Forwarding Engine. You can access this informaon by issuing the
show firewall log command at the command-line interface (CLI).
NOTE: The Layer 2 (L2) families log acon is available only for MX
Series routers with MPCs (MPC mode if the router has only MPCs,
or mix mode if it has MPCs and DCPs). For MX Series routers with
DPCs, the log acon for L2 families is ignored if congured.
• family bridge
• family ccc
• family inet
• family inet6
• family vpls
logical-system
logical-system-
name
Direct packets to a specic logical system.
• family inet
• family inet6
878
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
loss-priority
(high | medium-
high | medium-low
| low)
Set the packet loss priority (PLP) level.
You cannot also congure the three-color-policer nonterminang
acon for the same rewall lter term. These two nonterminang
acons are mutually exclusive.
This acon is supported on M120 and M320 routers; M7i and M10i
routers with the Enhanced CFEB (CFEB-E); and MX Series routers.
For IP trac on M320, MX Series, and T Series routers with
Enhanced II Flexible PIC Concentrators (FPCs), you must include the
tri-color statement at the [edit class-of-service] hierarchy level to
commit a PLP conguraon with any of the four levels specied. If
the tri-color statement is not enabled, you can only congure the
high and low levels. This applies to all protocol families.
For informaon about the tri-color statement and using behavior
aggregate (BA) classiers to set the PLP level of incoming packets,
see
Understanding How Behavior Aggregate Classiers Priorize
Trusted Trac
.
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
next-hop-group
group-name
Use the specied next-hop group.
We recommend that you do not use the next-hop-group acon with
the port-mirror-instance or port-mirror acon in the same rewall
lter.
• family any
• family inet
next-interface
interface-name
(MX Series) Direct packets to the specied outgoing interface.
• family inet
• family inet6
next-ip
ip-address
(MX Series) Direct packets to the specied desnaon IPv4 address.
family inet
next-ip6
ipv6-
address
(MX Series) Direct packets to the specied desnaon IPv6 address.
family inet6
879
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
packet-mode
Updates a bit eld in the packet key buer, which species trac
that will bypass ow-based forwarding. Packets with the packet-mode
acon modier follow the packet-based forwarding path and bypass
ow-based forwarding completely. Applies to SRX100, SRX210,
SRX220, SRX240, and SRX650 devices only. For more informaon
about selecve stateless packet-based services, see the
Junos OS
Security Conguraon Guide
.
family any
policer
policer-
name
Name of policer to use to rate-limit trac.
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
policy-map
policy-
map-name
(MX Series) Name of policy map used to assign specic rewrite rules
to a specic customer.
• family any
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
880
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
port-mirror
instance-name
Port-mirror the packet based on the specied family. This acon is
supported on M120 routers, M320 routers congured with
Enhanced III FPCs, MX Series routers, and PTX Series Packet
Transport Routers only.
We recommend that you do not use both the next-hop-group and the
port-mirror acons in the same rewall lter.
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family vpls
• family mpls
port-mirror-
instance
instance-
name
Port mirror a packet for an instance. This acon is supported only on
the MX Series routers.
We recommend that you do not use both the next-hop-group and the
port-mirror-instance acons in the same rewall lter.
• family any
• family bridge
• family ccc
• family inet
• family inet6
• family vpls
• family mpls
prefix-action
action-name
Count or police packets based on the specied acon name.
NOTE: This acon is not supported on PTX Series Packet Transport
Routers.
family inet
routing-instance
routing-instance-
name
Direct packets to the specied roung instance.
• family inet
• family inet6
•
881
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
sample
Sample the packet.
NOTE: Junos OS does not sample packets originang from the
router. If you congure a lter and apply it to the output side of an
interface, then only the transit packets going through that interface
are sampled. Packets that are sent from the Roung Engine to the
Packet Forwarding Engine are not sampled.
• family inet
• family inet6
• family mpls
service-accounting
Use the inline counng mechanism when capturing subscriber per-
service stascs.
Count the packet for service accounng. The count is applied to a
specic named counter (__junos-dyn-service-counter) that RADIUS
can obtain.
The service-accounting and service-accounting-deferred keywords
are mutually exclusive, both per-term and per-lter.
NOTE: This acon is not supported on T4000 Type 5 FPCs and PTX
Series Packet Transport Routers.
• family any
• family inet
• family inet6
service-
accounting-
deferred
Use the deferred counng mechanism when capturing subscriber
per-service stascs. The count is applied to a specic named
counter (__junos-dyn-service-counter) that RADIUS can obtain.
The service-accounting and service-accounting-deferred keywords
are mutually exclusive, both per-term and per-lter.
NOTE: This acon is not supported on T4000 Type 5 FPCs and PTX
Series Packet Transport Routers.
• family any
• family inet
• family inet6
882
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
service-filter-hit (Only if the service-filter-hit ag is marked by a previous lter in
the current type of chained lters) Direct the packet to the next type
of lters.
Indicate to subsequent lters in the chain that the packet was
already processed. This acon, coupled with the service-filter-hit
match condion in receiving lters, helps to streamline lter
processing.
NOTE: This acon is not supported on T4000 Type 5 FPCs and PTX
Series Packet Transport Routers.
• family any
• family inet
• family inet6
slice
slice-name
Mark packets that pass the match condions of the rule with the
slice idener corresponding to the Services Network-Slicing
conguraon. See slice (rewall lter acon).
• family any
• family bridge
• family ccc
• family evpn
• family inet
• family inet6
• family mpls
• family vpls
883
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
syslog
Log the packet to the system log le.
The syslog rewall acon for exisng inet and inet6 families, and the
syslog acon in L2 family lters includes the following L2
informaon:
Input interface, acon, VLAN ID1, VLAN ID2, Ethernet type, source
and desnaon MAC addresses, protocol, source and desnaon IP
addresses, source and desnaon ports, and the number of packets.
NOTE: The L2 families syslog acon is available only for MX Series
routers with MPCs (MPC mode if the router has only MPCs, or mix
mode if it has MPCs and DCPs). For MX Series routers with DPCs,
the syslog acon for L2 families is ignored if congured.
• family bridge
• family ccc
• family inet
• family inet6
• family vpls
three-color-
policer (single-
rate | two-rate)
policer-name
Police the packet using the specied single-rate or two-rate three-
color-policer.
NOTE: You cannot also congure the loss-priority acon for the
same rewall lter term. These two acons are mutually exclusive.
• family bridge
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
884
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
traffic-class
value
Specify the trac-class code point. You can specify a numerical
value from 0 through 63. To specify the value in hexadecimal form,
include 0x as a prex. To specify the value in binary form, include b
as a prex.
The default trac-class value is best eort, that is, be or 0.
In place of the numeric value, you can specify one of the following
text synonyms:
• af11—Assured forwarding class 1, low drop precedence
• af12—Assured forwarding class 1, medium drop precedence
• af13—Assured forwarding class 1, high drop precedence
• af21—Assured forwarding class 2, low drop precedence
• af22—Assured forwarding class 2, medium drop precedence
• af23—Assured forwarding class 2, high drop precedence
• af31—Assured forwarding class 3, low drop precedence
• af32—Assured forwarding class 3, medium drop precedence
• af33—Assured forwarding class 3, high drop precedence
• af41—Assured forwarding class 4, low drop precedence
• af42—Assured forwarding class 4, medium drop precedence
• af43—Assured forwarding class 4, high drop precedence
• be—Best eort
• cs0—Class selector 0
• cs1—Class selector 1
• cs2—Class selector 2
family inet6
885
Table 38: Nonterminang Acons for Firewall Filters
(Connued)
Nonterminang
Acon Descripon Protocol Families
• cs3—Class selector 3
• cs4—Class selector 4
• cs5—Class selector 5
• cs6—Class selector 6
• cs7—Class selector 7
• ef—Expedited forwarding
NOTE: The acons traffic-class 0and traffic-class be are
supported only on T Series and M320 routers and on the 10-Gigabit
Ethernet Modular Port Concentrator (MPC), 60-Gigabit Ethernet
MPC, 60-Gigabit Ethernet Queuing MPC, and 60-Gigabit Ethernet
Enhanced Queuing MPC on MX Series routers. However, these
acons are not supported on Enhanced III Flexible PIC
Concentrators (FPCs) on M320 routers.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
Firewall Filter Terminang Acons
Firewall lters support a set of terminang acons for each protocol family. A lter-terminang acon
halts all evaluaon of a rewall lter for a specic packet. The router performs the specied acon, and
no addional terms are examined.
886
NOTE: You cannot congure the next term acon with a
terminang
acon in the same lter
term. However, you can congure the next term acon with another
nonterminang
acon in
the same lter term.
On Junos OS and Junos OS Evolved, next term cannot appear as the last term of the acon. A
lter term where next term is specied as an acon but without any match condions congured
is not supported.
For MX Series routers with MPCs, you need to inialize the lter counter for Trio-only match
lters by walking the corresponding SNMP MIB, for example, show snmp mib walk
name
ascii. This
forces Junos to learn the lter counters and ensure that the lter stascs are displayed. This
guidance applies to all enhanced mode rewall lters, lters with exible condions, and lters
with the certain terminang acons. See those topics, listed under Related Documentaon, for
details.
Table 39 on page 887 describes the terminang acons you can specify in a rewall lter term.
Table 39: Terminang Acons for Firewall Filters
Terminang
Acon Descripon Protocols
accept Accept the packet.
• family any
• family inet
• family inet6
• family mpls
• family vpls
•
family ccc
•
family bridge
•
family ethernet-switching (for EX Series switches only)
887
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
decapsulate gre
[ routing-
instance
instance-name
]
At a customer-
facing interface on
an MX Series router
installed at the
provider edge (PE)
of an IPv4 transport
network, enable de-
encapsulaon of
generic roung
encapsulaon (GRE)
packets transported
through a lter-
based GRE tunnel.
You can congure a
lter term that pairs
this acon with a
match condion that
includes a packet
header match for
the GRE protocol.
For an IPv4 lter,
include the
protocol gre (or
protocol 47) match
condion. Aach
the lter to the
input of an Ethernet
logical interface or
aggregated Ethernet
interface on a
Modular Interface
Card (MIC) or
Modular Port
Concentrator (MPC)
in the router. If you
commit a
conguraon that
aaches a de-
encapsulang lter
•
family inet
888
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
to an interface that
does not support
lter-based GRE
tunneling, the
system writes a
syslog warning
message that the
interface does not
support the lter.
When the interface
receives a matched
packet, processes
that run on the
Packet Forwarding
Engine perform the
following
operaons:
• Remove the
outer GRE
header.
• Forward the
inner payload
packet to its
original
desnaon by
performing
desnaon
lookup.
By default, the
Packet Forwarding
Engine uses the
default roung
instance to forward
payload packets to
the desnaon
network. If the
payload is MPLS, the
Packet Forwarding
889
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
Engine performs
route lookup on the
MPLS path roung
table using the route
label in the MPLS
header.
If you specify the
decapsulate acon
with an oponal
roung instance
name, the Packet
Forwarding Engine
performs route
lookup on the
roung instance,
and the instance
must be congured.
NOTE: On MX960
routers, the
decapsulate acon
de-encapsulates
GRE, IP-in-IP and
IPv6-in-IP tunneling
packets. You
congure this acon
at the [edit firewall
family inet filter
filter-name
term
term-name
] hierarchy
level .
For more
informaon, see
"Understanding
Filter-Based
Tunneling Across
IPv4 Networks" on
page 1398 and
"Components of
890
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
Filter-Based
Tunneling Across
IPv4 Networks" on
page 1407.
891
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
decapsulate l2tp
[ routing-
instance
instance-name
]
[ forwarding-
class
class-
name
] [ output-
interface
interface-name
]
[ cookie
l2tpv3-
cookie
]
[ sample ]
At a customer-
facing interface on
an MX Series router
installed at the
provider edge (PE)
of an IPv4 transport
network, enable de-
encapsulaon of
Layer 2 tunneling
protocol (L2TP)
packets transported
through a lter-
based L2TP tunnel.
You can congure a
lter term that pairs
this acon with a
match condion that
includes a packet
header match for
the L2TP protocol.
For IPv4 trac, an
input rewall lter
$junos-input-filter
and an output
rewall lter $junos-
output-filter are
aached to the
interface. Aach the
lter to the input of
an Ethernet logical
interface or
aggregated Ethernet
interface on a
Modular Interface
Card (MIC) or
Modular Port
Concentrator (MPC)
in the router. If you
commit a
family inet
892
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
conguraon that
aaches a de-
encapsulang lter
to an interface that
does not support
lter-based L2TP
tunneling, the
system writes a
syslog warning
message that the
interface does not
support the lter.
The remote tunnel
endpoint sends an
IP tunnel packet that
contains an Ethernet
MAC address in the
payload. If the
desnaon MAC
address of the
payload packet
contains the MAC
address of the
router, the Ethernet
packet is sent in the
outgoing direcon
towards the
network, and it is
processed and
forwarded as though
it is received on the
customer port. If the
source MAC address
of the payload
packet contains the
MAC address of the
router, the Ethernet
packet is transmied
in the outgoing
direcon towards
893
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
the customer port. If
the tunnel does not
contain the receive-
cookie congured,
packet injecon
does not happen. In
such a case, any
received tunnel
packet is counted
and dropped in the
same manner in
which packets that
arrive with a wrong
cookie are counted
and dropped.
The following
parameters can be
specied with the
decapsulate l2tp
acon:
• routing-instance
instance-name
—
By default, the
Packet
Forwarding
Engine uses the
default roung
instance to
forward payload
packets to the
desnaon
network. If the
payload is MPLS,
the Packet
Forwarding
Engine performs
route lookup on
the MPLS path
894
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
roung table
using the route
label in the
MPLS header. If
you specify the
decapsulate
acon with an
oponal roung
instance name,
the Packet
Forwarding
Engine performs
route lookup on
the roung
instance, and the
instance must be
congured.
•
forwarding-class
class-name
—
(Oponal)
Classify l2TP
packets to the
specied
forwarding class.
• output-interface
interface-name
—
(Oponal) For
L2TP tunnels,
enable the
packet to be
duplicated and
sent towards the
customer or the
network (based
on the MAC
address in the
Ethernet
payload).
895
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
• cookie
l2tpv3-
cookie
—
(Oponal) For
L2TP tunnels,
specify the L2TP
cookie for the
duplicated
packets. If the
tunnel does not
contain the
receive-cookie
congured,
packet injecon
does not
happen. In such
a case, any
received tunnel
packet is
counted and
dropped in the
same manner in
which packets
that arrive with a
wrong cookie are
counted and
dropped.
• sample—
(Oponal)
Sample the
packet. Junos OS
does not sample
packets
originang from
the router. If you
congure a lter
and apply it to
the output side
of an interface,
896
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
then only the
transit packets
going through
that interface are
sampled. Packets
that are sent
from the Roung
Engine to the
Packet
Forwarding
Engine are not
sampled.
NOTE: The
decapsulate l2tp
acon that you
congure at the
[edit firewall
family inet filter
filter-name
term
term-name
] hierarchy
level does not
process trac with
IPv4 and IPv6
opons. As a result,
trac with such
opons is discarded
by the de-
encapsulaon of
L2TP packets
funconality.
897
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
discard
Discard a packet
silently, without
sending an Internet
Control Message
Protocol (ICMP)
message. Discarded
packets are available
for logging and
sampling.
• family any
• family inet
• family inet6
• family mpls
• family vpls
• family ccc
• family bridge
• family ethernet-switching (for EX Series switches only)
898
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
encapsulate
template-name
At a customer-
facing interface on
an MX Series router
installed at the
provider edge (PE)
of an IPv4 transport
network, enable
lter-based generic
roung
encapsulaon (GRE)
tunneling using the
specied tunnel
template.
You can congure a
lter term that pairs
this acon with the
appropriate match
condions, and then
aach the lter to
the input of an
Ethernet logical
interface or
aggregated Ethernet
interface on a
Modular Interface
Card (MIC) or
Modular Port
Concentrator (MPC)
in the router. If you
commit a
conguraon that
aaches an
encapsulang lter
to an interface that
does not support
lter-based GRE
tunneling, the
system writes a
syslog warning
•
family inet
• family inet6
• family any
• family mpls
899
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
message that the
interface does not
support the lter.
When the interface
receives a matched
packet, processes
that run on the
Packet Forwarding
Engine use
informaon in the
specied tunnel
template to perform
the following
operaons:
1. Aach a GRE
header (with or
without a tunnel
key value, as
specied in the
tunnel template.
2. Aach a header
for the IPv4
transport
protocol.
3. Forward the
resulng GRE
packet from the
tunnel source
interface to the
tunnel
desnaon (the
remote PE
router).
The specied tunnel
template must be
congured using the
tunnel-end-point
900
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
statement under the
[edit firewall] or
[edit logical-
systems
logical-
system-name
firewall] hierarchy
level. For more
informaon, see
"Understanding
Filter-Based
Tunneling Across
IPv4 Networks" on
page 1398.
901
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
encapsulate
template-name
(for L2TP
tunnels)
At a customer-
facing interface on
an MX Series router
installed at the
provider edge (PE)
of an IPv4 transport
network, enable
lter-based L2TP
tunneling using the
specied tunnel
template. You can
congure a lter
term that pairs this
acon with the
appropriate match
condions, and then
aach the lter to
the input of an
Ethernet logical
interface or
aggregated Ethernet
interface on a
Modular Interface
Card (MIC) or
Modular Port
Concentrator (MPC)
in the router. If you
commit a
conguraon that
aaches an
encapsulang lter
to an interface that
does not support
lter-based GRE
tunneling, the
system writes a
syslog warning
message that the
interface does not
support the lter.
•
family inet
902
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
When the interface
receives a matched
packet, processes
that run on the
Packet Forwarding
Engine use
informaon in the
specied tunnel
template to perform
the following
operaons:
1. Aach an L2TP
header (with or
without a tunnel
key value, as
specied in the
tunnel template).
2. Aach a header
for the IPv4
transport
protocol.
3. Forward the
resulng L2TP
packet from the
tunnel source
interface to the
tunnel
desnaon (the
remote PE
router). The
specied tunnel
template must be
congured using
the tunnel-end-
point statement
under the [edit
firewall]
or
[edit
903
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
logical-systems
logical-system-
name
firewall]
statement
hierarchy.
904
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
exclude-
accounting
Exclude the packet
from being included
in accurate
accounng stascs
for tunneled
subscribers on an
L2TP LAC. Typically
used in lters that
match DHCPv6 or
ICMPv6 control
trac Failure to
exclude these
packets results in
the idle-meout
detecon
mechanism
considering these
packets as data
trac, causing the
meout to never
expire. (The idle
meout is
congured with the
client-idle-timeout
and client-idle-
timeout-ingress-only
statements in the
access prole
session opons.)
The term excludes
packets from being
included in counts
for both family
accurate accounng
and service accurate
accounng. The
packets are sll
included in the
session interface
stascs.
•
family inet
• family inet6
905
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
The term is available
for both inet and
inet6 families, but is
used only for inet6.
logical-system
logical-system-
name
Direct the packet to
the specied logical
system.
NOTE: This acon is
not supported on
PTX Series Packet
Transport Routers.
• family inet
• family inet6
906
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
reject
message-
type
Reject the packet
and return an
ICMPv4 or ICMPv6
message:
• If no
message-
type
is specied,
a destination
unreachable
message is
returned by
default.
• If tcp-reset is
specied as the
message-type
,
tcp-reset is
returned only if
the packet is a
TCP packet.
Otherwise, the
administratively-
prohibited
message, which
has a value
of 13, is
returned.
• If any other
message-type
is
specied, that
message is
returned.
NOTE: Rejected
packets can be
sampled or logged if
you congure the
sample or syslog
acon. For MX2K-
•
family inet
• family inet6
907
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
MPC11E, ICMP
reject messages
traverse egress
lters, policers, and
class of service (CoS)
conguraons and
so are included in
those stascs. The
same is true for
destination
unreachable
messages.
The
message-type
can
be one of the
following values:
address-unreachable,
administratively-
prohibited, bad-host-
tos, bad-network-tos,
beyond-scope,
fragmentation-needed,
host-prohibited,
host-unknown, host-
unreachable, network-
prohibited, network-
unknown, network-
unreachable, no-
route, port-
unreachable,
precedence-cutoff,
precedence-violation,
protocol-unreachable,
source-host-isolated,
source-route-failed,
or tcp-reset.
On PTX1000
routers, the reject
908
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
acon is supported
on ingress interfaces
only.
routing-instance
instance-name
Direct the packet to
the specied roung
instance.
• family inet
• family inet6
909
Table 39: Terminang Acons for Firewall Filters
(Connued)
Terminang
Acon Descripon Protocols
topology
topology-name
Direct the packet to
the specied
topology.
NOTE: This acon is
not supported on
PTX Series Packet
Transport Routers.
Each roung
instance (primary or
virtual-router)
supports one default
topology to which
all forwarding
classes are
forwarded. For
multopology
roung, you can
congure a rewall
lter on the ingress
interface to match a
specic forwarding
class, such as
expedited
forwarding, with a
specic topology.
The trac that
matches the
specied forwarding
class is then added
to the roung table
for that topology.
• family inet
• family inet6
NOTE: On QFX5120-48Y and QFX5120-32C switch models, congure discard acon explicitly to
bring down a BFD session. However, note that if there is a port-mirror acon congured before
the discard acon, then the BFD session will not be brought down.
910
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Nonterminang Acons | 873
Firewall Filter Match Condions for IPv4 Trac | 942
Firewall Filter Match Condions for IPv6 Trac | 959
enhanced-mode
Firewall Filter Flexible Match Condions | 864
Firewall Filter Terminang and Nonterminang Acons for Protocol-Independent Trac in Dynamic
Service Proles
Firewall Filter Match Condions and Acons (ACX Series Routers)
IN THIS SECTION
Overview of Firewall Filter Match Condions and Acons on ACX Series Routers | 912
Match Condions for Bridge Family Firewall Filters (ACX Series Routers) | 914
Match Condions for CCC Firewall Family Filters (ACX Series Routers) | 918
Match Condions for IPv4 Trac (ACX Series Routers) | 919
Match Condions for IPv6 Trac (ACX Series Routers) | 925
Match Condions for MPLS Trac (ACX Series Routers) | 932
Nonterminang Acons (ACX Series Routers) | 933
Terminang Acons (ACX Series Routers) | 937
On ACX Series Universal Metro Routers, you can congure rewall lters to lter packets and to
perform an acon on packets that match the lter. The match condions specied to lter the packets
are specic to the type of trac being ltered.
Firewall lters with IPv6 match condions not supported at the firewall family inet6 filter
name
hierarchy
level on ACX6360-OR routers in Junos OS Release 19.1R1.
NOTE: On ACX Series routers, the lter for the exing trac (egress lter) can be applied only
for interface-specic instances of the
rewall lter
.
911
On ACX Series routers, TCAM errors are seen when you modify a prex or a term on the applied
rewall lters. To modify a prex or a term in the rewall lter, you need to remove the exisng
rewall lter and then apply the modied lter.
NOTE: On ACX Series routers, you cannot apply a rewall lter in the egress direcon on IRB
interfaces.
Overview of Firewall Filter Match Condions and Acons on ACX Series Routers
Table 40 on page 912 describes the types of trac for which you can congure standard stateless
rewall lters.
Table 40: Standard Firewall Filter Match Condions by Protocol Family for ACX Series Routers
Trac Type Hierarchy Level at Which Match Condions Are Specied
Protocol-independent
[edit firewall family any filter
filter-name
term
term-
name
]
No match condions are supported for this trac type on
ACX Series routers.
IPv4
[edit firewall family inet filter
filter-name
term
term-
name
For the complete list of match condions, see "Match
Condions for IPv4 Trac (ACX Series Routers)" on page
919.
MPLS
[edit firewall family mpls filter
filter-name
term
term-
name
]
For the complete list of match condions, see "Match
Condions for MPLS Trac (ACX Series Routers)" on page
932.
912
Table 40: Standard Firewall Filter Match Condions by Protocol Family for ACX Series Routers
(Connued)
Trac Type Hierarchy Level at Which Match Condions Are Specied
Layer 2 CCC
[edit firewall family ccc filter
filter-name
term
term-
name
]
No match condions are supported for this trac type on
ACX Series routers.
Bridge
[edit firewall family bridge filter filter-name term term-
name]
[edit firewall family ethernet-switching filter filter-
name term term-name] (Applicable to ACX5048 and
ACX5096 routers only.)
On ACX5448 router, the following ingress family lters can be scaled based on the availability of
external-tcam:
• family ethernet-switching
• family ccc
• family inet
• family inet6
• family mpls
• family vpls
Under the then statement for a standard stateless rewall lter term, you can specify the acons to be
taken on a packet that matches the term.
Table 41 on page 914 summarizes the types of acons you can specify in a standard stateless rewall
lter term.
913
Table 41: Standard Firewall Filter Acon Categories for ACX Series Routers
Type of Acon Descripon Comment
Terminang Halts all evaluaon of a rewall lter for a
specic packet. The router performs the
specied acon, and no addional terms are
used to examine the packet.
You can specify only one
terminang acon
in a standard rewall lter. You can, however,
specify one terminang acon with one or
more
nonterminang acons
in a single term.
For example, within a term, you can specify
accept with count and syslog.
See "Terminang Acons (ACX
Series Routers)" on page 937.
Nonterminang Performs other funcons on a packet (such
as incriminang a counter, logging
informaon about the packet header,
sampling the packet data, or sending
informaon to a remote host using the
system log funconality), but any addional
terms are used to examine the packet.
See "Nonterminang Acons
(ACX Series Routers)" on page
933.
Match Condions for Bridge Family Firewall Filters (ACX Series Routers)
IN THIS SECTION
Bridge Family Firewall Filters on ACX Series Routers | 914
Bridge Family Firewall Filters on ACX Series Routers
Bridge family rewall lters can be congured at the IFL-family level on ACX series routers. Bridge
family lters are used to match the L2 bridge ows based on the supported Layer2/Layer3 elds and
take rewall acon. The maximum number of terms supported for bridge rewall lters on ACX Series
routers is 124.
914
NOTE: On ACX5448 and ACX7000 series routers, you need to apply the layer 2 rewall lters
only on the layer 2 switched packets, even if the bridge domain has IRB aached to the bridge
domain. If the packet is layer 3 forwarded, then layer 3 lters must be applied on the IRB.
NOTE: On ACX Series routers, you cannot apply a rewall lter in the egress direcon on IRB
interfaces.
Table 42 on page 915 shows the match condions supported for bridge family lters.
Table 42: Bridge Family Firewall Filter Match Condions for ACX Series Routers
Match Condion Descripon
apply-groups Set the groups from which to inherit conguraon data
apply-groups-except Set which groups will not broadcast conguraon data
desnaon-mac-address Set the desnaon MAC address
desnaon-port Match the TCP/UDP desnaon port
destination-prefix-list
Match IP desnaon prexes in named list.
dscp Match the Dierenated Services (DiServ) code point
ether-type Match the Ethernet type
icmp-code Match a ICMP message code
icmp-type Match a ICMP message type
interface-group Match an interface group
915
Table 42: Bridge Family Firewall Filter Match Condions for ACX Series Routers
(Connued)
Match Condion Descripon
ip-desnaon-address Match an IP desnaon address
ip-precedence Match an IP precedence value
ip-protocol Match an IP protocol type
ip-source-address Match an IP source address
learn-vlan-1p-priority Match the learned 802.1p VLAN Priority
learn-vlan-dei Match user VLAN ID DEI bit
learn-vlan-id Match a learnt VLAN ID
source-mac-address Set the source MAC address
source-prefix-list
Match IP source prexes in named list.
source-port Match a TCP/UDP source port
user-vlan-1p-priority Match user 802.1p VLAN Priority
user-vlan-id Match a user VLAN ID
vlan-ether-type Match a VLAN Ethernet type
Table 43 on page 917 shows the acon elds supported.
916
Table 43: Bridge Family Firewall Filter Acon Fields for ACX Series Routers
Acon Field Descripon
accept Accept the packet
count Count the packet in the named counter
discard Discard the packet
forwarding-class Classify packet to forwarding class
loss-priority Packet’s loss priority
log Log the packet header informaon in a buer within the
Packet Forwarding Engine. You can access this informaon
by issuing the show rewall log command at the command-
line interface (CLI).
policer Name of policer to use to rate-limit trac
syslog Log the packet to the system log le.
three-color-policer Police the packet using a three-colo-policer
NOTE: Bridge family rewall lters can be applied as an output lter on Layer 2 interfaces. When
the Layer 2 interface is on a bridge-domain congured with the vlan-id statement, ACX series
routers can match the outer-vlan of the packet using the user vlan-id match specied in the
bridge family rewall lter.
917
Match Condions for CCC Firewall Family Filters (ACX Series Routers)
IN THIS SECTION
Match Condions for CCC Family Firewall Filters | 918
Match Condions for CCC Family Firewall Filters
On ACX Series routers, you can congure a standard rewall lter with match condions for circuit
cross-connecon (CCC) trac (family ccc).
Table 44 on page 918 describes the match condions you can congure at the [edit firewall family ccc
filter
filter-name
term
term-name
] hierarchy level.
Table 44: CCC Family Firewall Filter Match Condions for ACX Series Routers
Field Descripon
destination-mac-address
Desnaon MAC address
destination-port
Matches TCP/UDP desnaon port
dscp
Matches dierenated services (DiServ) code point
icmp-code
Matches ICMP message code
icmp-type
Matches ICMP message type
ip-destination-address
Matches desnaon IP address
ip-precedence
Matches IP precedence value
ip-protocol
Matches IP protocol type
918
Table 44: CCC Family Firewall Filter Match Condions for ACX Series Routers
(Connued)
Field Descripon
ip-source-address
Matches source IP address
learn-vlan-1p-priority
Matches learned 802.1p VLAN priority
source-mac-address
Source MAC address
source-port
Matches TCP/UDP source port
user-vlan-1p-priority
Matches user 802.1p VLAN priority
Match Condions for IPv4 Trac (ACX Series Routers)
On ACX Series routers, you can congure a standard stateless rewall lter with match condions for IP
version 4 (IPv4) trac (family inet). Table 45 on page 919 describes the match condions you can
congure at the [edit firewall family inet filter
filter-name
term
term-name
from] hierarchy level.
Table 45: Firewall Filter Match
Condions for IPv4 Trac on ACX Series Routers
Match Condion Descripon
destination-address
address
Match the IPv4 desnaon address eld.
NOTE: On ACX Series routers, you can specify only one desnaon address. A list of
IPv4 desnaon addresses is not supported.
919
Table 45: Firewall Filter Match Condions for IPv4 Trac on ACX Series Routers
(Connued)
Match Condion Descripon
destination-port
number
Match the UDP or TCP desnaon port eld.
If you congure this match condion, we recommend that you also congure the
protocol udp or protocol tcp match statement in the same term to specify which
protocol is being used on the port.
In place of the numeric value, you can specify one of the following text synonyms (the
port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68), bootps (67),
cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106),
exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113),
imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760),
kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434), mobilip-mn (435),
msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049),
nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813),
radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444),
socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49), tacacs-ds (65), talk (517),
telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-prefix-list
Match IP desnaon prexes in named list.
920
Table 45: Firewall Filter Match Condions for IPv4 Trac on ACX Series Routers
(Connued)
Match Condion Descripon
dscp
number
Match the Dierenated Services code point (DSCP). The DiServ protocol uses the
type-of-service (ToS) byte in the IP header. The most signicant 6 bits of this byte
form the DSCP. For more informaon, see
Understanding How Behavior Aggregate
Classiers Priorize Trusted Trac
.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms (the
eld values are also listed):
•
RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
•
RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
• af11 (10), af12 (12), af13 (14)
• af21 (18), af22 (20), af23 (22)
• af31 (26), af32 (28), af33 (30)
• af41 (34), af42 (36), af43 (38)
fragment-flags
number
(Ingress only) Match the three-bit IP fragmentaon ags eld in the IP header.
In place of the numeric eld value, you can specify one of the following keywords (the
eld values are also listed): dont-fragment (0x4), more-fragments (0x2), or reserved (0x8).
921
Table 45: Firewall Filter Match Condions for IPv4 Trac on ACX Series Routers
(Connued)
Match Condion Descripon
icmp-code
number
Match the ICMP message code eld.
If you congure this match condion, we recommend that you also congure the
protocol icmp match condion in the same term.
If you congure this match condion, you must also congure the icmp-type
message-
type
match condion in the same term. An ICMP message code provides more specic
informaon than an ICMP message type, but the meaning of an ICMP message code
is dependent on the associated ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms (the
eld values are also listed). The keywords are grouped by the ICMP type with which
they are associated:
• parameter-problem: ip-header-bad (0), required-option-missing (1)
• redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-
host (3), redirect-for-tos-and-net (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• unreachable: communication-prohibited-by-filtering (13), destination-host-
prohibited (10), destination-host-unknown (7), destination-network-prohibited (9),
destination-network-unknown (6), fragmentation-needed (4), host-precedence-
violation (14), host-unreachable (1), host-unreachable-for-TOS (12), network-
unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-
cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-
route-failed (5)
icmp-type
number
Match the ICMP message type eld.
If you congure this match condion, we recommend that you also congure the
protocol icmp match condion in the same term.
In place of the numeric value, you can specify one of the following text synonyms (the
eld values are also listed): echo-reply (0), echo-request (8), info-reply (16), info-
request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5),
router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11),
timestamp (13), timestamp-reply (14), or unreachable (3).
922
Table 45: Firewall Filter Match Condions for IPv4 Trac on ACX Series Routers
(Connued)
Match Condion Descripon
ip-options
values
Match the 8-bit IP opon eld, if present, to the specied value.
ACX Series routers support only the ip-options_any match condion, which ensures
that the packets are sent to the Packet Forwarding Engine for processing.
NOTE: On ACX Series routers, you can specify only one IP opon value. Conguring
mulple values is not supported.
precedence
ip-
precedence-field
Match the IP precedence eld.
In place of the numeric eld value, you can specify one of the following text
synonyms (the eld values are also listed): critical-ecp (0xa0), flash (0x60), flash-
override (0x80), immediate (0x40), internet-control (0xc0), net-control (0xe0),
priority (0x20), or routine (0x00). You can specify precedence in hexadecimal, binary,
or decimal form.
protocol
number
Match the IP protocol type eld. In place of the numeric value, you can specify one of
the following text synonyms (the eld values are also listed): dstopts (60), egp (8),
esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2),
ipip (4), ipv6 (41), no-next-header, ospf (89), pim (103), routing, rsvp (46), sctp (132),
tcp (6), udp (17), or vrrp (112).
source-address
address
Match the IPv4 address of the source node sending the packet.
source-port
number
Match the UDP or TCP source port eld.
If you congure this match condion for IPv4 trac, we recommend that you also
congure the protocol udp or protocol tcp match statement in the same term to
specify which protocol is being used on the port.
In place of the numeric value, you can specify one of the text synonyms listed with
the destination-port
number
match condion.
source-prefix-list
Match IP source prexes in named list.
923
Table 45: Firewall Filter Match Condions for IPv4 Trac on ACX Series Routers
(Connued)
Match Condion Descripon
tcp-flags
value
Match one or more of the low-order 6 bits in the 8-bit TCP ags eld in the TCP
header.
To specify individual bit elds, you can specify the following text synonyms or
hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag
is set in all packets sent aer the inial packet.
You can string together mulple ags using the bit-eld logical operators.
For combined bit-eld match condions, see the tcp-initial match condions.
If you congure this match condion, we recommend that you also congure the
protocol tcp match statement in the same term to specify that the TCP protocol is
being used on the port.
tcp-initial Match the inial packet of a TCP connecon. This is an alias for tcp-flags "(!ack &
syn)".
This condion does not implicitly check that the protocol is TCP. If you congure this
match condion, we recommend that you also congure the protocol tcp match
condion in the same term.
ttl
number
Match the IPv4 me-to-live number. Specify a TTL value or a range of TTL values. For
number
, you can specify one or more values from 2 through 255.
924
Match Condions for IPv6 Trac (ACX Series Routers)
You can congure a rewall lter with match condions for Internet Protocol version 6 (IPv6) trac
(family inet6). Table 46 on page 925 describes the match condions you can congure at the [edit
firewall family inet6 filter
filter-name
term
term-name
from] hierarchy level.
Table 46: Firewall Filter Match Condions for IPv6 Trac
Match Condion Descripon
destination-address
address
Match the IPv6 desnaon address eld.
destination-port
number
Match the UDP or TCP desnaon port eld.
You cannot specify both the port and destination-port match condions in the same
term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
In place of the numeric value, you can specify one of the following text synonyms
(the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515),
radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161),
snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-prefix-list
Match IP desnaon prexes in named list.
925
Table 46: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
extension-headers
header-type
Match an extension header type that is contained in the packet by idenfying a Next
Header value.
In the rst fragment of a packet, the lter searches for a match in any of the
extension header types. When a packet with a fragment header is found (a
subsequent fragment), the lter only searches for a match of the next extension
header type because the locaon of other extension headers is unpredictable.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): ah (51), destination (60), esp (50), fragment (44), hop-by-
hop (0), mobility (135), or routing (43).
To match
any
value for the extension header opon, use the text synonym any.
NOTE: Only the rst extension header of the IPv6 packet can be matched. L4 header
beyond one IPv6 extension header will be matched.
hop-limit
hop-limit
Match the hop limit to the specied hop limit or set of hop limits. For
hop-limit
,
specify a single value or a range of values from 0 through 255.
926
Table 46: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
icmp-code
message-code
Match the ICMP message code eld.
If you congure this match condion, we recommend that you also congure the
next-header icmp or next-header icmp6 match condion in the same term.
If you congure this match condion, you must also congure the icmp-type
message-
type
match condion in the same term. An ICMP message code provides more
specic informaon than an ICMP message type, but the meaning of an ICMP
message code is dependent on the associated ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed). The keywords are grouped by the ICMP type with
which they are associated:
• parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-
option (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• desnaon-unreachable: administratively-prohibited (1), address-unreachable (3),
no-route-to-destination (0), port-unreachable (4)
927
Table 46: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
icmp-type
message-type
Match the ICMP message type eld.
If you congure this match condion, we recommend that you also congure the
next-header icmp or next-header icmp6 match condion in the same term.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): certificate-path-advertisement (149), certificate-
path-solicitation (148), destination-unreachable (1), echo-reply (129), echo-
request (128), home-agent-address-discovery-reply (145), home-agent-address-discovery-
request (144), inverse-neighbor-discovery-advertisement (142), inverse-neighbor-
discovery-solicitation (141), membership-query (130), membership-report (131),
membership-termination (132), mobile-prefix-advertisement-reply (147), mobile-prefix-
solicitation (146), neighbor-advertisement (136), neighbor-solicit (135), node-
information-reply (140), node-information-request (139), packet-too-big (2), parameter-
problem (4), private-experimentation-100 (100), private-experimentation-101 (101),
private-experimentation-200 (200), private-experimentation-201 (201), redirect (137),
router-advertisement (134), router-renumbering (138), router-solicit (133), or time-
exceeded (3).
For private-experimentation-201 (201), you can also specify a range of values within
square brackets.
928
Table 46: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
next-header
header-type
Match the rst 8-bit Next Header eld in the packet. Support for the next-header
rewall match condion is available in Junos OS Release 13.3R6 and later.
For IPv6, we recommend that you use the payload-protocol term rather than the next-
header term when conguring a rewall lter with match condions. Although either
can be used, payload-protocol provides the more reliable match condion because it
uses the actual payload protocol to nd a match, whereas next-header simply takes
whatever appears in the rst header following the IPv6 header, which may or may
not be the actual protocol. In addion, if next-header is used with IPv6, the
accelerated lter block lookup process is bypassed and the standard lter used
instead.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): ah (51), dstops (60), egp (8), esp (50), fragment (44),
gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41),
mobility (135), no-next-header (59), ospf (89), pim (103), routing (43), rsvp (46),
sctp (132), tcp (6), udp (17), or vrrp (112).
NOTE: next-header icmp6 and next-header icmpv6 match condions perform the same
funcon. next-header icmp6 is the preferred opon. next-header icmpv6 is hidden in the
Junos OS CLI.
source-address
address
Match the IPv6 address of the source node sending the packet.
source-port
number
Match the UDP or TCP source port eld.
You cannot specify the port and source-port match condions in the same term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
In place of the numeric value, you can specify one of the text synonyms listed with
the destination-port
number
match condion.
source-prefix-list
Match IP source prexes in named list.
929
Table 46: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
tcp-flags
flags
Match one or more of the low-order 6 bits in the 8-bit TCP ags eld in the TCP
header.
To specify individual bit elds, you can specify the following text synonyms or
hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag
is set in all packets sent aer the inial packet.
You can string together mulple ags using the bit-eld logical operators.
For combined bit-eld match condions, see the tcp-established and tcp-initial
match condions.
If you congure this match condion, we recommend that you also congure the
next-header tcp match condion in the same term to specify that the TCP protocol is
being used on the port.
tcp-initial Match the inial packet of a TCP connecon. This is a text synonym for tcp-flags "(!
ack & syn)".
This condion does not implicitly check that the protocol is TCP. If you congure this
match condion, we recommend that you also congure the next-header tcp match
condion in the same term.
930
Table 46: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
traffic-class
number
Match the 8-bit eld that species the class-of-service (CoS) priority of the packet.
This eld was previously used as the type-of-service (ToS) eld in IPv4.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed):
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
•
RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
• af11 (10), af12 (12), af13 (14)
• af21 (18), af22 (20), af23 (22)
• af31 (26), af32 (28), af33 (30)
• af41 (34), af42 (36), af43 (38)
NOTE: If you specify an IPv6 address in a match condion (the address, destination-address, or
source-address match condions), use the syntax for text representaons described in RFC 4291,
IP Version 6 Addressing Architecture
. For more informaon about IPv6 addresses, see IPv6
Overview and Supported IPv6 Standards.
The following is a sample rewall family inet6 conguraon:
user@host# show firewall family inet6
filter ipv6-filter {
term t1 {
from {
source-address {
2001:0000:0020:0020:0000:0000:0000:0150/128;
931
}
destination-address {
2001:0000:0040:0040:0000:0000:0000:0150/128;
}
next-header tcp;
source-port 1000;
destination-port 2000;
extension-header dstopts;
traffic-class ef;
tcp-flags 0x20;
hop-limit 254;
}
then count ipv6-t1-count;
}
term t2 {
from {
icmp-type neighbor-solicit;
}
then count ipv6-t2-count;
}
}
Match Condions for MPLS Trac (ACX Series Routers)
On ACX Series routers, you can congure a standard stateless rewall lter with match condions for
MPLS trac (family mpls).
NOTE: The input-list
filter-names
and output-list
filter-names
statements for rewall lters for the
mpls protocol family are supported on all interfaces with the excepon of management interfaces
and internal Ethernet interfaces (fxp or em0), loopback interfaces (lo0), and USB modem interfaces
(umd).
Table 47 on page 933 describes the match condions you can congure at the [edit firewall family mpls
filter
filter-name
term
term-name
from] hierarchy level.
932
Table 47: Standard Firewall Filter Match Condions for MPLS Trac on ACX Series Routers
Match Condion Descripon
exp
number
Experimental (EXP) bit number or range of bit numbers in the MPLS header. For
number
, you can specify one or more values from 0 through 7 in decimal, binary, or
hexadecimal format.
Nonterminang Acons (ACX Series Routers)
Standard stateless rewall lters support dierent sets of nonterminang acons for each protocol
family.
NOTE: ACX Series routers do not support the next term acon.
ACX Series routers support log and syslog acons in ingress and egress direcons for family inet
and family bridge.
ACX5448, ACX710 and ACX7100 series routers do not support log, syslog, reject, forwarding-
class, and loss-priority in the egress direcon. In the ingress and egress direcon, the routers
support interface specic semancs only.
Table 48 on page 933 describes the nonterminang acons you can congure for a standard rewall
lter term.
Table 48:
Nonterminang Acons for Standard Firewall Filters on ACX Series Routers
Nonterminang Acon Descripon Protocol Families
count
counter-name
Count the packet in the
named counter.
• family any
• family inet
•
• family mpls
• family ccc
• family bridge
• family vpls
933
Table 48: Nonterminang Acons for Standard Firewall Filters on ACX Series Routers
(Connued)
Nonterminang Acon Descripon Protocol Families
forwarding-class
class-name
Classify the packet based on
the specied forwarding class:
• assured-forwarding
• best-effort
• expedited-forwarding
• network-control
NOTE: This acon is
supported on ingress only.
• family inet
• family inet6
•
• family mpls
• family ccc
• family bridge
• family vpls
log
Log the packet header
informaon in a buer within
the Packet Forwarding Engine.
You can access this
informaon by issuing the
show firewall log command at
the command-line interface
(CLI).
NOTE: This acon is
supported on ingress and
egress. The acon on egress is
not supported for family
inet6.
• family inet
• family inet6
• family bridge
934
Table 48: Nonterminang Acons for Standard Firewall Filters on ACX Series Routers
(Connued)
Nonterminang Acon Descripon Protocol Families
loss-priority (high | medium-high |
low)
Set the packet loss priority
(PLP) level.
You cannot also congure the
three-color-policer
nonterminang acon for the
same rewall lter term.
These two nonterminang
acons are mutually exclusive.
You must include the tri-
color statement at the [edit
class-of-service] hierarchy
level to commit a PLP
conguraon with any of the
four levels specied. If the
tri-color statement is not
enabled, you can congure
only the high and low levels.
This applies to all protocol
families.
For informaon about the
tri-color statement, see
Conguring and Applying
Tricolor Marking Policers
. For
informaon about using
behavior aggregate (BA)
classiers to set the PLP level
of incoming packets, see
Understanding How
Forwarding Classes Assign
Classes to Output Queues
.
NOTE: This acon is
supported on ingress only.
• family any
• family inet
• family inet6
• family mpls
• family ccc
• family bridge
• family vpls
935
Table 48: Nonterminang Acons for Standard Firewall Filters on ACX Series Routers
(Connued)
Nonterminang Acon Descripon Protocol Families
policer
policer-name
Name of policer to use to
rate-limit trac.
• family any
• family inet
• family inet6
• family mpls
• family ccc
• family bridge
• family vpls
port-mirror
Port-mirror the packet based
on the specied family.
NOTE: This acon is
supported on ingress only.
ACX5048 and ACX5096
routers do not support port-
mirror.
family inet
syslog
Log the packet to the system
log le.
NOTE: This acon is
supported on ingress and
egress. The acon on egress is
not supported for family
inet6.
• family inet
• family inet6
• family bridge
936
Table 48: Nonterminang Acons for Standard Firewall Filters on ACX Series Routers
(Connued)
Nonterminang Acon Descripon Protocol Families
three-color-policer (single-rate | two-
rate)
policer-name
Police the packet using the
specied single-rate or two-
rate three-color policer.
You cannot also congure the
loss-priority acon for the
same rewall lter term.
These two acons are
mutually exclusive.
• family any
• family inet
• family inet6
• family mpls
• family ccc
• family bridge
• family vpls
trac-class Set trac-class code point
NOTE: This acon is
supported on ingress only.
family inet6
Terminang Acons (ACX Series Routers)
Standard stateless rewall lters support dierent sets of terminang acons for each protocol family.
NOTE: ACX Series routers do not support the next term acon.
Table 49 on page 938 describes the terminang acons you can specify in a standard rewall lter
term.
937
Table 49: Terminang Acons for Standard Firewall Filters on ACX Series Routers
Terminang
Acon Descripon Protocols
accept
Accept the packet.
• family any
• family
inet
• family
mpls
• family ccc
discard
Discard a packet silently, without sending an Internet Control Message
Protocol (ICMP) message. Discarded packets are available for logging and
sampling.
• family any
• family
inet
• family
mpls
• family ccc
938
Table 49: Terminang Acons for Standard Firewall Filters on ACX Series Routers
(Connued)
Terminang
Acon Descripon Protocols
reject
message-
type
Reject the packet and return an ICMPv4 or ICMPv6 message:
• If no message type is specied, a destination-unreachable message is
returned by default.
• If tcp-reset is specied as the message type, tcp-reset is returned only if
the packet is a TCP packet. Otherwise, the administratively-prohibited
message, which has a value of 13, is returned.
• If any other message type is specied, that message is returned.
NOTE:
• Rejected packets can be sampled or logged if you congure the sample or
syslog acon.
• This acon is supported on ingress only.
The
message-type
opon can have one of the following values: address-
unreachable, administratively-prohibited, bad-host-tos, bad-network-tos,
beyond-scope, fragmentation-needed, host-prohibited, host-unknown, host-
unreachable, network-prohibited, network-unknown, network-unreachable, no-route,
port-unreachable, precedence-cutoff, precedence-violation, protocol-
unreachable, source-host-isolated, source-route-failed, or tcp-reset.
family inet
routing-instance
routing-instance-
name
Direct the packet to the specied roung instance.
• family ine
t
Firewall Filter Match Condions for Protocol-Independent Trac
You can congure a rewall lter with match condions for protocol-independent trac (family any).
To apply a protocol-independent rewall lter to a logical interface, congure the filter statement under
the logical unit.
939
NOTE: On MX Series routers, aach a protocol-independent rewall lter to a logical interface
by conguring the filter statement
directly
under the logical unit:
• [edit interfaces
name
unit
number
filter]
• [edit logical-systems
name
interfaces
name
unit
number
filter]
On all other supported devices, aach a protocol-independent rewall lter to a logical interface
by conguring the filter statement under the protocol family (family any):
• [edit interfaces
name
unit
number
family any filter]
• [edit logical-systems
name
interfaces
name
unit
number
family any filter]
Table 50 on page 940 describes the
match-conditions
you can congure at the [edit firewall family any
filter
filter-name
term
term-name
from] hierarchy level.
Table 50: Firewall Filter Match Condions for Protocol-Independent Trac
Match Condion Descripon
forwarding-class
class
Match the forwarding class of the packet.
Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.
For informaon about forwarding classes and router-internal output queues, see
Understanding How Forwarding Classes Assign Classes to Output Queues
.
NOTE: On T4000 Type 5 FPCs, a lter aached at the Layer 2 applicaon point (that
is, at the logical interface level) is unable to match with the forwarding class of a
packet that is set by a Layer 3 classier such as DSCP, DSCP V6, inet-precedence, and
mpls-exp.
forwarding-class-except
class
Do not match on the forwarding class. For details, see the forwarding-class match
condion.
interface
interface-name
Match the interface on which the packet was received.
NOTE: If you congure this match condion with an interface that does not exist, the
term does not match any packet.
940
Table 50: Firewall Filter Match Condions for Protocol-Independent Trac
(Connued)
Match Condion Descripon
interface-set
interface-
set-name
Match the interface on which the packet was received to the specied interface set.
To dene an interface set, include the interface-set statement at the [edit firewall]
hierarchy level. For more informaon, see "Filtering Packets Received on an Interface
Set Overview" on page 1378.
loss-priority
level
Match the packet loss priority (PLP) level.
Specify a single level or mulple levels: low, medium-low, medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced
CFEB (CFEB-E); and MX Series routers.
For IP trac on M320, MX Series, and T Series routers with Enhanced II Flexible PIC
Concentrators (FPCs), you must include the tri-color statement at the [edit class-
of-service] hierarchy level to commit a PLP conguraon with any of the four levels
specied. If the tri-color statement is not enabled, you can only congure the high
and low levels. This applies to all protocol families.
NOTE: This match condion is not supported on PTX series packet transport routers.
For informaon about the tri-color statement, see
Conguring and Applying Tricolor
Marking Policers
. For informaon about using behavior aggregate (BA) classiers to
set the PLP level of incoming packets, see
Understanding How Forwarding Classes
Assign Classes to Output Queues
.
loss-priority-except
level
Do not match the PLP level. For details, see the loss-priority match condion.
NOTE: This match condion is not supported on PTX series packet transport routers.
packet-length
bytes
Match the length of the received packet, in bytes. The length refers only to the IP
packet, including the packet header, and does not include any Layer 2 encapsulaon
overhead. You can also specify a range of values to be matched.
packet-length-except
bytes
Do not match on the received packet length, in bytes. For details, see the packet-
length match type.
941
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
Firewall Filter Nonterminang Acons | 873
Firewall Filter Match Condions for IPv4 Trac
You can congure a rewall lter with match condions for Internet Protocol version 4 (IPv4) trac
(family inet).
NOTE: For MX Series routers with MPCs, you need to inialize the lter counter for Trio-only
match lters in the MIB by walking the corresponding SNMP MIB, for example, show snmp mib walk
name
ascii. This forces Junos to learn the lter counters, and ensures that the lter stascs are
displayed (this is because the rst poll to lter stascs may not show all counters). This
guidance applies to all enhanced mode rewall lters, lters with exible condions, and lters
with certain terminang acons. See those topics, listed under Related Documentaon, for
details.
Table 51 on page 942 describes the
match-conditions
you can congure at the [edit firewall family inet
filter
filter-name
term
term-name
from] hierarchy level.
Table 51: Firewall Filter Match
Condions for IPv4 Trac
Match Condion Descripon
address
address
[ except ]
Match the IPv4 source or desnaon address eld unless the except opon is
included. If the opon is included, do not match the IPv4 source or desnaon
address eld.
The except modier is not supported on EX2300 and EX3400 plaorms.
ah-spi
spi-value
(M Series routers, except M120 and M320) Match the IPsec authencaon header
(AH) security parameter index (SPI) value.
NOTE: This match condion is not supported on PTX series routers.
942
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
ah-spi-except
spi-value
(M Series routers, except M120 and M320) Do not match the IPsec AH SPI value.
NOTE: This match condion is not supported on PTX series routers.
apply-groups
Specify which groups to inherit conguraon data from. You can specify more than
one group name. You must list them in order of inheritance priority. The
conguraon data in the rst group takes priority over the data in subsequent
groups.
apply-groups-except
Specify which groups not to inherit conguraon data from. You can specify more
than one group name.
destination-address
address
[ except ]
Match the IPv4 desnaon address eld unless the except opon is included. If the
opon is included, do not match the IPv4 desnaon address eld.
You cannot specify both the address and destination-address match condions in the
same term.
destination-class
class-
names
Match one or more specied desnaon class names (sets of desnaon prexes
grouped together and given a class name). For more informaon, see "Firewall Filter
Match Condions Based on Address Classes" on page 996.
destination-class-except
class-names
Do not match one or more specied desnaon class names. For details, see the
destination-class match condion.
943
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
destination-port
number
Match the UDP or TCP desnaon port eld.
You cannot specify both the port and destination-port match condions in the same
term.
When conguring port based matches you must also congure the protocol udp or
protocol tcp match statement in the same lter term. Matching only on the port
value can result in unexpected matches.
In place of the numeric value, you can specify one of the following text synonyms
(the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515),
radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161),
snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except
number
Do not match the UDP or TCP desnaon port eld. For details, see the destination-
port match condion.
destination-prefix-list
name
[ except ]
Match desnaon prexes in the specied list unless the except opon is included. If
the opon is included, do not match the desnaon prexes in the specied list.
Specify the name of a prex list dened at the [edit policy-options prefix-list
prefix-list-name
] hierarchy level.
944
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
dscp
number
Match the Dierenated Services code point (DSCP). The DiServ protocol uses the
type-of-service (ToS) byte in the IP header. The most signicant 6 bits of this byte
form the DSCP. For more informaon, see
Understanding How Behavior Aggregate
Classiers Priorize Trusted Trac
.
Support was added for ltering on Dierenated Services Code Point (DSCP) and
forwarding class for Roung Engine sourced packets, including IS-IS packets
encapsulated in generic roung encapsulaon (GRE). Subsequently, when upgrading
from a previous version of Junos OS where you have both a class of service (CoS) and
rewall lter, and both include DSCP or forwarding class lter acons, the criteria in
the rewall lter automacally takes precedence over the CoS sengs. The same is
true when creang new conguraons; that is, where the same sengs exist, the
rewall lter takes precedence over the CoS, regardless of which was created rst.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed):
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
• RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
• af11 (10), af12 (12), af13 (14)
• af21 (18), af22 (20), af23 (22)
• af31 (26), af32 (28), af33 (30)
• af41 (34), af42 (36), af43 (38)
dscp-except
number
Do not match on the DSCP number. For more informaon, see the dscp match
condion.
945
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
esp-spi
spi-value
Match the IPsec encapsulang security payload (ESP) SPI value. Match on this
specic SPI value. You can specify the ESP SPI value in hexadecimal, binary, or
decimal form.
NOTE: This match condion is not supported on PTX series routers.
esp-spi-except
spi-value
Match the IPsec ESP SPI value. Do not match on this specic SPI value.
NOTE: This match condion is not supported on PTX series routers.
first-fragment
Match if the packet is the rst fragment of a fragmented packet. Do not match if the
packet is a trailing fragment of a fragmented packet. The rst fragment of a
fragmented packet has a fragment oset value of 0.
This match condion is an alias for the bit-eld match condion fragment-offset 0
match condion.
To match both rst and trailing fragments, you can use two terms that specify
dierent match condions: first-fragment and is-fragment.
flexible-match-mask
value
bit-length
Length of the data to be matched in bits,
not needed for string input (0..128)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-mask-name
Select a exible match from predened
template eld
mask-in-hex
Mask out bits in the packet data to be
matched
match-start
Start point to match in packet
946
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
prefix
Value data/string to be matched
flexible-match-range
value
bit-length
Length of the data to be matched in bits
(0..32)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-range-name
Select a exible match from predened
template eld
match-start
Start point to match in packet
range
Range of values to be matched
range-except
Do not match this range of values
forwarding-class
class
Match the forwarding class of the packet.
Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.
For informaon about forwarding classes and router-internal output queues, see
Understanding How Forwarding Classes Assign Classes to Output Queues
.
forwarding-class-except
class
Do not match the forwarding class of the packet. For details, see the forwarding-class
match condion.
947
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
fragment-flags
number
(Ingress only) Match the three-bit IP fragmentaon ags eld in the IP header.
In place of the numeric eld value, you can specify one of the following keywords
(the eld values are also listed): dont-fragment (0x4), more-fragments (0x2), or
reserved (0x8).
fragment-offset
value
Match the 13-bit fragment oset eld in the IP header. The value is the oset, in 8-
byte units, in the overall datagram message to the data fragment. Specify a numeric
value, a range of values, or a set of values. An oset value of 0 indicates the rst
fragment of a fragmented packet.
The first-fragment match condion is an alias for the fragment-offset 0 match
condion.
To match both rst and trailing fragments, you can use two terms that specify
dierent match condions (first-fragment and is-fragment).
fragment-offset-except
number
Do not match the 13-bit fragment oset eld.
gre-key
range
Match the gre-key eld. The GRE key eld is a 4 octet number inserted by the GRE
encapsulator. It is an oponal eld for use in GRE encapsulaon. The
range
can be a
single GRE key number or a range of key numbers.
For MX Series routers with MPCs, inialize new rewall lters that include this
condion by walking the corresponding SNMP MIB.
948
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
icmp-code
number
Match the ICMP message code eld.
NOTE: When using this match condion, you should also use the protocol icmp
match condion in the same term (as shown below) to ensure that icmp packets are
being evaluated.
term Allow _ICMP {
from protocol icmp {
icmp-code ip-header-bad;
icmp-type echo-reply;
}
then {
policer ICMP_Policier;
count Allow_ICMP;
You must also congure the icmp-type
message-type
match condion in the same term.
An ICMP message code provides more specic informaon than an ICMP message
type, but the meaning of an ICMP message code is dependent on the associated
ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed). The keywords are grouped by the ICMP type with
which they are associated:
• parameter-problem: ip-header-bad (0), required-option-missing (1)
• redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-
host (3), redirect-for-tos-and-net (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• unreachable: communication-prohibited-by-filtering (13), destination-host-
prohibited (10), destination-host-unknown (7), destination-network-prohibited (9),
destination-network-unknown (6), fragmentation-needed (4), host-precedence-
violation (14), host-unreachable (1), host-unreachable-for-TOS (12), network-
unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-
cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-
route-failed (5)
949
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
icmp-code-except
message-code
Do not match the ICMP message code eld. For details, see the icmp-code match
condion.
icmp-type
number
Match the ICMP message type eld.
NOTE: When using this match condion, you should also use the protocol icmp
match condion in the same term (as shown below) to ensure that icmp packets are
being evaluated.
term Allow _ICMP {
from protocol icmp {
icmp-code ip-header-bad;
icmp-type echo-reply;
}
then {
policer ICMP_Policier;
count Allow_ICMP;
You must also congure the icmp-type
message-type
match condion in the same term.
An ICMP message code provides more specic informaon than an ICMP message
type, but the meaning of an ICMP message code is dependent on the associated
ICMP message type.
NOTE: For Junos OS Evolved, you must congure the protocol match statement in
the same term.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): echo-reply (0), echo-request (8), info-reply (16), info-
request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5),
router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11),
timestamp (13), timestamp-reply (14), or unreachable (3).
icmp-type-except
message-type
Do not match the ICMP message type eld. For details, see the icmp-type match
condion.
950
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
interface
interface-name
Match the interface on which the packet was received.
NOTE: If you congure this match condion with an interface that does not exist, the
term does not match any packet.
interface-group
group-
number
Match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For
group-number
, specify a single value or a
range of values from 0 through 255.
To assign a logical interface to an interface group
group-number
, specify the
group-
number
at the [interfaces
interface-name
unit
number
family
family
filter group]
hierarchy level.
NOTE: This match condion is not supported on PTX series routers.
For more informaon, see "Filtering Packets Received on a Set of Interface Groups
Overview" on page 1377.
interface-group-except
group-number
Do not match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For details, see the interface-group match
condion.
NOTE: This match condion is not supported on PTX series routers.
interface-set
interface-
set-name
Match the interface on which the packet was received to the specied interface set.
To dene an interface set, include the interface-set statement at the [edit firewall]
hierarchy level.
NOTE: This match condion is not supported on PTX series routers.
For more informaon, see "Filtering Packets Received on an Interface Set Overview"
on page 1378.
951
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
ip-options
values
Match the 8-bit IP opon eld, if present, to the specied value or list of values.
In place of a numeric value, you can specify one of the following text synonyms (the
opon values are also listed): loose-source-route (131), record-route (7), router-
alert (148), security (130), stream-id (136),strict-source-route (137), or
timestamp (68).
To match
any
value for the IP opon, use the text synonym any. To match on
mulple
values, specify the list of values within square brackets ('[’ and ']’). To match a
range
of values, use the value specicaon [
value1
-
value2
].
For example, the match condion ip-options [ 0-147 ] matches on an IP opons eld
that contains the loose-source-route, record-route, or security values, or any other
value from 0 through 147. However, this match condion does not match on an IP
opons eld that contains only the router-alert value (148).
For most interfaces, a lter term that species an ip-option match on one or more
specic
IP opon values (a value other than any) causes packets to be sent to the
Roung Engine so that the kernel can parse the IP opon eld in the packet header.
• For a rewall lter term that species an ip-option match on one or more specic
IP opon values, you cannot specify the count, log, or syslog nonterminang
acons
unless
you also specify the discard terminang acon in the same term.
This behavior prevents double-counng of packets for a lter applied to a transit
interface on the router.
• Packets processed on the kernel might be dropped in case of a system boleneck.
To ensure that matched packets are instead sent to the Packet Forwarding Engine
(where packet processing is implemented in hardware), use the ip-options any
match condion.
The 10-Gigabit Ethernet Modular Port Concentrator (MPC), 100-Gigabit Ethernet
MPC, 60-Gigabit Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, and 60-Gigabit
Ethernet Enhanced Queuing MPC on MX Series routers are capable of parsing the
IP opon eld of the IPv4 packet header. For interfaces congured on those MPCs,
all
packets that are matched using the ip-options match condion are sent to the
Packet Forwarding Engine for processing.
The ip-options
any
match condion is supported on PTX10003 and PTX10008 Series
routers starng with Junos Evolved OS Release 20.2R1.
NOTE:
952
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
• On MX series routers, lter matches using ip-options cannot be used with egress
(output) lters.
• On M and T series routers, rewall lters cannot count ip-options packets on a
per opon type and per interface basis. A limited work around is to use the show
pfe statistics ip options command to see ip-options stascs on a per PFE
basis. See show pfe stascs ip for sample output.
ip-options-except
values
Do not match the IP opon eld to the specied value or list of values. For details
about specifying the
values
, see the ip-options match condion.
is-fragment
Using this condion causes a match if the More Fragments ag is enabled in the IP
header and if the fragment oset is not zero.
NOTE: To match both rst and trailing fragments, you can use two terms that specify
dierent match condions (first-fragment and is-fragment).
loss-priority
level
Match the packet loss priority (PLP) level.
Specify a single level or mulple levels: low, medium-low, medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced
CFEB (CFEB-E); and MX Series routers.
For IP trac on M320, MX Series, and T Series routers with Enhanced II Flexible PIC
Concentrators (FPCs), you must include the tri-color statement at the [edit class-
of-service] hierarchy level to commit a PLP conguraon with any of the four levels
specied. If the tri-color statement is not enabled, you can only congure the high
and low levels. This applies to all protocol families.
For informaon about the tri-color statement, see
Conguring and Applying Tricolor
Marking Policers
. For informaon about using behavior aggregate (BA) classiers to
set the PLP level of incoming packets, see
Understanding How Behavior Aggregate
Classiers Priorize Trusted Trac
.
953
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
loss-priority-except
level
Do not match the PLP level. For details, see the loss-priority match condion.
packet-length
bytes
Match the length of the received packet, in bytes. The length refers only to the IP
packet, including the packet header, and does not include any Layer 2 encapsulaon
overhead. You can also specify a range of values to be matched.
packet-length-except
bytes
Do not match the length of the received packet, in bytes. For details, see the packet-
length match type.
port
number
Match the UDP or TCP source or desnaon port eld.
If you congure this match condion, you cannot congure the destination-port
match condion or the source-port match condion in the same term.
When conguring port based matches you must also congure the protocol udp or
protocol tcp match statement in the same lter term. Matching only on the port
value can result in unexpected matches.
In place of the numeric value, you can specify one of the text synonyms listed under
destination-port.
port-except
number
Do not match either the source or desnaon UDP or TCP port eld. For details, see
the port match condion.
precedence
ip-
precedence-value
Match the IP precedence eld.
In place of the numeric eld value, you can specify one of the following text
synonyms (the eld values are also listed): critical-ecp (0xa0), flash (0x60), flash-
override (0x80), immediate (0x40), internet-control (0xc0), net-control (0xe0),
priority (0x20), or routine (0x00). You can specify precedence in hexadecimal, binary,
or decimal form.
954
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
precedence-except
ip-
precedence-value
Do not match the IP precedence eld.
In place of the numeric eld value, you can specify one of the following text
synonyms (the eld values are also listed): critical-ecp (0xa0), flash (0x60), flash-
override (0x80), immediate (0x40), internet-control (0xc0), net-control (0xe0),
priority (0x20), or routine (0x00). You can specify precedence in hexadecimal, binary,
or decimal form.
prefix-list
name
[ except ]
Match the prexes of the source or desnaon address elds to the prexes in the
specied list unless the except opon is included. If the opon is included, do not
match the prexes of the source or desnaon address elds to the prexes in the
specied list.
The prex list is dened at the [edit policy-options prefix-list
prefix-list-name
]
hierarchy level.
NOTE: This match condion is not supported on PTX1000 routers.
protocol
number
Match the IP protocol type eld. In place of the numeric value, you can specify one of
the following text synonyms (the eld values are also listed): ah (51), dstopts (60),
egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58),
igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6), udp (17), or
vrrp (112).
protocol-except
number
Do not match the IP protocol type eld. In place of the numeric value, you can
specify one of the following text synonyms (the eld values are also listed): ah (51),
dstopts (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58),
icmpv6 (58), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6),
udp (17), or vrrp (112).
955
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
rat-type
tech-type-value
Match the radio-access technology (RAT) type specied in the 8-bit Tech-Type eld
of Proxy Mobile IPv4 (PMIPv4) access technology type extension. The technology
type species the access technology through which the mobile device is connected
to the access network.
Specify a single value, a range of values, or a set of values. You can specify a
technology type as a numeric value from 0 through 255 or as a system keyword.
• The following numeric values are examples of well-known technology types:
• Numeric value 1 matches IEEE 802.3.
•
Numeric value 2 matches IEEE 802.11a/b/g.
•
Numeric value 3 matches IEEE 802.16e
•
Numeric value 4 matches IEEE 802.16m.
• Text string eutran matches 4G.
•
Text string geran matches 2G.
• Text string utran matches 3G.
rat-type-except
tech-
type-value
Do not match the RAT Type.
service-filter-hit Match a packet received from a lter where a service-filter-hit acon was applied.
NOTE: This match condion is not supported on PTX series routers.
source-address
address
[ except ]
Match the IPv4 address of the source node sending the packet unless the except
opon is included. If the opon is included, do not match the IPv4 address of the
source node sending the packet.
You cannot specify both the address and source-address match condions in the same
term.
956
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
source-class
class-names
Match one or more specied source class names (sets of source prexes grouped
together and given a class name). For more informaon, see "Firewall Filter Match
Condions Based on Address Classes" on page 996.
source-class-except
class-names
Do not match one or more specied source class names. For details, see the source-
class match condion.
source-port
number
Match the UDP or TCP source port eld.
You cannot specify the port and source-port match condions in the same term.
When conguring port based matches you must also congure the protocol udp or
protocol tcp match statement in the same lter term. Matching only on the port
value can result in unexpected matches.
In place of the numeric value, you can specify one of the text synonyms listed with
the destination-port
number
match condion.
source-port-except
number
Do not match the UDP or TCP source port eld. For details, see the source-port
match condion.
source-prefix-list
name
[ except ]
Match source prexes in the specied list unless the except opon is included. If the
opon is included, do not match the source prexes in the specied list.
Specify the name of a prex list dened at the [edit policy-options prefix-list
prefix-list-name
] hierarchy level.
tcp-established
Match TCP packets of an established TCP session (packets other than the rst packet
of a connecon). This is an alias for tcp-flags "(ack | rst)".
This match condion does not implicitly check that the protocol is TCP. To check this,
specify the protocol tcp match condion.
957
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
tcp-flags
value
Match one or more of the low-order 6 bits in the 8-bit TCP ags eld in the TCP
header.
To specify individual bit elds, you can specify the following text synonyms or
hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag
is set in all packets sent aer the inial packet.
You can string together mulple ags using the bit-eld logical operators.
For combined bit-eld match condions, see the tcp-established and tcp-initial
match condions.
If you congure this match condion, we recommend that you also congure the
protocol tcp match statement in the same term to specify that the TCP protocol is
being used on the port.
For IPv4 trac only, this match condion does not implicitly check whether the
datagram contains the rst fragment of a fragmented packet. To check for this
condion for IPv4 trac only, use the first-fragment match condion.
tcp-initial Match the inial packet of a TCP connecon. This is an alias for tcp-flags "(!ack &
syn)".
This condion does not implicitly check that the protocol is TCP. If you congure this
match condion, we recommend that you also congure the protocol tcp match
condion in the same term.
958
Table 51: Firewall Filter Match Condions for IPv4 Trac
(Connued)
Match Condion Descripon
ttl
number
Match the IPv4 me-to-live number. Specify a TTL value or a range of TTL values.
For
number
, you can specify one or more values from 0 through 255. This match
condion is supported only on M120, M320, MX Series, and T Series routers.
ttl-except
number
Do not match on the IPv4 TTL number. For details, see the ttl match condion.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release Descripon
13.3R7 Support was added for ltering on Dierenated Services Code Point (DSCP) and forwarding class for
Roung Engine sourced packets, including IS-IS packets encapsulated in generic roung encapsulaon
(GRE).
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
Firewall Filter Nonterminang Acons | 873
Firewall Filter Match Condions for IPv6 Trac | 959
enhanced-mode
Firewall Filter Flexible Match Condions | 864
Firewall Filter Match Condions for IPv6 Trac
You can congure a rewall lter with match condions for Internet Protocol version 6 (IPv6) trac
(family inet6).
959
NOTE: For MX Series routers with MPCs, you need to inialize the lter counter for Trio-only
match lters by walking the corresponding SNMP MIB, for example, show snmp mib walk
name
ascii.
This forces Junos to learn the lter counters and ensure that the lter stascs are displayed.
This guidance applies to all enhanced mode rewall lters, lters with exible condions, and
lters with the certain terminang acons. See those topics, listed under Related
Documentaon, for details.
Table 52 on page 960 describes the match condions you can congure at the [edit firewall family
inet6 filter
filter-name
term
term-name
from] hierarchy level.
Table 52: Firewall Filter Match Condions for IPv6 Trac
Match Condion Descripon
address
address
[ except ]
Match the IPv6 source or desnaon address eld unless the except opon is
included. If the opon is included, do not match the IPv6 source or desnaon
address eld.
apply-groups
Specify which groups to inherit conguraon data from. You can specify more than
one group name. You must list them in order of inheritance priority. The
conguraon data in the rst group takes priority over the data in subsequent
groups.
apply-groups-except
Specify which groups not to inherit conguraon data from. You can specify more
than one group name.
destination-address
address
[ except ]
Match the IPv6 desnaon address eld unless the except opon is included. If the
opon is included, do not match the IPv6 desnaon address eld.
You cannot specify both the address and destination-address match condions in the
same term.
960
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
destination-class
class-
names
Match one or more specied desnaon class names (sets of desnaon prexes
grouped together and given a class name).
For more informaon, see "Firewall Filter Match Condions Based on Address
Classes" on page 996.
destination-class-except
class-names
Do not match one or more specied desnaon class names. For details, see the
destination-class match condion.
destination-port
number
Match the UDP or TCP desnaon port eld.
You cannot specify both the port and destination-port match condions in the same
term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
NOTE: For Junos OS Evolved, you must congure the next-header match statement in
the same term.
In place of the numeric value, you can specify one of the following text synonyms
(the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515),
radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161),
snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except
number
Do not match the UDP or TCP desnaon port eld. For details, see the destination-
port match condion.
961
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
destination-prefix-list
prefix-list-name
[ except ]
Match the IPv6 desnaon prex to the specied list unless the except opon is
included. If the opon is included, do not match the IPv6 desnaon prex to the
specied list.
The prex list is dened at the [edit policy-options prefix-list
prefix-list-name
]
hierarchy level.
extension-headers
header-type
Match an extension header type that is contained in the packet by idenfying a Next
Header value.
NOTE: This match condion is only supported on MPCs in MX Series routers.
In the rst fragment of a packet, the lter searches for a match in any of the
extension header types. When a packet with a fragment header is found (a
subsequent fragment), the lter only searches for a match of the next extension
header type because the locaon of other extension headers is unpredictable.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): ah (51), destination (60), esp (50), fragment (44), hop-by-
hop (0), mobility (135), or routing (43).
To match
any
value for the extension header opon, use the text synonym any.
For MX Series routers with MPCs, inialize new rewall lters that include this
condion by walking the corresponding SNMP MIB.
first-fragment
Match if the packet is the rst
fragment.
962
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
ow-label
ow label
value
Match the 20-bit ow-label eld in the header of an IPv6 packet. Values range from
0x1 to 0xFFFFF.
ow-label
and
next-header
match condions cannot co-exist. Only either one of
these match condions can be applied at a me. To enable
ow-label
and disable
next-header
apply the following conguraon: set firewall v6-flowlabel-enable.
The following table summarizes the behavior of the
ow-label
match condion with
the
next-header
condion.
Scenario Conguraon Filter cong has Acon
1 No conguraon ow-label No ow-label
match is allowed.
2 No conguraon next-header next-header
match to rst
extension header
not allowed.
Defaults to match
payload-protocol.
3 no-next-header-
to-payload-
protocol-mapping
ow-label ow-label match
not allowed.
4 no-next-header-
to-payload-
protocol-mapping
next-header next-header
match to rst
extension header
allowed.
5 v6-owlabel-
enable
ow-label ow-label match
allowed
6 v6-owlabel-
enable
next-header next-header
match to rst
963
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
Scenario Conguraon Filter cong has Acon
extension header
not allowed.
Defaults to match
payload-protocol.
NOTE: The v6-flowlabel-enable and flow-label match condions are only supported
only on Junos EVO on PTX10001-36MR, PTX10003, PTX10004, PTX10008, and
PTX10016.
ow-label
ow label
value
mask
mask value
In addion to the regular
ow-label
value, you can use a mask value while conguring
the match; the mask value matches specic bits of the given
ow-label
value.
NOTE: The flow-label ow label value mask mask value match condion is only
supported only on Junos EVO on PTX10001-36MR, PTX10003, PTX10004,
PTX10008, and PTX10016.
extension-headers-except
header-type
Do not match an extension header type that is contained in the packet. For details,
see the extension-headers match condion.
NOTE: This match condion is only supported on MPCs in MX Series routers.
flexible-match-mask
value
bit-length
Length of integer input (1..32 bits);
(Oponal) Length of string input (1..128 bits)
bit-offset
Bit oset aer the (match-start + byte) oset
(0..7)
byte-offset
Byte oset aer the match start point
flexible-mask-name
Select a exible match from predened
template eld
964
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
mask-in-hex
Mask out bits in the packet data to be matched
match-start
Start point to match in packet
prefix
Value data/string to be matched
See "Firewall Filter Flexible Match Condions" on page 864 for details
flexible-match-range
value
Ranges should use the
following format:
Integer
-
Integer
bit-length
Length of the data to be matched in bits (0..32)
bit-offset
Bit oset aer the (match-start + byte) oset
(0..7)
byte-offset
Byte oset aer the match start point
flexible-range-name
Select a exible match from predened
template eld
match-start
Start point to match in packet
range
Range of values to be matched
range-except
Do not match this range of values
See "Firewall Filter Flexible Match Condions" on page 864 for details
965
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
forwarding-class
class
Match the forwarding class of the packet.
Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.
For informaon about forwarding classes and router-internal output queues, see
Understanding How Forwarding Classes Assign Classes to Output Queues
.
forwarding-class-except
class
Do not match the forwarding class of the packet. For details, see the forwarding-class
match condion.
hop-limit
hop-limit
Match the hop limit to the specied hop limit or set of hop limits. For
hop-limit
,
specify a single value or a range of values from 0 through 255.
Supported on interfaces hosted on MICs or MPCs in MX Series routers only.
NOTE: This match condion is supported on PTX series routers when enhanced-mode
is congured on the router.
hop-limit-except
hop-
limit
Do not match the hop limit to the specied hop limit or set of hop limits. For details,
see the hop-limit match condion.
Supported on interfaces hosted on MICs or MPCs in MX Series routers only.
NOTE: This match condion is supported on PTX series routers when enhanced-mode
is congured on the router.
966
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
icmp-code
message-code
Match the ICMP message code eld.
If you congure this match condion, we recommend that you also congure the
next-header icmp or next-header icmp6 match condion in the same term.
If you congure this match condion, you must also congure the icmp-type
message-
type
match condion in the same term. An ICMP message code provides more
specic informaon than an ICMP message type, but the meaning of an ICMP
message code is dependent on the associated ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed). The keywords are grouped by the ICMP type with
which they are associated:
• parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-
option (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• desnaon-unreachable: administratively-prohibited (1), address-unreachable (3),
no-route-to-destination (0), port-unreachable (4)
icmp-code-except
message-code
Do not match the ICMP message code eld. For details, see the icmp-code match
condion.
967
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
icmp-type
message-type
Match the ICMP message type eld.
If you congure this match condion, we recommend that you also congure the
next-header icmp or next-header icmp6 match condion in the same term.
NOTE: For Junos OS Evolved, you must congure the next-header match statement in
the same term.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): certificate-path-advertisement (149), certificate-
path-solicitation (148), destination-unreachable (1), echo-reply (129), echo-
request (128), home-agent-address-discovery-reply (145), home-agent-address-discovery-
request (144), inverse-neighbor-discovery-advertisement (142), inverse-neighbor-
discovery-solicitation (141), membership-query (130), membership-report (131),
membership-termination (132), mobile-prefix-advertisement-reply (147), mobile-prefix-
solicitation (146), neighbor-advertisement (136), neighbor-solicit (135), node-
information-reply (140), node-information-request (139), packet-too-big (2), parameter-
problem (4), private-experimentation-100 (100), private-experimentation-101 (101),
private-experimentation-200 (200), private-experimentation-201 (201), redirect (137),
router-advertisement (134), router-renumbering (138), router-solicit (133), or time-
exceeded (3).
For private-experimentation-201 (201), you can also specify a range of values within
square brackets.
icmp-type-except
message-type
Do not match the ICMP message type eld. For details, see the icmp-type match
condion.
interface
interface-name
Match the interface on which the packet was received.
NOTE: If you congure this match condion with an interface that does not exist, the
term does not match any packet.
968
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
interface-group
group-
number
Match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For
group-number
, specify a single value or a
range of values from 0 through 255.
To assign a logical interface to an interface group
group-number
, specify the
group-
number
at the [interfaces
interface-name
unit
number
family
family
filter group]
hierarchy level.
For more informaon, see "Filtering Packets Received on a Set of Interface Groups
Overview" on page 1377.
interface-group-except
group-number
Do not match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For details, see the interface-group match
condion.
interface-set
interface-
set-name
Match the interface on which the packet was received to the specied interface set.
To dene an interface set, include the interface-set statement at the [edit firewall]
hierarchy level.
For more informaon, see "Filtering Packets Received on an Interface Set Overview"
on page 1378.
969
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
ip-options
values
Match the 8-bit IP opon eld, if present, to the specied value or list of values.
In place of a numeric value, you can specify one of the following text synonyms (the
opon values are also listed): loose-source-route (131), record-route (7), router-
alert (148), security (130), stream-id (136),strict-source-route (137), or
timestamp (68).
To match
any
value for the IP opon, use the text synonym any. To match on
mulple
values, specify the list of values within square brackets ('[’ and ']’). To match a
range
of values, use the value specicaon [
value1
-
value2
].
For example, the match condion ip-options [ 0-147 ] matches on an IP opons eld
that contains the loose-source-route, record-route, or security values, or any other
value from 0 through 147. However, this match condion does not match on an IP
opons eld that contains only the router-alert value (148).
For most interfaces, a lter term that species an ip-option match on one or more
specic
IP opon values (a value other than any) causes packets to be sent to the
Roung Engine so that the kernel can parse the IP opon eld in the packet header.
• For a rewall lter term that species an ip-option match on one or more specic
IP opon values, you cannot specify the count, log, or syslog nonterminang
acons
unless
you also specify the discard terminang acon in the same term.
This behavior prevents double-counng of packets for a lter applied to a transit
interface on the router.
• Packets processed on the kernel might be dropped in case of a system boleneck.
To ensure that matched packets are instead sent to the Packet Forwarding Engine
(where packet processing is implemented in hardware), use the ip-options any
match condion.
The 10-Gigabit Ethernet Modular Port Concentrator (MPC), 100-Gigabit Ethernet
MPC, 60-Gigabit Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, and 60-Gigabit
Ethernet Enhanced Queuing MPC on MX Series routers are capable of parsing the
IP opon eld of the IPv4 packet header. For interfaces congured on those MPCs,
all
packets that are matched using the ip-options match condion are sent to the
Packet Forwarding Engine for processing.
970
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
ip-options-except
values
Do not match the IP opon eld to the specied value or list of values. For details
about specifying the
values
, see the ip-options match condion.
is-fragment
Match if the packet is a fragment.
last-fragment
Match if the packet is the last
fragment.
loss-priority
level
Match the packet loss priority (PLP) level.
Specify a single level or mulple levels: low, medium-low, medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced
CFEB (CFEB-E); and MX Series routers and EX Series switches.
For IP trac on M320, MX Series, T Series routers and EX Series switches with
Enhanced II Flexible PIC Concentrators (FPCs), you must include the tri-color
statement at the [edit class-of-service] hierarchy level to commit a PLP
conguraon with any of the four levels specied. If the tri-color statement is not
enabled, you can only congure the high and low levels. This applies to all protocol
families.
For informaon about the tri-color statement, see
Conguring and Applying Tricolor
Marking Policers
. For informaon about using behavior aggregate (BA) classiers to
set the PLP level of incoming packets, see
Understanding How Forwarding Classes
Assign Classes to Output Queues
.
loss-priority-except
level
Do not match the PLP level. For details, see the loss-priority match condion.
971
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
next-header
header-type
Match the rst 8-bit Next Header eld in the packet. Support for the next-header
rewall match condion is available in Junos OS Release 13.3R6 and later.
NOTE: MX plaorms have a next-header match that matches the rst Next Header
(NH) in the packet and the payload-protocol to match the last NH. Whereas EVO-PTX
plaorms supported the next-header match on the last NH, but not the rst one. The
most common use case is to match the last NH, and this was nave to the PTX
plaorms. Now the next-header matches the rst NH, and the payload-protocol
matches the last NH, and behaves the same way as on MX plaorms. If you are using
the IPv6 lter next-header clause on your WAN interfaces' rewall, you need to
review and modify the rewall to match the new behavior. This change was
introduced into Junos OS Evolved versions:
•
21.4R2-S1-EVO, 21.4R2-S2-EVO, 21.4R3-S1-EVO and later
•
Exclude 21.4R3-EVO
•
22.2R2-EVO
• 22.3R1-EVO
Match the rst 8-bit Next Header eld in the packet.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): ah (51), dstops (60), egp (8), esp (50), fragment (44),
gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41),
mobility (135), no-next-header (59), ospf (89), pim (103), routing (43), rsvp (46),
sctp (132), tcp (6), udp (17), or vrrp (112).
NOTE:
• next-header icmp6 and next-header icmpv6 match condions perform the same
funcon. next-header icmp6 is the preferred opon. next-header icmpv6 is hidden in
the Junos OS CLI.
• On the QFX5000 series devices running Junos OS Evolved, the next-header match
is not supported under ERACLv6, and instead, you must congure the payload-
protocol match.
972
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
next-header-except
header-type
Do not match the 8-bit Next Header eld that idenes the type of header between
the IPv6 header and payload. For details, see the next-header match type.
packet-length
bytes
Match the length of the received packet, in bytes. The length refers only to the IP
packet, including the packet header, and does not include any Layer 2 encapsulaon
overhead.
packet-length-except
bytes
Do not match the length of the received packet, in bytes. For details, see the packet-
length match type.
payload-protocol
protocol-type
Match the payload protocol type.
In place of the
protocol-type
numeric value, you can specify one of the following text
synonyms (the eld values are also listed): specify one or a set of of the following:
ah (51), dstopts (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1),
icmp6 (58, igmp (2), ipip (4), ipv6 (41), no-next-header, ospf (89), pim (103), routing,
rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112) (dstopts (60), fragment (44), hop-
by-hop 0), and roung are not available in Junos OS Release 16.1 and later).
You can also use the payload-protocol condion to match an extension header type
that the Juniper Networks rmware cannot interpret. You can specify a range of
extension header values within square brackets. When the rmware nds the rst
extension header type that it cannot interpret in a packet, the payload-protocol value
is set to that extension header type. The rewall lter only examines the rst
extension header type that the rmware cannot interpret in the packet.
NOTE: This match condion is only supported on MPCs on MX Series Routers.
Inialize new rewall lters that include this condion by walking the corresponding
SNMP MIB.
payload-protocol-except
protocol-type
Do not match the payload protocol type. For details, see the payload-protocol match
type.
NOTE: This match condion is only supported on MPCs on MX Series Routers
973
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
port
number
Match the UDP or TCP source or desnaon port eld.
If you congure this match condion, you cannot congure the destination-port
match condion or the source-port match condion in the same term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
NOTE: For Junos OS Evolved, you must congure the next-header match statement in
the same term.
In place of the numeric value, you can specify one of the text synonyms listed under
destination-port.
port-except
number
Do not match the UDP or TCP source or desnaon port eld. For details, see the
port match condion.
prefix-list
prefix-list-
name
[ except ]
Match the prexes of the source or desnaon address elds to the prexes in the
specied list unless the except opon is included. If the opon is included, do not
match the prexes of the source or desnaon address elds to the prexes in the
specied list.
The prex list is dened at the [edit policy-options prefix-list
prefix-list-name
]
hierarchy level.
service-filter-hit Match a packet received from a lter where a service-filter-hit acon was applied.
source-address
address
[ except ]
Match the IPv6 address of the source node sending the packet unless the except
opon is included. If the opon is included, do not match the IPv6 address of the
source node sending the packet.
You cannot specify both the address and source-address match condions in the same
term.
974
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
source-class
class-names
Match one or more specied source class names (sets of source prexes grouped
together and given a class name).
For more informaon, see "Firewall Filter Match Condions Based on Address
Classes" on page 996.
source-class-except
class-names
Do not match one or more specied source class names. For details, see the source-
class match condion.
source-port
number
Match the UDP or TCP source port eld.
You cannot specify the port and source-port match condions in the same term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
NOTE: For Junos OS Evolved, you must congure the next-header or next-header tcp
match statement in the same term.
In place of the numeric value, you can specify one of the text synonyms listed with
the destination-port
number
match condion.
source-port-except
number
Do not match the UDP or TCP source port eld. For details, see the source-port
match condion.
source-prefix-list
name
[ except ]
Match the IPv6 address prex of the packet source eld unless the except opon is
included. If the opon is included, do not match the IPv6 address prex of the packet
source eld.
Specify a prex list name dened at the [edit policy-options prefix-list
prefix-
list-name
] hierarchy level.
975
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
tcp-established
Match TCP packets other than the rst packet of a connecon. This is a text
synonym for tcp-flags "(ack | rst)" (0x14).
NOTE: This condion does not implicitly check that the protocol is TCP. To check
this, specify the protocol tcp match condion.
If you congure this match condion, we recommend that you also congure the
next-header tcp match condion in the same term.
tcp-flags
flags
Match one or more of the low-order 6 bits in the 8-bit TCP ags eld in the TCP
header.
To specify individual bit elds, you can specify the following text synonyms or
hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag
is set in all packets sent aer the inial packet.
You can string together mulple ags using the bit-eld logical operators.
For combined bit-eld match condions, see the tcp-established and tcp-initial
match condions.
If you congure this match condion, we recommend that you also congure the
next-header tcp match condion in the same term to specify that the TCP protocol is
being used on the port.
976
Table 52: Firewall Filter Match Condions for IPv6 Trac
(Connued)
Match Condion Descripon
tcp-initial Match the inial packet of a TCP connecon. This is a text synonym for tcp-flags "(!
ack & syn)".
This condion does not implicitly check that the protocol is TCP. If you congure this
match condion, we recommend that you also congure the next-header tcp match
condion in the same term.
traffic-class
number
Match the 8-bit eld that species the class-of-service (CoS) priority of the packet.
This eld was previously used as the type-of-service (ToS) eld in IPv4.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed):
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
•
RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
• af11 (10), af12 (12), af13 (14)
• af21 (18), af22 (20), af23 (22)
• af31 (26), af32 (28), af33 (30)
• af41 (34), af42 (36), af43 (38)
traffic-class-except
number
Do not match the 8-bit eld that species the CoS priority of the packet. For details,
see the traffic-class match descripon.
977
NOTE: If you specify an IPv6 address in a match condion (the address, destination-address, or
source-address match condions), use the syntax for text representaons described in RFC 4291,
IP Version 6 Addressing Architecture
. For more informaon about IPv6 addresses, see IPv6
Overview and Supported IPv6 Standards.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release Descripon
13.3R6
Support for the next-header rewall match condion is available in Junos OS Release 13.3R6 and later.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
Firewall Filter Nonterminang Acons | 873
Firewall Filter Match Condions for IPv4 Trac | 942
enhanced-mode
Firewall Filter Flexible Match Condions | 864
Firewall Filter Match Condions Based on Numbers or Text Aliases
IN THIS SECTION
Matching on a Single Numeric Value | 979
Matching on a Range of Numeric Values | 979
Matching on a Text Alias for a Numeric Value | 979
Matching on a List of Numeric Values or Text Aliases | 979
978
Matching on a Single Numeric Value
You can specify a
rewall lter
match condion based on whether a parcular packet eld value is a
specied numeric value. In the following example, a match occurs if the packet source port number is
25:
[edit firewall family inet filter filter1 term term1 from]
user@host# set source-port 25
Matching on a Range of Numeric Values
You can specify a rewall lter match condion based on whether a parcular packet eld value falls
within a specied range of numeric values. In the following example, a match occurs for source
ports values from 1024 through 65,535, inclusive:
[edit firewall family inet filter filter2 term term1 from]
user@host# set source-port 1024-65536
Matching on a Text Alias for a Numeric Value
You can specify a rewall lter match condion based on whether a parcular packet eld value is a
numeric value that you specify by using a text string as an
alias
for the numeric value. In the following
example, a match occurs if the packet source port number is 25. For the source-port and desnaon-
port match condions, the text aliassmtp corresponds to the numeric value 25.
[edit firewall family inet filter filter3 term term1 from]
user@host# set source-port smtp
Matching on a List of Numeric Values or Text Aliases
You can specify a rewall lter match condion based on whether a parcular packet eld value
matches any one of mulple numeric values or text aliases that you specify within square brackets and
delimited by spaces. In the following example, a match occurs if the packet source port number is any of
979
the following values: 20 (which corresponds to the text aliases p-data), 25, or any value from 1024
through 65535.
[edit firewall family inet filter filter3 term term1 from]
user@host# set source-port [ smtp ftp-data 25 1024-65535 ]
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Fields | 986
Firewall Filter Match Condions Based on Address Classes | 996
Firewall Filter Match Condions Based on Bit-Field Values
IN THIS SECTION
Match Condions for Bit-Field Values | 980
Match Condions for Common Bit-Field Values or Combinaons | 981
Logical Operators for Bit-Field Values | 982
Matching on a Single Bit-Field Value or Text Alias | 983
Matching on Mulple Bit-Field Values or Text Aliases | 984
Matching on a Negated Bit-Field Value | 984
Matching on the Logical OR of Two Bit-Field Values | 985
Matching on the Logical AND of Two Bit-Field Values | 985
Grouping Bit-Field Match Condions | 985
Match Condions for Bit-Field Values
Table 53 on page 981 lists the
rewall lter
match condions that are based on whether certain bit
elds in a packet are set or not set. The second and third columns list the types of trac for which the
match condion is supported.
980
Table 53: Binary and Bit-Field Match Condions for Firewall Filters
Bit-Field Match Condion Match Values Protocol Families
for Standard
Stateless
Firewall Filters
Protocol Families for
Service Filters
fragment-ags
ags
Hexadecimal values or text aliases
for the three-bit IP fragmentaon
ags eld in the IP header.
family inet family inet
fragment-oset
value
Hexadecimal values or text aliases
for the 13-bit fragment oset eld
in the IP header.
family inet family inet
tcp-ags
value
†
Hexadecimal values or text aliases
for the low-order 6 bits of the 8-bit
TCP ags eld in the TCP header.
family inet
family inet6
family vpls
family bridge
family inet
family inet6
†
 The Junos OS does not automacally check the rst fragment bit when matching TCP ags for IPv4 trac. To
check the rst fragment bit for IPv4 trac only, use the rst-fragment match condion.
Match Condions for Common Bit-Field Values or Combinaons
Table 54 on page 982 describes rewall lter match condions that are based on whether certain
commonly used values or
combinaons
of bit elds in a packet are set or not set.
You can use text synonyms to specify some common bit-eld matches. In the previous example, you can
specify tcp-inial as the same match condion.
NOTE: Some of the numeric range and bit-eld match condions allow you to specify a text
synonym. For a complete list of synonyms:
• If you are using the J-Web interface, select the synonym from the appropriate list.
• If you are using the CLI, type a queson mark (?) aer the from statement.
981
Table 54: Bit-Field Match Condions for Common Combinaons
Match Condion Descripon Protocol Families for
Standard Stateless
Firewall Filters
Protocol Families for
Service Filters
rst-fragment Text alias for the bit-eld match
condion fragment-oset 0, which
indicates the rst fragment of a
fragmented packet.
family inet family inet
is-fragment Text alias for the bit-eld match
condion fragment-oset 0 except,
which indicates a trailing fragment
of a fragmented packet.
family inet family inet
tcp-established Alias for the bit-eld match
condion tcp-ags "(ack | rst)",
which indicates an established TCP
session, but not the rst packet of a
TCP connecon.
family inet
family inet6
—
tcp-inial Alias for the bit-eld match
condion tcp-ags "(!ack & syn)",
which indicates the rst packet of a
TCP connecon, but not an
established TCP session.
family inet
family inet6
—
Logical Operators for Bit-Field Values
Table 55 on page 983 lists the logical operators you can apply to
single
bit-eld values when specifying
stateless rewall lter match condions. The operators are listed in order, from highest precedence to
lowest precedence. Operaons are le-associave, meaning that the operaons are processed from le
to right.
982
Table 55: Bit-Field Logical Operators
Precedence
Order
Bit-Field Logical Operator Descripon
1 (
complex-match-condion
) Grouping—The complex match condion is
evaluated before any operators outside the
parentheses are applied.
2 !
match-condion
Negaon—A match occurs if the match
condion is false.
3
match-condion-1
&
match-condion-2
or
match-condion-1
+
match-condion-2
Logical AND—A match occurs if both match
condions are true.
4
match-condion-1
|
match-condion-2
or
match-condion-1
,
match-condion-2
 
Logical OR—A match occurs if either match
condion is true.
Matching on a Single Bit-Field Value or Text Alias
For the fragment-ags and tcp-ags bit-match condions, you can specify rewall lter match
condions based on whether a parcular bit in the packet eld is set or not set.
• Numeric value to specify a single bit—You can specify a single bit-eld match condion by using a
numeric value that has one bit set. Depending on the match condion, you can specify a decimal
value, a binary value, or a hexadecimal value. To specify a binary value, specify the number with the
prex b. To specify a hexadecimal value, specify the number with the prex 0x.
In the following example, a match occurs if the RST bit in the TCP ags eld is set:
[edit firewall family inet filter filter_tcp_rst_number term term1 from]
user@host# set tcp-flags 0x04
• Text alias to specify a single bit—You generally specify a single bit-eld match condion by using a
text alias enclosed in double-quotaon marks (“ ”).
983
In the following example, a match occurs if the RST bit in the TCP ags eld is set:
[edit firewall family inet filter filter_tcp_rst_alias term term1 from]
user@host# set tcp-flags “rst”
Matching on Mulple Bit-Field Values or Text Aliases
You can specify a rewall lter match condion based on whether a parcular set of bits in a packet eld
are set.
• Numeric values to specify mulple set bits—When you specify a numeric value whose binary
representaon has more than one set bit, the value is treated as a logical AND of the set bits.
In the following example, the two match condions are the same. A match occurs if either bit 0x01
or 0x02 is not set:
[edit firewall family inet filter reset_or_not_initial_packet term term5 from]
user@host# set tcp-flags “!0x3”
user@host# set tcp-flags “!(0x01 & 0x02)”
• Text aliases that specify common bit-eld matches—You can use text aliases to specify some common
bit-eld matches. You specify these matches as a single keyword.
In the following example, the tcp-established condion, which is an alias for “(ack | rst)”, species that
a match occurs on TCP packets other than the rst packet of a connecon:
[edit firewall family inet filter reset_or_not_initial_packet term term6 from]
user@host# set tcp-established
Matching on a Negated Bit-Field Value
To negate a match, precede the value with an exclamaon point.
In the following example, a match occurs if the RST bit in the TCP ags eld is set:
[edit firewall family inet filter filter_tcp_rst term term1 from]
user@host# set tcp-flags “!rst”
984
Matching on the Logical OR of Two Bit-Field Values
You can use the (| or ,) to specify that a match occurs if a bit eld matches either of two bit-eld values
specied.
In the following example, a match occurs if the packet is
not
the inial packet in a TCP session:
[edit firewall family inet filter not_initial_packet term term3 from]
user@host# set tcp-flags "!syn | ack"
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag is set in all packets
sent aer the inial packet. In a packet that is not the inial packet in a TCP session, either the SYN ag
is not set or the ACK ag is set.
Matching on the Logical AND of Two Bit-Field Values
You can use the (& or +) to specify that a match occurs if a bit eld matches both of two bit-eld values
specied.
In the following example, a match occurs if the packet is the inial packet in a TCP session:
[edit firewall family inet filter initial_packet term term2 from]
user@host# set tcp-flags “syn & !ack”
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag is set in all packets
sent aer the inial packet. In a packet that is an inial packet in a TCP session, the SYN ag is set and
the ACK ag is not set.
Grouping Bit-Field Match Condions
You can use the to specify that the complex match condion inside the parentheses is evaluated before
any operators outside the parentheses are applied.
In the following example, a match occurs if the packet is a TCP reset or if the packet is not the inial
packet in the TCP session:
[edit firewall family inet filter reset_or_not_initial_packet term term4 from]
user@host# set tcp-flags “!(syn & !ack) | rst”
985
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag is set in all packets
sent aer the inial packet. In a packet that is
not
the inial packet in a TCP session, the SYN ag is not
set and the ACK eld is set.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
Firewall Filter Match Condions Based on Address Fields | 986
Firewall Filter Match Condions Based on Address Classes | 996
Firewall Filter Match Condions Based on Address Fields
IN THIS SECTION
Implied Match on the ’0/0 except’ Address for Firewall Filter Match Condions Based on Address
Fields | 986
Matching an Address Field to a Subnet Mask or Prex | 987
Matching an Address Field to an Excluded Value | 988
Matching Either IP Address Field to a Single Value | 993
Matching an Address Field to Nonconguous Prexes | 993
Matching an Address Field to a Prex List | 995
You can congure
rewall lter
match condions that evaluate packet address elds—IPv4 source and
desnaon addresses, IPv6 source and desnaon addresses, or media access control (MAC) source and
desnaon addresses—against specied addresses or prex values.
Implied Match on the ’0/0 except’ Address for Firewall Filter Match Condions Based
on Address Fields
Every rewall lter match condion based on a set of addresses or address prexes is associated with an
implicit match on the address 0.0.0.0/0 except (for IPv4 or VPLS trac) or 0:0:0:0:0:0:0:0/0 except (for
IPv6 trac). As a result, any packet whose specied address eld does not match any of the specied
addresses or address prexes fails to match the enre term.
986
Matching an Address Field to a Subnet Mask or Prex
You can specify a single match condion to match a source address or desnaon address that falls
within a specied address prex.
IPv4 Subnet Mask Notaon
For an IPv4 address, you can specify a subnet mask value rather than a prex length. For example:
[edit firewall family inet filter filter_on_dst_addr term term3 from]
user@host# set address 10.0.0.10/255.0.0.255
Prex Notaon
To specify the address prex, use the notaon
prex
/
prex-length
. In the following example, a match
occurs if a desnaon address matches the prex 10.0.0.0/8:
[edit firewall family inet filter filter_on_dst_addr term term1 from]
user@host# set destination-address 10.0.0.0/8
Default Prex Length for IPv4 Addresses
If you do not specify /
prex-length
for an IPv4 address, the prex length defaults to /32. The following
example illustrates the default prex value:
[edit firewall family inet filter filter_on_dst_addr term term2 from]
user@host# set destination-address 10
user@host# show
destination-address {
10.0.0.0/32;
}
987
Default Prex Length for IPv6 Addresses
If you do not specify /
prex-length
for an IPv6 address, the prex length defaults to /128. The following
example illustrates the default prex value:
[edit firewall family inet6 filter filter_on_dst_addr term term1 from]
user@host# set destination-address ::10
user@host# show
destination-address {
::10/128;
}
Default Prex Length for MAC Addresses
If you do not specify /
prex-length
for a media access control (MAC) address of a VPLS, Layer 2 CCC, or
Layer 2 bridging packet, the prex length defaults to /48. The following example illustrates the default
prex value:
[edit firewall family vpls filter filter_on_dst_mac_addr term term1 from]
user@host# set destination-mac-address 01:00:0c:cc:cc:cd
user@host# show
destination-address {
01:00:0c:cc:cc:cd/48;
}
Matching an Address Field to an Excluded Value
For the address-eld match condions, you can include the except keyword to specify that a match
occurs for an address eld that does not match the specied address or prex.
Excluding IP Addresses in IPv4 or IPv6 Trac
For the following IPv4 and IPv6 match condions, you can include the except keyword to specify that a
match occurs for an IP address eld that does not match the specied IP address or prex:
• address
address
except—A match occurs if either the source IP address or the desnaon IP address
does not match the specied address or prex.
• source-address
address
except—A match occurs if the source IP address does not match the
specied address or prex.
988
• desnaon-address
address
except—A match occurs if the desnaon IP address does not match the
specied address or prex.
In the following example, a match occurs for any IPv4 desnaon addresses that fall under the
172.0.0.0/8 prex, except for addresses that fall under 172.16.0.0/16. All other addresses implicitly
do not match this condion.
[edit firewall family inet filter filter_on_dst_addr term term1 from]
user@host# set destination-address 172.16.0.0/16 except
user@host# set destination-address 172.0.0.0/8
user@host# show
destination-address {
172.16.0.0/16 except;
172.0.0.0/8;
}
In the following example, a match occurs for any IPv4 desnaon address that does not fall within the
prex 10.1.1.0/24:
[edit firewall family inet filter filter_on_dst_addr term term24 from]
user@host# set destination-address 0.0.0.0/0
user@host# set destination-address 10.1.1.0/24 except
user@host# show
destination-address {
0.0.0.0/0;
10.1.1.0/24 except;
}
Excluding IP Addresses in VPLS or Layer 2 Bridging Trac
For the following VPLS and Layer 2 bridging match condions on MX Series routers only, you can
include the except keyword to specify that a match occurs for an IP address eld that does not match
the specied IP address or prex:
• ip-address
address
except—A match occurs if either the source IP address or the desnaon IP
address does not match the specied address or prex.
• source-ip-address
address
except—A match occurs if the source IP address does not match the
specied address or prex.
• desnaon-ip-address
address
except—A match occurs if the desnaon IP address does not match
the specied address or prex.
989
In the following example for ltering VPLS trac on an MX Series router, a match occurs if the source IP
address falls within the excepon range of 55.0.1.0/255.0.255.0 and the desnaon IP address matches
5172.16.5.0/8:
[edit]
firewall {
family vpls {
filter fvpls {
term 1 {
from {
ip-address {
55.0.0.0/8;
55.0.1.0/255.0.255.0 except;
}
}
then {
count from-55/8;
discard;
}
}
}
}
}
Excluding MAC Addresses in VPLS or Layer 2 Bridging Trac
For the following VPLS or Layer 2 bridging trac match condions, you can include the except keyword
to specify that a match occurs for a MAC address eld that does not match the specied MAC address
or prex:
• source-mac-address
address
except—A match occurs if the source MAC address does not match the
specied address or prex.
• desnaon-mac-address
address
except—A match occurs if either the desnaon MAC address
does not match the specied address or prex.
990
Excluding All Addresses Requires an Explicit Match on the ’0/0’ Address
If you specify a rewall lter match condion that consists of one or more address-
excepon
match
condions (address match condions that use the except keyword) but no
matchable
address match
condions, packets that do not match any of the congured prexes fails the overall match operaon. To
congure a rewall lter term of address-excepon match condions to match any address that is not in
the prex list, include an explicit match of 0/0 so that the term contain a matchable address.
For the following example rewall lter for IPv4 trac, the from-trusted-addresses term fails to discard
matching trac, and the INTRUDERS-COUNT counter is missing from the output of the show rewall
operaonal mode command
:
[edit]
user@host# show policy-options
prefix-list TRUSTED-ADDRESSES {
10.2.1.0/24;
192.168.122.0/24;
}
[edit firewall family inet filter protect-RE]
user@host# show
term from-trusted-addresses {
from {
source-prefix-list {
TRUSTED-ADDRESSES except;
}
protocol icmp;
}
then {
count INTRUDERS-COUNT;
discard;
}
}
term other-icmp {
from {
protocol icmp;
}
then {
count VALID-COUNT;
accept;
}
}
991
term all {
then accept;
}
[edit]
user@host# run show firewall
Filter: protect-RE
Counters:
Name Bytes Packets
VALID-COUNT 2770 70
Filter: __default_bpdu_filter__
To cause a lter term of address-excepon match condions to match any address that is not in the
prex list, include an explicit match of 0/0 in the set of match condions:
[edit firewall family inet filter protect-RE]
user@host# show term from-trusted-addresses
from {
source-prefix-list {
0.0.0.0/0;
TRUSTED-ADDRESSES except;
}
protocol icmp;
}
With the addion of the 0.0.0.0/0 source prex address to the match condion, the from-trusted-
addresses term discards matching trac, and the INTRUDERS-COUNT counter displays in the output of
the show rewall operaonal mode command:
[edit]
user@host# run show firewall
Filter: protect-RE
Counters:
Name Bytes Packets
VALID-COUNT 2770 70
INTRUDERS-COUNT 420 5
Filter: __default_bpdu_filter__
992
Matching Either IP Address Field to a Single Value
For IPv4 and IPv6 trac and for VPLS and Layer 2 bridging trac on MX Series routers only, you can
use a single match condion to match a single address or prex value to either the source or desnaon
IP address eld.
Matching Either IP Address Field in IPv4 or IPv6 Trac
For IPv4 or IPv6 trac, you can use a single match condion to specify the same address or prex value
as the match for either the source or desnaon IP address eld. Instead of creang separate lter
terms that specify the same address for the source-address and desnaon-address match condions,
you use only the address match condion. A match occurs if
either
the source IP address
or
the
desnaon IP address matches the specied address or prex.
If you use the except keyword with the address match condion, a match occurs if
both
the source IP
address and the desnaon IP address match the specied value
before
the excepon applies.
In a rewall lter term that species either the source-address or the desnaon-address match
condion, you cannot also specify the address match condion.
Matching Either IP Address Field in VPLS or Layer 2 Bridging Trac
For VPLS or Layer 2 bridging trac on MX Series routers only, you can use a single match condion to
specify the same address or prex value as the match for either the source or desnaon IP address
eld. Instead of creang separate lter terms that specify the same address for the source-ip-address
and desnaon-ip-address match condions, you use only the ip-address match condion. A match
occurs if
either
the source IP address
or
the desnaon IP address matches the specied address or
prex.
If you use the except keyword with the ip-address match condion, a match occurs if
both
the source IP
address and the desnaon IP address match the specied value
before
the excepon applies.
In a rewall lter term that species either the source-ip-address or the desnaon-ip-address match
condion, you cannot also specify the ip-address match condion.
Matching an Address Field to Nonconguous Prexes
For IPv4 trac only, specify a single match condion to match the IP source or desnaon address eld
to any prex specied. The prexes do not need to be conguous. That is, the prexes under the
source-address or desnaon-address match condion do not need to be adjacent or neighboring to
one another.
993
In the following example, a match occurs if a desnaon address matches either the 10.0.0.0/8 prex or
the 192.168.0.0/32 prex:
[edit firewall family inet filter filter_on_dst_addr term term5 from]
user@host# set destination-address 10.0.0.0/8
user@host# set destination-address 192.168.0.0/32
user@host# show
destination-address {
destination-address 10.0.0.0/8;
destination-address 192.168.0.0/32;
}
The order in which you specify the prexes within the match condion is not signicant. Packets are
evaluated against all the prexes in the match condion to determine whether a match occurs. If
prexes overlap, longest-match rules are used to determine whether a match occurs. A match condion
of nonconguous prexes includes an implicit 0/0 except statement, which means that any prex that
does not match any prex included in the match condion is explicitly considered not to match.
Because the prexes are order-independent and use longest-match rules, longer prexes subsume
shorter ones as long as they are the same type (whether you specify except or not). This is because
anything that would match the longer prex would also match the shorter one.
Consider the following example:
[edit firewall family inet filter filter_on_src_addr term term1 from]
source-address {
172.16.0.0/10;
172.16.2.0/24 except;
192.168.1.0;
192.168.1.192/26 except;
192.168.1.254;
172.16.3.0/24; # ignored
10.2.2.2 except; # ignored
}
Within the source-address match condion, two addresses are ignored. The 172.16.3.0/16 value is
ignored because it falls under the address 172.16.0.0/10, which is the same type. The 10.2.2.2 except
value is ignored because it is subsumed by the implicit 0.0.0.0/0 except match value.
Suppose the following source IP address are evaluated by this rewall lter:
• Source IP address 172.16.1.2—This address matches the 172.16.0.0/10 prex, and thus the acon in
the then statement is taken.
994
• Source IP address 172.16.2.2—This address matches the 172.16.2.0/24 prex. Because this prex is
negated (that is, includes the except keyword), an explicit
mismatch
occurs. The next term in the lter
is evaluated, if there is one. If there are no more terms, the packet is discarded.
• Source IP address 10.1.2.3—This address does not match any of the prexes included in the source-
address condion. Instead, it matches the implicit 0.0.0.0/0 except at the end of the list of prexes
congured under the source-address match condion, and is considered to be a mismatch.
The 172.16.3.0/24 statement is ignored because it falls under the address 172.16.0.0/10—both are
the same type.
The 10.2.2.2 except statement is ignored because it is subsumed by the implicit 0.0.0.0/0 except
statement at the end of the list of prexes congured under the source-address match condion.
BEST PRACTICE: When a rewall lter term includes the from address
address
match
condion and a subsequent term includes the from source-address
address
match condion
for the same address, packets might be processed by the laer term before they are
evaluated by any intervening terms. As a result, packets that should be rejected by the
intervening terms might be accepted instead, or packets that should be accepted might be
rejected instead.
To prevent this from occurring, we recommend that you do the following. For every rewall
lter term that contains the from address
address
match condion, replace that term with
two separate terms: one that contains the from source-address
address
match condion, and
another that contains the from desnaon-address
address
match condion.
Matching an Address Field to a Prex List
You can dene a list of IPv4 or IPv6 address prexes for use in a roung policy statement or in a
stateless rewall lter match condion that evaluates packet address elds.
To dene a list of IPv4 or IPv6 address prexes, include the prex-list
prex-list
statement.
prefix-list
name
{
ip-addresses
;
apply-path
path
;
}
You can include the statement at the following hierarchy levels:
• [edit policy-opons]
• [edit logical-systems
logical-system-name
policy-opons]
995
Aer you have dened a prex list, you can use it when specifying a rewall lter match condion based
on an IPv4 or IPv6 address prex.
[edit firewall family
family-name
filter
filter-name
term
term-name
]
from {
source-prefix-list {
prefix-lists
;
}
destination-prefix-list {
prefix-lists
;
}
}
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Classes | 996
Firewall Filter Match Condions Based on Address Classes
IN THIS SECTION
Source-Class Usage | 997
Desnaon-Class Usage | 997
Guidelines for Applying SCU or DCU Firewall Filters to Output Interfaces | 997
For IPv4 and IPv6 trac only, you can use class-based
rewall lter
condions to match packet elds
based on source class or desnaon class.
996
Source-Class Usage
A is a set of source prexes grouped together and given a class name. To congure a rewall lter term
that matches an IP source address eld to one or more source classes, use the source-class
class-name
match condion under the [edit firewall family (inet | inet6) filter
filter-name
term
term-name
from]
hierarchy level.
Source-class usage
(SCU) enables you to monitor the amount of trac originang from a specic prex.
With this feature, usage can be tracked and customers can be billed for the trac they receive.
Desnaon-Class Usage
A is a set of desnaon prexes grouped together and given a class name. To congure a rewall lter
term that matches an IP desnaon address eld to one or more desnaon classes, use the destination-
class
class-name
match condion at the [edit firewall family (inet | inet6) filter
filter-name
term
term-name
from] hierarchy level.
Desnaon-class usage
(DCU) enables you can track how much trac is sent to a specic prex in the
core of the network originang from one of the specied interfaces.
Note, however, that DCU limits your ability to keep track of trac moving in the reverse direcon. It can
account for all trac that arrives on a core interface and heads toward a specic customer, but it cannot
count trac that arrives on a core interface from a specic prex.
Guidelines for Applying SCU or DCU Firewall Filters to Output Interfaces
When applying a SCU or DCU rewall lter to an interface, keep the following guidelines in mind:
• Output interfaces—Class-based rewall lter match condions work only for rewall lters that you
apply to output interfaces. This is because the SCU and DCU are determined aer route lookup
occurs.
• Input interfaces—Although you can specify a source class and desnaon class for an input rewall
lter, the counters are incremented only if the rewall lter is applied on the output interface.
• Output interfaces for tunnel trac—SCU and DCU are not supported on the interfaces you congure
as the output interface for tunnel trac for transit packets exing the router (or switch) through the
tunnel.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Match Condions for IPv4 Trac | 942
997
Firewall Filter Match Condions for IPv6 Trac | 959
Junos OS Roung Policies, Firewall Filters, and Trac Policers User Guide
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Fields | 986
Understanding IP-Based Filtering and Selecve Port Mirroring of MPLS
Trac
IN THIS SECTION
IP-Based Filtering of MPLS Trac | 998
Selecve Port Mirroring of MPLS Trac | 999
Sample Conguraons | 1000
In an MPLS packet, the IP header comes immediately aer the MPLS header. The IP-based ltering
feature provides a deep inspecon mechanism, where a maximum of upto eight MPLS labels of the inner
payload can be inspected to enable ltering of MPLS trac based on IP parameters. The ltered MPLS
trac can also be port mirrored to a monitoring device to oer network-based services in the core
MPLS network.
IP-Based Filtering of MPLS Trac
Prior to Junos OS Release 18.4R1, ltering based on IP parameters was not supported for MPLS family
lter. With the introducon of the IP-based ltering feature, you can apply inbound and outbound lters
for MPLS-tagged IPv4 and IPv6 packets based on IP parameters, such as source and desnaon
addresses, Layer 4 protocol type, and source and desnaon ports.
The IP-based ltering feature enables you to lter MPLS packets at the ingress of an interface, where
the ltering is done using match condions on the inner payload of the MPLS packet. The selecve
MPLS trac can then be port mirrored to a remote monitoring device using logical tunnels.
To support IP-based ltering, addional match condions are added that allow MPLS packets to be deep
inspected to parse the inner payload with Layer 3 and Layer 4 headers before the appropriate lters are
applied.
998
NOTE: The IP-based ltering feature is supported only for MPLS-tagged IPv4 and IPv6 packets.
In other words, the MPLS lters match IP parameters only when the IP payload comes
immediately aer the MPLS labels.
In other scenarios, where the MPLS payload includes pseudowires, protocols other than inet and
inet6, or other encapsulaons like Layer 2 VPN or VPLS, the IP-based ltering feature is not
supported.
The following match condions are added for the IP-based ltering of MPLS trac:
• IPv4 source address
• IPv4 desnaon address
• IPv6 source address
• IPv6 desnaon address
• Protocol
• Source port
• Desnaon port
• Source IPv4 prex list
• Desnaon IPv4 prex list
• Source IPv6 prex list
• Desnaon IPv6 prex list
NOTE: The following match combinaons are supported for the IP-based ltering of MPLS
trac:
• Source and desnaon address match condions with IPv4 and IPv6 prex lists.
• Source and desnaon port address and protocol types match condions with IPv4 and IPv6
prex lists.
Selecve Port Mirroring of MPLS Trac
Port mirroring is the capability of mirroring a packet to a congured desnaon, in addion to the
normal processing and forwarding of the packets. Port mirroring is applied as an acon for a rewall
999
lter, which is applied at the ingress or egress of any interface. Similarly, the selecve port mirroring
feature provides the capability to mirror MPLS trac, which is ltered based on IP parameters, to a
mirrored desnaon using logical tunnels.
To enable selecve port mirroring, addional acons are congured at the [edit firewall family mpls
filter
filter-name
term
term-name
then] hierarchy level, in addion to the exisng counter, accept, and discard
acons:
• port-mirror
• port-mirror-instance
Port Mirroring
The port-mirror acon enables port mirroring globally on the device, which applies to all Packet
Forwarding Engines (PFEs) and associated interfaces.
For MPLS family lter, the port-mirror acon is enabled for global port mirroring.
Port Mirroring Instance
The port-mirror-instance acon enables you to customize each instance with dierent properes for input
sampling and port mirroring output desnaons, instead of having to use a single system-wide
conguraon for port mirroring.
You can congure only two port mirroring instances per Flexible PIC Concentrator (FPC) by including the
instance
port-mirror-instance-name
statement at the [edit forwarding-options port-mirror] hierarchy level. You
can then associate individual port mirroring instances with an FPC, PIC, or (Forwarding Engine Board
(FEB) depending on the device hardware.
For MPLS family lter, the port-mirror-instance acon is enabled only for the port-mirroring instance.
NOTE: For both port-mirror and port-mirror-instance acons, the output interface must be enabled
with Layer 2 family and not family MPLS (Layer 3) for the selecve port mirroring feature to
work.
Sample Conguraons
IP-Based Filtering Conguraon
[edit firewall family mpls filter
mpls-filter
]
term ipv4-term {
from {
1000
ip-version {
ipv4 {
source-address {
10.10.10.10/24;
}
destination-address {
20.20.20.20/24;
}
protocol tcp {
source-port 100;
destination-port 200;
}
soure-prefix-list ipv4-source-users;
destination-prefix-list ipv4-destination-users;
}
}
exp 1;
}
then port-mirror;
then accept;
then count;
}
term ipv6-term {
from {
ip-version {
ipv6 {
source-address {
2000::1/128;
}
destination-address {
3000::1/128;
}
protocol tcp {
source-port 100;
destination-port 200;
}
source-prefix-list ipv6-source-users;
destination-prefix-list ipv6-destination-users;
}
}
exp 1;
}
then port-mirror-instance port-mirror-instance1;
1001
then accept;
then count;
}
[edit policy-options]
prefix-list ipv4-source-users {
172.16.1.16/28;
172.16.2.16/28;
}
prefix-list ipv6-source-users {
2001::1/128;
3001::1/128;
}
[edit interfaces]
xe-0/0/1 {
unit 0 {
family inet {
address 100.100.100.1/30;
}
family mpls {
filter {
input mpls-filter;
}
}
}
}
Selecve Port Mirroring Conguraon
[edit forwarding-options]
port-mirroring {
input {
rate 2;
run-length 4;
maximum-packet-length 500;
}
family any {
1002
output {
interface xe-2/0/2.0;
}
}
}
[edit forwarding-options]
port-mirroring {
instance {
port-mirror-instance1 {
input {
rate 3;
run-length 5;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
}
}
NOTE: The output interface xe-2/0/2.0 is congured for Layer 2 family and not family MPLS.
For both port-mirror and port-mirror-instance acons, the output interface must be enabled with
Layer 2 family and not family MPLS (Layer 3) for the selecve port mirroring feature to work.
Mirrored Desnaon Conguraon
[edit interfaces]
xe-2/0/2 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
1003
}
}
[edit bridge-domains]
bd {
domain-type bridge;
interface xe-2/0/2.0;
}
Firewall Filter Match Condions for MPLS Trac
You can congure a rewall lter with match condions for MPLS trac (family mpls).
•
The input-list
filter-names
and output-list
filter-names
statements for rewall lters for the mpls
protocol family are supported on all interfaces except for management interfaces and internal
Ethernet interfaces (fxp or em0), loopback interfaces (lo0), and USB modem interfaces (umd)
• (QFX5100, QFX5110, QFX5200, QFX5210) If you are applying an MPLS lter on a loopback
interface, you can only lter on the label, exp, ttl=1, and Layer 4 tcp and udp port number elds. For
TTL, you must explicitly specify ttl=1 under family mpls to match on TTL=1 packets. The only acons
you can congure are accept, discard, and count. You can apply the lter only in the ingress direcon.
• For MX Series Routers with MPC and MIC, you can apply inbound and outbound lters for MPLS
family based on MPLS-tagged IPv4 and IPv6 parameters using inner payload match condions, and
enable selecve port mirroring of MPLS trac unto a monitoring device (starng in Junos OS
Release 18.4R1). For IP-based ltering, addional match condions are available under the MPLS
lter term from parameter, and to support port mirroring, addional acons (such as port-mirror and
port-mirror-instance), are available under the lter term thenparameter.
Table 56 on page 1004 describes the
match-conditions
you can congure at the [edit firewall family mpls
filter
filter-name
term
term-name
from] hierarchy level.
Table 56: Firewall Filter Match
Condions for MPLS Trac
Match Condion Descripon
apply-groups
Specify which groups to inherit conguraon data from. You can specify more than
one group name. You must list them in order of inheritance priority. The conguraon
data in the rst group takes priority over the data in subsequent groups.
1004
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
apply-groups-except
Specify which groups not to inherit conguraon data from. You can specify more
than one group name.
destination-port
number
Match on the UDP or TCP desnaon port eld.
In place of the numeric value, you can specify one of the following text synonyms
(the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515),
radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161),
snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
exp
number
Experimental (EXP) bit number or range of bit numbers in the MPLS header of a
packet.
For
number
, you can specify one or more values from 0 through 7 in binary, decimal
or hexadecimal format, as given below:
• A single EXP bit—for example, exp 3
• Several EXP bits—for example, exp 0,4
•
A range of EXP bits—for example, exp [0-5]. These values are not supported on
lters applied to the loopback interface.
NOTE: This match condion is deprecated on PTX10001-36MR, PTX10003,
PTX10004, PTX10008, and PTX10016 devices and is replaced by exp0
number
.
exp-except
number
Do not match on the EXP bit number or range of bit numbers in the MPLS header.
For
number
, you can specify one or more values from 0 through 7.
NOTE: This match condion is deprecated on PTX10001-36MR, PTX10003,
PTX10004, PTX10008, and PTX10016 devices and is replaced by exp0-except.
1005
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
exp0
number
Experimental (EXP) bit number or range of bit numbers in the TOS MPLS header of a
packet.
For
number
, you can specify one or more values from 0 through 7 in binary, decimal
or hexadecimal format, as given below:
• A single EXP bit—for example, exp0 3
• Several EXP bits—for example, exp0 0,4
•
A range of EXP bits—for example, exp0 [0-5]. These values are not supported on
lters applied to the loopback interface.
exp0-except
number
Do not match EXP bit number or range of bit numbers in the TOS MPLS header of a
packet.
For
number
, you can specify one or more values from 0 through 7 in binary, decimal
or hexadecimal format, as given below:
• A single EXP bit—for example, exp0-except 3
• Several EXP bits—for example, exp0-except 0,4
•
A range of EXP bits—for example, exp0-except [0-5]. These values are not
supported on lters applied to the loopback interface.
exp1
number
Experimental (EXP) bit number or range of bit numbers in the MPLS header that is
next to the TOS (top of stack) MPLS header.
For
number
, you can specify one or more values from 0 through 7 in binary, decimal
or hexadecimal format, as given below:
• A single EXP bit—for example, exp1 3
• Several EXP bits—for example, exp1 0,4
•
A range of EXP bits—for example, exp1 [0-5]. These values are not supported on
lters applied to the loopback interface.
1006
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
exp1-except
number
Do not match on the EXP bit number or range of bit numbers in the MPLS header
next to the TOS MPLS header.
For
number
, you can specify one or more values from 0 through 7 in binary, decimal
or hexadecimal format, as given below:
• A single EXP bit—for example, exp1-except 3
• Several EXP bits—for example, exp1-except 0,4
•
A range of EXP bits—for example, exp1-except [0-5]. These values are not
supported on lters applied to the loopback interface.
forwarding-class
class
Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or
network-control.
NOTE: On PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016 routers,
exp0 or exp1 bits are used to obtain the forwarding class.
forwarding-class-except
class
Do not match on the forwarding class. Specify assured-forwarding, best-effort,
expedited-forwarding, or network-control.
interface
interface-name
Interface on which the packet was received. You can congure a match condion that
matches packets based on the interface on which they were received.
NOTE: If you congure this match condion with an interface that does not exist, the
term does not match any packet.
interface-set
interface-
set-name
Match the interface on which the packet was received to the specied interface set.
To dene an interface set, include the interface-set statement at the [edit firewall]
hierarchy level.
NOTE: This match condion is not supported on PTX series packet transport routers.
For more informaon, see "Filtering Packets Received on an Interface Set Overview"
on page 1378.
1007
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
ip-version
number
Match inner IP version. For example, to match MPLS-tagged IPv4 packets, match on
the text synonym ipv4. Within ip-version
number
you can further match packets based
on source and desnaon addresses and ports. Refer Table 58 on page 1015 and
Table 59 on page 1016.
label
number
MPLS label value or range of label values in the MPLS header of a packet.
For
number
, you can specify one or more values from 0 through 1048575 in decimal
or hexadecimal format, as given below:
• A single label—for example, label 3
• Several labels—for example, label 0,4
• A range of labels—for example, label [0-5]. These values are not supported on
lters applied to the loopback interface.
NOTE: This opon is deprecated on PTX10001-36MR, PTX10003, PTX10004,
PTX10008, and PTX10016 devices and is replaced by label0.
label0
number
MPLS label value or range of label values in the TOS MPLS header of a packet.
For
number
, you can specify one or more values from 0 through 1048575 in decimal
or hexadecimal format, as given below:
• A single label—for example, label0 3
• Several labels—for example, label0 0,4
• A range of labels—for example, label0 [0-5]. These values are not supported on
lters applied to the loopback interface.
1008
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
label0-except
number
Do not match MPLS label value or range of label values in the TOS MPLS header of a
packet.
For
number
, you can specify one or more values from 0 through 1048575 in decimal
or hexadecimal format, as given below:
• A single label—for example, label0-except 3
• Several labels—for example, label0-except 0,4
•
A range of labels—for example, label0-except [0-5]. These values are not
supported on lters applied to the loopback interface.
label1
number
Match the MPLS label value or range of label values in the MPLS header label of the
MPLS header that is next to the TOS MPLS header.
For
number
, you can specify one or more values from 0 through 1048575 in decimal
or hexadecimal format, as given below:
• A single label—for example, label1 3
• Several labels—for example, label1 0,4
•
A range of labels—for example, label1 [0-5]. These values are not supported on
lters applied to the loopback interface.
label1-except
number
Do not match on the MPLS label value or range of label values in the MPLS header
label of the MPLS header that is next to the TOS MPLS header.
For
number
, you can specify one or more values from 0 through 1048575 in decimal
or hexadecimal format, as given below:
• A single label—for example, label1-except 3
• Several labels—for example, label1-except 0,4
•
A range of labels—for example, label1-except [0-5]. These values are not
supported on lters applied to the loopback interface.
1009
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
label
number
top | bottom
| offset
oset-value
Match top label, or boom label or the label at a specied oset (from the top or
boom of the label stack) of the incoming MPLS packet.
• top - Match with reference to top-of-stack towards boom-of-stack.
• bottom - Match with reference to boom-of-stack towards top-of-stack.
• offset
<oset-value>
- Match with reference to MPLS stack depth with respect to
top or boom of stack, where
oset-value
= (0..15).
• label
number
top offset
oset-value
- MPLS top label lter match with an
oset to stack sanding from 0 to 15. 0 being the rst label posion from top
of stack for both implicit and CLI lters.
• label
number
bottom offset
oset-value
- MPLS boom label lter match with
an oset to stack sanding from 0 to 15. 0 being the rst label posion from
boom of stack for both implicit and CLI lters.
• label
number
offset
oset-value
- If no opons, top or boom, are provided
next to label
number
then the default match starts from top-of-stack with
given oset. In other words, label number oset [n = 0..15] is equivalent to
label number top oset [n = 0..15].
• label
number
- If no opons are provided next to label
number
then the default
match will be done on top label (implicit oset 0 and anchor point being top-of-
stack).
NOTE:
• Filter match on label with oset out of the MPLS stack depth might not give the
expected behaviour.
• For lter label match with posion as boom, if oset is out of MPLS stack
depth then lter will always match on end-of-stack label.
• For lter match with posion as top, if oset is out of MPLS stack depth, will
point to pay load to match against the congured label.
NOTE: The conguraon command opons are introduced in Junos Release 22.3R1.
1010
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
loss-priority
level
Match the packet loss priority (PLP) level.
Specify a single level or mulple levels: low, medium-low, medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced
CFEB (CFEB-E); and MX Series routers and EX Series switches.
For IP trac on M320, MX Series, and T Series routers with Enhanced II Flexible PIC
Concentrators (FPCs), and EX Series switches, you must include the tri-color
statement at the [edit class-of-service] hierarchy level to commit a PLP
conguraon with any of the four levels specied. If the tri-color statement is not
enabled, you can only congure the high and low levels. This applies to all protocol
families.
For informaon about the tri-color statement, see
Conguring and Applying Tricolor
Marking Policers
. For informaon about using behavior aggregate (BA) classiers to
set the PLP level of incoming packets, see
Understanding How Forwarding Classes
Assign Classes to Output Queues
.
NOTE: On PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016 routers,
exp0 or exp1 bits are used to obtain the loss priority.
loss-priority-except
level
Do not match the PLP level. For details, see the loss-priority match condion.
NOTE: This match condion is not supported on PTX series packet transport routers.
source-port
number
Match on the TCP or UDP source port eld.
You cannot specify the port and source-port match condions in the same term.
If you congure this match condion for IPv4 trac, we recommend that you also
congure the protocol udp or protocol tcp match statement in the same term to
specify which protocol is being used on the port.
In place of the numeric eld, you can specify one of the text synonyms listed under
destination-port.
ttl0
number
Match TTL number or range of numbers in the TOS MPLS header of a packet. Time
To Live (TTL) is an 8-bit eld in the MPLS label that signies the remaining me that a
packet has le before its life ends and is dropped.
For
number
, you can specify a value from 0 through 255.
1011
Table 56: Firewall Filter Match Condions for MPLS Trac
(Connued)
Match Condion Descripon
ttl0-except
number
Do not match TTL number or range of numbers in the TOS MPLS header of a packet.
Time To Live (TTL) is an 8-bit eld in the MPLS label that signies the remaining me
that a packet has le before its life ends and is dropped.
For
number
, you can specify a value from 0 through 255.
ttl1
number
Match TTL number or range of numbers in the MPLS header that is next to the TOS
MPLS header of a packet. Time To Live (TTL) is an 8-bit eld in the MPLS label that
signies the remaining me that a packet has le before its life ends and is dropped.
For
number
, you can specify a value from 0 through 255.
ttl1-except
number
Do not match TTL number or range of numbers in the MPLS header that is next to
the TOS MPLS header of a packet. Time To Live (TTL) is an 8-bit eld in the MPLS
label that signies the remaining me that a packet has le before its life ends and is
dropped.
For
number
, you can specify a value from 0 through 255.
NOTE: exp0, exp0-except, exp1, exp1-except, ip-version, label0, label0-except, label1, label1-except, ttl0,
ttl0-except, ttl1, and ttl1-except are only supported on PTX10001-36MR, PTX10003, PTX10004,
PTX10008, PTX10016.
Table 57 on page 1012 describes the acons you can congure for MPLS rewall lters at the [edit
firewall family mpls filter
filter-name
term
term-name
then] hierarchy level.
Table 57: Supported
Acons for MPLS Firewall Filters
Acon Descripon
accept
Accept a packet
1012
Table 57: Supported Acons for MPLS Firewall Filters
(Connued)
Acon Descripon
count
counter-name
Count the number of packets that pass this lter or term.
NOTE: We recommend that you congure a counter for each term in a
rewall lter, so that you can monitor the number of packets that match
the condions specied in each lter term.
discard
Discard a packet silently without sending an Internet Control Message
Protocol (ICMP) message
policer
Starng with Junos OS 13.2X51-D15, you can send trac matched by an
MPLS lter to a two-color policer.
three-color-policer
Starng with Junos OS 13.2X51-D15, you can send trac matched by an
MPLS lter to a three-color policer.
RELATED DOCUMENTATION
Overview of MPLS Firewall Filters on Loopback Interface | 1838
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
Firewall Filter Nonterminang Acons | 873
Firewall Filter Match Condions for MPLS-Tagged IPv4 or IPv6 Trac
IN THIS SECTION
Matching on IPv4 or IPv6 Packet Header Address or Port Fields in MPLS Flows | 1014
IP Address Match Condions for MPLS Trac | 1014
IP Port Match Condions for MPLS Trac | 1015
1013
Matching on IPv4 or IPv6 Packet Header Address or Port Fields in MPLS Flows
To support network-based service in a core network, you can congure a rewall lter that matches
Internet Protocol version 4 (IPv4) or version 6 (IPv6) packet header elds in MPLS trac (family mpls).
The rewall lter can match IPv4 or IPv6 packets as an inner payload of an MPLS packet that has a
single MPLS label or up to ve MPLS labels stacked together. You can congure match condions based
on IPv4 addresses and IPv4 port numbers or IPv6 addresses and IPv6 port numbers in the header.
Firewall lters based on MPLS-tagged IPv4 headers are supported for interfaces on Enhanced Scaling
exible PIC concentrators (FPCs) on T320, T640, T1600, TX Matrix, and TX Matrix Plus routers and
switches only. However, the rewall lters based on MPLS-tagged IPv6 headers are supported for
interfaces on the Type 5 FPC on T4000 Core Routers only. The feature is not supported for the router or
switch loopback interface (lo0), the router or switch management interface (fxp0 or em0), or USB modem
interfaces (umd).
To congure a rewall lter term that matches an address or port elds in the Layer 4 header of packets
in an MPLS ow, you use the ip-version ipv4 match condion to specify that the term is to match packets
based on inner IP elds:
• To match an MPLS-tagged IPv4 packet on the source or desnaon address eld in the IPv4 header,
specify the match condion at the [edit firewall family mpls filter
filter-name
term
term-name
from ip-
version ipv4] hierarchy level.
• To match an MPLS-tagged IPv4 packet on the source or desnaon port eld in the Layer 4 header,
specify the match condion at the [edit firewall family mpls filter
filter-name
term
term-name
from ip-
version ipv4 protocol (udp | tcp)] hierarchy level.
To congure a rewall lter term that matches an address or port elds in the IPv6 header of packets in
an MPLS ow, you use the ip-version ipv6 match condion to specify that the term is to match packets
based on inner IP elds:
• To match an MPLS-tagged IPv6 packet on the source or desnaon address eld in the IPv6 header,
specify the match condion at the [edit firewall family mpls filter
filter-name
term
term-name
from ip-
version ipv6] hierarchy level.
• To match an MPLS-tagged IPv6 packet on the source or desnaon port eld in the Layer 4 header,
specify the match condion at the [edit firewall family mpls filter
filter-name
term
term-name
from ip-
version ipv6 protocol (udp | tcp)] hierarchy level.
IP Address Match Condions for MPLS Trac
Table 58 on page 1015 describes the IP address-specic match condions you can congure at the [edit
firewall family mpls filter
filter-name
term
term-name
from ip-version
ip-version
] hierarchy level.
1014
Table 58: IP Address-Specic Firewall Filter Match Condions for MPLS Trac
Match Condion Descripon
destination-address
address
Match the address of the desnaon node to receive the packet.
destination-address
address
except
Do not match the address of the desnaon node to receive the packet.
protocol
number
Match the IP protocol type eld. In place of the numeric value, you can specify one of
the following text synonyms (the eld values are also listed): ah (51), dstopts (60),
egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58),
igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6), udp (17), or
vrrp (112).
source-address
address
Match the address of the source node sending the packet.
source-address
address
except
Do not match the address of the source node sending the packet.
IP Port Match Condions for MPLS Trac
Table 59 on page 1016 describes the IP port-specic
match-conditions
you can congure at the [edit
firewall family mpls filter
filter-name
term
term-name
from ip-version
ip-version
protocol (udp | tcp )]
hierarchy level.
1015
Table 59: IP Port-Specic Firewall Filter Match Condions for MPLS Trac
Match Condion Descripon
destination-port
number
Match on the UDP or TCP desnaon port eld.
In place of the numeric value, you can specify one of the following text synonyms
(the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515),
radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161),
snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except
number
Do not match on the UDP or TCP desnaon port eld.
In place of the numeric value, you can specify one of the text synonyms listed with
the destination-port match condion.
source-port
number
Match on the TCP or UDP source port eld.
In place of the numeric eld, you can specify one of the text synonyms listed under
destination-port.
source-port-except
number
Do not match on the TCP or UDP source port eld.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
Firewall Filter Nonterminang Acons | 873
1016
Firewall Filter Match Condions for VPLS Trac
In the from statement in the VPLS lter term, you specify condions that the packet must match for the
acon in the then statement to be taken. All condions in the from statement must match for the acon
to be taken. The order in which you specify match condions is not important, because a packet must
match all the condions in a term for a match to occur.
If you specify no match condions in a term, that term matches all packets.
An individual condion in a from statement can contain a list of values. For example, you can specify
numeric ranges. You can also specify mulple source addresses or desnaon addresses. When a
condion denes a list of values, a match occurs if one of the values in the list matches the packet.
Individual condions in a from statement can be negated. When you negate a condion, you are dening
an explicit mismatch. For example, the negated match condion for forwarding-class is forwarding-class-
except. If a packet matches a negated condion, it is immediately considered not to match the from
statement, and the next term in the lter is evaluated, if there is one. If there are no more terms, the
packet is discarded.
You can congure a rewall lter with match condions for Virtual Private LAN Service (VPLS) trac
(family vpls). Table 60 on page 1017 describes the
match-conditions
you can congure at the [edit firewall
family vpls filter
filter-name
term
term-name
from] hierarchy level.
NOTE: Not all match condions for VPLS trac are supported on all roung plaorms or
switching plaorms. A number of match condions for VPLS trac are supported only on MX
Series 5G Universal Roung Plaorms.
In the VPLS documentaon, the word
router
in terms such as
PE router
is used to refer to any
device that provides roung funcons.
Table 60: Firewall Filter Match
Condions for VPLS Trac
Match Condion Descripon
destination-mac-address
address
Match the desnaon media access control (MAC) address of a VPLS packet.
1017
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
destination-port
number
(MX Series routers and EX Series switches only) Match the UDP or TCP desnaon
port eld.
You cannot specify both the port and destination-port match condions in the same
term.
In place of the numeric value, you can specify one of the following text synonyms
(the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515),
radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161),
snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except
number
(MX Series routers and EX Series switches only) Do not match on the TCP or UDP
desnaon port eld. You cannot specify both the port and destination-port match
condions in the same term.
destination-prefix-list
name
(ACX Series routers, MX Series routers, and EX Series switches only) Match
desnaon prexes in the specied list. Specify the name of a prex list dened at
the [edit policy-options prefix-list
prefix-list-name
] hierarchy level.
NOTE: VPLS prex lists support only IPv4 addresses. IPv6 addresses included in a
VPLS prex list will be discarded.
destination-prefix-list
name
except
(MX Series routers and EX Series switches only) Do not match desnaon prexes in
the specied list. For more informaon, see the destination-prefix-list match
condion.
1018
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
dscp
number
(MX Series routers and EX Series switches only) Match the Dierenated Services
code point (DSCP). The DiServ protocol uses the type-of-service (ToS) byte in the IP
header. The most signicant 6 bits of this byte form the DSCP. For more informaon,
see the Understanding How Behavior Aggregate Classiers Priorize Trusted Trac.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed):
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
•
RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
af11 (10), af12 (12), af13 (14),
af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30),
af41 (34), af42 (36), af43 (38)
dscp-except
number
(MX Series routers and EX Series switches only) Do not match on the DSCP. For
details, see the dscp match condion.
1019
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
ether-type
values
Match the 2-octet IEEE 802.3 Length/EtherType eld to the specied value or list of
values.
You can specify decimal or hexadecimal values from 0 through 65535 (0xFFFF). A
value from 0 through 1500 (0x05DC) species the length of an Ethernet Version 1
frame. A value from 1536 (0x0600) through 65535 species the EtherType (nature of
the MAC client protocol) of an Ethernet Version 2 frame.
In place of the numeric value, you can specify one of the following text synonyms
(the hexadecimal values are also listed): aarp (0x80F3), appletalk (0x809B),
arp (0x0806), ipv4 (0x0800), ipv6 (0x86DD), mpls-multicast (0x8848), mpls-
unicast (0x8847), oam (0x8902), ppp (0x880B), pppoe-discovery (0x8863), pppoe-
session (0x8864), or sna (0x80D5).
ether-type-except
values
Do not match the 2-octet Length/EtherType eld to the specied value or list of
values.
For details about specifying the
values
, see the ether-type match condion.
flexible-match-mask
value
bit-length
Starng in Junos OS 14.2, exible oset
lters are supported in rewall hierarchy
conguraons.
Length of the data to be matched in bits, not
needed for string input (0..128)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-mask-name
Select a exible match from predened
template eld
mask-in-hex
Mask out bits in the packet data to be
matched
1020
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
match-start
Start point to match in packet
prefix
Value data/string to be matched
flexible-match-range
value
bit-length
Length of the data to be matched in bits
(0..32)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-range-name
Select a exible match from predened
template eld
match-start
Start point to match in packet
range
Range of values to be matched
range-except
Do not match this range of values
forwarding-class
class
Match the forwarding class. Specify assured-forwarding, best-effort, expedited-
forwarding, or network-control.
forwarding-class-except
class
Do not match the forwarding class. For details, see the forwarding-class match
condion.
1021
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
icmp-code
message-code
Match the ICMP message code eld.
If you congure this match condion, we recommend that you also congure the
next-header icmp or next-header icmp6 match condion in the same term.
If you congure this match condion, you must also congure the icmp-type
message-
type
match condion in the same term. An ICMP message code provides more
specic informaon than an ICMP message type, but the meaning of an ICMP
message code is dependent on the associated ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed). The keywords are grouped by the ICMP type with
which they are associated:
• parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-
option (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• desnaon-unreachable: address-unreachable (3), administratively-prohibited (1),
no-route-to-destination (0), port-unreachable (4)
icmp-code-except
message-code
Do not match the ICMP message code eld. For details, see the icmp-code match
condion.
1022
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
icmp-code
number
(MX Series routers and EX Series switches only) Match the ICMP message code eld.
If you congure this match condion, we recommend that you also congure the ip-
protocol icmp or ip-protocol icmp6 match condion in the same term.
If you congure this match condion, you must also congure the icmp-type
message-
type
match condion in the same term. An ICMP message code provides more
specic informaon than an ICMP message type, but the meaning of an ICMP
message code is dependent on the associated ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed). The keywords are grouped by the ICMP type with
which they are associated:
• parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-
option (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• desnaon-unreachable: address-unreachable (3), administratively-prohibited (1),
no-route-to-destination (0), port-unreachable (4)
icmp-code-except
number
(MX Series routers and EX Series switches only) Do not match on the ICMP code
eld. For details, see the icmp-code match condion.
interface
interface-name
Interface on which the packet was received. You can congure a match condion that
matches packets based on the interface on which they were received.
NOTE: If you congure this match condion with an interface that does not exist, the
term does not match any packet.
1023
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
interface-group
group-
number
Match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For
group-number
, specify a single value or a
range of values from 0 through 255.
To assign a logical interface to an interface group
group-number
, specify the
group-
number
at the [interfaces
interface-name
unit
number
family
family
filter group]
hierarchy level.
For more informaon, see Filtering Packets Received on a Set of Interface Groups
Overview.
NOTE: This match condion is not supported on T4000 Type 5 FPCs.
interface-group-except
group-name
Do not match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For details, see the interface-group match
condion.
NOTE: This match condion is not supported on T4000 Type 5 FPCs.
interface-set
interface-
set-name
Match the interface on which the packet was received to the specied interface set.
To dene an interface set, include the interface-set statement at the [edit firewall]
hierarchy level. For more informaon, see Filtering Packets Received on an Interface
Set Overview.
ip-address
address
(MX Series routers and EX Series switches only) 32-bit address that supports the
standard syntax for IPv4 addresses.
Note that when using this term, the match condion ether-type IPv4 must be dened
on the same term.
ip-destination-address
address
(MX Series routers and EX Series switches only) 32-bit address that is the nal
desnaon node address for the packet.
Note that when using this term, the match condion ether-type IPv4 must be dened
on the same term.
1024
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
ip-precedence
ip-
precedence-field
(MX Series routers and EX Series switches only) IP precedence eld. In place of the
numeric eld value, you can specify one of the following text synonyms (the eld
values are also listed): critical-ecp (0xa0), flash (0x60), flash-override (0x80),
immediate (0x40), internet-control (0xc0), net-control (0xe0), priority (0x20), or
routine (0x00).
ip-precedence-except
ip-
precedence-field
(MX Series routers and EX Series switches only) Do not match on the IP precedence
eld.
ip-protocol
number
(MX Series routers and EX Series switches only) IP protocol eld.
ip-protocol-except
number
(MX Series routers and EX Series switches only) Do not match on the IP protocol
eld.
ip-source-address
address
(MX Series routers and EX Series switches only) IP address of the source node
sending the packet.
Note that when using this term, the match condion ether-type IPv4 must also be
dened on the same term.
ipv6-source-prefix-list
named-list
(MX Series only) Match the IPv6 source address in a
named-list
.
ipv6-address
address
(MX Series and EX9200 only) 128-bit address that supports the standard syntax for
IPv6 addresses. Starng in Junos OS 14.2, rewall family bridge IPv6 match criteria is
supported on MX Series and EX9200 switches.
ipv6-destination-address
address
((MX Series and EX9200 only) 128-bit address that is the nal desnaon node
address for this packet. Note that when using this term, the match condion ether-
type IPv6 must be dened on the same term.
1025
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
ipv6-destination-prefix-
list
named-list
(MX Series only) Match the IPv6 desnaon addresses in a
named-list
.
1026
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
ipv6-next-header
protocol
(MX Series only) Match IPv6 next header protocol type.
The following list shows the supported values for
protocol
:
• ah—IP Security authencaon header
• dstopts—IPv6 desnaon opons
• egp—Exterior gateway protocol
• esp—IPSec Encapsulang Security Payload
•
fragment—IPv6 fragment header
•
gre—Generic roung encapsulaon
•
hop-by-hop—IPv6 hop by hop opons
•
icmp—Internet Control Message Protocol
• icmp6—Internet Control Message Protocol Version 6
• igmp—Internet Group Management Protocol
• ipip—IP in IP
• ipv6—IPv6 in IP
• no-next-header—IPv6 no next header
• ospf—Open Shortest Path First
• pim—Protocol Independent Mulcast
• roung—IPv6 roung header
• rsvp—Resource Reservaon Protocol
• sctp—Stream Control Transmission Protocol
• tcp—Transmission Control Protocol
• udp—User Datagram Protocol
1027
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
• vrrp—Virtual Router Redundancy Protocol
ipv6-next-header-except
protocol
(MX Series only) Do not match the IPv6 next header protocol type.
1028
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
ipv6-payload-protocol
protocol
(MX Series only) Match IPv6 payload protocol type.
The following list shows the supported values for
protocol
:
• ah—IP Security authencaon header
• dstopts—IPv6 desnaon opons
• egp—Exterior gateway protocol
• esp—IPSec Encapsulang Security Payload
•
fragment—IPv6 fragment header
•
gre—Generic roung encapsulaon
•
hop-by-hop—IPv6 hop by hop opons
•
icmp—Internet Control Message Protocol
• icmp6—Internet Control Message Protocol Version 6
• igmp—Internet Group Management Protocol
• ipip—IP in IP
• ipv6—IPv6 in IP
• no-next-header—IPv6 no next header
• ospf—Open Shortest Path First
• pim—Protocol Independent Mulcast
• roung—IPv6 roung header
• rsvp—Resource Reservaon Protocol
• sctp—Stream Control Transmission Protocol
• tcp—Transmission Control Protocol
• udp—User Datagram Protocol
1029
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
• vrrp—Virtual Router Redundancy Protocol
ipv6-payload-protocol-
except
protocol
(MX Series only) Do not match the IPv6 payload protocol.
ipv6-prefix-list
named-
list
(MX Series only) Match the IPv6 address in a
named-list
.
ipv6-source-address
address
(MX Series only) 128-bit address that is the originang source node address for this
packet.
ipv6-traffic-class
number
(MX Series only) Dierenated Services code point (DSCP). The DiServ protocol
uses the type-of-service (ToS) byte in the IP header. The most signicant 6 bits of this
byte form the DSCP. For more informaon, see Understanding How Behavior
Aggregate Classiers Priorize Trusted Trac.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed):
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
•
RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
af11 (10), af12 (12), af13 (14),
af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30),
af41 (34), af42 (36), af43 (38)
1030
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
ipv6-traffic-class-
except
number
Do not match the DSCP number.
learn-vlan-1p-priority
number
(MX Series routers, M320 router, and EX Series switches only) Match on the
IEEE 802.1p learned VLAN priority bits in the provider VLAN tag (the only tag in a
single-tag frame with 802.1Q VLAN tags or the outer tag in a dual-tag frame with
802.1Q VLAN tags). Specify a single value or mulple values from 0 through 7.
Compare with the user-vlan-1p-priority match condion.
NOTE: This match condion supports the presence of a control word for MX Series
routers and the M320 router.
learn-vlan-1p-priority-
except
number
(MX Series routers, M320 router, and EX Series switches only) Do not match on the
IEEE 802.1p learned VLAN priority bits. For details, see the learn-vlan-1p-priority
match condion.
NOTE: This match condion supports the presence of a control word for MX Series
routers and the M320 router.
learn-vlan-dei
(MX Series routers and EX Series switches only) Match the user VLAN ID drop
eligability indicator (DEI) bit.
learn-vlan-dei-except
(MX Series routers and EX Series switches only) Do not match the user VLAN ID DEI
bit.
learn-vlan-id
number
(MX Series routers and EX Series switches only) VLAN idener used for MAC
learning.
learn-vlan-id-except
number
(MX Series routers and EX Series switches only) Do not match on the VLAN idener
used for MAC learning.
1031
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
loss-priority
level
Packet loss priority (PLP) level. Specify a single level or mulple levels: low, medium-low,
medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced
CFEB (CFEB-E); and MX Series routers.
For IP trac on M320, MX Series, and T Series routers with Enhanced II Flexible PIC
Concentrators (FPCs) and EX Series switches, you must include the tri-color
statement at the [edit class-of-service] hierarchy level to commit a PLP
conguraon with any of the four levels specied. If the tri-color statement is not
enabled, you can only congure the high and low levels. This applies to all protocol
families.
For informaon about the tri-color statement and about using behavior aggregate
(BA) classiers to set the PLP level of incoming packets, see Understanding How
Forwarding Classes Assign Classes to Output Queues.
loss-priority-except
level
Do not match on the packet loss priority level. Specify a single level or mulple levels:
low, medium-low, medium-high, or high.
For informaon about using behavior aggregate (BA) classiers to set the PLP level of
incoming packets, see Understanding How Behavior Aggregate Classiers Priorize
Trusted Trac.
port
number
(MX Series routers and EX Series switches only) TCP or UDP source or desnaon
port. You cannot specify both the port match condion and either the destination-
port or source-port match condion in the same term.
port-except
number
(MX Series routers and EX Series switches only) Do not match on the TCP or UDP
source or desnaon port. You cannot specify both the port match condion and
either the destination-port or source-port match condion in the same term.
1032
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
prefix-list
name
(MX Series routers and EX Series switches only) Match the desnaon or source
prexes in the specied list. Specify the name of a prex list dened at the [edit
policy-options prefix-list
prefix-list-name
] hierarchy level.
NOTE: VPLS prex lists support only IPV4 addresses. IPV6 addresses included in a
VPLS prex list will be discarded.
prefix-list
name
except
(MX Series routers and EX Series switches only) Do not match the desnaon or
source prexes in the specied list. For more informaon, see the destination-prefix-
list match condion.
source-mac-address
address
Source MAC address of a VPLS packet.
source-port
number
(MX Series routers and EX Series switches only) TCP or UDP source port eld. You
cannot specify the port and source-port match condions in the same term.
source-port-except
number
(MX Series routers and EX Series switches only) Do not match on the TCP or UDP
source port eld. You cannot specify the port and source-port match condions in the
same term.
source-prefix-list
name
(ACX Series routers, MX Series routers, and EX Series switches only) Match the
source prexes in the specied prex list. Specify a prex list name dened at the
[edit policy-options prefix-list
prefix-list-name
] hierarchy level.
NOTE: VPLS prex lists support only IPV4 addresses. IPV6 addresses included in a
VPLS prex list will be discarded.
source-prefix-list
name
except
(MX Series routers and EX Series switches only) Do not match the source prexes in
the specied prex list. For more informaon, see the source-prefix-list match
condion.
1033
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
tcp-flags
flags
Match one or more of the low-order 6 bits in the 8-bit TCP ags eld in the TCP
header.
To specify individual bit elds, you can specify the following text synonyms or
hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag
is set in all packets sent aer the inial packet.
You can string together mulple ags using the bit-eld logical operators.
If you congure this match condion for IPv6 trac, we recommend that you also
congure the next-header tcp match condion in the same term to specify that the
TCP protocol is being used on the port.
traffic-type
type-name
(MX Series routers and EX Series switches only) Trac type. Specify broadcast,
multicast, unknown-unicast, or known-unicast.
traffic-type-except
type-name
(MX Series routers and EX Series switches only) Do not match on the trac type.
Specify broadcast, multicast, unknown-unicast, or known-unicast.
1034
Table 60: Firewall Filter Match Condions for VPLS Trac
(Connued)
Match Condion Descripon
user-vlan-1p-priority
number
(MX Series routers, M320 router, and EX Series switches only) Match on the IEEE
802.1p user priority bits in the customer VLAN tag (the inner tag in a dual-tag frame
with 802.1Q VLAN tags). Specify a single value or mulple values from 0 through 7.
Compare with the learn-vlan-1p-priority match condion.
NOTE: This match condion supports the presence of a control word for MX Series
routers and the M320 router.
user-vlan-1p-priority-
except
number
(MX Series routers, M320 rouer, and EX Series switches only) Do not match on the
IEEE 802.1p user priority bits. For details, see the user-vlan-1p-priority match
condion.
NOTE: This match condion supports the presence of a control word for MX Series
routers and the M320 router.
user-vlan-id
number
(MX Series routers and EX Series switches only) Match the rst VLAN idener that
is part of the payload.
user-vlan-id-except
number
(MX Series routers and EX Series switches only) Do not match on the rst VLAN
idener that is part of the payload.
vlan-ether-type
value
VLAN Ethernet type eld of a VPLS packet.
vlan-ether-type-except
value
Do not match on the VLAN Ethernet type eld of a VPLS packet.
NOTE: For matches flexible-match-mask and flexible-match-range match-start layer-4 used to match
over IPV6 header will not work for L2 family lters such as "bridge, CCC, VPLS". Instead, use
layer-3 with appropriate oset to match over IPV6 payload elds.
1035
NOTE: Commit check issues an error if traffic-type
known-unicast
or traffic-type
unknown-unicast
is
unsupported.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release Descripon
14.2 Starng in Junos OS 14.2, exible oset lters are supported in rewall hierarchy conguraons.
14.2 Starng in Junos OS 14.2, rewall family bridge IPv6 match criteria is supported on MX Series and
EX9200 switches.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters
Firewall Filter Terminang Acons
Firewall Filter Nonterminang Acons
Firewall Filter Match Condions for Layer 2 CCC Trac
You can congure a rewall lter with match condions for Layer 2 circuit cross-connect (CCC) trac
(family ccc).
The following restricons apply to rewall lters for Layer 2 CCC trac:
• The input-list
filter-names
and output-list
filter-names
statements for rewall lters for the ccc protocol
family are supported on all interfaces with the excepon of management interfaces and internal
Ethernet interfaces (fxp or em0), loopback interfaces (lo0), and USB modem interfaces (umd).
• Only on MX Series routers and EX Series switches, you cannot apply a Layer 2 CCC stateless rewall
lter (a rewall lter congured at the [edit firewall filter family ccc] hierarchy level) as an output
lter. On MX Series routers and EX Series switches, rewall lters congured for the family ccc
statement can be applied only as input lters.
Table 61 on page 1037 describes the
match-conditions
you can congure at the [edit firewall family ccc
filter
filter-name
term
term-name
from] hierarchy level.
1036
Table 61: Firewall Filter Match Condions for Layer 2 CCC Trac
Match Condion Descripon
apply-groups
Specify which groups to inherit conguraon data from. You can specify more than
one group name. You must list them in order of inheritance priority. The
conguraon data in the rst group takes priority over the data in subsequent
groups.
apply-groups-except
Specify which groups not to inherit conguraon data from. You can specify more
than one group name.
destination-mac-address
address
(MX Series routers and EX Series switches only) Match the desnaon media access
control (MAC) address of a virtual private LAN service (VPLS) packet.
To have packets correctly evaluated by this match condion when applied to egress
trac owing over a CCC circuit from a logical interface on an I-chip DPC in a
Layer 2 virtual private network (VPN) roung instance, you must make a
conguraon change to the Layer 2 VPN roung instance. You must explicitly disable
the use of a control word for trac owing out over a Layer 2 circuit. The use of a
control word is enabled by default for Layer 2 VPN roung instances to support the
emulated virtual circuit (VC) encapsulaon for Layer 2 circuits.
To explicitly disable the use of a control word for Layer 2 VPNs, include the no-
control-word statement at either of the following hierarchy levels:
• [edit routing-instances
routing-instance-name
protocols l2vpn]
• [edit logical-systems
logical-system-name
routing-instances
routing-instance-
name
protocols l2vpn]
NOTE: This match condion is not supported on PTX series packet transport routers.
For more informaon, see
Disabling the Control Word for Layer 2 VPNs
.
flexible-match-mask
value
bit-length
Length of the data to be matched in bits,
not needed for string input (0..128)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
1037
Table 61: Firewall Filter Match Condions for Layer 2 CCC Trac
(Connued)
Match Condion Descripon
byte-offset
Byte oset aer the match start point
flexible-mask-name
Select a exible match from predened
template eld
mask-in-hex
Mask out bits in the packet data to be
matched
match-start
Start point to match in packet
prefix
Value data/string to be matched
flexible-match-range
value
bit-length
Length of the data to be matched in bits
(0..32)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-range-name
Select a exible match from predened
template eld
match-start
Start point to match in packet
range
Range of values to be matched
range-except
Do not match this range of values
1038
Table 61: Firewall Filter Match Condions for Layer 2 CCC Trac
(Connued)
Match Condion Descripon
forwarding-class
class
Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or
network-control.
forwarding-class-except
class
Do not match on the forwarding class. Specify assured-forwarding, best-effort,
expedited-forwarding, or network-control.
interface-group
group-
number
Match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For
group-number
, specify a single value or a
range of values from 0 through 255.
To assign a logical interface to an interface group
group-number
, specify the
group-
number
at the [interfaces
interface-name
unit
number
family
family
filter group]
hierarchy level.
NOTE: This match condion is not supported on PTX series packet transport routers.
For more informaon, see "Filtering Packets Received on a Set of Interface Groups
Overview" on page 1377.
interface-group-except
number
Do not match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For details, see the interface-group match
condion.
NOTE: This match condion is not supported on PTX series packet transport routers.
learn-vlan-1p-priority
number
(MX Series routers, M320 router, and EX Series switches only) Match on the
IEEE 802.1p learned VLAN priority bits in the provider VLAN tag (the only tag in a
single-tag frame with 802.1Q VLAN tags or the outer tag in a dual-tag frame with
802.1Q VLAN tags). Specify a single value or mulple values from 0 through 7.
Compare with the user-vlan-1p-priority match condion.
NOTE: This match condion is not supported on PTX series packet transport routers.
NOTE: This match condion supports the presence of a control word for MX Series
and M320 routers.
1039
Table 61: Firewall Filter Match Condions for Layer 2 CCC Trac
(Connued)
Match Condion Descripon
learn-vlan-1p-priority-
except
number
(MX Series routers, M320 router, and EX Series switches only) Do not match on the
IEEE 802.1p learned VLAN priority bits. For details, see the learn-vlan-1p-priority
match condion.
NOTE: This match condion is not supported on PTX series packet transport routers.
NOTE: This match condion supports the presence of a control word for MX Series
and M320 routers.
loss-priority
level
Packet loss priority (PLP) level. Specify a single level or mulple levels: low, medium-low,
medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced
CFEB (CFEB-E); and MX Series routers and EX Series switches.
For IP trac on M320, MX Series, and T Series routers with Enhanced II Flexible PIC
Concentrators (FPCs), and EX Series switches, you must include the tri-color
statement at the [edit class-of-service] hierarchy level to commit a PLP
conguraon with any of the four levels specied. If the tri-color statement is not
enabled, you can only congure the high and low levels. This applies to all protocol
families.
For informaon about the tri-color statement, see
Conguring and Applying Tricolor
Marking Policers
. For informaon about using behavior aggregate (BA) classiers to
set the PLP level of incoming packets, see
Understanding How Forwarding Classes
Assign Classes to Output Queues
.
loss-priority-except
level
Do not match on the packet loss priority level. Specify a single level or mulple levels:
low, medium-low, medium-high, or high.
NOTE: This match condion is not supported on PTX series packet transport routers.
For informaon about using behavior aggregate (BA) classiers to set the PLP level of
incoming packets, see
Understanding How Behavior Aggregate Classiers Priorize
Trusted Trac
.
1040
Table 61: Firewall Filter Match Condions for Layer 2 CCC Trac
(Connued)
Match Condion Descripon
user-vlan-1p-priority
number
(MX Series routers, M320 router, and EX Series switches only) Match on the IEEE
802.1p user priority bits in the customer VLAN tag (the inner tag in a dual-tag frame
with 802.1Q VLAN tags). Specify a single value or mulple values from 0 through 7.
Compare with the learn-vlan-1p-priority match condion.
NOTE: This match condion is not supported on PTX series packet transport routers.
NOTE: This match condion supports the presence of a control word for MX Series
and M320 routers.
user-vlan-1p-priority-
except
number
(MX Series routers, M320 router, and EX Series switches only) Do not match on the
IEEE 802.1p user priority bits. For details, see the user-vlan-1p-priority match
condion.
NOTE: This match condion is not supported on PTX series packet transport routers.
NOTE: This match condion supports the presence of a control word for MX Series
and M320 routers.
NOTE: For matches flexible-match-mask and flexible-match-range match-start layer-4 used to match
over IPV6 header will not work for L2 family lters such as "bridge, CCC, VPLS". Instead, use
layer-3 with appropriate oset to match over IPV6 payload elds.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
Firewall Filter Nonterminang Acons | 873
1041
Firewall Filter Match Condions for Layer 2 Bridging Trac
Only on MX Series routers and EX Series switches, you can congure a standard stateless rewall lter
with match condions for Layer 2 bridging trac (family bridge). Table 62 on page 1042 describes the
match-conditions
you can congure at the [edit firewall family bridge filter
filter-name
term
term-name
from]
hierarchy level.
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
Match Condion Descripon
destination-mac-address
address
Desnaon media access control (MAC) address of a Layer 2 packet in a bridging
environment.
destination-port
number
TCP or UDP desnaon port eld. You cannot specify both the port and destination-
port match condions in the same term.
destination-port-except
Do not match the TCP/UDP desnaon port.
destination-prefix-list
named-list
Match the IP desnaon prexes in a
named-list
.
1042
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
dscp
number
Dierenated Services code point (DSCP). The DiServ protocol uses the type-of-
service (ToS) byte in the IP header. The most signicant 6 bits of this byte form the
DSCP. For more informaon, see
Understanding How Behavior Aggregate Classiers
Priorize Trusted Trac
.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed):
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
•
RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
af11 (10), af12 (12), af13 (14),
af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30),
af41 (34), af42 (36), af43 (38)
dscp-except
number
Do not match on the DSCP number. For more informaon, see the dscp-except match
condion.
1043
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
ether-type
value
Match the 2-octet IEEE 802.3 Length/EtherType eld to the specied value or list of
values.
You can specify decimal or hexadecimal values from 0 through 65535 (0xFFFF). A
value from 0 through 1500 (0x05DC) species the length of an Ethernet Version 1
frame. A value from 1536 (0x0600) through 65535 species the EtherType (nature of
the MAC client protocol) of an Ethernet Version 2 frame.
In place of the numeric value, you can specify one of the following text synonyms
(the hexadecimal values are also listed): aarp (0x80F3), appletalk (0x809B),
arp (0x0806), ipv4 (0x0800), ipv6 (0x86DD), mpls-multicast (0x8848), mpls-
unicast (0x8847), oam (0x8902), ppp (0x880B), pppoe-discovery (0x8863), pppoe-
session (0x8864), sna (0x80D5).
NOTE: When matching on ip-address or ipv6-address, the ether-type ipv4 or ipv6,
respecvely, must also be specied in order to limit matches to ip trac only.
ether-type-except
value
Do not match the 2-octet IEEE 802.3 Length/EtherType eld to the specied value or
list of values.
For details about specifying the
values
, see the ether-type match condion.
flexible-match-mask
value
bit-length
Length of the data to be matched in bits,
not needed for string input (0..128)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-mask-name
Select a exible match from predened
template eld
1044
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
mask-in-hex
Mask out bits in the packet data to be
matched
match-start
Start point to match in packet
prefix
Value data/string to be matched
flexible-match-range
value
bit-length
Length of the data to be matched in bits
(0..32)
bit-offset
Bit oset aer the (match-start + byte)
oset (0..7)
byte-offset
Byte oset aer the match start point
flexible-range-name
Select a exible match from predened
template eld
match-start
Start point to match in packet
range
Range of values to be matched
range-except
Do not match this range of values
forwarding class
class
Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or
network-control.
1045
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
forwarding-class-except
class
Ethernet type eld of a Layer 2 packet environment. Specify assured-forwarding, best-
effort, expedited-forwarding, or network-control.
icmp-code
message-code
Match the ICMP message code eld.
If you congure this match condion, we recommend that you also congure the ip-
protocol icmp, ip-protocol icmp6, or ip-protocol icmpv6 match condion in the same
term.
If you congure this match condion, you must also congure the icmp-type
message-
type
match condion in the same term. An ICMP message code provides more
specic informaon than an ICMP message type, but the meaning of an ICMP
message code is dependent on the associated ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed). The keywords are grouped by the ICMP type with
which they are associated:
• parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-
option (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• desnaon-unreachable: address-unreachable (3), administratively-prohibited (1),
no-route-to-destination (0), port-unreachable (4)
icmp-code-except
message-code
Do not match the ICMP message code eld. For details, see the icmp-code match
condion.
1046
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
icmp-type
message-type
Match the ICMP message type eld.
If you congure this match condion, we recommend that you also congure the ip-
protocol icmp, ip-protocol icmp6, or ip-protocol icmpv6 match condion in the same
term.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): destination-unreachable (1), echo-reply (129), echo-
request (128), membership-query (130), membership-report (131), membership-
termination (132), neighbor-advertisement (136), neighbor-solicit (135), node-
information-reply (140), node-information-request (139), packet-too-big (2), parameter-
problem (4), redirect (137), router-advertisement (134), router-renumbering (138),
router-solicit (133), or time-exceeded (3).
icmp-type-except
message-type
Do not match the ICMP message type eld. For details, see the icmp-type match
condion.
interface
interface-name
Interface on which the packet was received. You can congure a match condion that
matches packets based on the interface on which they were received.
NOTE: If you congure this match condion with an interface that does not exist, the
term does not match any packet.
interface-group
group-
number
Match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For
group-number
, specify a single value or a
range of values from 0 through 255.
To assign a logical interface to an interface group
group-number
, specify the
group-
number
at the [interfaces
interface-name
unit
number
family
family
filter group]
hierarchy level.
For more informaon, see "Filtering Packets Received on a Set of Interface Groups
Overview" on page 1377.
1047
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
interface-group-except
number
Do not match the logical interface on which the packet was received to the specied
interface group or set of interface groups. For details, see the interface-group match
condion.
interface-set
interface-
set-name
Match the interface on which the packet was received to the specied interface set.
To dene an interface set, include the interface-set statement at the [edit firewall]
hierarchy level. For more informaon, see "Filtering Packets Received on an Interface
Set Overview" on page 1378.
ip-address
address
32-bit address that supports the standard syntax for IPv4 addresses.
NOTE: In order to limit matches to IPv4 trac only, the ether-type ipv4 must also be
specied in the same term.
ip-destination-address
address
32-bit address that is the nal desnaon node address for the packet.
ip-precedence
ip-
precedence-field
IP precedence eld. In place of the numeric eld value, you can specify one of the
following text synonyms (the eld values are also listed): critical-ecp (0xa0),
flash (0x60), flash-override (0x80), immediate (0x40), internet-control (0xc0), net-
control (0xe0), priority (0x20), or routine (0x00).
ip-precedence-except
ip-
precedence-field
Do not match on the IP precedence eld.
ip-protocol
number
IP protocol eld.
ip-protocol-except
Do not match the IP protocol type.
1048
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
ip-source-address
address
IP address of the source node sending the packet.
ipv6-address
address
(MX Series only) 128-bit address that supports the standard syntax for IPv6
addresses.
NOTE: In order to limit matches to IPv6 trac only, the ether-type ipv6 must also be
specied in the same term.
ipv6-destination-address
address
(MX Series only) 128-bit address that is the nal desnaon node address for this
packet.
ipv6-destination-prefix-
list
named-list
(MX Series only) Match the IPv6 desnaon addresses in a
named-list
.
1049
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
ipv6-next-header
protocol
(MX Series only) Match IPv6 next header protocol type.
The following list shows the supported values for
protocol
:
• ah—IP Security authencaon header
• dstopts—IPv6 desnaon opons
• egp—Exterior gateway protocol
• esp—IPSec Encapsulang Security Payload
•
fragment—IPv6 fragment header
•
gre—Generic roung encapsulaon
•
hop-by-hop—IPv6 hop by hop opons
•
icmp—Internet Control Message Protocol
• icmp6—Internet Control Message Protocol Version 6
• igmp—Internet Group Management Protocol
• ipip—IP in IP
• ipv6—IPv6 in IP
• no-next-header—IPv6 no next header
• ospf—Open Shortest Path First
• pim—Protocol Independent Mulcast
• roung—IPv6 roung header
• rsvp—Resource Reservaon Protocol
• sctp—Stream Control Transmission Protocol
• tcp—Transmission Control Protocol
1050
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
• udp—User Datagram Protocol
• vrrp—Virtual Router Redundancy Protocol
ipv6-next-header-except
protocol
(MX Series only) Do not match the IPv6 next header protocol type.
1051
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
ipv6-payload-protocol
protocol
(MX Series only) Match IPv6 payload protocol type.
The following list shows the supported values for
protocol
:
• ah—IP Security authencaon header
• dstopts—IPv6 desnaon opons
• egp—Exterior gateway protocol
• esp—IPSec Encapsulang Security Payload
•
fragment—IPv6 fragment header
•
gre—Generic roung encapsulaon
•
hop-by-hop—IPv6 hop by hop opons
•
icmp—Internet Control Message Protocol
• icmp6—Internet Control Message Protocol Version 6
• igmp—Internet Group Management Protocol
• ipip—IP in IP
• ipv6—IPv6 in IP
• no-next-header—IPv6 no next header
• ospf—Open Shortest Path First
• pim—Protocol Independent Mulcast
• roung—IPv6 roung header
• rsvp—Resource Reservaon Protocol
• sctp—Stream Control Transmission Protocol
• tcp—Transmission Control Protocol
1052
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
• udp—User Datagram Protocol
• vrrp—Virtual Router Redundancy Protocol
ipv6-payload-protocol-
except
protocol
(MX Series only) Do not match the IPv6 payload protocol.
ipv6-prefix-list
named-
list
(MX Series only) Match the IPv6 address in a
named-list
.
ipv6-source-address
address
(MX Series only) 128-bit address that is the originang source node address for this
packet.
ipv6-source-prefix-list
named-list
(MX Series only) Match the IPv6 source address in a
named-list
.
1053
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
ipv6-traffic-class
number
(MX Series only) Dierenated Services code point (DSCP). The DiServ protocol
uses the type-of-service (ToS) byte in the IP header. The most signicant 6 bits of this
byte form the DSCP. For more informaon, see
Understanding How Behavior
Aggregate Classiers Priorize Trusted Trac
.
You can specify a numeric value from 0 through 63. To specify the value in
hexadecimal form, include 0x as a prex. To specify the value in binary form, include b
as a prex.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed):
• RFC 3246,
An Expedited Forwarding PHB (Per-Hop Behavior)
, denes one code
point: ef (46).
•
RFC 2597,
Assured Forwarding PHB Group
, denes 4 classes, with 3 drop
precedences in each class, for a total of 12 code points:
af11 (10), af12 (12), af13 (14),
af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30),
af41 (34), af42 (36), af43 (38)
ipv6-traffic-class-
except
number
Do not match the DSCP number.
isid
number
(Supported with Provider Backbone Bridging [PBB]) Match internet service idener.
isid-dei
number
(Supported with PBB) Match the Internet service idener drop eligibility indicator
(DEI) bit.
isid-dei-except
number
(Supported with PBB) Do not match the Internet service idener DEI bit.
1054
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
isid-priority-code-point
number
(Supported with PBB) Match the Internet service idener priority code point.
isid-priority-code-
point-except
number
(Supported with PBB) Do not match the Internet service idener priority code point.
learn-vlan-1p-priority
value
(MX Series routers and EX Series switches only) Match on the IEEE 802.1p learned
VLAN priority bits in the provider VLAN tag (the only tag in a single-tag frame with
802.1Q VLAN tags or the outer tag in a dual-tag frame with 802.1Q VLAN tags).
Specify a single value or mulple values from 0 through 7.
Compare with the user-vlan-1p-priority match condion.
learn-vlan-1p-priority-
except
value
(MX Series routers and EX Series switches only) Do not match on the IEEE 802.1p
learned VLAN priority bits. For details, see the learn-vlan-1p-priority match
condion.
learn-vlan-dei
number
(Supported with bridging) Match user virtual LAN (VLAN) idener DEI bit.
learn-vlan-dei-except
number
(Supported with bridging) Do not match user VLAN idener DEI bit.
learn-vlan-id
number
VLAN idener used for MAC learning.
learn-vlan-id-except
number
Do not match on the VLAN idener used for MAC learning.
1055
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
loss-priority
level
Packet loss priority (PLP) level. Specify a single level or mulple levels: low, medium-low,
medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced
CFEB (CFEB-E); and MX Series routers and EX Series switches.
For IP trac on M320, MX Series, and T Series routers with Enhanced II Flexible PIC
Concentrators (FPCs), and EX Series switches, you must include the tri-color
statement at the [edit class-of-service] hierarchy level to commit a PLP
conguraon with any of the four levels specied. If the tri-color statement is not
enabled, you can only congure the high and low levels. This applies to all protocol
families.
For informaon about the tri-color statement, see
Conguring and Applying Tricolor
Marking Policers
. For informaon about using behavior aggregate (BA) classiers to
set the PLP level of incoming packets, see
Understanding How Forwarding Classes
Assign Classes to Output Queues
.
loss-priority-except
level
Do not match on the packet loss priority level. Specify a single level or mulple levels:
low, medium-low, medium-high, or high.
For informaon about using behavior aggregate (BA) classiers to set the PLP level of
incoming packets, see the
Understanding How Behavior Aggregate Classiers
Priorize Trusted Trac
.
port
number
TCP or UDP source or desnaon port. You cannot specify both the port match
condion and either the destination-port or source-port match condions in the same
term.
source-mac-address
address
Source MAC address of a Layer 2 packet.
source-port
number
TCP or UDP source port eld. You cannot specify the port and source-port match
condions in the same term.
1056
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
source-port-except
Do not match the TCP/UDP source port.
tcp-flags
flags
Match one or more of the low-order 6 bits in the 8-bit TCP ags eld in the TCP
header.
To specify individual bit elds, you can specify the following text synonyms or
hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in the inial packet sent, while the ACK ag
is set in all packets sent aer the inial packet.
You can string together mulple ags using the bit-eld logical operators.
Conguring the tcp-flags match condion requires that you congure the next-
header-tcp match condion.
traffic-type
type
Trac type. Specify broadcast, multicast, unknown-unicast, or known-unicast.
traffic-type-except
type
Do not match on the trac type.
1057
Table 62: Standard Firewall Filter Match Condions for Layer 2 Bridging (MX Series Routers and EX
Series Switches Only)
(Connued)
Match Condion Descripon
user-vlan-1p-priority
value
(MX Series routers and EX Series switches only) Match on the IEEE 802.1p user
priority bits in the customer VLAN tag (the inner tag in a dual-tag frame with 802.1Q
VLAN tags). Specify a single value or mulple values from 0 through 7.
Compare with the learn-vlan-1p-priority match condion.
user-vlan-1p-priority-
except
value
(MX Series routers and EX Series switches only) Do not match on the IEEE 802.1p
user priority bits. For details, see the user-vlan-1p-priority match condion.
user-vlan-id
number
(MX Series routers and EX Series switches only) Match the rst VLAN idener that
is part of the payload.
user-vlan-id-except
number
(MX Series routers and EX Series switches only) Do not match on the rst VLAN
idener that is part of the payload.
vlan-ether-type
value
VLAN Ethernet type eld of a Layer 2 bridging packet.
vlan-ether-type-except
value
Do not match on the VLAN Ethernet type eld of a Layer 2 bridging packet.
NOTE: For matches flexible-match-mask and flexible-match-range match-start layer-4 used to match
over IPV6 header will not work for L2 family lters such as "bridge, CCC, VPLS". Instead, use
layer-3 with appropriate oset to match over IPV6 payload elds.
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Firewall Filter Terminang Acons | 886
1058
Firewall Filter Nonterminang Acons | 873
Firewall Filter Support on Loopback Interface
A loopback interface is a gateway for all the control trac that enters the Roung Engine of the router.
If you want to monitor this control trac, you must congure a rewall lter on the loopback interface
(lo0).
Loopback rewall lters are only applied to packets sent to the Roung Engine for further processing.
Both inet and inet6 family lters are supported, and you can apply a rewall lter in the ingress and
egress direcons on the lo0 interface. However, only interface-specific instances of the rewall lter are
supported.
For standard rewall lter match condions, see "Match Condions for IPv4 Trac (ACX Series
Routers)" on page 919.
The rewall lter on lo0 handles the following excepon packets in ingress direcon:
• TTL excepon packets
• Mulcast packets having 224.0.0.x as the desnaon IP address
• Broadcast packets
• IP opon packets
NOTE: Although policer acons can be aached to loopback lters in the ingress direcon, the
exact behavior depends on the CPU RX queue conguraons. For example, rate liming in
ingress direcon (through policer conguraon) occurs aer any CPU rate limiters.
The following is a sample conguraon for aaching a rewall to the loopback interface:
[edit interfaces]
lo0 {
unit 0 {
family <inet | inet6> {
filter {
input f1;
}
}
}
1059
}
family <inet | inet6>{
filter f1 {
interface-specific; >> Mandatory Field.
term t1 {
from {
protocol ospf;
}
then {
count c1;
discard;
}
}
term t2 {
then {
count c2;
accept;
}
}
}
}
1060
CHAPTER 15
Applying Firewall Filters to Roung Engine Trac
IN THIS CHAPTER
Conguring Logical Units on the Loopback Interface for Roung Instances in Layer 3 VPNs | 1061
Example: Conguring a Filter to Limit TCP Access to a Port Based On a Prex List | 1063
Example: Conguring a Stateless Firewall Filter to Accept Trac from Trusted Sources | 1069
Example: Congure a Filter to Block Telnet and SSH Access | 1077
Example: Conguring a Filter to Block TFTP Access | 1090
Example: Conguring a Filter to Accept Packets Based on IPv6 TCP Flags | 1095
Example: Conguring a Filter to Block TCP Access to a Port Except from Specied BGP Peers | 1099
Example: Conguring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods | 1107
Example: Protecng the Roung Engine with a Packets-Per-Second Rate Liming Filter | 1123
Example: Conguring a Filter to Exclude DHCPv6 and ICMPv6 Control Trac for LAC Subscriber | 1128
Port Number Requirements for DHCP Firewall Filters | 1135
Example: Conguring a DHCP Firewall Filter to Protect the Roung Engine | 1136
Conguring Logical Units on the Loopback Interface for Roung
Instances in Layer 3 VPNs
For Layer 3 VPNs (VRF roung instances), you can congure a logical unit on the loopback interface into
each VRF roung instance that you have congured on the router. Associang a VRF roung instance
with a logical unit on the loopback interface allows you to easily idenfy the VRF roung instance.
Doing this is useful for troubleshoong:
• It allows you to ping a remote CE router from a local PE router in a Layer 3 VPN. For more
informaon, see
Example: Troubleshoong Layer 3 VPNs
.
• It ensures that a path maximum transmission unit (MTU) check on trac originang on a VRF or
virtual-router roung instance funcons properly. For more informaon, see
Conguring Path MTU
Checks for VPN Roung Instances
.
1061
You can also congure a rewall lter for the logical unit on the loopback interface; this conguraon
allows you to lter trac for the VRF roung instance associated with it.
The following describes how rewall lters aect the VRF roung instance depending on whether they
are congured on the default loopback interface, the VRF roung instance, or some combinaon of the
two. The “default loopback interface” refers to lo0.0 (associated with the default roung table), and the
“VRF loopback interface” refers to lo0.
n
, which is congured in the VRF roung instance.
• If you congure Filter A on the default loopback interface and Filter B on the VRF loopback interface,
the VRF roung instance uses Filter B.
• If you congure Filter A on the default loopback interface but do not congure a lter on the VRF
loopback interface, the VRF roung instance does not use a lter.
• If you congure Filter A on the default loopback interface but do not congure a VRF loopback
interface, the VRF roung instance uses Filter A. For MX80 devices, the behavior is slightly dierent:
If you congure lters on the default loopback interface but do not congure a VRF loopback
interface, the VRF roung instance uses only the input lters assigned to the default loopback (it
does not use output lters from the default loopback).
For some ACX Series Universal Metro Routers (ACX1000, ACX2000, ACX4000, and ACX5000), the
default loopback lter must be in the same roung, or virtual roung and forwarding (VRF), instance as
the ingress trac it lters. That is, on these devices, the default loopback lter cannot be used for trac
traversing an interface that belongs to a dierent roung instance.
To congure a logical unit on the loopback interface, include the unit statement:
unit
number
{
family inet {
address
address
;
}
}
You can include this statement at the following hierarchy levels:
• [edit interfaces lo0]
• [edit logical-systems
logical-system-name
interfaces lo0]
To associate a rewall lter with the logical unit on the loopback interface, include the filter statement:
filter {
input
filter-name
;
}
1062
You can include this statement at the following hierarchy levels:
• [edit interfaces lo0 unit
unit-number
family inet]
• [edit logical-systems
logical-system-name
interfaces lo0 unit
unit-number
family inet]
To include the lo0.
n
interface (where
n
species the logical unit) in the conguraon for the VRF roung
instance, include the following statement:
interface lo0.
n
;
You can include this statement at the following hierarchy levels:
• [edit routing-instances
routing-instance-name
]
• [edit logical-systems
logical-system-name
routing-instances
routing-instance-name
]
Example: Conguring a Filter to Limit TCP Access to a Port Based On a
Prex List
IN THIS SECTION
Requirements | 1063
Overview | 1064
Conguraon | 1064
Vericaon | 1067
This example shows how to congure a standard stateless rewall lter that limits certain TCP and
Internet Control Message Protocol (ICMP) trac desned for the Roung Engine by specifying a list of
prex sources that contain allowed BGP peers.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
1063
Overview
IN THIS SECTION
Topology | 1064
In this example, you create a stateless rewall lter that blocks all TCP connecon aempts to port 179
from all requesters except BGP peers that have a specied prex.
Topology
A source prex list, plist_bgp179, is created that species the list of source prexes that contain allowed
BGP peers.
The stateless rewall lter lter_bgp179 matches all packets from the source prex list plist_bgp179 to
the desnaon port number 179.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1064
Congure the Filter | 1065
Results | 1066
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set policy-options prefix-list plist_bgp179 apply-path "protocols bgp group <*> neighbor <*>"
set firewall family inet filter filter_bgp179 term 1 from source-address 0.0.0.0/0
set firewall family inet filter filter_bgp179 term 1 from source-prefix-list plist_bgp179 except
set firewall family inet filter filter_bgp179 term 1 from destination-port bgp
set firewall family inet filter filter_bgp179 term 1 then reject
1064
set firewall family inet filter filter_bgp179 term 2 then accept
set interfaces lo0 unit 0 family inet filter input filter_bgp179
set interfaces lo0 unit 0 family inet address 127.0.0.1/32
Congure the Filter
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure the lter:
1. Expand the prex list bgp179 to include all prexes pointed to by the BGP peer group dened by
protocols bgp group <*> neighbor <*>.
[edit policy-options prefix-list plist_bgp179]
user@host# set apply-path " protocols bgp group <*> neighbor <*>"
2. Dene the lter term that rejects TCP connecon aempts to port 179 from all requesters except
the specied BGP peers.
[edit firewall family inet filter filter_bgp179]
user@host# set term term1 from source-address 0.0.0.0/0
user@host# set term term1 from source-prefix-list bgp179 except
user@host# set term term1 from destination-port bgp
user@host# set term term1 then reject
3. Dene the other lter term to accept all packets.
[edit firewall family inet filter filter_bgp179]
user@host# set term term2 then accept
1065
4. Apply the rewall lter to the loopback interface.
[edit interfaces lo0 unit 0 family inet]
user@host# set filter input filter_bgp179
user@host# set address 127.0.0.1/32
Results
From conguraon mode, conrm your conguraon by entering the show rewall, show interfaces, and
show policy-opons commands. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
user@host# show firewall
family inet {
filter filter_bgp179 {
term 1 {
from {
source-address {
0.0.0.0/0;
}
source-prefix-list {
plist_bgp179 except;
}
destination-port bgp;
}
then {
reject;
}
}
term 2 {
then {
accept;
}
}
}
}
user@host# show interfaces
lo0 {
1066
unit 0 {
family inet {
filter {
input filter_bgp179;
}
address 127.0.0.1/32;
}
}
}
user@host# show policy-options
prefix-list plist_bgp179 {
apply-path "protocols bgp group <*> neighbor <*>";
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying the Firewall Filter Applied to the Loopback Interface | 1067
Conrm that the conguraon is working properly.
Displaying the Firewall Filter Applied to the Loopback Interface
Purpose
Verify that the rewall lter lter_bgp179 is applied to the IPv4 input trac at logical interface lo0.0.
1067
Acon
Use the show interfaces statistics operational mode command for logical interface lo0.0, and include the
detail opon. Under the Protocol inet secon of the command output secon, the Input Filters eld
displays the name of the stateless rewall lter applied to the logical interface in the input direcon.
[edit]
user@host> show interfaces statistics lo0.0 detail
Logical interface lo0.0 (Index 321) (SNMP ifIndex 16) (Generation 130)
Flags: SNMP-Traps Encapsulation: Unspecified
Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: Unlimited, Generation: 145, Route table: 0
Flags: Sendbcast-pkt-to-re
Input Filters: filter_bgp179
Addresses, Flags: Primary
Destination: Unspecified, Local: 127.0.0.1, Broadcast: Unspecified, Generation: 138
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Firewall Filter Match Condions Based on Address Fields | 986
Example: Conguring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods | 1107
Example: Conguring a Filter to Accept Packets Based on IPv6 TCP Flags | 1095
prex-list
1068
Example: Conguring a Stateless Firewall Filter to Accept Trac from
Trusted Sources
IN THIS SECTION
Requirements | 1069
Overview | 1069
Conguraon | 1070
Vericaon | 1073
This example shows how to create a stateless
rewall lter that protects the Roung Engine from trac
originang from untrusted sources.
Requirements
No special conguraon beyond device inializaon is required before conguring stateless rewall
lters.
Overview
In this example, you create a stateless rewall lter called protect-RE that discards all trac desned for
the Roung Engine except SSH and BGP protocol packets from specied trusted sources. This example
includes the following rewall lter terms:
• ssh-term—Accepts TCP packets with a source address of 192.168.122.0/24 and a desnaon port that
species SSH.
• bgp-term—Accepts TCP packets with a source address of 10.2.1.0/24 and a desnaon port that
species BGP.
• discard-rest-term—For all packets that are not accepted by ssh-term or bgp-term, creates a rewall lter
log and system logging records, then discards all packets.
NOTE: You can move terms within the rewall lter using the insert command. See
insert
in the
Junos OS CLI User Guide.
1069
Conguraon
IN THIS SECTION
Procedure | 1070
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter protect-RE term ssh-term from source-address 192.168.122.0/24
set firewall family inet filter protect-RE term ssh-term from protocol tcp
set firewall family inet filter protect-RE term ssh-term from destination-port ssh
set firewall family inet filter protect-RE term ssh-term then accept
set firewall family inet filter protect-RE term bgp-term from source-address 10.2.1.0/24
set firewall family inet filter protect-RE term bgp-term from protocol tcp
set firewall family inet filter protect-RE term bgp-term from destination-port bgp
set firewall family inet filter protect-RE term bgp-term then accept
set firewall family inet filter protect-RE term discard-rest-term then log
set firewall family inet filter protect-RE term discard-rest-term then syslog
set firewall family inet filter protect-RE term discard-rest-term then discard
set interfaces lo0 unit 0 family inet filter input protect-RE
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure the stateless rewall lter:
1070
1. Create the stateless rewall lter.
[edit]
user@host# edit firewall family inet filter protect-RE
2. Create the rst lter term.
[edit firewall family inet filter protect-RE]
user@host# edit term ssh-term
3. Dene the protocol, desnaon port, and source address match condions for the term.
[edit firewall family inet filter protect-RE term ssh-term]
user@host# set from protocol tcp destination-port ssh source-address 192.168.122.0/24
4. Dene the acons for the term.
[edit firewall family inet filter protect-RE term ssh-term]
user@host# set then accept
5. Create the second lter term.
[edit firewall family inet filter protect-RE]
user@host# edit term bgp-term
6. Dene the protocol, desnaon port, and source address match condions for the term.
[edit firewall family inet filter protect-RE term bgp-term]
user@host# set from protocol tcp destination-port bgp source-address 10.2.1.0/24
7. Dene the acon for the term.
[edit firewall family inet filter protect-RE term bgp-term]
user@host# set then accept
1071
8. Create the third lter term.
[edit firewall family inet filter protect-RE]
user@host# edit term discard-rest-term
9. Dene the acon for the term.
[edit firewall family inet filter protect-RE term discard-rest]
user@host# set then log syslog discard
10. Apply the lter to the input side of the Roung Engine interface.
[edit]
user@host# set interfaces lo0 unit 0 family inet filter input protect-RE
Results
Conrm your conguraon by entering the show firewall command and the show interfaces lo0 command
from conguraon mode. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
user@host# show firewall
family inet {
filter protect-RE {
term ssh-term {
from {
source-address {
192.168.122.0/24;
}
protocol tcp;
destination-port ssh;
}
then accept;
}
term bgp-term {
from {
source-address {
10.2.1.0/24;
}
1072
protocol tcp;
destination-port bgp;
}
then accept;
}
term discard-rest-term {
then {
log;
syslog;
discard;
}
}
}
}
user@host# show interfaces lo0
unit 0 {
family inet {
filter {
input protect-RE;
}
address 127.0.0.1/32;
}
}
If you are done conguring the device, enter commit from conguraon mode.
[edit]
user@host# commit
Vericaon
IN THIS SECTION
Displaying Stateless Firewall Filter Conguraons | 1074
Verifying a Services, Protocols, and Trusted Sources Firewall Filter | 1074
Displaying Stateless Firewall Filter Logs | 1075
1073
To conrm that the conguraon is working properly, perform these tasks:
Displaying Stateless Firewall Filter Conguraons
Purpose
Verify the conguraon of the rewall lter.
Acon
From conguraon mode, enter the show firewall command and the show interfaces lo0 command.
Meaning
Verify that the output shows the intended conguraon of the rewall lter. In addion, verify that the
terms are listed in the order in which you want the packets to be tested. You can move terms within a
rewall lter by using the insert CLI command.
Verifying a Services, Protocols, and Trusted Sources Firewall Filter
Purpose
Verify that the acons of the rewall lter terms are taken.
Acon
Send packets to the device that match the terms. In addion, verify that the lter acons are
not
taken
for packets that do not match.
• Use the ssh
host-name
command from a host at an IP address that matches 192.168.122.0/24 to verify
that you can log in to the device using only SSH from a host with this address prex.
• Use the show route summary command to verify that the roung table on the device does not contain
any entries with a protocol other than Direct, Local, BGP, or Static.
Sample Output
command-name
% ssh 192.168.249.71
%ssh host
1074
user@host's password:
--- JUNOS 6.4-20040518.0 (JSERIES) #0: 2004-05-18 09:27:50 UTC
user@host>
command-name
user@host> show route summary
Router ID: 192.168.249.71
inet.0: 34 destinations, 34 routes (33 active, 0 holddown, 1 hidden)
Direct: 10 routes, 9 active
Local: 9 routes, 9 active
BGP: 10 routes, 10 active
Static: 5 routes, 5 active
...
Meaning
Verify the following informaon:
• You can successfully log in to the device using SSH.
• The show route summary command does not display a protocol other than Direct, Local, BGP, or Static.
Displaying Stateless Firewall Filter Logs
Purpose
Verify that packets are being logged. If you included the log or syslog acon in a term, verify that packets
matching the term are recorded in the rewall log or your system logging facility.
Acon
From operaonal mode, enter the show firewall log command.
1075
Sample Output
command-name
user@host> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
15:11:02 pfe D ge-0/0/0.0 TCP 172.17.28.19 192.168.70.71
15:11:01 pfe D ge-0/0/0.0 TCP 172.17.28.19 192.168.70.71
15:11:01 pfe D ge-0/0/0.0 TCP 172.17.28.19 192.168.70.71
15:11:01 pfe D ge-0/0/0.0 TCP 172.17.28.19 192.168.70.71
...
Meaning
Each record of the output contains informaon about the logged packet. Verify the following
informaon:
• Under Time, the me of day the packet was ltered is shown.
• The Filter output is always pfe.
• Under Action, the congured acon of the term matches the acon taken on the packet—A (accept),
D (discard), R (reject).
• Under Interface, the inbound (ingress) interface on which the packet arrived is appropriate for the
lter.
• Under Protocol, the protocol in the IP header of the packet is appropriate for the lter.
• Under Src Addr, the source address in the IP header of the packet is appropriate for the lter.
• Under Dest Addr, the desnaon address in the IP header of the packet is appropriate for the lter.
RELATED DOCUMENTATION
show route summary
show rewall
show rewall log
show interfaces (Loopback)
1076
Example: Congure a Filter to Block Telnet and SSH Access
IN THIS SECTION
Requirements | 1077
Overview and Topology | 1077
Conguraon | 1078
Verify the Stateless Firewall Filter | 1086
Requirements
You need two devices running Junos OS with a shared network link. No special conguraon beyond
basic device inializaon (management interface, remote access, user login accounts, etc.) is required
before conguring this example. While not a strict requirement, console access to the R2 device is
recommended.
NOTE: Our content tesng team has validated and updated this example.
Overview and Topology
IN THIS SECTION
Example Topology | 1078
In this example, you create an IPv4 stateless rewall lter that logs and rejects Telnet or SSH packets
sent to the local Roung Engine, unless the packet originates from the 192.168.1.0/30 subnet. The lter
is applied to the loopback interface to ensure that only trac desned to the local device is aected.
You apply the lter in the input direcon. An output lter is not used. As a result all locally generated
trac is allowed.
•
To match packets originang from a specic subnet or IP prex, you use the source-address IPv4 match
condion applied in the input direcon.
1077
• To match packets desned for the Telnet port and SSH ports, you use the protocol tcp match
condion combined with a port telnet and port ssh IPv4 match condions applied in the input
direcon.
Example Topology
Figure 51 on page 1078 shows the test topology for this example. The rewall lter is applied to the R2
device, making it the device under test (DUT). The R1 and the R2 devices share a link that is assigned a
subnet of 192.168.1.0/30. Both devices have loopback addresses assigned from the 192.168.255.0/30
prex using a /32 subnet mask. Stac routes provide reachability between loopback addresses because
an interior gateway protocol is not congured in this basic example.
Figure 51: Example Topology
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1079
Congure the R1 Device | 1080
Verify and Commit the Conguraon at the R1 Device | 1081
Congure the R2 Device | 1082
Verify and Commit the Conguraon at Device R2 | 1084
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
.
CAUTION: By design the sample lter restricts Telnet and SSH access to R2 unless it
originates from the shared subnet at R1. If you use SSH or Telnet to access the R2
device directly, you will lose connecvity when the lter is applied. We recommend that
1078
you have console access when conguring this example. If needed you can use the R1
device as a jump host to launch an SSH session to R2 aer the lter is applied.
Alternavely, consider modifying the sample lter to also permit the IP subnet assigned
to the machine you use to access the R2 device.
Perform the following tasks to congure this example:
CLI Quick Conguraon
Quick Conguraon for the R1 Device
To quickly congure the R1 device, edit the following commands as needed and paste them into the CLI
at the [edit] hierarchy level. Be sure to issue a commitin conguraon mode to acvate the changes.
set system host-name R1
set system services ssh root-login allow
set interfaces ge-0/0/0 description "Link from R1 to R2"
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30
set interfaces lo0 unit 0 family inet address 192.168.255.1/32
set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
Quick Conguraon for the R2 Device
To quickly congure the R2 device, edit the following commands as needed and paste them into the CLI
at the [edit] hierarchy level. Be sure to issue a commit in conguraon mode to acvate the changes.
TIP: Consider using commit-confirmed when making changes that might aect remote access to
your device.
Acvang a Junos OS Conguraon but Requiring Conrmaon
set system host-name R2
set system services ssh root-login allow
set system services telnet
set interfaces ge-0/0/0 description "Link from R2 to R1"
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30
set interfaces lo0 unit 0 family inet filter input local_acl
set interfaces lo0 unit 0 family inet address 192.168.255.2/32
set firewall family inet filter local_acl term terminal_access from source-address 192.168.1.0/30
set firewall family inet filter local_acl term terminal_access from protocol tcp
set firewall family inet filter local_acl term terminal_access from port ssh
1079
set firewall family inet filter local_acl term terminal_access from port telnet
set firewall family inet filter local_acl term terminal_access then accept
set firewall family inet filter local_acl term terminal_access_denied from protocol tcp
set firewall family inet filter local_acl term tcp-estab from protocol tcp
set firewall family inet filter local_acl term tcp-estab from tcp-established
set firewall family inet filter local_acl term tcp-estab then accept
set firewall family inet filter local_acl term terminal_access_denied from port ssh
set firewall family inet filter local_acl term terminal_access_denied from port telnet
set firewall family inet filter local_acl term terminal_access_denied then log
set firewall family inet filter local_acl term terminal_access_denied then reject
set firewall family inet filter local_acl term default-term then accept
set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
Congure the R1 Device
Step-by-Step Procedure
Follow these steps to congure the R1 device:
1. Congure the interfaces:
[edit]
user@R1# set interfaces ge-0/0/0 description "Link from R1 to R2"
user@R1# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30
user@R1# set interfaces lo0 unit 0 family inet address 192.168.255.1/32
2. Congure the host name and stac route to the R2 device’s loopback address. You also congure
Telnet and SSH access:
[edit]
user@R1# set system host-name R1
user@R1# set system services ssh root-login allow
user@R1# set system services telnet
user@R1# set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
1080
Verify and Commit the Conguraon at the R1 Device
Step-by-Step Procedure
Complete the following steps to verify and commit your candidate conguraon at the R1 device:
1. Conrm interface conguraon with the show interfaces conguraon mode command. If the
command output does not display the intended conguraon, repeat the instrucons in this example
to correct the conguraon.
[edit]
user@R1# show interfaces
ge-0/0/0 {
description "Link from R1 to R2";
unit 0 {
family inet {
address 192.168.1.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.255.1/32;
}
}
}
2. Verify the stac route used to reach the R2 device’s loopback address and that SSH and Telnet
access are enabled. Use the show routing-options and show system services conguraon mode
commands. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@R1# show routing-options
static {
route 192.168.255.2/32 next-hop 192.168.1.2;
}
user@R1# show system services
ssh {
root-login allow;
1081
}
telnet;
3. When sased with the conguraon on the R1 device, commit your candidate conguraon.
[edit]
user@R1# commit
Congure the R2 Device
Step-by-Step Procedure
Complete the following steps to congure the R2 device. You begin by dening the stateless rewall
lter that selecvely blocks Telnet and SSH access:
1. Posion yourself at the edit firewall family inet filter
local_acl
hierarchy:
[edit]
user@R2# edit firewall family inet filter local_acl
2. Dene the lter term
terminal_access
. This term permits Telnet and SSH from the specied source
prex(s):
[edit firewall family inet filter local_acl]
user@R2# set term terminal_access from source-address 192.168.1.0/30
user@R2# set term terminal_access from protocol tcp
user@R2# set term terminal_access from port ssh
user@R2# set term terminal_access from port telnet
user@R2# set term terminal_access then accept
3. Dene the lter term
terminal_access_denied
. This term rejects SSH and Telnet from
all other
source
addresses. This term is congured to log matches to the term and to generate an explicit Internet
Control Message Protocol (ICMP) desnaon unreachable response back to the packet’s source. See
"Firewall Filter Logging Acons" on page 1286 for details on lter logging opons.
1082
TIP: You can use the discard acon to suppress generaon of ICMP error messages back to
the source. See "Firewall Filter Terminang Acons" on page 886 for details.
[edit firewall family inet filter local_acl]
user@R2# set term terminal_access_denied from protocol tcp
user@R2# set term terminal_access_denied from port ssh
user@R2# set term terminal_access_denied from port telnet
user@R2# set term terminal_access_denied then log
user@R2# set term terminal_access_denied then reject
user@R2# set term default-term then accept
4. Oponal.
Dene the lter term
tcp-estab
. This term permits outbound access to the Internet to support
connecons to the Juniper Mist cloud (
tcp-established
is a bit-eld match condion, tcp-ags "(ack |
rst)", which indicates an established TCP session, but not the rst packet of a TCP connecon):
[edit firewall family inet filter local_acl]
user@R2# set term tcp-estab from protocol tcp
user@R2# set term tcp-estab from tcp-established
user@R2# set term tcp-estab then accept
5. Dene the lter term
default-term
. This term accepts all other trac. Recall that Junos OS stateless
lters have an implicit
deny
term at their end. The
default-term
overrides this behavior by
terminang the lter with an explicit
accept
acon. The terminaon of the lter results in all other
trac being accepted by the ler.
NOTE: For this example we are allowing all other trac, but for your network you might want
to secure the roung engine. See protecng the roung engine for more informaon.
[edit firewall family inet filter local_acl]
user@R2# set term default-term then accept
1083
6. Congure the loopback interface, and apply the lter in the input direcon:
[edit]
user@R2# set interfaces lo0 unit 0 family inet filter input local_acl
user@R2# set interfaces lo0 unit 0 family inet address 192.168.255.2/32
7. Congure the host name, the ge-0/0/0 interface, the stac route to the R1 device’s loopback
address, and enable remote access through SSH and Telnet:
[edit]
user@R2# set system host-name R2
user@R2# set system services ssh root-login allow
user@R2# set system services telnet
user@R2# set interfaces ge-0/0/0 description "Link from R2 to R1"
user@R2# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30
user@R2# set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
Verify and Commit the Conguraon at Device R2
Step-by-Step Procedure
Complete the following steps to verify and commit your candidate conguraon at the R2 device:
1. Conrm the conguraon of the stateless rewall lter with the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@R2# show firewall
family inet {
filter local_acl {
term terminal_access {
from {
source-address {
192.168.1.0/30;
}
protocol tcp;
port [ssh telnet];
}
then accept;
1084
}
term terminal_access_denied {
from {
protocol tcp;
port [ssh telnet];
}
then {
log;
reject;
}
}
term default-term {
then accept;
}
}
}
2. Conrm interface conguraon and lter applicaon with the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@R2# show interfaces
ge-0/0/0 {
description "Link from R2 to R1";
unit 0 {
family inet {
address 192.168.1.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
filter {
input local_acl;
}
address 192.168.255.2/32;
}
}
}
1085
3. Verify the stac route used to reach the loopback address of the R1 device, and verify that Telnet
and SSH access are enabled. Use the show routing-options and show system services conguraon mode
commands. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@R2# show routing-options
static {
route 192.168.255.1/32 next-hop 192.168.1.1;
}
user@R2# show system services
ssh {
root-login allow;
}
telnet;
4. When sased with the conguraon on the R2 device, commit your candidate conguraon.
TIP: Consider using commit-confirmed when making changes that might aect remote access to
your device.
[edit]
user@R2# commit
Verify the Stateless Firewall Filter
IN THIS SECTION
Verify Accepted Packets | 1087
Verify Logged and Rejected Packets | 1088
Conrm that the rewall lter to limit Telnet and SSH access is working properly.
1086
Verify Accepted Packets
Purpose
Verify that the rewall lter correctly allows SSH and Telnet when the trac is sourced from the
192.168.1.0/30 subnet.
Acon
1. Clear the rewall log on your router or switch.
user@R2> clear firewall log
2. From a host at an IP address
within
the 192.168.1.0/30 subnet, use a ssh
192.168.255.2
command to
verify that you can log in to the device using SSH from an allowed source address. This packet should
be accepted, but the packet header informaon for this packet should not be logged in the rewall
lter log buer in the Packet Forwarding Engine. You will be prompted to save the SSH host key if
this is the rst SSH login as
user
between these devices.
NOTE: By default the R1 device will source the SSH trac from the egress interface used to
reach the desnaon. As a result this trac is sourced from the 192.168.1.1 address assigned
to the R1 device’s ge-0/0/0 interface.
user@R1>ssh 192.168.255.2
Password:
Last login: Wed Aug 19 09:23:58 2020 from 192.168.1.1
--- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil
user@R2>
3. Log out of the CLI at the R2 device to close the SSH session.
user@R2> exit
logout
Connection to 192.168.255.2 closed.
user@R1>
4. From a host at an IP address
within
the 192.168.1.0/30 subnet, use the telnet
192.168.255.2
command
to verify that you can log in to your router or switch using Telnet from an allowed source address.
1087
This packet should be accepted, but the packet header informaon for this packet should not be
logged in the rewall lter log buer in the Packet Forwarding Engine.
user@host-A> telnet 192.168.255.2
Trying 192.168.255.2...
Connected to 192.168.255.2.
Escape character is '^]'.
login: user
Password:
--- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil
user@R2>
5. Log out of the CLI to close the Telnet session to the R2 device.
user@R2:~ # exit
Connection closed by foreign host.
root@R1>
6. Use the show firewall log command to verify that the rewall log buer on the R2 device’s Packet
Forwarding Engine (PFE)
does not
contain any entries with a source address in the 192.168.1.0/30
subnet.
user@R2> show firewall log
Verify Logged and Rejected Packets
Purpose
Verify that the rewall lter correctly rejects SSH and Telnet trac that does
not
originate from the
192.168.1.0/30 subnet.
Acon
1088
1. Clear the rewall log on your router or switch.
user@R2> clear firewall log
2. Generate SSH trac sourced from the loopback address of the R1 device. The source address of this
trac is
outside of
the allowed 192.168.1.0/30 subnet. Use the ssh
192.168.255.2
source
192.168.255.1
command to verify that you
cannot
log in to the device using SSH from this source address. This
packet should be rejected, and the packet header informaon should be logged in the rewall lter
log buer.
user@R1 ssh 192.168.255.2 source 192.168.255.1
ssh: connect to host 192.168.255.2 port 22: Connection refused
root@R1>
The output shows that the SSH connecon is rejected. This output conrms that the lter is
generang an ICMP error message and that it correctly blocks SSH trac when sent from a
disallowed source address.
3. Generate Telnet trac sourced from the loopback address of the R1 device. The source address of
this trac is
outside of
the allowed 192.168.1.0/30 subnet. Use the telnet
192.168.255.2
source
192.168.255.1
command to verify that you
cannot
log in to the device using Telnet from this source
address. This packet should be rejected, and the packet header informaon for this packet should be
logged in the rewall lter log buer in the PFE.
user@R1> telnet 192.168.255.2 source 192.168.255.1
Trying 192.168.255.2...
telnet: connect to address 192.168.255.2: Connection refused
telnet: Unable to connect to remote host
The output shows that the Telnet connecon is rejected. This output conrms that the lter is
generang an ICMP error message and that it correctly blocks Telnet trac when sent from a
disallowed source address.
4. Use the show firewall log command to verify that the rewall log buer on the R2 device contains
entries showing that packets with a source address of 192.168.255.1 were rejected.
user@R2> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
1089
15:17:11 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2
15:12:04 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2
The output conrms that trac from the 192.168.255.1 source address matched the lter’s
terminal_access_denied
term. The Action column displays an R to indicate that these packets were
rejected. The interface, transport protocol, and source and desnaon addresses are also listed.
These results conrm that the rewall lter is working properly for this example.
Example: Conguring a Filter to Block TFTP Access
IN THIS SECTION
Requirements | 1090
Overview | 1090
Conguraon | 1091
Vericaon | 1094
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 1091
By default, to decrease vulnerability to denial-of-service (DoS) aacks, the Junos OS lters and discards
Dynamic Host Conguraon Protocol (DHCP) or Bootstrap Protocol (BOOTP) packets that have a
source address of 0.0.0.0 and a desnaon address of 255.255.255.255. This default lter is known as a
unicast RPF check. However, some vendors’ equipment automacally accepts these packets.
1090
Topology
To interoperate with other vendors' equipment, you can congure a lter that checks for both of these
addresses and overrides the default RPF-check lter by accepng these packets. In this example, you
block Trivial File Transfer Protocol (TFTP) access, logging any aempts to establish TFTP connecons.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1091
Congure the Stateless Firewall Filter | 1091
Apply the Firewall Filter to the Loopback Interface | 1092
Conrm and Commit Your Candidate Conguraon | 1092
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter tftp_access_control term one from protocol udp
set firewall family inet filter tftp_access_control term one from port tftp
set firewall family inet filter tftp_access_control term one then log
set firewall family inet filter tftp_access_control term one then discard
set interfaces lo0 unit 0 family inet filter input tftp_access_control
set interfaces lo0 unit 0 family inet address 127.0.0.1/32
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter that selecvely blocks TFTP access:
1091
1. Create the stateless rewall lter tftp_access_control.
[edit]
user@host# edit firewall family inet filter tftp_access_control
2. Specify a match on packets received on UDP port 69.
[edit firewall family inet filter tftp_access_control]
user@host# set term one from protocol udp
user@host# set term one from port tftp
3. Specify that matched packets be logged to the buer on the Packet Forwarding Engine and then
discarded.
[edit firewall family inet filter tftp_access_control]
user@host# set term one then log
user@host# set term one then discard
Apply the Firewall Filter to the Loopback Interface
Step-by-Step Procedure
To apply the rewall lter to the loopback interface:
• [edit]
user@host# set interfaces lo0 unit 0 family inet filter input tftp_access_control
user@host# set interfaces lo0 unit 0 family inet address 127.0.0.1/32
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1092
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter tftp_access_control {
term one {
from {
protocol udp;
port tftp;
}
then {
log;
discard;
}
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
lo0 {
unit 0 {
family inet {
filter {
input tftp_access_control;
}
address 127.0.0.1/32;
}
}
}
1093
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
IN THIS SECTION
Verifying Logged and Discarded Packets | 1094
Conrm
that the conguraon is operang properly:
Verifying Logged and Discarded Packets
Purpose
Verify that the acons of the rewall lter terms are taken.
Acon
To
1. Clear the rewall log on your router or switch.
user@myhost> clear firewall log
2. From another host, send a packet to UDP port 69 on this router or switch.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Stateless Firewall Filter to Accept Trac from Trusted Sources | 1069
Example: Congure a Filter to Block Telnet and SSH Access | 1077
Example: Conguring a Filter to Accept OSPF Packets from a Prex | 1193
1094
Example: Conguring a Filter to Accept DHCP Packets Based on Address | 1189
Example: Conguring a Filter to Accept Packets Based on IPv6 TCP Flags
IN THIS SECTION
Requirements | 1095
Overview | 1095
Conguraon | 1095
Vericaon | 1098
This example shows how to congure a standard stateless rewall lter to accept packets from a trusted
source.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you create a lter that accepts packets with specic IPv6 TCP ags.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1096
Congure the Stateless Firewall Filter | 1096
Apply the Firewall Filter to the Loopback Interface | 1097
Conrm and Commit Your Candidate Conguraon | 1097
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
1095
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet6 filter tcp_filter term 1 from next-header tcp
set firewall family inet6 filter tcp_filter term 1 from tcp-flags syn
set firewall family inet6 filter tcp_filter term 1 then count tcp_syn_pkt
set firewall family inet6 filter tcp_filter term 1 then log
set firewall family inet6 filter tcp_filter term 1 then accept
set interfaces lo0 unit 0 family inet6 filter input tcp_filter
set interfaces lo0 unit 0 family inet6 address ::10.34.1.0/120
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the rewall lter
1. Create the IPv6 stateless rewall lter tcp_lter.
[edit]
user@host# edit firewall family inet6 filter tcp_filter
2. Specify that a packet matches if it is the inial packet in a TCP session and the next header aer the
IPv6 header is type TCP.
[edit firewall family inet6 filter tcp_filter]
user@host# set term 1 from next-header tcp
user@host# set term 1 from tcp-flags syn
3. Specify that matched packets are counted, logged to the buer on the Packet Forwarding Engine,
and accepted.
[edit firewall family inet6 filter tcp_filter]
user@host# set term 1 then count tcp_syn_pkt
user@host# set term 1 then log
user@host# set term 1 then accept
1096
Apply the Firewall Filter to the Loopback Interface
Step-by-Step Procedure
To apply the rewall lter to the loopback interface:
• [edit]
user@host# set interfaces lo0 unit 0 family inet6 filter input tcp_filter
user@host# set interfaces lo0 unit 0 family inet6 address ::10.34.1.0/120
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1.
Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet6 {
filter tcp_filter {
term 1 {
from {
next-header tcp;
tcp-flags syn;
}
then {
count tcp_syn_pkt;
log;
accept;
}
}
}
}
1097
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
lo0 {
unit 0 {
family inet6 {
filter {
input tcp_filter;
}
address ::10.34.1.0/120;
}
}
}
3. When you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show rewall operaonal mode
command.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods | 1107
Example: Conguring a Filter to Block TCP Access to a Port Except from Specied BGP Peers | 1099
1098
Example: Conguring a Filter to Block TCP Access to a Port Except from
Specied BGP Peers
IN THIS SECTION
Requirements | 1099
Overview | 1099
Conguraon | 1100
Vericaon | 1105
This example shows how to
congure a standard stateless rewall lter that blocks all TCP connecon
aempts to port 179 from all requesters except from specied BGP peers.
Requirements
No special conguraon beyond device inializaon is required before you congure this example.
Overview
IN THIS SECTION
Topology | 1099
In this example, you create a stateless rewall lter that blocks all TCP connecon aempts to port 179
from all requesters except the specied BGP peers.
The stateless rewall lter lter_bgp179 matches all packets from the directly connected interfaces on
Device A and Device B to the desnaon port number 179.
Topology
Figure 52 on page 1100 shows the topology used in this example. Device C aempts to make a TCP
connecon to Device E. Device E blocks the connecon aempt. This example shows the conguraon
on Device E.
1099
Figure 52: Typical Network with BGP Peer Sessions
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1100
Conguring Device E | 1101
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device C
set interfaces ge-1/2/0 unit 10 description to-E
set interfaces ge-1/2/0 unit 10 family inet address 10.10.10.10/30
set protocols bgp group external-peers type external
set protocols bgp group external-peers peer-as 17
set protocols bgp group external-peers neighbor 10.10.10.9
set routing-options autonomous-system 22
1100
Device E
set interfaces ge-1/2/0 unit 0 description to-A
set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30
set interfaces ge-1/2/1 unit 5 description to-B
set interfaces ge-1/2/1 unit 5 family inet address 10.10.10.5/30
set interfaces ge-1/0/0 unit 9 description to-C
set interfaces ge-1/0/0 unit 9 family inet address 10.10.10.9/30
set interfaces lo0 unit 2 family inet filter input filter_bgp179
set interfaces lo0 unit 2 family inet address 192.168.0.1/32
set protocols bgp group external-peers type external
set protocols bgp group external-peers peer-as 22
set protocols bgp group external-peers neighbor 10.10.10.2
set protocols bgp group external-peers neighbor 10.10.10.6
set protocols bgp group external-peers neighbor 10.10.10.10
set routing-options autonomous-system 17
set firewall family inet filter filter_bgp179 term 1 from source-address 10.10.10.2/32
set firewall family inet filter filter_bgp179 term 1 from source-address 10.10.10.6/32
set firewall family inet filter filter_bgp179 term 1 from destination-port bgp
set firewall family inet filter filter_bgp179 term 1 then accept
set firewall family inet filter filter_bgp179 term 2 then reject
Conguring Device E
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device E with a stateless rewall lter that blocks all TCP connecon aempts to port 179
from all requestors except specied BGP peers:
1. Congure the interfaces.
user@E# set interfaces ge-1/2/0 unit 0 description to-A
user@E# set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30
user@E# set interfaces ge-1/2/1 unit 5 description to-B
user@E# set interfaces ge-1/2/1 unit 5 family inet address 10.10.10.5/30
user@E# set interfaces ge-1/0/0 unit 9 description to-C
user@E# set interfaces ge-1/0/0 unit 9 family inet address 10.10.10.9/30
1101
2. Congure BGP.
[edit protocols bgp group external-peers]
user@E# set type external
user@E# set peer-as 22
user@E# set neighbor 10.10.10.2
user@E# set neighbor 10.10.10.6
user@E# set neighbor 10.10.10.10
3. Congure the autonomous system number.
[edit routing-options]
user@E# set autonomous-system 17
4. Dene the lter term that accepts TCP connecon aempts to port 179 from the specied BGP
peers.
[edit firewall family inet filter filter_bgp179]
user@E# set term 1 from source-address 10.10.10.2/32
user@E# set term 1 from source-address 10.10.10.6/32
user@E# set term 1 from destination-port bgp
user@E# set term 1 then accept
5. Dene the other lter term to reject packets from other sources.
[edit firewall family inet filter filter_bgp179]
user@E# set term 2 then reject
6. Apply the rewall lter to the loopback interface.
[edit interfaces lo0 unit 2 family inet]
user@E# set filter input filter_bgp179
user@E# set address 192.168.0.1/32
1102
Results
From conguraon mode, conrm your conguraon by entering the show rewall, show interfaces,
show protocols, and show roung-opons commands. If the output does not display the intended
conguraon, repeat the instrucons in this example to correct the conguraon.
user@E# show firewall
family inet {
filter filter_bgp179 {
term 1 {
from {
source-address {
10.10.10.2/32;
10.10.10.6/32;
}
destination-port bgp;
}
then accept;
}
term 2 {
then {
reject;
}
}
}
}
user@E# show interfaces
lo0 {
unit 2 {
family inet {
filter {
input filter_bgp179;
}
address 192.168.0.1/32;
}
}
}
ge-1/2/0 {
unit 0 {
description to-A;
1103
family inet {
address 10.10.10.1/30;
}
}
}
ge-1/2/1 {
unit 5 {
description to-B;
family inet {
address 10.10.10.5/30;
}
}
}
ge-1/0/0 {
unit 9 {
description to-C;
family inet {
address 10.10.10.9/30;
}
}
}
user@E# show protocols
bgp {
group external-peers {
type external;
peer-as 22;
neighbor 10.10.10.2;
neighbor 10.10.10.6;
neighbor 10.10.10.10;
}
}
user@E# show routing-options
autonomous-system 17;
If you are done conguring the device, enter commit from conguraon mode.
1104
Vericaon
IN THIS SECTION
Verifying That the Filter Is Congured | 1105
Verifying the TCP Connecons | 1105
Monitoring Trac on the Interfaces | 1106
Conrm that the conguraon is working properly.
Verifying That the Filter Is Congured
Purpose
Make sure that the lter is listed in output of the show firewall filter command.
Acon
user@E> show firewall filter filter_bgp179
Filter: filter_bgp179
Verifying the TCP Connecons
Purpose
Verify the TCP connecons.
Acon
From operaonal mode, run the show system connections extensive command on Device C and Device E.
1105
The output on Device C shows the aempt to establish a TCP connecon. The output on Device E
shows that connecons are established with Device A and Device B only.
user@C> show system connections extensive | match 10.10.10
tcp4 0 0 10.10.10.9.51872 10.10.10.10.179 SYN_SENT
user@E> show system connections extensive | match 10.10.10
tcp4 0 0 10.10.10.5.179 10.10.10.6.62096 ESTABLISHED
tcp4 0 0 10.10.10.6.62096 10.10.10.5.179 ESTABLISHED
tcp4 0 0 10.10.10.1.179 10.10.10.2.61506 ESTABLISHED
tcp4 0 0 10.10.10.2.61506 10.10.10.1.179 ESTABLISHED
Monitoring Trac on the Interfaces
Purpose
Use the monitor trac command to compare the trac on an interface that establishes a TCP
connecon with the trac on an interface that does not establish a TCP connecon.
Acon
From operaonal mode, run the monitor trac command on the Device E interface to Device B and on
the Device E interface to Device C. The following sample output veries that in the rst example,
acknowledgment (ack) messages are received. In the second example, ack messages are not received.
user@E> monitor traffic size 1500 interface ge-1/2/1.5
19:02:49.700912 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: P 3330573561:3330573580(19) ack
915601686 win 16384 <nop,nop,timestamp 1869518816 1869504850>: BGP, length: 19
19:02:49.801244 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: . ack 19 win 16384 <nop,nop,timestamp
1869518916 1869518816>
19:03:03.323018 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: P 1:20(19) ack 19 win 16384
<nop,nop,timestamp 1869532439 1869518816>: BGP, length: 19
19:03:03.422418 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: . ack 20 win 16384 <nop,nop,timestamp
1869532539 1869532439>
19:03:17.220162 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: P 19:38(19) ack 20 win 16384
<nop,nop,timestamp 1869546338 1869532439>: BGP, length: 19
1106
19:03:17.320501 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: . ack 38 win 16384 <nop,nop,timestamp
1869546438 1869546338>
user@E> monitor traffic size 1500 interface ge-1/0/0.9
18:54:20.175471 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384
<mss 1460,nop,wscale 0,nop,nop,timestamp 1869009240 0,sackOK,eol>
18:54:23.174422 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384
<mss 1460,nop,wscale 0,nop,nop,timestamp 1869012240 0,sackOK,eol>
18:54:26.374118 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384
<mss 1460,nop,wscale 0,nop,nop,timestamp 1869015440 0,sackOK,eol>
18:54:29.573799 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384
<mss 1460,sackOK,eol>
18:54:32.773493 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384
<mss 1460,sackOK,eol>
18:54:35.973185 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384
<mss 1460,sackOK,eol>
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods | 1107
Example: Conguring a Filter to Accept Packets Based on IPv6 TCP Flags | 1095
Example: Conguring a Stateless Firewall Filter to Protect Against TCP
and ICMP Floods
IN THIS SECTION
Requirements | 1108
Overview | 1108
Conguraon | 1109
Vericaon | 1116
1107
This example shows how to create a stateless rewall lter that protects against TCP and ICMP denial-
of-service aacks.
Requirements
No special conguraon beyond device inializaon is required before conguring stateless rewall
lters.
Overview
In this example we create a stateless rewall lter called protect-RE to police TCP and ICMP packets. It
uses the policers described here:
• tcp-connection-policer—This policer limits TCP trac to 1,000,000 bits per second (bps) with a
maximum burst size of 15,000 bytes. Trac exceeding either limit is discarded.
• icmp-policer—This policer limits ICMP trac to 1,000,000 bps with a maximum burst size of
15,000 bytes. Trac exceeding either limit is discarded.
When specifying limits, the bandwidth limit can be from 32,000 bps to 32,000,000,000 bps and the
burst-size limit can be from 1,500 bytes through 100,000,000 bytes. Use the following abbreviaons
when specifying limits: k (1,000), m (1,000,000), and g (1,000,000,000).
Each policer is incorporated into the acon of a lter term. This example includes the following terms:
• tcp-connection-term—Polices certain TCP packets with a source address of 192.168.0.0/24 or
10.0.0.0/24. These addresses are dened in the trusted-addresses prex list.
Filtered packets include tcp-established packets The tcp-established match condion is an alias for the
bit-eld match condion tcp-flags “(ack | rst)”, which indicates an established TCP session, but not
the rst packet of a TCP connecon.
• icmp-term—Polices ICMP packets. All ICMP packets are counted in the icmp-counter counter.
NOTE: You can move terms within the rewall lter by using the insert command. See
insert
in
the Junos OS CLI User Guide.
You can apply a stateless rewall to the input or output sides, or both, of an interface. To lter packets
transing the device, apply the rewall lter to any non-Roung Engine interface. To lter packets
originang from, or desned for, the Roung Engine, apply the rewall lter to the loopback (lo0)
interface.
Figure 53 on page 1109 shows the sample network.
1108
Figure 53: Firewall Filter to Protect Against TCP and ICMP Floods
Because this rewall lter limits Roung Engine trac to TCP packets, roung protocols that use other
transport protocols for Layer 4 cannot successfully establish sessions when this lter is acve. To
demonstrate, this example sets up OSPF between Device R1 and Device R2.
"CLI Quick Conguraon" on page 1109 shows the conguraon for all of the devices in Figure 53 on
page 1109.
The secon "No Link Title" on page 1111 describes the steps on Device R2.
Conguraon
IN THIS SECTION
Procedure | 1109
Procedure
CLI Quick Conguraon
To quickly congure the stateless rewall lter, copy the following commands to a text le, remove any
line breaks, and then paste the commands into the CLI.
1109
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 primary
set interfaces lo0 unit 0 family inet address 172.16.0.1/32
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext peer-as 200
set protocols bgp group ext neighbor 10.0.0.2
set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options router-id 192.168.0.1
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 lo0 unit 0 family inet filter input protect-RE
set interfaces lo0 unit 0 family inet address 192.168.0.2/32 primary
set interfaces lo0 unit 0 family inet address 172.16.0.2/32
set protocols bgp group ext type external
set protocols bgp group ext export send-direct
set protocols bgp group ext neighbor 10.0.0.1 peer-as 100
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
set policy-options prefix-list trusted-addresses 10.0.0.0/24
set policy-options prefix-list trusted-addresses 192.168.0.0/24
set policy-options policy-statement send-direct term 1 from protocol direct
set policy-options policy-statement send-direct term 1 then accept
set routing-options router-id 192.168.0.2
set routing-options autonomous-system 200
set firewall family inet filter protect-RE term tcp-connection-term from source-prefix-list
trusted-addresses
set firewall family inet filter protect-RE term tcp-connection-term from protocol tcp
set firewall family inet filter protect-RE term tcp-connection-term from tcp-established
set firewall family inet filter protect-RE term tcp-connection-term then policer tcp-connection-
policer
set firewall family inet filter protect-RE term tcp-connection-term then accept
set firewall family inet filter protect-RE term icmp-term from source-prefix-list trusted-
1110
addresses
set firewall family inet filter protect-RE term icmp-term from protocol icmp
set firewall family inet filter protect-RE term icmp-term then policer icmp-policer
set firewall family inet filter protect-RE term icmp-term then count icmp-counter
set firewall family inet filter protect-RE term icmp-term then accept
set firewall policer tcp-connection-policer filter-specific
set firewall policer tcp-connection-policer if-exceeding bandwidth-limit 1m
set firewall policer tcp-connection-policer if-exceeding burst-size-limit 15k
set firewall policer tcp-connection-policer then discard
set firewall policer icmp-policer filter-specific
set firewall policer icmp-policer if-exceeding bandwidth-limit 1m
set firewall policer icmp-policer if-exceeding burst-size-limit 15k
set firewall policer icmp-policer then discard
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure stateless rewall lter to discard :
1. Congure the device interfaces.
[edit interfaces fe-1/2/0 unit 0 family inet ]
user@R2# set address 10.0.0.2/30
[edit interfaces lo0 unit 0 family inet]
user@R2# set address 192.168.0.2/32 primary
user@R2# set address 172.16.0.2/32
2. Congure the BGP peering session.
[edit protocols bgp group ext]
user@R2# set type external
user@R2# set export send-direct
user@R2# set neighbor 10.0.0.1 peer-as 100
1111
3. Congure the autonomous system (AS) number and router ID.
[edit routing-options]
user@R2# set autonomous-system 200
user@R2# set router-id 192.168.0.2
4. Congure OSPF.
[edit protocols ospf area 0.0.0.0]
user@R2# set interface lo0.0 passive
user@R2# set interface fe-1/2/0.0
5. Dene the list of trusted addresses.
[edit policy-options prefix-list trusted-addresses]
user@R2# set 10.0.0.0/24
user@R2# set 192.168.0.0/24
6. Congure a policy to adverse direct routes.
[edit policy-options policy-statement send-direct term 1]
user@R2# set from protocol direct
user@R2# set then accept
7. Congure the TCP policer.
[edit firewall policer tcp-connection-policer]
user@R2# set filter-specific
user@R2# set if-exceeding bandwidth-limit 1m
user@R2# set if-exceeding burst-size-limit 15k
user@R2# set then discard
8. Create the ICMP policer.
[edit firewall policer icmp-policer]
user@R2# set filter-specific
user@R2# set if-exceeding bandwidth-limit 1m
1112
user@R2# set if-exceeding burst-size-limit 15k
user@R2# set then discard
9. Congure the TCP lter rules.
[edit firewall family inet filter protect-RE term tcp-connection-term]
user@R2# set from source-prefix-list trusted-addresses
user@R2# set from protocol tcp
user@R2# set from tcp-established
user@R2# set then policer tcp-connection-policer
user@R2# set then accept
10. Congure the ICMP lter rules.
[edit firewall family inet filter protect-RE term icmp-term]
user@R2# set from source-prefix-list trusted-addresses
user@R2# set from protocol icmp
user@R2# set then policer icmp-policer
user@R2# set then count icmp-counter
user@R2# set then accept
11. Apply the lter to the loopback interface.
[edit interfaces lo0 unit 0]
user@R2# set family inet filter input protect-RE
Results
Conrm your conguraon by entering the show interfaces, show protocols, show policy-options, show routing-
options, and show firewall commands from conguraon mode. If the output does not display the
intended conguraon, repeat the instrucons in this example to correct the conguraon.
user@R2# show interfaces
fe-1/2/0 {
unit 0 {
family inet {
address 10.0.0.2/30;
}
1113
}
}
lo0 {
unit 0 {
family inet {
filter {
input protect-RE;
}
address 192.168.0.2/32 {
primary;
}
address 172.16.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
type external;
export send-direct;
neighbor 10.0.0.1 {
peer-as 100;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fe-1/2/0.0;
}
}
user@R2# show policy-options
prefix-list trusted-addresses {
10.0.0.0/24;
192.168.0.0/24;
}
1114
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
user@R2# show routing-options
router-id 192.168.0.2;
autonomous-system 200;
user@R2# show firewall
family inet {
filter protect-RE {
term tcp-connection-term {
from {
source-prefix-list {
trusted-addresses;
}
protocol tcp;
tcp-established;
}
then {
policer tcp-connection-policer;
accept;
}
}
term icmp-term {
from {
source-prefix-list {
trusted-addresses;
}
protocol icmp;
}
then {
policer icmp-policer;
count icmp-counter;
accept;
}
}
1115
}
}
policer tcp-connection-policer {
filter-specific;
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 15k;
}
then discard;
}
policer icmp-policer {
filter-specific;
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 15k;
}
then discard;
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying Stateless Firewall Filter That Are in Eect | 1117
Using telnet to Verify the tcp-established Condion in the TCP Firewall Filter | 1117
Using telnet to Verify the Trusted Prexes Condion in the TCP Firewall Filter | 1119
Using OSPF to Verify the TCP Firewall Filter | 1120
Verifying the ICMP Firewall Filter | 1121
Conrm that the conguraon is working properly.
NOTE: To verify the TCP policer, you can use a packet generaon tool. This task is not shown
here.
1116
Displaying Stateless Firewall Filter That Are in Eect
Purpose
Verify the conguraon of the rewall lter.
Acon
From operaonal mode, enter the show firewall command.
user@R2> show firewall
Filter: protect-RE
Counters:
Name Bytes Packets
icmp-counter 0 0
Policers:
Name Bytes Packets
icmp-policer 0
tcp-connection-policer 0
Meaning
The output shows the lter, the counter, and the policers that are in eect on Device R2.
Using telnet to Verify the tcp-established Condion in the TCP Firewall Filter
Purpose
Make sure that telnet trac works as expected.
Acon
Verify that the device can establish only TCP sessions with hosts that meet the from tcp-established
condion.
1. From Device R2, make sure that the BGP session with Device R1 is established.
user@R2> show bgp summary | match down
Groups: 1 Peers: 1 Down peers: 0
1117
2. From Device R2, telnet to Device R1.
user@R2> telnet 192.168.0.1
Trying 192.168.0.1...
Connected to R1.example.net.
Escape character is '^]'.
R1 (ttyp4)
login:
3. From Device R1, telnet to Device R2.
user@R1> telnet 192.168.0.2
Trying 192.168.0.2...
telnet: connect to address 192.168.0.2: Operation timed out
telnet: Unable to connect to remote host
4. On Device R2, deacvate the from tcp-established match condion.
[edit firewall family inet filter protect-RE term tcp-connection-term]
user@R2# deactivate from tcp-established
user@R2# commit
5. From Device R1, try again to telnet to Device R2.
user@R1> telnet 192.168.0.1
Trying 192.168.0.2...
Connected to R2.example.net.
Escape character is '^]'.
R2 (ttyp4)
login:
Meaning
Verify the following informaon:
1118
• As expected , the BGP session is established. The from tcp-established match condion is not expected
to block BGP session establishment.
• From Device R2, you can telnet to Device R1. Device R1 has no rewall lter congured, so this is
the expected behavior.
• From Device R1, you cannot telnet to Device R2. Telnet uses TCP as the transport protocol, so this
result might be surprising. The cause for the lack of telnet connecvity is the from tcp-established
match condion. This match condion limits the type of TCP trac that is accepted of Device R2.
Aer this match condion is deacvated, the telnet session is successful.
Using telnet to Verify the Trusted Prexes Condion in the TCP Firewall Filter
Purpose
Make sure that telnet trac works as expected.
Acon
Verify that the device can establish only telnet sessions with a host at an IP address that matches one of
the trusted source addresses. For example, log in to the device with the telnet command from another
host with one of the trusted address prexes. Also, verify that telnet sessions with untrusted source
addresses are blocked.
1. From Device R1, telnet to Device R2 from an untrusted source address.
user@R1> telnet 172.16.0.2 source 172.16.0.1
Trying 172.16.0.2...
^C
2. From Device R2, add 172.16/16 to the list of trusted prexes.
[edit policy-options prefix-list trusted-addresses]
user@R2# set 172.16.0.0/16
user@R2# commit
3. From Device R1, try again to telnet to Device R2.
user@R1> telnet 172.16.0.2 source 172.16.0.1
Trying 172.16.0.2...
Connected to R2.example.net.
1119
Escape character is '^]'.
R2 (ttyp4)
login:
Meaning
Verify the following informaon:
• From Device R1, you cannot telnet to Device R2 with an unstrusted source address. Aer the
172.16/16 prex is added to the list of trusted prexes, the telnet request from source address
172.16.0.1 is accepted.
• OSPF session establishment is blocked. OSPF does not use TCP as its transport protocol. Aer the
from protocol tcp match condion is deacvated, OSPF session establishment is not blocked.
Using OSPF to Verify the TCP Firewall Filter
Purpose
Make sure that OSPF trac works as expected.
Acon
Verify that the device cannot establish OSPF connecvity.
1. From Device R1, check the OSPF sessions.
user@R1> show ospf neighbor
Address Interface State ID Pri Dead
10.0.0.2 fe-1/2/0.0 Init 192.168.0.2 128 34
2. From Device R2, check the OSPF sessions.
user@R2> show ospf neighbor
1120
3. From Device R2, remove the from protocol tcp match condion.
[edit firewall family inet filter protect-RE term tcp-connection-term]
user@R2# deactivate from protocol
user@R2# commit
4. From Device R1, recheck the OSPF sessions.
user@R1> show ospf neighbor
Address Interface State ID Pri Dead
10.0.0.2 fe-1/2/0.0 Full 192.168.0.2 128 36
5. From Device R2, recheck the OSPF sessions.
user@R2> show ospf neighbor
Address Interface State ID Pri Dead
10.0.0.1 fe-1/2/0.0 Full 192.168.0.1 128 39
Meaning
Verify the following informaon:
• OSPF session establishment is blocked. OSPF does not use TCP as its transport protocol. Aer the
from protocol tcp match condion is deacvated, OSPF session establishment is successful.
Verifying the ICMP Firewall Filter
Purpose
Verify that ICMP packets are being policed and counted. Also make sure that ping requests are
discarded when the requests originate from an untrusted source address.
Acon
1. Undo the conguraon changes made in previous vericaon steps.
1121
Reacvate the TCP rewall sengs, and delete the 172.16/16 trusted source address.
[edit firewall family inet filter protect-RE term tcp-connection-term]
user@R2# activate from protocol
user@R2# activate from tcp-established
[edit policy-options prefix-list trusted-addresses]
user@R2# delete 172.16.0.0/16
user@R2# commit
2. From Device R1, ping the loopback interface on Device R2.
user@R1> ping 192.168.0.2 rapid count 600 size 2000
PING 192.168.0.2 (192.168.0.2): 2000 data bytes
!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!
!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!
!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!
!!!!.!!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!
!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!
!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.
!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!
--- 192.168.0.2 ping statistics ---
600 packets transmitted, 536 packets received, 10% packet loss
pinground-trip min/avg/max/stddev = 2.976/3.405/42.380/2.293 ms
3. From Device R2, check the rewall stascs.
user@R2> show firewall
Filter: protect-RE
Counters:
Name Bytes Packets
icmp-counter 1180804 1135
Policers:
Name Bytes Packets
icmp-policer 66
tcp-connection-policer 0
1122
4. From an untrusted source address on Device R1, send a ping request to Device R2’s loopback
interface.
user@R1> ping 172.16.0.2 source 172.16.0.1
PING 172.16.0.2 (172.16.0.2): 56 data bytes
^C
--- 172.16.0.2 ping statistics ---
14 packets transmitted, 0 packets received, 100% packet loss
Meaning
Verify the following informaon:
• The ping output shows that 10% packet loss is occurring.
• The ICMP packet counter is incremenng, and the icmp-policer is incremenng.
• Device R2 does not send ICMP responses to the ping 172.16.0.2 source 172.16.0.1 command.
RELATED DOCUMENTATION
Example: Conguring a Stateless Firewall Filter to Accept Trac from Trusted Sources | 1069
Two-Color Policer Conguraon Overview | 2038
Example: Protecng the Roung Engine with a Packets-Per-Second Rate
Liming Filter
IN THIS SECTION
Requirements | 1124
Overview | 1124
Conguraon | 1124
Vericaon | 1127
1123
This example shows how to congure a packets-per-second based rate-liming lter to improve
security. It will be applied to the loopback interface in order to help protect the Roung Engine from
denial of service aacks.
BEST PRACTICE: This type of lter and policer combinaon is only one element in a
mullayered approach that can be used to help protect the Roung Engine. Other layers of
protecon are needed in order to fully protect the Roung Engine. See Day One: Securing
the Roung Engine on M, MX, and T Series for more informaon.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you use a stateless rewall lter to set packets-per-second (pps) rate limits for any
trac desned for the Roung Engine through the loopback interface (lo0.0).
To acvate a policer from within a stateless rewall lter conguraon:
1. Create a template for the policer by including the policer
policer-name
statement at the [edit firewall]
hierarchy.
2. Reference the policer in a lter term that species the policer in the policer
policer-name
nonterminang acon.
You can also apply a policer by including the policer (input | output)
policer-name
statement in a logical
interface conguraon.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1125
Conguring the Policer and the Stateless Firewall Filter | 1125
Applying the Stateless Firewall Filter to the Loopback Logical Interface | 1126
Results | 1126
1124
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set firewall policer police_pps if-exceeding-pps pps-limit 1k
set firewall policer police_pps if-exceeding-pps packet-burst 150
set firewall policer police_pps then discard
set firewall family inet filter my_pps_filter term term1 then policer police_pps
set interfaces lo0 unit 0 family inet filter input my_pps_filter
set interfaces lo0 unit 0 family inet address 127.0.0.1/32
Conguring the Policer and the Stateless Firewall Filter
Step-by-Step Procedure
To congure the policer
police_pps
and stateless rewall lter
my_pps_filter
:
1. Congure the policer template police_pps.
[edit firewall]
user@host# set policer police_pps if-exceeding-pps pps-limit 1k
user@host# set policer police_pps if-exceeding-pps packet-burst 150
user@host# set policer police_pps then discard
2. Create the stateless rewall lter my_pps_filter.
[edit]
user@host# edit firewall family inet filter my_pps_filter
1125
3. Congure a lter term that uses policer police_pps to rate limit trac by protocol family.
[edit firewall family inet filter my_pps_filter]
user@host# set term term1 then policer police_pps
Applying the Stateless Firewall Filter to the Loopback Logical Interface
Step-by-Step Procedure
To apply the lter my_pps_filter to the loopback interface:
1. Congure the logical loopback interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces lo0 unit 0
2. Apply the stateless rewall lter to the loopback interface.
[edit interfaces lo0 unit 0]
user@host# set family inet filter input my_pps_filter
3. Congure the interface address for the loopback interface.
[edit interfaces lo0 unit 0]
user@host# set family inet address 127.0.0.1/32
Results
Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this example to correct the conguraon.
user@host# show firewall
family inet{
filter my_pps_filter {
term term1 {
then policer police_pps;
1126
}
}
}
policer police_pps {
if-exceeding-pps {
pps-limit 1k;
packet-burst 150;
}
then discard;
}
Conrm the conguraon of the interface by entering the show interfaces lo0 conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this example to correct the conguraon.
user@host# show interfaces lo0
unit 0 {
family inet {
filter {
input my_pps_filter;
}
address 127.0.0.1/32;
}
}
If you are done conguring the device, enter commit from conguraon mode.
user@host# commit
Vericaon
IN THIS SECTION
Verifying the Operaon of the Filter | 1128
1127
Verifying the Operaon of the Filter
Purpose
To conrm that the conguraon is working properly, enter the show firewall filter my_pps_filter
operaonal mode command.
NOTE: The following output results from running a rapid ping from another host to the router
under test. In order to show results in the output, a pps-limit seng of 50 and a packet-burst
seng of 10 were used during the ping test.
Acon
user@host> show firewall filter my_pps_filter
Filter: my_pps_filter
Policers:
Name Bytes Packets
police_pps-term1 8704 17
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Packets-Per-Second (pps)-Based Policer Overview | 1938
if-exceeding-pps (Policer)
Example: Conguring a Filter to Exclude DHCPv6 and ICMPv6 Control
Trac for LAC Subscriber
IN THIS SECTION
Requirements | 1129
Overview | 1129
1128
Conguraon | 1129
This example shows how to congure a standard stateless rewall lter that excludes DHCPv6 and
ICMPv6 control packets from being considered for idle-meout detecon for tunneled subscribers at
the LAC.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
Subscriber access on a LAC can be limited by conguring an idle meout period that species the
maximum period of me a subscriber can remain idle aer the subscriber session is established. The
LAC monitors the subscriber’s upstream and downstream data trac to determine whether the
subscriber is inacve. Based on the session accounng stascs. the subscriber is not considered idle as
long as data trac is detected in either direcon. When no trac is detected for the duraon of the idle
me out, the subscriber is logged out gracefully similarly to a RADIUS-iniated disconnect or a CLI-
iniated logout.
However, aer a tunnel is established for L2TP subscribers, all packets through the tunnel at the LAC
are treated as data packets. Consequently, the accounng stascs for the session are inaccurate and
the subscriber is not considered to be idle as long as DHCPv6 and ICMPv6 control packets are being
sent.
Starng in Junos OS Release 17.2R1, you can dene a rewall lter for the inet6 family with terms to
match on these control packets. Include the use the exclude-accounting terminang acon in the lter
terms to drop these control packets.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1130
Congure the Filter | 1130
Results | 1133
1129
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set access profile v6-exclude-idle session-options client-idle-timeout 10
set access profile v6-exclude-idle session-options client-idle-timeout-ingress-only
edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER
set interface-specific
set term EXCLUDE-ACCT-DHCP-INET6 from next-header udp
set term EXCLUDE-ACCT-DHCP-INET6 from source-port 546
set term EXCLUDE-ACCT-DHCP-INET6 from source-port 547
set term EXCLUDE-ACCT-DHCP-INET6 from destination-port 546
set term EXCLUDE-ACCT-DHCP-INET6 from destination-port 547
set term EXCLUDE-ACCT-DHCP-INET6 then count exclude-acct-dhcpv6
set term EXCLUDE-ACCT-DHCP-INET6 then exclude-accounting
set term EXCLUDE-ACCT-ICMP6 from next-header icmp6
set term EXCLUDE-ACCT-ICMP6 from icmp-type router-solicit
set term EXCLUDE-ACCT-ICMP6 from icmp-type neighbor-solicit
set term EXCLUDE-ACCT-ICMP6 from icmp-type neighbor-advertisement
set term EXCLUDE-ACCT-ICMP6 then count exclude-acct-icmpv6
set term EXCLUDE-ACCT-ICMP6 then exclude-accounting
set term default then accept
top
edit dynamic-profiles pppoe-dynamic-profile interfaces pp0 unit "$junos-interface-unit"
set family inet6 filter input EXCLUDE-ACCT-INET6-FILTER
set family inet6 filter output EXCLUDE-ACCT-INET6-FILTER
set actual-transit-statistics
Congure the Filter
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in theCLI User
Guide.
1130
To congure the lter:
1. Set the idle meout for subscriber sessions..
[edit access profile v6-exclude-idle]
user@host# set session-options client-idle-timeout 10
2. Specify the idle meout applies only to ingress trac.
[edit access profile v6-exclude-idle]
user@host# set session-options client-idle-timeout-ingress-only
3. Dene the rewall lter term that excludes the DHCPv6 control packets from accounng stascs.
a. Specify a match on packets with the rst Next Header eld set to UDP (17).
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-DHCP-INET6 from next-header udp
b. Specify a match on packets with a source port of 546 or 547 (DHCPv6).
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-DHCP-INET6 from source-port 546
user@host# set term EXCLUDE-ACCT-DHCP-INET6 from source-port 547
c. Specify a match on packets with a DHCP desnaon port of 546 or 547 (DHCPv6).
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-DHCP-INET6 from destination-port 546
user@host# set term EXCLUDE-ACCT-DHCP-INET6 from destination-port 547
d. Count the matched DHCPv6 packets.
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-DHCP-INET6 then count exclude-acct-dhcpv6
1131
e. Exclude the matched DHCPv6 packets from accounng stascs.
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-DHCP-INET6 then exclude-accounting
4. Dene the rewall lter term that excludes the ICMPv6 control packets from accounng stascs.
a. Specify a match on packets with the rst Next Header eld set to ICMPv6 (58).
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-ICMP6 from next-header icmp6
b. Specify a match on packets with an ICMPv6 message type.
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-ICMP6 from icmp-type router-solicit
user@host# set term EXCLUDE-ACCT-ICMP6 from icmp-type neighbor-solicit
user@host# set term EXCLUDE-ACCT-ICMP6 from icmp-type neighbor-advertisement
c. Count the matched ICMPv6 packets.
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-ICMP6 then count exclude-acct-icmpv6
d. Exclude the matched ICMPv6 packets from accounng stascs.
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term EXCLUDE-ACCT-DHCP-INET6 then exclude-accounting
5. Dene the default lter term to accept all other packets.
[edit firewall family inet6 filter EXCLUDE-ACCT-INET6-FILTER]
user@host# set term default then accept
1132
6. Congure the dynamic prole to apply the lter to input and output interfaces for the inet6 family.
[edit dynamic-profiles pppoe-dynamic-profile interfaces pp0 unit "$junos-interface-unit"]
user@host# set family inet6 filter input EXCLUDE-ACCT-INET6-FILTER
user@host# set family inet6 filter output EXCLUDE-ACCT-INET6-FILTER
7. Enable subscriber management accurate accounng.
[edit dynamic-profiles pppoe-dynamic-profile interfaces pp0 unit "$junos-interface-unit"]
user@host# set actual-transit-statistics
Results
From conguraon mode, conrm your conguraon by entering the show access, show firewall, and show
dynamic-profiles commands. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
user@host# show access
profile v6-exclude-idle {
session-options {
client-idle-timeout 10;
client-idle-timeout-ingress-only;
}
}
user@host# show firewall
family inet6 {
filter EXCLUDE-ACCT-INET6-FILTER {
interface-specific;
term EXCLUDE-ACCT-DHCP-INET6 {
from {
next-header udp;
source-port [ 546 547 ];
destination-port [ 546 547 ];
}
then {
count exclude-acct-dhcpv6;
exclude-accounting
1133
}
}
term EXCLUDE-ACCT-ICMP6 {
from {
next-header icmp6;
icmp-type [ router-solicit neighbor-solicit neighbor-advertisement ]
}
then {
count exclude-acct-icmpv6;
exclude-accounting;
}
}
term default {
then accept;
}
}
}
user@host# show dynamic-profiles
pppoe-dynamic-profile {
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
family inet6 {
filter {
input EXCLUDE-ACCT-INET6-FILTER;
output EXCLUDE-ACCT-INET6-FILTER;
}
}
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
RELATED DOCUMENTATION
Classic Filters Overview
1134
Dynamically Aaching Stacally Created Filters for a Specic Interface Family Type
Understanding How to Use Standard Firewall Filters
Firewall Filter Terminang Acons
Firewall Filter Match Condions for IPv6 Trac
Port Number Requirements for DHCP Firewall Filters
When you congure a
rewall lter
to perform some acon on DHCP packets at the Roung Engine,
such as protecng the Roung Engine by allowing only proper DHCP packets, you must specify both
port 67 (bootps) and port 68 (bootpc) for both the source and desnaon. The rewall lter acts at both
the line cards and the Roung Engine.
This requirement applies to both DHCP local server and DHCP relay, but it applies only when DHCP is
provided by the jdhcpd process. MX Series routers use jdhcpd. For DHCP relay, that means the
conguraon is required only at the [edit forwarding-options dhcp-relay] hierarchy level and not at the [edit
forwarding-options helpers bootp] hierarchy level.
DHCP packets received on the line cards are encapsulated by jdhcpd with a new UDP header where
their source and desnaon addresses are set to port 68 before being forwarded to the Roung Engine.
For DHCP relay and DHCP proxy, packets sent to the DHCP server from the router have both the
source and desnaon UDP ports set to 67. The DHCP server responds using the same ports. However,
when the line card receives these DHCP response packets, it changes both port numbers from 67 to 68
before passing the packets to the Roung Engine. Consequently the lter needs to accept port 67 for
packets relayed from the client to the server, and port 68 for packets relayed from the server to the
client.
Failure to include both port 67 and port 68 as described here results in most DHCP packets not being
accepted.
For complete informaon about conguring rewall lters in general, see Junos OS Roung Policies,
Firewall Filters and Trac Policers User Guide for Roung Devices.
RELATED DOCUMENTATION
Example: Conguring a DHCP Firewall Filter to Protect the Roung Engine | 1136
Understanding Dierences Between Legacy DHCP and Extended DHCP
Extended DHCP Relay Agent Overview
Understanding Dynamic Firewall Filters
1135
Example: Conguring a DHCP Firewall Filter to Protect the Roung
Engine
IN THIS SECTION
Requirements | 1136
Overview | 1136
Conguraon | 1137
Vericaon | 1140
This example shows how to
congure a rewall lter to ensure that proper DHCP packets can reach the
Roung Engine on MX Series routers.
Requirements
This conguraon example applies only to routers where DHCP local server and DHCP relay agent
services are provided by the jdhcpd process rather than the legacy dhcpd process or fud (UDP
forwarding) process. MX Series routers, M120 routers, and M320 routers use jdhcpd. For DHCP relay,
that means the conguraon is required only at the [edit forwarding-options dhcp-relay] hierarchy level and
not at the [edit forwarding-options helpers bootp] hierarchy level.
No special conguraon beyond device inializaon is required before you can congure this feature.
Overview
Firewall lters that perform some acon on DHCP packets at the Roung Engine, such as a lter to
protect the Roung Engine by allowing only proper DHCP packets, require that both port 67 (bootps)
and port 68 (bootpc) are congured as both source and desnaon ports.
DHCP packets received on the line cards are encapsulated by jdhcpd with a new UDP header where
their source and desnaon addresses are set to port 68 before being forwarded to the Roung Engine.
For DHCP relay and DHCP proxy, packets sent to the DHCP server from the router have both the
source and desnaon UDP ports set to 67. The DHCP server responds using the same ports. However,
when the line card receives these DHCP response packets, it changes both port numbers from 67 to 68
before passing the packets to the Roung Engine. Consequently the lter needs to accept port 67 for
packets relayed from the client to the server, and port 68 for packets relayed from the server to the
client.
In this example, you congure two lter terms, dhcp-client-accept and dhcp-server-accept. The match
condions for dhcp-client-accept specify a source address and desnaon address for broadcast packets,
1136
the UDP protocol used for DHCP packets, and the bootpc (68) source port. Packets that match these
condions are counted and accepted. This term does not need to specify a match condion for the boot
ps (67) desnaon port. As congured below, this term can handle both the actual packet (port 68)
passing to the Packet Forwarding Engine and the encapsulated packet (port 67 converted to 68 by
jdhcpd) that reaches the DHCP daemon.
The match condions for dhcp-server-accept specify the UDP protocol used for DHCP packets, and both
port 67 and 68 for both source port and desnaon port. Packets that match these condions are
counted and accepted.
NOTE: This example does not show all possible conguraon choices, nor does it show how the
lter is applied in your conguraon. This example applies to both stac applicaon of the lter
as well as dynamic applicaon with a dynamic prole.
Conguraon
IN THIS SECTION
Procedure | 1137
Procedure
CLI Quick Conguraon
To quickly congure the sample Roung Engine DHCP lter, copy the following commands, paste them
in a text le, remove any line breaks, and then copy and paste the commands into the CLI.
[edit]
edit firewall family inet filter RE-protect
edit term dhcp-client-accept
set from source-address 0.0.0.0/32
set from destination-address 255.255.255.255/32
set from protocol udp
set from source-port 68
set then count dhcp-client-accept
set then accept
up
edit term dhcp-server-accept
1137
set from protocol udp
set from source-port 67
set from source-port 68
set from destination-port 67
set from destination-port 68
set then count dhcp-server-accept
set then accept
top
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see
Using the CLI Editor in Conguraon Mode
.
To congure a DHCP rewall lter to protect the Roung Engine:
1. Create or specify a rewall lter.
[edit firewall]
user@host# edit family inet filter RE-protect
2. Create a lter term for the client.
[edit firewall family inet filter RE-protect]
user@host# edit term dhcp-client-accept
3. Specify the match condions for DHCP packets.
[edit firewall family inet filter RE-protect term dhcp-client-accept]
user@host# set from source-address 0.0.0.0/32
user@host# set from destination-address 255.255.255.255/32
user@host# set from protocol udp
user@host# set from source-port 68
user@host# set from destination-port 67
1138
4. Specify the acon to take for matched packets.
[edit firewall family inet filter RE-protect term dhcp-client-accept]
user@host# set then count dhcp-client-accept
user@host# set then accept
5. Create a lter term for the server.
[edit firewall family inet filter RE-protect]
user@host# edit term dhcp-server-accept
6. Specify the match condions for DHCP packets.
[edit firewall family inet filter RE-protect term dhcp-server-accept]
user@host# set from protocol udp
user@host# set from source-port [67 68]
user@host# set from destination-port [67 68]
7. Specify the acon to take for matched packets.
[edit firewall family inet filter RE-protect term dhcp-server-accept]
user@host# set then count dhcp-client-accept
user@host# set then accept
Results
From conguraon mode, conrm your conguraon by entering the show firewall command. If the
output does not display the intended conguraon, repeat the conguraon instrucons in this example
to correct it.
[edit]
user@host# show firewall
family inet {
filter RE-protect {
term dhcp-client-accept {
from {
source-address {
0.0.0.0/32;
1139
}
destination-address {
255.255.255.255/32;
}
protocol udp;
source-port 68;
destination-port 67;
}
then {
count dhcp-client-accept;
accept;
}
}
term dhcp-server-accept {
from {
protocol udp;
source-port [ 67 68 ];
destination-port [ 67 68 ];
}
then {
count dhcp-server-accept;
accept;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the DHCP Filter Operaon | 1141
To conrm that the Roung Engine DHCP protecon lter is properly passing DHCP packets, perform
these tasks:
1140
Verifying the DHCP Filter Operaon
Purpose
Verify that both counters increment as DHCP trac passes to the Roung Engine.
Acon
From operaonal mode, enter the show firewall family inet filter RE-protect command.
user@host> show firewall family inet filter RE-protect
Filter: RE-protect
Counters:
Name Bytes Packets
dhcp-client-accept 328 1
dhcp-server-accept 574 1
user@host> show firewall family inet filter RE-protect
Filter: RE-protect
Counters:
Name Bytes Packets
dhcp-client-accept 660 2
dhcp-server-accept 1152 2
Meaning
The output lists both congured counters, dhcp-client-accept and dhcp-server-accept. By issuing the
command more than once, you can see that the byte and packet elds both show that trac is being
accepted and counted.
RELATED DOCUMENTATION
Port Number Requirements for DHCP Firewall Filters | 1135
Understanding Dynamic Firewall Filters
Understanding Dynamic Firewall Filters
Junos OS Roung Policies, Firewall Filters and Trac Policers User Guide for Roung Devices
Understanding Dierences Between Legacy DHCP and Extended DHCP
Extended DHCP Relay Agent Overview
1141
CHAPTER 16
Applying Firewall Filters to Transit Trac
IN THIS CHAPTER
Example: Conguring a Filter for Use as an Ingress Queuing Filter | 1142
Example: Conguring a Filter to Match on IPv6 Flags | 1146
Example: Conguring a Filter to Match on Port and Protocol Fields | 1148
Example: Conguring a Filter to Count Accepted and Rejected Packets | 1153
Example: Conguring a Filter to Count and Discard IP Opons Packets | 1158
Example: Conguring a Filter to Count IP Opons Packets | 1162
Example: Conguring a Filter to Count and Sample Accepted Packets | 1169
Example: Conguring a Filter to Set the DSCP Bit to Zero | 1176
Example: Conguring a Filter to Set the DSCP Bit to Zero | 1181
Example: Conguring a Filter to Match on Two Unrelated Criteria | 1185
Example: Conguring a Filter to Accept DHCP Packets Based on Address | 1189
Example: Conguring a Filter to Accept OSPF Packets from a Prex | 1193
Example: Conguring a Stateless Firewall Filter to Handle Fragments | 1197
Conguring a Firewall Filter to Prevent or Allow IPv4 Packet Fragmentaon | 1205
Conguring a Firewall Filter to Discard Ingress IPv6 Packets with a Mobility Extension Header | 1206
Example: Conguring an Egress Filter Based on IPv6 Source or Desnaon IP Addresses | 1207
Example: Conguring a Rate-Liming Filter Based on Desnaon Class | 1212
Example: Conguring a Filter for Use as an Ingress Queuing Filter
IN THIS SECTION
Requirements | 1143
Overview | 1143
1142
Conguraon | 1144
This example shows how to congure a rewall lter for use as an ingress queuing lter. The ingress
queuing lter assists in trac shaping operaons by enabling you to set the forwarding class and packet
loss priority, or drop the packet before ingress queue selecon. The rewall lter must be congured
within one of the following protocol families: bridge, cc, inet, inet6, mpls, or vpls and have one or more of
the following acons: accept, discard, forwarding-class, and loss-priority.
NOTE: Although the ingress queuing lter can be used with EX9200 switches and T-Series
routers as well as MX-Series routers, it is used only on those MX Series routers that have MPCs.
An error is generated at commit if the ingress queuing lter is applied to an interface on any
other type of port concentrator.
Requirements
This example uses the following hardware and soware components:
• An MX Series router with MPC
In order for ingress queuing lters to funcon, ingress-and-egress must be congured as the traffic-manager
mode at the [edit chassis fpc
slot
pic
slot
traffic-manager mode] hierarchy level.
Overview
In this example, you create a rewall lter named iqfilter1 in the inet protocol family that sets the loss
priority and forwarding class of packets coming from the 192.168.2.0/24 network. You then apply the
iqfilter1 lter to the ge-0/0/0.0 logical interface as an ingress queuing lter.
To congure a rewall lter and apply it for use as an ingress queuing lter involves:
• Creang a rewall lter named iqfilter1 in the inet protocol family with the following two acons:
forwarding-class and loss-priority.
• Applying the rewall lter to the ge-0/0/0.0 interface as an ingress queuing lter.
1143
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1144
Conguring the Firewall Filter and Applying It to an Interface as an Input Queuing Filter | 1144
Results | 1145
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter iqfilter1 term t1 from address 192.168.2.0/24
set firewall family inet filter iqfilter1 term t1 then loss-priority low
set firewall family inet filter iqfilter1 term t1 then forwarding-class expedited-forwarding
set interfaces ge-0/0/0 unit 0 family inet ingress-queuing-filter iqfilter1
Conguring the Firewall Filter and Applying It to an Interface as an Input Queuing Filter
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure the rewall lter, iqfilter1, and apply it to logical interface ge-0/0/0 unit 0:
1. Create a rewall lter named iqfilter1.
[edit firewall family inet]
user@router# set filter iqfilter1 term t1 from address 192.168.2.0/24
user@router# set filter iqfilter1 term t1 then loss-priority low
user@router# set filter iqfilter1 term t1 then forwarding-class expedited-forwarding
1144
2. Apply the rewall lter to the logical interface.
[edit]
user@router# set interfaces ge-0/0/0 unit 0 family inet ingress-queuing-filter iqfilter1
Results
From conguraon mode, conrm your conguraon by entering the show firewall and the show interfaces
ge-0/0/0.0 commands. If the output does not display the intended conguraon, repeat the instrucons
in this example to correct the conguraon.
user@router# show firewall
family inet {
filter iqfilter1 {
term t1 {
from {
address {
192.168.0.0/24;
}
}
then {
loss-priority low;
forwarding-class expedited-forwarding;
}
}
}
}
user@router# show interfaces ge-0/0/0.0
family inet {
ingress-queuing-filter iqfilter1;
}
If you are done conguring the device, enter commit from conguraon mode.
user@router# commit
1145
RELATED DOCUMENTATION
Muleld Classier for Ingress Queuing on MX Series Routers with MPC | 1334
ingress-queuing-lter
Example: Conguring a Filter to Match on IPv6 Flags
IN THIS SECTION
Requirements | 1146
Overview | 1146
Conguraon | 1146
Vericaon | 1148
This example shows how to congure a lter to match on IPv6 TCP ags.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you congure a lter to match on IPv6 TCP ags. You can use this example to congure
IPv6 TCP ags in M Series, MX Series, and T Series roung devices.
Conguraon
IN THIS SECTION
Procedure | 1147
1146
Procedure
Step-by-Step Procedure
To congure a lter to match on IPv6 TCP ags:
1. Include the family statement at the rewall hierarchy level, specifying inet6 as the protocol family.
[edit]
user@host# edit firewall family inet6
2. Create the stateless rewall lter.
[edit firewall family inet6]
user@host# edit filter tcpfilt
3. Dene the rst term for the lter.
[edit firewall family inet6 filter tcpfilt]
user@host# edit term 1
4. Dene the source address match condions for the term.
[edit firewall family inet6 filter tcpfilt term 1]
user@host# set from next-header tcp tcp-flags syn
5. Dene the acons for the term.
[edit firewall family inet6 filter tcpfilt term 1]
user@host# set then count tcp_syn_pkt log accept
6. If you are done conguring the device, commit the conguraon.
[edit firewall family inet6 filter tcpfilt term 1]
user@host top
1147
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter tcpfilt command.
Example: Conguring a Filter to Match on Port and Protocol Fields
IN THIS SECTION
Requirements | 1148
Overview | 1148
Conguraon | 1148
Vericaon | 1153
This example shows how to congure a standard stateless rewall lter to match on desnaon port
and protocol elds.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you congure a stateless rewall lter that accepts all IPv4 packets except for TCP and
UDP packets. TCP and UDP packets are accepted if desned for the SSH port or the Telnet port. All
other packets are rejected.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1149
Congure the Stateless Firewall Filter | 1149
1148
Apply the Stateless Firewall Filter to a Logical Interface | 1150
Conrm and Commit Your Candidate Conguraon | 1151
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level:
set firewall family inet filter filter1 term term1 from protocol-except tcp
set firewall family inet filter filter1 term term1 from protocol-except udp
set firewall family inet filter filter1 term term1 then accept
set firewall family inet filter filter1 term term2 from address 192.168.0.0/16
set firewall family inet filter filter1 term term2 then reject
set firewall family inet filter filter1 term term3 from destination-port ssh
set firewall family inet filter filter1 term term3 from destination-port telnet
set firewall family inet filter filter1 term term3 then accept
set firewall family inet filter filter1 term term4 then reject
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
set interfaces ge-0/0/1 unit 0 family inet filter input filter1
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter filter1:
1. Create the IPv4 stateless rewall lter.
[edit]
user@host# edit firewall family inet filter filter1
1149
2. Congure a term to accept all trac except for TCP and UDP packets.
[edit firewall family inet filter filter1]
user@host# set term term1 from protocol-except tcp
user@host# set term term1 from protocol-except udp
user@host# set term term1 then accept
3. Congure a term to reject packets to or from the 192.168/16 prex.
[edit firewall family inet filter filter1]
user@host# set term term2 from address 192.168.0.0/16
user@host# set term term2 then reject
4. Congure a term to accept packets desned for either the SSH port or the Telnet port.
[edit firewall family inet filter filter1]
user@host# set term term3 from destination-port ssh
user@host# set term term3 from destination-port telnet
user@host# set term term3 then accept
5. Congure the last term to reject all packets.
[edit firewall family inet filter filter1]
user@host# set term term4 then reject
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
1150
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the stateless rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input filter1
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter filter1 {
term term1 {
from {
protocol-except [tcp udp];
}
then {
accept;
}
}
term term2 {
from {
address 192.168/16;
}
then {
reject;
}
}
1151
term term3 {
from {
destination-port [ssh telnet];
}
then {
accept;
}
}
term term4 {
then {
reject;
}
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
filter {
input filter1;
}
address 10.1.2.3/30;
}
}
}
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
1152
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter filter1 operaonal
mode command.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Filter to Match on IPv6 Flags | 1146
Example: Conguring a Filter to Match on Two Unrelated Criteria | 1185
Example: Conguring a Filter to Count Accepted and Rejected Packets
IN THIS SECTION
Requirements | 1153
Overview | 1153
Conguraon | 1154
Vericaon | 1157
This example shows how to congure a rewall lter to count packets.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 1154
In this example, you use a stateless rewall lter to reject all addresses except 192.168.5.0/24.
1153
Topology
In the rst term, the match condion address 192.168.5.0/24 except causes this address to be considered a
mismatch, and this address is passed to the next term in the lter. The match condion address 0.0.0.0/0
matches all other packets, and these are counted, logged, and rejected.
In the second term, all packets that passed though the rst term (that is, packets whose address matches
192.168.5.0/24) are counted, logged, and accepted.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1154
Congure the Stateless Firewall Filter | 1155
Apply the Stateless Firewall Filter to a Logical Interface | 1155
Conrm and Commit Your Candidate Conguraon | 1156
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter fire1 term 1 from address 192.168.5.0/24 except
set firewall family inet filter fire1 term 1 from address 0.0.0.0/0
set firewall family inet filter fire1 term 1 then count reject_pref1_1
set firewall family inet filter fire1 term 1 then log
set firewall family inet filter fire1 term 1 then reject
set firewall family inet filter fire1 term 2 then count reject_pref1_2
set firewall family inet filter fire1 term 2 then log
set firewall family inet filter fire1 term 2 then accept
set interfaces ge-0/0/1 unit 0 family inet filter input fire1
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
1154
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter fire1:
1. Create the stateless rewall lter fire1.
[edit]
user@host# edit firewall family inet filter fire1
2. Congure the rst term to reject all addresses except those to or from the 192.168.5.0/24 prex and
then count, log, and reject all other packets.
[edit firewall family inet filter fire1]
user@host# set term 1 from address 192.168.5.0/24 except
user@host# set term 1 from address 0.0.0.0/0
user@host# set term 1 then count reject_pref1_1
user@host# set term 1 then log
user@host# set term 1 then reject
3. Congure the next term to count, log, and accept packets in the 192.168.5.0/24 prex.
[edit firewall family inet filter fire1]
user@host# set term 2 then count reject_pref1_2
user@host# set term 2 then log
user@host# set term 2 then accept
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
1155
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the stateless rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input fire1
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter fire1 {
term 1 {
from {
address {
192.168.5.0/24 except;
0.0.0.0/0;
}
}
then {
count reject_pref1_1;
log;
reject;
}
}
term 2 {
then {
count reject_pref1_2;
1156
log;
accept;
}
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
filter {
input fire1;
}
address 10.1.2.3/30;
}
}
}
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter fire1 operaonal
mode command. You can also display the log and individual counters separately by using the following
forms of the command:
• show firewall counter reject_pref1_1
•
show firewall counter reject_pref1_2
• show firewall log
1157
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Filter to Count IP Opons Packets | 1162
Example: Conguring a Filter to Count and Discard IP Opons Packets | 1158
Example: Conguring a Filter to Count and Discard IP Opons Packets
IN THIS SECTION
Requirements | 1158
Overview | 1158
Conguraon | 1159
Vericaon | 1162
This example shows how to congure a standard stateless rewall to count packets.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Because the lter term matches on
any
IP opon value, the lter term can use the count nonterminang
acon without the discard terminang acon or (alternavely) without requiring an interface on a 10-
Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit Ethernet MPC, 60-Gigabit Queuing
Ethernet MPC, or 60-Gigabit Ethernet Enhanced Queuing MPC on an MX Series router.
Overview
In this example, you use a standard stateless rewall lter to count and discard packets that include any
IP opon value but accept all other packets.
The IP opon header eld is an oponal eld in IPv4 headers only. The ip-options and ip-options-except
match condions are supported for standard stateless rewall lters and service lters only.
NOTE: On M and T series routers, rewall lters cannot count ip-options packets on a per opon
type and per interface basis. A limited work around is to use the show pfe statistics ip options
1158
command to see ip-options stascs on a per Packet Forwarding Engine (PFE) basis. See show pfe
stascs ip for sample output.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1159
Congure the Stateless Firewall Filter | 1159
Apply the Stateless Firewall Filter to a Logical Interface | 1160
Conrm and Commit Your Candidate Conguraon | 1161
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter block_ip_options term 10 from ip-options any
set firewall family inet filter block_ip_options term 10 then count option_any
set firewall family inet filter block_ip_options term 10 then discard
set firewall family inet filter block_ip_options term 999 then accept
set interfaces ge-0/0/1 unit 0 family inet filter input block_ip_options
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter:
1159
1. Create the stateless rewall lter block_ip_options.
[edit]
user@host# edit firewall family inet filter block_ip_options
2. Congure the rst term to count and discard packets that include any IP opons header elds.
[edit firewall family inet filter block_ip_options]
user@host# set term 10 from ip-options any
user@host# set term 10 then count option_any
user@host# set term 10 then discard
3. Congure the other term to accept all other packets.
[edit firewall family inet filter block_ip_options]
user@host# set term 999 then accept
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
1160
3. Apply the stateless rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input block_ip_options
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter block_ip_options {
term 10 {
from {
ip-options any;
}
then {
count option_any;
discard;
}
}
term 999 {
then accept;
}
}
}
2.
Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
1161
ge-0/0/1 {
unit 0 {
family inet {
filter {
input block_ip_options;
}
address 10.1.2.3/30;
}
}
}
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter block_ip_options
operaonal mode command. To display the count of discarded packets separately, enter the show firewall
count option_any form of the command.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Filter to Count Accepted and Rejected Packets | 1153
Example: Conguring a Filter to Count IP Opons Packets | 1162
Example: Conguring a Filter to Count IP Opons Packets
IN THIS SECTION
Requirements | 1163
Overview | 1163
Conguraon | 1163
1162
Vericaon | 1169
This example shows how use a stateless rewall lter to count individual IP opons packets:
Requirements
This example uses an interface on a 10-Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit
Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, or 60-Gigabit Ethernet Enhanced Queuing MPC on
an MX Series router. This interface enables you to apply an IPv4 rewall lter (standard or service lter)
that can use the count, log, and syslog nonterminang acons on packets that match a
specic
ip-option
value without having to also use the discard terminang acon.
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you use a stateless rewall lter to count IP opons packets but not block any trac.
Also, the lter logs packets that have loose or strict source roung.
The IP opon header eld is an oponal eld in IPv4 headers only. The ip-options and ip-options-except
match condions are supported for standard stateless rewall lters and service lters only.
NOTE: On M and T series routers, rewall lters cannot count ip-options packets on a per opon
type and per interface basis. A limited work around is to use the show pfe statistics ip options
command to see ip-options stascs on a per Packet Forwarding Engine (PFE) basis. See show pfe
stascs ip for sample output.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1164
Congure the Stateless Firewall Filter | 1164
Apply the Stateless Firewall Filter to a Logical Interface | 1166
Conrm and Commit Your Candidate Conguraon | 1167
1163
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter ip_options_filter term match_strict_source from ip-options
strict-source-route
set firewall family inet filter ip_options_filter term match_strict_source then count
strict_source_route
set firewall family inet filter ip_options_filter term match_strict_source then log
set firewall family inet filter ip_options_filter term match_strict_source then accept
set firewall family inet filter ip_options_filter term match_loose_source from ip-options loose-
source-route
set firewall family inet filter ip_options_filter term match_loose_source then count
loose_source_route
set firewall family inet filter ip_options_filter term match_loose_source then log
set firewall family inet filter ip_options_filter term match_loose_source then accept
set firewall family inet filter ip_options_filter term match_record from ip-options record-route
set firewall family inet filter ip_options_filter term match_record then count record_route
set firewall family inet filter ip_options_filter term match_record then accept
set firewall family inet filter ip_options_filter term match_timestamp from ip-options timestamp
set firewall family inet filter ip_options_filter term match_timestamp then count timestamp
set firewall family inet filter ip_options_filter term match_timestamp then accept
set firewall family inet filter ip_options_filter term match_router_alert from ip-options router-
alert
set firewall family inet filter ip_options_filter term match_router_alert then count router_alert
set firewall family inet filter ip_options_filter term match_router_alert then accept
set firewall family inet filter ip_options_filter term match_all then accept
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
set interfaces ge-0/0/1 unit 0 family inet filter input ip_options_filter
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter ip_option_filter:
1164
1. Create the stateless rewall lter ip_option_filter.
[edit]
user@host# edit firewall family inet filter ip_options_filter
2. Congure the rst term to count, log, and accept packets with the strict_source_route IP oponal
header eld.
[edit firewall family inet filter ip_option_filter]
user@host# set term match_strict_source from ip-options strict_source_route
user@host# set term match_strict_source then count strict_source_route
user@host# set term match_strict_source then log
user@host# set term match_strict_source then accept
3. Congure the next term to count, log, and accept packets with the loose-source-route IP oponal
header eld.
[edit firewall family inet filter ip_option_filter]
user@host# set term match_loose_source from ip-options loose-source-route
user@host# set term match_loose_source then count loose_source_route
user@host# set term match_loose_source then log
user@host# set term match_loose_source then accept
4. Congure the next term to count and accept packets with the record-route IP oponal header eld.
[edit firewall family inet filter ip_option_filter]
user@host# set term match_record from ip-options record-route
user@host# set term match_record then count record_route
user@host# set term match_record then accept
5.
Congure the next term to count and accept packets with the timestamp IP oponal header eld.
[edit firewall family inet filter ip_option_filter]
user@host# set term match_timestamp from ip-options timestamp
user@host# set term match_timestamp then count timestamp
user@host# set term match_timestamp then accept
1165
6. Congure the next term to count and accept packets with the router-alert IP oponal header eld.
[edit firewall family inet filter ip_option_filter]
user@host# set term match_router_alert from ip-options router-alert
user@host# set term match_router_alert then count router_alert
user@host# set term match_router_alert then accept
7. Create the last term to accept any packet without incremenng any counters.
[edit firewall family inet filter ip_option_filter]
user@host# set term match_all then accept
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the stateless rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input ip_options_filter
1166
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter ip_options_filter {
term match_strict_source {
from {
ip-options strict-source-route;
}
then {
count strict_source_route;
log;
accept;
}
}
term match_loose_source {
from {
ip-options loose-source-route;
}
then {
count loose_source_route;
log;
accept;
}
}
term match_record {
from {
ip-options record-route;
}
then {
count record_route;
accept;
}
1167
}
term match_timestamp {
from {
ip-options timestamp;
}
then {
count timestamp;
accept;
}
}
term match_router_alert {
from {
ip-options router-alert;
}
then {
count router_alert;
accept;
}
}
term match_all {
then accept;
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
filter {
input ip_option_filter;
}
address 10.1.2.3/30;
}
}
}
1168
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter ip_option_filter
operaonal mode command. You can also display the log and individual counters separately by using the
following forms of the command:
• show firewall counter strict_source_route
• show firewall counter loose_source_route
• show firewall counter record_route
• show firewall counter timestamp
• show firewall counter router_alert
• show firewall log
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Filter to Count Accepted and Rejected Packets | 1153
Example: Conguring a Filter to Count and Discard IP Opons Packets | 1158
Example: Conguring a Filter to Count and Sample Accepted Packets
IN THIS SECTION
Requirements | 1170
Overview | 1170
Conguraon | 1171
Vericaon | 1174
1169
This example shows how to congure a standard stateless rewall lter to count and sample accepted
packets.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Before you begin, congure trac sampling by including the sampling statement at the [edit forwarding-
options] hierarchy level.
Overview
In this example, you use a standard stateless rewall lter to count and sample all packets received on a
logical interface.
NOTE: When you enable reverse path forwarding (RPF) on an interface with an input lter for
rewall log and count, the input rewall lter does not log the packets rejected by RPF, although
the rejected packets are counted. To log the rejected packets, use an RPF check fail lter.
WARNING: On MX Series routers with MPC3 or MPC4, if rewall lters are congured
to count Two-Way Acve Measurement Protocol (TWAMP) packets then the count is
doubled for all TWAMP packets. There may also be a small increase in round trip me
(RTT) when the TWAMP server is hosted on MPC3 or MPC4. This warning does not
apply for routers with MPC1 or MPC2 cards.
NOTE: On QFX5130 and QFX5700 when a packet hits mulple rewall lters which has counter
acon, only the highest priority group counter will increment. For example, assume the packet
has hit a IPACL (Port ACL) lter and a IRACL (Routed ACL) lter, both having counter acon.
According to priority, IRACL has high priority over IPACL. Hence only IRACL counter will
increment. If there is no hit in IRACL, then IPACL counter will increment.
Below is the order of priority of user congured ACLs (from highest to lowest),
• Loopback
• IRACL
• IPACL
• IVACL
1170
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1171
Congure the Stateless Firewall Filter | 1171
Apply the Stateless Firewall Filter to a Logical Interface | 1172
Conrm and Commit Your Candidate Conguraon | 1173
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter sam term all then count count_sam
set firewall family inet filter sam term all then sample
set interfaces at-2/0/0 unit 301 family inet address 10.1.2.3/30
set interfaces at-2/0/0 unit 301 family inet filter input sam
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter sam:
1.
Create the stateless rewall lter sam.
[edit]
user@host# edit firewall family inet filter sam
1171
2. Congure the term to count and sample all packets.
[edit firewall family inet filter sam]
user@host# set term all then count count_sam
user@host# set term all then sample
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the stateless rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input sam
NOTE: The Junos OS does not sample packets originang from the router or switch. If you
congure a lter and apply it to the output side of an interface, then only the transit packets
going through that interface are sampled. Packets that are sent from the Roung Engine to
the Packet Forwarding Engine are not sampled.
1172
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter sam {
term all {
then {
count count_sam;
sample; # default action is accept
}
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
interfaces {
at-2/0/0 {
unit 301 {
family inet {
filter {
input sam;
}
address 10.1.2.3/30;
}
}
}
}
1173
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
IN THIS SECTION
Displaying the Packet Counter | 1174
Displaying the Firewall Filter Log Output | 1174
Displaying the Sampling Output | 1176
Conrm that the conguraon is working properly.
Displaying the Packet Counter
Purpose
Verify that the rewall lter is evaluang packets.
Acon
user@host> show firewall filter sam
Filter:
Counters:
Name Bytes Packets
sam
sam-1 98 8028
Displaying the Firewall Filter Log Output
Purpose
Display the packet header informaon for all packets evaluated by the rewall lter.
1174
Acon
user@host> show firewall log
Time Filter A Interface Pro Source address Destination address
23:09:09 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:80
23:09:07 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:56
23:09:07 - A at-2/0/0.301 ICM 10.2.0.25 10.211.211.1:49552
23:02:27 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:56
23:02:25 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:80
23:01:22 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:23251
23:01:21 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:16557
23:01:20 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:29471
23:01:19 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:26873
Meaning
This output le contains the following elds:
• Time—Time at which the packet was received (not shown in the default).
• Filter—Name of a lter that has been congured with the filter statement at the [edit firewall]
hierarchy level. A hyphen (-) or the abbreviaon pfe indicates that the packet was handled by the
Packet Forwarding Engine. A space (no hyphen) indicates that the packet was handled by the Roung
Engine.
• A—Filter acon:
• A—Accept (or next term)
• D—Discard
• R—Reject
• Interface—Interface on which the lter is congured.
NOTE: We strongly recommend that you always explicitly congure an acon in the then
statement.
• Pro—Packet’s protocol name or number.
•
Source address—Source IP address in the packet.
• Destination address—Desnaon IP address in the packet.
1175
Displaying the Sampling Output
Purpose
Verify that the sampling output contains appropriate data.
Acon
wtmp.0.gz Size: 15017, Last changed: Dec 19 13:15:54 wtmp.1.gz Size:
493, Last changed: Nov 19 13:47:29
wtmp.2.gz Size: 57, Last changed: Oct 20 15:24:34
| Pipe through a command
user@host> show log /var/tmp/sam
# Apr 7 15:48:50
Time Dest Src Dest Src Proto TOS Pkt Intf IP TCP
addr addr port port len num frag flags
Apr 7 15:48:54 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0
Apr 7 15:48:55 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0
Apr 7 15:48:56 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Filter to Set the DSCP Bit to Zero | 1176
Example: Conguring a Filter to Set the DSCP Bit to Zero
IN THIS SECTION
Requirements | 1177
Overview | 1177
Conguraon | 1177
1176
Vericaon | 1180
This example shows how to congure a standard stateless rewall lter based on the Dierenated
Services code point (DSCP).
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you use a stateless rewall lter to match packets on DSCP bit paerns. If the DSCP is
2, the packet is classied to the best-effort forwarding class, and the DSCP is set to 0. If the DSCP is 3, the
packet is classied to the best-effort forwarding class.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1177
Congure the Stateless Firewall Filter | 1178
Apply the Stateless Firewall Filter to a Logical Interface | 1178
Conrm and Commit Your Candidate Conguraon | 1179
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall filter filter1 term 1 from dscp 2
set firewall filter filter1 term 1 then forwarding-class best-effort
1177
set firewall filter filter1 term 1 then dscp 0
set firewall filter filter1 term 2 from dscp 3
set firewall filter filter1 term 2 then forwarding-class best-effort
set interfaces so-0/1/0 unit 0 family inet filter input filter1
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter filter1:
1. Create the stateless rewall lter.
[edit]
user@host# edit firewall filter filter1
2. Congure the rst term to match a packet with a DSCP of 2, change the DSCP to 0, and classify the
packet to the best-effort forwarding class.
[edit firewall filter filter1]
user@host# set term 1 from dscp 2
user@host# set term 1 then forwarding-class best-effort
user@host# set term 1 then dscp 0
3. Congure the other term to match a packet with a DSCP of 3 and classify the packet to the best-effort
forwarding class.
[edit firewall filter filter1]
user@host# set term 2 from dscp 3
user@host# set term 2 then forwarding-class best-effort
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to the logical interface corresponding to the VPN roung and
forwarding (VRF) instance:
1178
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces so-0/1/0 unit 0 family inet
2. Apply the stateless rewall lter to the logical interface.
[ input filter1]
user@host# set filter input filter1
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
filter filter1 {
term term1 {
from {
dscp 2;
}
then {
forwarding-class best-effort;
dscp 0;
}
}
term term2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
1179
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
so-0/1/0 {
unit 0 {
family inet {
filter input filter1;
}
}
}
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the following operaonal mode commands:
• show class-of-service—Displays the enre class-of-service (CoS) conguraon, including system-
chosen defaults.
• show class-of-service classifier type dscp—Displays only the classiers of the DSCP for IPv4 type.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Filter to Count and Sample Accepted Packets | 1169
1180
Example: Conguring a Filter to Set the DSCP Bit to Zero
IN THIS SECTION
Requirements | 1181
Overview | 1181
Conguraon | 1181
Vericaon | 1184
This example shows how to congure a standard stateless rewall lter based on the Dierenated
Services code point (DSCP).
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you use a stateless rewall lter to match packets on DSCP bit paerns. If the DSCP is
2, the packet is classied to the best-eort forwarding class, and the DSCP is set to 0. If the DSCP is 3,
the packet is classied to the best-eort forwarding class.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1182
Congure the Stateless Firewall Filter | 1182
Apply the Stateless Firewall Filter to a Logical Interface | 1183
Conrm and Commit Your Candidate Conguraon | 1183
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
1181
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall filter filter1 term 1 from dscp 2
set firewall filter filter1 term 1 then forwarding-class best-effort
set firewall filter filter1 term 1 then dscp 0
set firewall filter filter1 term 2 from dscp 3
set firewall filter filter1 term 2 then forwarding-class best-effort
set interfaces ge-0/1/0 unit 0 family inet filter input filter1
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter lter1:
1. Create the stateless rewall lter.
[edit]
user@host# edit firewall filter filter1
2. Congure the rst term to match a packet with a DSCP of 2, change the DSCP to 0, and classify the
packet to the best-eort forwarding class.
[edit firewall filter filter1]
user@host# set term 1 from dscp 2
user@host# set term 1 then forwarding-class best-effort
user@host# set term 1 then dscp 0
3. Congure the other term to match a packet with a DSCP of 3 and classify the packet to the best-
eort forwarding class.
[edit firewall filter filter1]
user@host# set term 2 from dscp 3
user@host# set term 2 then forwarding-class best-effort
1182
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to the logical interface corresponding to the VPN roung and
forwarding (VRF) instance:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/1/0 unit 0 family inet
2. Apply the stateless rewall lter to the logical interface.
[ input filter1]
user@host# set filter input filter1
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
filter filter1 {
term term1 {
from {
dscp 2;
}
then {
forwarding-class best-effort;
dscp 0;
}
}
term term2 {
1183
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/1/0 {
unit 0 {
family inet {
filter input filter1;
}
}
}
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the following operaonal mode commands:
• show class-of-service—Displays the enre class-of-service (CoS) conguraon, including system-
chosen defaults.
• show class-of-service classier type dscp—Displays only the classiers of the DSCP for IPv4 type.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
1184
Example: Conguring a Filter to Count and Sample Accepted Packets | 1169
Example: Conguring a Filter to Match on Two Unrelated Criteria
IN THIS SECTION
Requirements | 1185
Overview | 1185
Conguraon | 1185
Vericaon | 1188
This example shows how to congure a standard stateless rewall lter to match on two unrelated
criteria.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you use a standard stateless rewall lter to match IPv4 packets that are either OSPF
packets or packets that come from an address in the prex 10.108/16, and send an administratively-
prohibited ICMP message for all packets that do not match.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1186
Conguring the IPv4 Firewall Filter | 1186
Applying the IPv4 Firewall Filter to a Logical Interface | 1187
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
1185
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter ospf_or_131 term protocol_match from protocol ospf
set firewall family inet filter ospf_or_131 term address-match from source-address 10.108.0.0/16
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
set interfaces ge-0/0/1 unit 0 family inet filter input ospf_or_131
Conguring the IPv4 Firewall Filter
Step-by-Step Procedure
To congure the IPv4 rewall lter:
1. Enable conguraon of the IPv4 rewall lter.
[edit]
user@host# edit firewall family inet filter ospf_or_131
2. Congure the rst term to accept OSPF packets.
[edit firewall family inet filter ospf_or_131]
user@host# set term protocol_match from protocol ospf
Packets that match the condion are accepted by default. Because another term follows this term,
packets that do not match this condion are evaluated by the next term.
3. Congure the second term to accept packets from any IPv4 address in a parcular prex.
[edit firewall family inet filter ospf_or_131]
user@host# set term address_match from source-address 10.108.0.0/16
Packets that match this condion are accepted by default. Because this is the last term in the lter,
packets that do not match this condion are discarded by default.
1186
Results
Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter ospf_or_131 {
term protocol_match {
from {
protocol ospf;
}
}
term address_match {
from {
source-address {
10.108.0.0/16;
}
}
}
}
}
Applying the IPv4 Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to a logical interface:
1. Enable conguraon of a logical interface.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
1187
2. Congure an IP address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the IPv4 rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input ospf_or_131
Results
Conrm the conguraon of the interface by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
filter {
input ospf_or_131;
}
address 10.1.2.3/30;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter ospf_or_131
operaonal mode command.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
1188
Example: Conguring a Filter to Match on IPv6 Flags | 1146
Example: Conguring a Filter to Match on Port and Protocol Fields | 1148
Example: Conguring a Filter to Accept DHCP Packets Based on Address
IN THIS SECTION
Requirements | 1189
Overview | 1189
Conguraon | 1189
Vericaon | 1192
This example shows how to congure a standard stateless rewall lter to accept packets from a trusted
source.
Requirements
This example is supported only on MX Series routers and EX Series switches.
Overview
In this example, you create a lter (rpf_dhcp) that accepts DHCP packets with a source address of 0.0.0.0
and a desnaon address of 255.255.255.255.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1190
Congure the Stateless Firewall Filter | 1190
Apply the Firewall Filter to the Loopback Interface | 1191
Conrm and Commit Your Candidate Conguraon | 1191
1189
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter rpf_dhcp term dhcp_term from source-address 0.0.0.0/32
set firewall family inet filter rpf_dhcp term dhcp_term from destination-address
255.255.255.255/32
set firewall family inet filter rpf_dhcp term dhcp_term then accept
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
set interfaces ge-0/0/1 unit 0 family inet filter input sam
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter:
1. Create the stateless rewall lter rpf_dhcp.
[edit]
user@host# edit firewall family inet filter rpf_dhcp
2. Congure the term to match packets with a source address of 0.0.0.0 and a desnaon address of
255.255.255.255.
[edit firewall family inet filter rpf_dhcp]
user@host# set term dhcp_term from source-address 0.0.0.0/32
user@host# set term dhcp_term from destination-address 255.255.255.255/32
3. Congure the term to accept packets that match the specied condions.
[edit firewall family inet filter rpf_dhcp]
set term dhcp_term then accept
1190
Apply the Firewall Filter to the Loopback Interface
Step-by-Step Procedure
To apply the lter to the input at the loopback interface:
1. Apply the rpf_dhcp lter if packets are not arriving on an expected path.
[edit]
user@host# set interfaces lo0 unit 0 family inet rpf-check fail-filter rpf_dhcp
2. Congure an address for the loopback interface.
[edit]
user@host# set interfaces lo0 unit 0 family inet address 127.0.0.1/32
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter rpf_dhcp {
term dhcp_term {
from {
source-address {
0.0.0.0/32;
}
destination-address {
255.255.255.255/32;
}
}
then accept;
1191
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
lo0 {
unit 0 {
family inet {
filter {
rpf-check {
fail-filter rpf_dhcp;
mode loose;
}
}
address 127.0.0.1/32;
}
}
}
3. When you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show firewall operaonal mode
command.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Stateless Firewall Filter to Accept Trac from Trusted Sources | 1069
Example: Congure a Filter to Block Telnet and SSH Access | 1077
1192
Example: Conguring a Filter to Block TFTP Access | 1090
Example: Conguring a Filter to Accept OSPF Packets from a Prex | 1193
Example: Conguring a Filter to Accept OSPF Packets from a Prex
IN THIS SECTION
Requirements | 1193
Overview | 1193
Conguraon | 1193
Vericaon | 1197
This example shows how to congure a standard stateless rewall lter to accept packets from a trusted
source.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you create a lter that accepts only OSPF packets from an address in the prex
10.108.0.0/16, discarding all other packets with an administravely-prohibited ICMP message
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1194
Congure the Stateless Firewall Filter | 1194
Apply the Firewall Filter to the Loopback Interface | 1195
Conrm and Commit Your Candidate Conguraon | 1195
1193
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter ospf_filter term term1 from source-address 10.108.0.0/16
set firewall family inet filter ospf_filter term term1 from protocol ospf
set firewall family inet filter ospf_filter term term1 then accept
set firewall family inet filter ospf_filter term default-term then reject administratively-
prohibited
set interfaces lo0 unit 0 family inet address 10.1.2.3/30
set interfaces lo0 unit 0 family inet filter input ospf_filter
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter ospf_filter:
1. Create the lter.
[edit]
user@host# edit firewall family inet filter ospf_filter
2. Congure the term that accepts packets.
[edit firewall family inet filter ospf_filter]
user@host# set term term1 from source-address 10.108.0.0/16
user@host# set term term1 from protocol ospf
user@host# set term term1 then accept
1194
3. Congure the term that rejects all other packets.
[edit firewall family inet filter ospf_filter]
user@host# set term default_term then reject administratively-prohibited
Apply the Firewall Filter to the Loopback Interface
Step-by-Step Procedure
To apply the rewall lter to the loopback interface:
1. Congure the interface.
[edit]
user@host# edit interfaces lo0 unit 0 family inet
2. Congure the logical interface IP address.
[edit interfaces lo0 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the lter to the input.
[edit interfaces lo0 unit 0 family inet]
user@host# set filter input ospf_filter
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
1195
family inet {
filter ospf_filter {
term term1 {
from {
source-address {
10.108.0.0/16;
}
protocol ospf;
}
then {
accept;
}
}
term default_term {
then {
reject administratively-prohibited; # default reject action
}
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
lo0 {
unit 0 {
family inet {
filter {
input ospf_filter;
}
address 10.1.2.3/30;
}
}
}
1196
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter ospf_filter
operaonal mode command.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Stateless Firewall Filter to Accept Trac from Trusted Sources | 1069
Example: Congure a Filter to Block Telnet and SSH Access | 1077
Example: Conguring a Filter to Block TFTP Access | 1090
Example: Conguring a Filter to Accept DHCP Packets Based on Address | 1189
Example: Conguring a Stateless Firewall Filter to Handle Fragments
IN THIS SECTION
Requirements | 1197
Overview | 1198
Conguraon | 1199
Vericaon | 1203
This example shows how to create a stateless rewall lter that handles packet fragments.
Requirements
No special conguraon beyond device inializaon is required before conguring stateless rewall
lters.
1197
Overview
IN THIS SECTION
Topology | 1198
In this example, you create a stateless rewall lter called fragment-RE that accepts fragmented packets
originang from 10.2.1.0/24 and desned for the BGP port. This example includes the following rewall
lter terms:
• not-from-prefix-term-–Discards packets that are not from 10.2.1.0/24 to ensure that subsequent terms
in the rewall lter are matched against packets from 10.2.1.0/24 only.
• small-offset-term—Discards small (1–5) oset packets to ensure that subsequent terms in the rewall
lter can be matched against all the headers in the packet. In addion, the term adds a record to the
system logging desnaons for the rewall facility.
• not-fragmented-term—Accepts unfragmented TCP packets with a desnaon port that species the BGP
protocol. A packet is considered unfragmented if the MF ag is not set and the fragment oset
equals 0.
• first-fragment-term—Accepts the rst fragment of a fragmented TCP packet with a desnaon port
that species the BGP protocol.
• fragment-term—Accepts all fragments that were not discarded by small-offset-term. (packet fragments 6–
8191). However, only those fragments that are part of a packet containing a rst fragment accepted
by first-fragment-term are reassembled by the desnaon device.
Packet fragments oset can be from 1 through 8191.
NOTE: You can move terms within the rewall lter by using the insert command. For more
informaon, see “
insert
” in the Junos OS CLI User Guide.
Topology
1198
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1199
Procedure | 1200
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter fragment-RE term not-from-prefix-term from source-address
0.0.0.0/0
set firewall family inet filter fragment-RE term not-from-prefix-term from source-address
10.2.1.0/24 except
set firewall family inet filter fragment-RE term not-from-prefix-term then discard
set firewall family inet filter fragment-RE term small-offset-term from fragment-offset 1-5
set firewall family inet filter fragment-RE term small-offset-term then syslog
set firewall family inet filter fragment-RE term small-offset-term then discard
set firewall family inet filter fragment-RE term not-fragmented-term from fragment-offset 0
set firewall family inet filter fragment-RE term not-fragmented-term from fragment-flags "!more-
fragments"
set firewall family inet filter fragment-RE term not-fragmented-term from protocol tcp
set firewall family inet filter fragment-RE term not-fragmented-term from destination-port bgp
set firewall family inet filter fragment-RE term not-fragmented-term then accept
set firewall family inet filter fragment-RE term first-fragment-term from first-fragment
set firewall family inet filter fragment-RE term first-fragment-term from protocol tcp
set firewall family inet filter fragment-RE term first-fragment-term from destination-port bgp
set firewall family inet filter fragment-RE term first-fragment-term then accept
set firewall family inet filter fragment-RE term fragment-term from fragment-offset 6-8191
set firewall family inet filter fragment-RE term fragment-term then accept
1199
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the
Junos OS CLI User Guide.
To congure the stateless rewall lter:
1. Dene the stateless rewall lter.
[edit]
user@host# edit firewall family inet filter fragment-RE
2. Congure the rst term for the lter.
[edit firewall family inet filter fragment-RE ]
user@host# set term not-from-prefix-term from source-address 0.0.0.0/0
user@host# set term not-from-prefix-term from source-address 10.2.1.0/24 except
user@host# set term not-from-prefix-term then discard
3. Dene the second term for the lter.
[edit firewall family inet filter fragment-RE]
user@host# edit term small-offset-term
4. Dene the match condions for the term.
[edit firewall family inet filter fragment-RE term small-offset-term]
user@host# set from fragment-offset 1-5
5. Dene the acon for the term.
[edit firewall family inet filter fragment-RE term small-offset-term]
user@host# set then syslog discard
1200
6. Dene the third term for the lter.
[edit]
user@host# edit firewall family inet filter fragment-RE term not-fragmented-term
7. Dene the match condions for the term.
[edit firewall family inet filter fragment-RE term not-fragmented-term]
user@host# set from fragment-flags "!more-fragments" fragment-offset 0 protocol tcp
destination-port bgp
8. Dene the acon for the term.
[edit firewall family inet filter fragment-RE term not-fragmented-term]
user@host# set then accept
9. Dene the fourth term for the lter.
[edit]
user@host# edit firewall family inet filter fragment-RE term first-fragment-term
10. Dene the match condions for the term.
[edit firewall family inet filter fragment-RE term first-fragment-term]
user@host# set from first-fragment protocol tcp destination-port bgp
11. Dene the acon for the term.
[edit firewall family inet filter fragment-RE term first-fragment-term]
user@host# set then accept
12. Dene the last term for the lter.
[edit]
user@host# edit firewall family inet filter fragment-RE term fragment-term
1201
13. Dene the match condions for the term.
[edit firewall family inet filter fragment-RE term fragment-term]
user@host# set from fragment-offset 6–8191
14. Dene the acon for the term.
[edit firewall family inet filter fragment-RE term fragment-term]
user@host# set then accept
Results
Conrm your conguraon by entering the show firewall command from conguraon mode. If the
output does not display the intended conguraon, repeat the instrucons in this example to correct
the conguraon.
user@host# show firewall
family inet {
filter fragment-RE {
term not-from-prefix-term {
from {
source-address {
0.0.0.0/0;
10.2.1.0/24 except;
}
}
then discard;
}
term small-offset-term {
from {
fragment-offset 1-5;
}
then {
syslog;
discard;
}
}
term not-fragmented-term {
from {
fragment-offset 0;
1202
fragment-flags "!more-fragments";
protocol tcp;
destination-port bgp;
}
then accept;
}
term first-fragment-term {
from {
first-fragment;
protocol tcp;
destination-port bgp;
}
then accept;
}
term fragment-term {
from {
fragment-offset 6-8191;
}
then accept;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying Stateless Firewall Filter Conguraons | 1204
Verifying a Firewall Filter that Handles Fragments | 1204
To conrm that the conguraon is working properly, perform these tasks:
1203
Displaying Stateless Firewall Filter Conguraons
Purpose
Verify the conguraon of the rewall lter. You can analyze the ow of the lter terms by displaying
the enre conguraon.
Acon
From conguraon mode, enter the show firewall command.
Meaning
Verify that the output shows the intended conguraon of the rewall lter. In addion, verify that the
terms are listed in the order in which you want the packets to be tested. You can move terms within a
rewall lter by using the insert CLI command.
Verifying a Firewall Filter that Handles Fragments
Purpose
Verify that the acons of the rewall lter terms are taken.
Acon
Send packets to the device that match the terms.
Meaning
Verify that packets from 10.2.1.0/24 with small fragment osets are recorded in the device’s system
logging desnaons for the rewall facility.
RELATED DOCUMENTATION
show route summary
1204
Conguring a Firewall Filter to Prevent or Allow IPv4 Packet
Fragmentaon
This topic explains how to use the dont-fragment (set | clear) acons in an ingress rewall lter to modify
the Don’t Fragment ag in IPv4 packet headers. These acons are supported only on MPCs in MX Series
routers.
You can use a rewall lter on an ingress interface to match IPv4 packets that have the Don’t Fragment
ag set to one or cleared to zero. Fragmentaon is prevented when this ag is set in the packet header.
Fragmentaon is allowed when the ag is not set.
To prevent an IPv4 packet from being fragmented:
• Congure a lter term that modies the Don’t Fragment ag to one.
[edit firewall family inet filter dfSet]
user@host# set term t1 then dont-fragment set
To allow an IPv4 packet to be fragmented:
• Congure a lter term that modies the Don’t Fragment ag to zero.
[edit firewall family inet filter dfClear]
user@host# set term t1 then dont-fragment clear
In the following example, the dfSet rewall lter matches packets that are fragmented and changes the
Don’t Fragment ag to prevent fragmentaon. The dfClear rewall lter matches packets that are not
fragmented and changes the Don’t Fragment ag to allow fragmentaon.
[edit firewall family inet]
user@host# edit filter dfSet
user@host# set term t1 from fragment-flags is-fragment
user@host# set term t1 then dont-fragment set
user@host# up
user@host# edit filter dfClear
user@host# set term t1 from fragment-flags dont-fragment
user@host# set term t1 then dont-fragment clear
1205
RELATED DOCUMENTATION
Firewall Filter Match Condions for IPv4 Trac | 942
Firewall Filter Nonterminang Acons | 873
Stateless Firewall Filter Components | 783
Stateless Firewall Filter Overview | 778
Conguring a Firewall Filter to Discard Ingress IPv6 Packets with a
Mobility Extension Header
This topic explains how to congure a rewall lter to discard IPv6 packets that contain a mobility
extension header. This feature is supported only on MPCs in MX Series routers.
To congure the stateless rewall lter:
1. Create the stateless rewall lter.
[edit]
user@host# edit firewall family inet6 filter
filter-name
For example:
[edit]
user@host# edit firewall family inet6 filter drop-mobility
2. Congure a term to discard all trac that contains a mobility extension header.
[edit firewall family inet6 filter drop-mobility]
user@host# set term term1 from extension-header mobility
user@host# set term term1 then discard
3. Congure a term to accept all other trac.
[edit firewall family inet6 filter drop-mobility]
user@host# set term term2 then accept
1206
4. Apply the rewall lter to a logical interface.
[edit interfaces ge-1/2/10 unit 0 family inet6]
user@host# set filter input drop-mobility
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Firewall Filter Match Condions for IPv6 Trac | 959
Example: Conguring an Egress Filter Based on IPv6 Source or
Desnaon IP Addresses
IN THIS SECTION
Requirements | 1207
Overview | 1207
Conguraon | 1208
This example shows how to congure a rewall lter to accept IPv6 packets egressing an inet6 interface.
Requirements
This topic describes a feature supported on EX4300 and QFX5100 that was introduced in Junos OS
Release 19.1R1. No special conguraon beyond device inializaon is required before conguring this
example.
Overview
In this example, you create a typical rewall lter to accept IPv6 source and desnaon packets in the
egress direcon of an inet6 interface. To support ltering in the egress direcon, however, you’ll rst
need to set the set system packet-forwarding-options eracl-ip6-match using either the srcip6-and-destip6 or
srcip6-only opon. You'll also need to restart the packet forwarding engine(PFE) aer comming the
conguraon.
1207
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1208
Enable the system for IPv6 address ltering | 1208
Apply the rewall lter to an egress interface | 1210
Conrm and Commit Your Candidate Conguraon | 1210
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set system packet-forwarding-options eracl-ip6-match srcip6-and-destip6
set firewall family inet6 filter ipv6_filter term t1 from source-address 3001::10/64
set firewall family inet6 filter ipv6_filter term t1 from destination-address 2001::10/64
set interfaces ge-0/0/0 unit 0 family inet6 filter output ipv6_filter
Enable the system for IPv6 address ltering
Step-by-Step Procedure
To congure a rewall lter for IPv6 ltering on an inet6 egress interface:
1. Enable packet forwarding opons for matching on either IPv6 source, or IPv6 source and desnaon
IP addresses. In this example, we’ll enable both source and desnaon IP address matching.
[edit]
user@host# set system packet-forwarding-options eracl-ip6-match srcip6-and-destip6
1208
2. Check, and if appropriate, delete any exisng rewall lters that are already bound to the interface
you will use for the IPv6 rewall lter:
[edit]
user@host# delete interfaces ge-0/0/0 unit 0 family inet6 filter output tcp_filter.
3. Commit the changes above, then stop and restart the PFE to accept the packet-forwarding-options and
clear the PFE for the IPv6 lter(s).
• For EX4300, use the following:
user@host# commit
user@host# run request restart pfe-manager
• For EX4300 virtual chassis, use the following:
user@host# commit
user@host# run request system reboot all-members
• For QFX5100, reboot the system:
user@host# commit
user@host# run request system reboot
4. Create a IPv6 rewall lter named tcp_lter.
[edit]
user@host# edit firewall family inet6 filter tcp_filter
1209
5. Congure the required lter acon, here to match packets with an IPv6 source or desnaon address
within the congured range.
[edit firewall family inet6 filter tcp_filter]
user@host# set term t1 from source-address 3001::10/64
user@host# set term t1 from destination-address 2001::10/64
6. Specify that matched packets are counted, logged to the buer on the PFE, and accepted.
[edit firewall family inet6 filter tcp_filter]
user@host# set term t1 then count egress_ipv6-packets
user@host# set term t1 then log
user@host# set term t1 then accept
Apply the rewall lter to an egress interface
Step-by-Step Procedure
To apply the rewall lter to an egress inet6 interface, type the following:
• user@host# set interfaces ge-0/0/0 unit 0 family inet6 lter output tcp_lter
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet6 {
filter tcp_filter {
term t1 {
from {
source-address 3001::10/64;
destination-address 2001::10/64;
1210
}
then {
count egress_ipv6-packets;
log;
accept;
}
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/0 {
unit 0 {
family inet6 {
filter {
output tcp_filter;
}
source-address 3001::10/64;
destination-address 2001::10/64;
}
}
}
3. When you are done conguring the device, commit the candidate conguraon.
[edit]
user@host# commit
RELATED DOCUMENTATION
eracl-ip6-match
Understanding How to Use Standard Firewall Filters | 780
1211
Example: Conguring a Rate-Liming Filter Based on Desnaon Class
IN THIS SECTION
Requirements | 1212
Overview | 1212
Conguraon | 1212
Vericaon | 1216
This example shows how to congure a rate-liming stateless rewall lter.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Before you begin, congure the desnaon class class1.
Overview
In this example, you use a stateless rewall lter to set rate limits based on a desnaon class.
To acvate a policer from within a stateless rewall lter conguraon:
• Create a template for the policer by including the policer
policer-name
statement.
• Reference the policer in a lter term that species the policer in the policer
policer-name
nonterminang acon.
You can also acvate a policer by including the policer (input | output)
policer-template-name
statement at a
logical interface.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1213
Congure the Stateless Firewall Filter | 1213
Apply the Stateless Firewall Filter to a Logical Interface | 1214
1212
Conrm and Commit Your Candidate Conguraon | 1214
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall policer police_class1 if-exceeding bandwidth-limit 25m
set firewall policer police_class1 if-exceeding burst-size-limit 25m
set firewall policer police_class1 then discard
set firewall filter rl_dclass1 term term1 from destination-class class1
set firewall filter rl_dclass1 term term1 then policer police_class1
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.1/30
set interfaces ge-0/0/1 unit 0 family inet filter input rl_dclass1
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter rl_dclass1 with policer police_class1 for desnaon class class1:
1. Create the policer template police_class1.
[edit]
user@host# edit firewall policer police_class1
2. Congure the policer template police_class1.
[edit firewall policer police_class1]
user@host# set if-exceeding bandwidth-limit 25m
user@host# set if-exceeding burst-size-limit 25m
user@host# set then discard
1213
3. Create the stateless rewall lter rl_dclass1.
[edit]
user@host# edit firewall filter rl_dclass1
4. Congure a lter term that uses policer police_class1 to rate-limit trac for desnaon class class1.
[edit firewall filter rl_dclass1]
user@host# set term term1 from destination-class class1
user@host# set term term1 then policer police_class1
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the lter rl_dclass1 to a logical interface:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.1/30
3. Apply the stateless rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input rl_dclass1
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1214
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
policer police_class1 {
if-exceeding {
bandwidth-limit 25m;
burst-size-limit 25m;
}
then discard;
}
filter rl_dclass1 {
term term1 {
from {
destination-class class1;
}
then policer police_class1;
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
filter {
input rl_dclass1;
}
address 10.1.2.1/30;
}
}
}
1215
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show class-of-service ge-0/0/1 operaonal
mode command.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Filtering Packets Received on an Interface Set Overview | 1378
Example: Filtering Packets Received on an Interface Set | 1362
1216
CHAPTER 17
Conguring Firewall Filters in Logical Systems
IN THIS CHAPTER
Firewall Filters in Logical Systems Overview | 1217
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
References from a Firewall Filter in a Logical System to Subordinate Objects | 1222
References from a Firewall Filter in a Logical System to Nonrewall Objects | 1224
References from a Nonrewall Object in a Logical System to a Firewall Filter | 1227
Example: Conguring Filter-Based Forwarding | 1234
Example: Conguring Filter-Based Forwarding on Logical Systems | 1240
Example: Conguring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods | 1254
Example: Conguring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods | 1260
Unsupported Firewall Filter Statements for Logical Systems | 1266
Unsupported Acons for Firewall Filters in Logical Systems | 1269
Filter-Based Forwarding for Roung Instances | 1276
Forwarding Table Filters for Roung Instances on ACX Series Routers | 1277
Conguring Forwarding Table Filters | 1278
Firewall Filters in Logical Systems Overview
IN THIS SECTION
Logical Systems | 1218
Firewall Filters in Logical Systems | 1218
Ideners for Firewall Objects in Logical Systems | 1218
1217
Logical Systems
With the Junos OS, you can paron a single physical router or switch into mulple logical devices that
perform independent roung tasks. Because logical systems perform a subset of the tasks once handled
by the physical router or switch, logical systems oer an eecve way to maximize the use of a single
router or switch.
Firewall Filters in Logical Systems
You can congure a separate set of rewall lters for each logical system on a router or switch. To
congure a lter in a logical system, you must dene the lter in the firewall stanza at the [edit logical-
systems
logical-system-name
] hierarchy level, and you must apply the lter to a
logical interface
that is also
congured at the [edit logical-systems
logical-system-name
] hierarchy level.
Ideners for Firewall Objects in Logical Systems
To idenfy rewall objects congured under logical systems, operaonal show commands and rewall-
related SNMP MIB objects include a __logical-system-name/ prex in the object name. For example, rewall
objects congured under the ls1 logical system include __ls1/ as the prex.
RELATED DOCUMENTATION
Stateless Firewall Filter Types
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
Unsupported Firewall Filter Statements for Logical Systems | 1266
Unsupported Acons for Firewall Filters in Logical Systems | 1269
Example: Conguring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods |
1254
Introducon to Logical Systems
Logical Systems Operaons and Restricons
1218
Guidelines for Conguring and Applying Firewall Filters in Logical
Systems
IN THIS SECTION
Statement Hierarchy for Conguring Firewall Filters in Logical Systems | 1219
Filter Types in Logical Systems | 1220
Firewall Filter Protocol Families in Logical Systems | 1220
Firewall Filter Match Condions in Logical Systems | 1221
Firewall Filter Acons in Logical Systems | 1221
Statement Hierarchy for Applying Firewall Filters in Logical Systems | 1221
Statement Hierarchy for Conguring Firewall Filters in Logical Systems
To congure a
rewall lter
in a logical system, include the filter, service-filter, or simple-filter
statement at the [edit logical-systems
logical-system-name
firewall family
family-name
] hierarchy level.
[edit]
logical systems {
logical-system-name
{
firewall {
family
family-name
{
filter
filter-name
{
interface-specific;
physical-interface-filter;
term
term-name
{
filter
filter-name
;
from {
match-conditions
;
}
then {
actions
;
}
}
}
service-filter
filter-name
{ # For ’family inet’ or ’family inet6’ only.
1219
term
term-name
{
from {
match-conditions
;
}
then {
actions
;
}
}
}
simple-filter
filter-name
{ # For ’family inet’ only.
term
term-name
{
from {
match-conditions
;
}
then {
actions
;
}
}
}
}
}
}
}
Filter Types in Logical Systems
There are no special restricons on the types of stateless rewall lter types that you can congure in
logical systems.
In a logical system, you can use the same types of stateless rewall lters that are available on a physical
router or switch:
• Standard stateless rewall lters
• Service lters
• Simple lters
Firewall Filter Protocol Families in Logical Systems
There are no special restricons on the protocol families supported with stateless rewall lters in
logical systems.
1220
In a logical system, you can lter the same protocol families as you can on a physical router or switch.
• Standard stateless rewall lters—In logical systems, you can lter the following trac types:
protocol-independent, IPv4, IPv6, MPLS, MPLS-tagged IPv4 or IPv6, VPLS, Layer 2 circuit cross-
connecon, and Layer 2 bridging.
• Service lters—In logical systems, you can lter IPv4 and IPv6 trac.
• Simple lters—In logical systems, you can lter IPv4 trac only.
Firewall Filter Match Condions in Logical Systems
There are no special restricons on the match condions supported with stateless rewall lters in
logical systems.
Firewall Filter Acons in Logical Systems
There are no special restricons on the acons supported with stateless rewall lters in logical systems.
Statement Hierarchy for Applying Firewall Filters in Logical Systems
To apply a rewall lter in a logical system, include the filter
filter-name
, service-filter
service-filter-name
,
or simple-filter
simple-filter-name
statement to a
logical interface
in the logical system.
The following conguraon shows the hierarchy levels at which you can apply the statements:
[edit]
logical-systems
logical-system-name
{
interfaces {
interface-name
{
unit
logical-unit-number
{
family
family-name
{
filter {
group
group-name
;
input
filter-name
;
input-list [
filter-names
];
output
filter-name
;
output-list [ filter-names ]
}
rpf-check { # For ’family inet’ or ’family inet6’ only.
fail-filter
filter-name
;
mode loose;
}
1221
service { # For ’family inet’ or ’family inet6’ only.
input {
service-set
service-set-name
<service-filter
service-filter-name
>;
post-service-filter
service-filter-name
;
}
output {
service-set
service-set-name
<service-filter
service-filter-name
>;
}
}
simple-filter { # For ’family inet’ only.
input
simple-filter-name
;
}
}
}
}
}
}
RELATED DOCUMENTATION
Firewall Filters in Logical Systems Overview | 1217
References from a Firewall Filter in a Logical System to Subordinate Objects | 1222
References from a Firewall Filter in a Logical System to Nonrewall Objects | 1224
References from a Nonrewall Object in a Logical System to a Firewall Filter | 1227
Example: Conguring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods |
1254
Unsupported Firewall Filter Statements for Logical Systems | 1266
Unsupported Acons for Firewall Filters in Logical Systems | 1269
References from a Firewall Filter in a Logical System to Subordinate
Objects
IN THIS SECTION
Resoluon of References from a Firewall Filter to Subordinate Objects | 1223
1222
Valid Reference from a Firewall Filter to a Subordinate Object | 1223
Resoluon of References from a Firewall Filter to Subordinate Objects
If a
rewall lter
dened in a logical system references a subordinate object (for example, a policer or
prex list), that subordinate object must be dened within the firewall stanza of the same logical system.
For example, if a rewall lter conguraon references a policer, the rewall lter and the policer must
be congured under the same [edit logical-systems
logical-system-name
firewall] hierarchy level.
This rule applies even if the same policer is congured under the main rewall conguraon or if the
same policer is congured as part of a rewall in another logical system.
Valid Reference from a Firewall Filter to a Subordinate Object
In this example, the rewall lter filter1 references the policer pol1. Both filter1 and pol1 are dened
under the same rewall object. This conguraon is valid. If pol1 had been dened under another rewall
object, the conguraon would not be valid.
[edit]
logical systems {
ls-A {
firewall {
policer pol1 {
if-exceeding {
bandwidth-limit 401k;
burst-size-limit 50k;
}
then discard;
}
filter filter1 {
term one {
from {
source-address 12.1.0.0/16;
}
then {
reject host-unknown;
}
}
term two {
1223
from {
source-address 12.2.0.0/16;
}
then policer pol1;
}
}
}
}
}
RELATED DOCUMENTATION
Firewall Filters in Logical Systems Overview | 1217
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
References from a Firewall Filter in a Logical System to Nonrewall Objects | 1224
References from a Nonrewall Object in a Logical System to a Firewall Filter | 1227
References from a Firewall Filter in a Logical System to Nonrewall
Objects
IN THIS SECTION
Resoluon of References from a Firewall Filter to Nonrewall Objects | 1224
Valid Reference to a Nonrewall Object Outside of the Logical System | 1225
Resoluon of References from a Firewall Filter to Nonrewall Objects
In many cases, a rewall conguraon references objects outside the rewall conguraon. As a general
rule, the referenced object must be dened under the same logical system as the referencing object.
However, there are cases when the conguraon of the referenced object is not supported at the [edit
logical-systems
logical-system-name
] hierarchy level.
1224
Valid Reference to a Nonrewall Object Outside of the Logical System
This example conguraon illustrates an excepon to the general rule that the objects referenced by a
rewall lter
in a logical system must be dened under the same logical system as the referencing
object.
In the following scenario, the service lter inetsf1 is applied to IPv4 trac associated with the service set
fred at the
logical interface
fe-0/3/2.0, which is on an adapve services interface.
• Service lter inetsf1 is dened in ls-B and references prex list prefix1.
• Service set fred is dened at the main services hierarchy level, and the policy framework soware
searches the [edit services] hierarchy for the denion of the fred service set.
Because service rules cannot be congured in logical systems. rewall lter conguraons in the [edit
logical-systems logical-system
logical-system-name
] hierarchy are allowed to reference
service sets
outside
the logical system hierarchy.
[edit]
logical-systems {
ls-B {
interfaces {
fe-0/3/2 {
unit 0 {
family inet {
service {
input {
service-set fred service-filter inetsf1;
}
}
}
}
}
}
policy-options {
prefix-list prefix1 {
1.1.0.0/16;
1.2.0.0/16;
1.3.0.0/16;
}
}
firewall { # Under logical-system ’ls-B’.
family inet {
1225
filter filter1 {
term one {
from {
source-address {
12.1.0.0/16;
}
}
then {
reject host-unknown;
}
}
term two {
from {
source-address {
12.2.0.0/16;
}
}
then policer pol1;
}
}
service-filter inetsf1 {
term term1 {
from {
source-prefix-list {
prefix1;
}
}
then count prefix1;
}
}
}
policer pol1 {
if-exceeding {
bandwidth-limit 401k;
burst-size-limit 50k;
}
then discard;
}
}
}
} # End of logical systems configuration.
services { # Main services hierarchy level.
service-set fred {
1226
max-flows 100;
interface-service {
service-interface sp-1/2/0.0;
}
}
}
RELATED DOCUMENTATION
Firewall Filters in Logical Systems Overview | 1217
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
References from a Firewall Filter in a Logical System to Subordinate Objects | 1222
References from a Nonrewall Object in a Logical System to a Firewall Filter | 1227
References from a Nonrewall Object in a Logical System to a Firewall
Filter
IN THIS SECTION
Resoluon of References from a Nonrewall Object to a Firewall Filter | 1227
Invalid Reference to a Firewall Filter Outside of the Logical System | 1228
Valid Reference to a Firewall Filter Within the Logical System | 1229
Valid Reference to a Firewall Filter Outside of the Logical System | 1232
Resoluon of References from a Nonrewall Object to a Firewall Filter
If a nonrewall lter object in a logical system references an object in a
rewall lter
congured in a
logical system, the reference is resolved using the following logic:
• If the nonrewall lter object is congured in a logical system that includes rewall lter
conguraon statements, the policy framework soware searches the [edit logical-systems
logical-
system-name
firewall] hierarchy level. Firewall lter conguraons that belong to
other
logical systems
or to the main [edit firewall] hierarchy level are not searched.
1227
• If the nonrewall lter object is congured in a logical system that does not include any rewall lter
conguraon statements, the policy framework soware searches the rewall conguraons dened
at the [edit firewall] hierarchy level.
Invalid Reference to a Firewall Filter Outside of the Logical System
This example conguraon illustrates an unresolvable reference from a nonrewall object in a logical
system to a rewall lter.
In the following scenario, the stateless rewall lters filter1 and fred are applied to the
logical interface
fe-0/3/2.0 in the logical system ls-C.
• Filter filter1 is dened in ls-C.
• Filter fred is dened in the main rewall conguraon.
Because ls-C contains rewall lter statements (for filter1), the policy framework soware resolves
references to and from rewall lters by searching the [edit logical systems ls-C firewall] hierarchy level.
Consequently, the reference from fe-0/3/2.0 in the logical system to fred in the main rewall
conguraon cannot be resolved.
[edit]
logical-systems {
ls-C {
interfaces {
fe-0/3/2 {
unit 0 {
family inet {
filter {
input-list [ filter1 fred ];
}
}
}
}
}
firewall { # Under logical system ’ls-C’.
family inet {
filter filter1 {
term one {
from {
source-address 12.1.0.0/16;
}
then {
1228
reject host-unknown;
}
}
term two {
from {
source-address 12.2.0.0/16;
}
then policer pol1;
}
}
}
policer pol1 {
if-exceeding {
bandwidth-limit 401k;
burst-size-limit 50k;
}
then discard;
}
}
}
} # End of logical systems
firewall { # Under the main firewall hierarchy level
family inet {
filter fred {
term one {
from {
source-address 11.1.0.0/16;
}
then {
log;
reject host-unknown;
}
}
}
}
} # End of main firewall configurations.
Valid Reference to a Firewall Filter Within the Logical System
This example conguraon illustrates resolvable references from a nonrewall object in a logical system
to two rewall lter.
1229
In the following scenario, the stateless rewall lters filter1 and fred are applied to the logical interface
fe-0/3/2.0 in the logical system ls-C.
• Filter filter1 is dened in ls-C.
• Filter fred is dened in ls-C and also in the main rewall conguraon.
Because ls-C contains rewall lter statements, the policy framework soware resolves references to
and from rewall lters by searching the [edit logical systems ls-C firewall] hierarchy level. Consequently,
the references from fe-0/3/2.0 in the logical system to filter1 and fred use the stateless rewall lters
congured in ls-C.
[edit]
logical-systems {
ls-C {
interfaces {
fe-0/3/2 {
unit 0 {
family inet {
filter {
input-list [ filter1 fred ];
}
}
}
}
}
firewall { # Under logical system ’ls-C’.
family inet {
filter filter1 {
term one {
from {
source-address 12.1.0.0/16;
}
then {
reject host-unknown;
}
}
term two {
from {
source-address 12.2.0.0/16;
}
then policer pol1;
}
1230
}
filter fred { # This ’fred’ is in ’ls-C’.
term one {
from {
source-address 10.1.0.0/16;
}
then {
log;
reject host-unknown;
}
}
}
}
policer pol1 {
if-exceeding {
bandwidth-limit 401k;
burst-size-limit 50k;
}
then discard;
}
}
}
} # End of logical systems configurations.
firewall { # Main firewall filter hierarchy level
family inet {
filter fred {
term one {
from {
source-address 11.1.0.0/16;
}
then {
log;
reject host-unknown;
}
}
}
}
} # End of main firewall configurations.
1231
Valid Reference to a Firewall Filter Outside of the Logical System
This example conguraon illustrates resolvable references from a nonrewall object in a logical system
to two rewall lter.
In the following scenario, the stateless rewall lters filter1 and fred are applied to the logical interface
fe-0/3/2.0 in the logical system ls-C.
• Filter filter1 is dened in the main rewall conguraon.
• Filter fred is dened in the main rewall conguraon.
Because ls-C does not contain any rewall lter statements, the policy framework soware resolves
references to and from rewall lters by searching the [edit firewall] hierarchy level. Consequently, the
references from fe-0/3/2.0 in the logical system to filter1 and fred use the stateless rewall lters
congured in the main rewall conguraon.
[edit]
logical-systems {
ls-C {
interfaces {
fe-0/3/2 {
unit 0 {
family inet {
filter {
input-list [ filter1 fred ];
}
}
}
}
}
}
} # End of logical systems configurations.
firewall { # Main firewall hierarchy level.
family inet {
filter filter1 {
term one {
from {
source-address 12.1.0.0/16;
}
then {
reject host-unknown;
}
1232
}
term two {
from {
source-address 12.2.0.0/16;
}
then policer pol1;
}
}
filter fred {
term one {
from {
source-address 11.1.0.0/16;
}
then {
log;
reject host-unknown;
}
}
}
}
policer pol1 {
if-exceeding {
bandwidth-limit 701k;
burst-size-limit 70k;
}
then discard;
}
} # End of main firewall configurations.
RELATED DOCUMENTATION
Firewall Filters in Logical Systems Overview | 1217
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
References from a Firewall Filter in a Logical System to Subordinate Objects | 1222
References from a Firewall Filter in a Logical System to Nonrewall Objects | 1224
1233
Example: Conguring Filter-Based Forwarding
IN THIS SECTION
Requirements | 1234
Overview | 1234
Conguraon | 1235
Filter-based forwarding (FBF), which is also called Policy Based Roung (PBR), provides a a simple but
powerful way to route IP trac to dierent interfaces on the basis of Layer-3 or Layer-4 parameters.
FBF works by using match condions in a rewall lter to select certain trac and then direct it to a
given roung instance that points to the desired next hop. To ensure the next hop is resolvable, interface
routes from the main roung table are shared via RIB group with the roung table(s) specied in the
roung instance(s).
Match condions can include the source or desnaon IP address, source or desnaon port, IP
protocol, DSCP value, TCP ag, ICMP type, and packet length.
Requirements
This example has the following hardware and soware requirements:
• MX Series 5G Universal Roung Plaorm as the roung device with the rewall lter congured.
• Junos OS Release 13.3 or later running on the roung device with the rewall lter congured.
Overview
This example shows the conguraon sengs you need to set up lter-based forwarding on a single
device. Figure 54 on page 1235 shows the ingress and egress interfaces on an MX Series router and
illustrates the logical ow of events as packets traverse the device.
1234
Figure 54: Filter-Based Forwarding to Specied Interfaces
A rewall lter called webFilter is aached to the ingress interface, fe-0/0/0. Packets arriving over the
interface are evaluated against the match condions specied in the lter, the logic of which directs
HTTP and HTTPS trac to a roung instance called webtrac. This roung instance accomplishes three
things: rst, it establishes a roung table called webtrac.inet.0; second, it lets you dene a stac route
and next hop; and third, lets you congure the instance for forwarding trac to the next hop (here,
192.0.2.2 on interface fe-0/0/1).
Term 2 in the rewall lter, then accept, species that all non-matching trac take a dierent path. We
dene a stac route with next hop of 203.0.113.2 to have this trac egress the device via fe-0/0/2. The
route is automacally installed in the master roung table, inet.0.
The last (logical) step in seng up FBF is to ensure that both routes are resolvable. The RIB group (FBF-
rib in this example) makes it so interface-routes from inet.0 can be shared with webtrac.inet.0.
For examples that focus on a specic use case or mul-device topologies, see the Related Topics.
Conguraon
IN THIS SECTION
Procedure | 1236
1235
Procedure
CLI Quick Conguraon
Both copy-paste and step-by-step instrucons for creang lter-based forwarding on a single device are
provided.
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Congure a device for lter-based forwarding
set interfaces fe-0/0/0 unit 0 family inet address 198.51.100.1/24
set interfaces fe-0/0/0 unit 0 family inet filter input webFilter
set interfaces fe-0/0/1 unit 0 family inet address 192.0.2.1/24
set interfaces fe-0/0/2 unit 0 family inet address 203.0.113.1/24
set firewall family inet filter webFilter term 1 from destination-port http
set firewall family inet filter webFilter term 1 from destination-port https
set firewall family inet filter webFilter term 1 then routing-instance webtraffic
set firewall family inet filter webFilter term 2 then accept
set routing-instances webtraffic routing-options static route 0.0.0.0/0 next-hop 192.0.2.2
set routing-instances webtraffic instance-type forwarding
set routing-options static route 0.0.0.0/0 next-hop 203.0.113.2
set routing-options rib-groups FBF-rib import-rib inet.0
set routing-options rib-groups FBF-rib import-rib webtraffic.inet.0
set routing-options interface-routes rib-group inet FBF-rib
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure the device:
1. Congure the inbound interface and aach the webFilter rewall lter to it.
[edit interfaces fe-0/0/0 unit 0 family inet]
user@device# set filter input webFilter
user@device# set address 198.51.100.1/24
1236
2. Congure the outbound interfaces, one for Web trac and the other for all other trac.
[edit interfaces]
user@device# set fe-0/0/1 unit 0 family inet address 192.0.2.1/24
user@device# set fe-0/0/2 unit 0 family inet address 203.0.113.1/24
3. Congure the rewall lter to pass Web trac to the webtrac roung instance and all other trac
to 203.0.113.1.
[edit firewall family inet filter webFilter]
user@device# set term 1 from destination-port http
user@device# set term 1 from destination-port https
user@device# set term 1 then routing-instance webtraffic
user@device# set term 2 then accept
4. Oponal: Monitor trac handling of the rewall lter by adding a counter>
[edit interfaces fe-0/0/0 unit 0 family inet]
user@device# set firewall family inet filter webFilter term 1 then count webtraffic-count
5. Create the webtrac roung instance and congure it to forward Web trac to fe-0/0/1.
[edit routing-instances webtraffic]
user@device# set routing-options static route 0.0.0.0/0 next-hop 192.0.2.2
user@device# set instance-type forwarding
6. Create a route for non-Web trac (the route is automacally installed in the inet.0 roung table).
[edit routing-options]
user@device# set static route 0.0.0.0/0 next-hop 203.0.113.2
1237
7. Create a RIB group called FBF-rib, and congure it so inet.0 shares interface routes with
webtrac.inet.0, and then associate a roung table group with the roung device’s interfaces, and
specify roung table groups into which interface routes are imported..
[edit routing-options]
user@device# set rib-groups FBF-rib import-rib inet.0
user@device# set rib-groups FBF-rib import-rib webtraffic.inet.0
8. Associate a roung table group with the roung device’s interfaces, and specify roung table groups
into which interface routes are imported.
[edit routing-options]
user@device# set interface-routes rib-group inet FBF-rib
Results
From conguraon mode, conrm your conguraon by entering the show firewall, show routing-instances,
show routing-options, and show interfaces, commands. If the output does not display the intended
conguraon, repeat the conguraon instrucons in this example to correct it.
If you are done conguring the device, enter commit from conguraon mode.
user@device# show interfaces fe-0/0/0
unit 0 {
family inet {
filter {
input webFilter;
}
address 198.51.100.1/24;
}
}
user@device# show interfaces fe-0/0/1
unit 0 {
family inet {
address 192.0.2.1/24;
}
}
user@device# show interfaces fe-0/0/2
unit 0 {
family inet {
1238
address 203.0.113.1/24;
}
}
user@device# show firewall
family inet {
filter webFilter {
term 1 {
from {
destination-port [ http https ];
}
then {
routing-instance webtraffic;
}
}
term 2 {
then accept;
}
}
}
user@device# show routing-options
interface-routes {
rib-group inet FBF-rib;
}
static {
route 0.0.0.0/0 next-hop 203.0.113.2;
}
rib-groups {
FBF-rib {
import-rib [ inet.0 webtraffic.inet.0 ];
}
}
user@device# show routing-instances
webtraffic {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.0.2.2;
}
1239
}
}
RELATED DOCUMENTATION
Understanding Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP Address |
1515
Conguring Filter-Based Forwarding
Understanding Filter-Based Forwarding | 1857
Using Filter-Based Forwarding to Select Trac to Be Secured
Example: Conguring Filter-Based Forwarding on the Source Address | 1501
Understanding RIB Groups
Example: Conguring Filter-Based Forwarding on Logical Systems
IN THIS SECTION
Requirements | 1240
Overview | 1241
Conguraon | 1244
Vericaon | 1251
This example shows how to congure lter-based forwarding within a logical system. The lter classies
packets to determine their forwarding path within the ingress roung device.
Requirements
In this example, no special conguraon beyond device inializaon is required.
1240
Overview
IN THIS SECTION
Topology | 1243
Filter-based forwarding is supported for IP version 4 (IPv4) and IP version 6 (IPv6).
Use lter-based forwarding for service provider selecon when customers have Internet connecvity
provided by dierent ISPs yet share a common access layer. When a shared media (such as a cable
modem) is used, a mechanism on the common access layer looks at Layer 2 or Layer 3 addresses and
disnguishes between customers. You can use lter-based forwarding when the common access layer is
implemented using a combinaon of Layer 2 switches and a single router.
With lter-based forwarding, all packets received on an interface are considered. Each packet passes
through a lter that has match condions. If the match condions are met for a lter and you have
created a roung instance, lter-based forwarding is applied to a packet. The packet is forwarded based
on the next hop specied in the roung instance. For stac routes, the next hop can be a specic LSP.
NOTE: Source-class usage lter matching and unicast reverse-path forwarding checks are not
supported on an interface congured with lter-based forwarding (FBF).
To congure lter-based forwarding, perform the following tasks:
• Create a match lter on an ingress router or switch. To specify a match lter, include the filter
filter-name
statement at the [edit firewall] hierarchy level. A packet that passes through the lter is
compared against a set of rules to classify it and to determine its membership in a set. Once
classied, the packet is forwarded to a roung table specied in the accept acon in the lter
descripon language. The roung table then forwards the packet to the next hop that corresponds to
the desnaon address entry in the table.
• Create roung instances that specify the roung table(s) to which a packet is forwarded, and the
desnaon to which the packet is forwarded at the [edit routing-instances] or [edit logical-systems
logical-system-name
routing-instances] hierarchy level. For example:
[edit]
routing-instances {
routing-table-name1
{
instance-type forwarding;
1241
routing-options {
static {
route 0.0.0.0/0 nexthop 10.0.0.1;
}
}
}
routing-table-name2
{
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 nexthop 10.0.0.2;
}
}
}
}
• Create a roung table group that adds interface routes to the forwarding roung instances used in
lter-based forwarding (FBF), as well as to the default roung instance inet.0. This part of the
conguraon resolves the routes installed in the roung instances to directly connected next hops
on that interface. Create the roung table group at the [edit routing-options] or [edit logical-systems
logical-system-name
routing-options] hierarchy level.
NOTE: Specify inet.0 as one of the roung instances that the interface routes are imported into.
If the default instance inet.0 is not specied, interface routes are not imported into the default
roung instance.
This example shows a packet lter that directs customer trac to a next-hop router in the domains, SP 1
or SP 2, based on the packet’s source address.
If the packet has a source address assigned to an SP 1 customer, desnaon-based forwarding occurs
using the sp1-route-table.inet.0 roung table. If the packet has a source address assigned to an SP 2
customer, desnaon-based forwarding occurs using the sp2-route-table.inet.0 roung table. If a packet
does not match either of these condions, the lter accepts the packet, and desnaon-based
forwarding occurs using the standard inet.0 roung table.
One way to make lter-based forwarding work within a logical system is to congure the rewall lter
on the logical system that receives the packets. Another way is to congure the rewall lter on the
main router and then reference the logical system in the rewall lter. This example uses the second
approach. The specic roung instances are congured within the logical system. Because each roung
1242
instance has its own roung table, you have to reference the roung instances in the rewall lter, as
well. The syntax looks as follows:
[edit firewall filter
filter-name
term
term-name
]
user@host# set then logical-system
logical-system-name
routing-instance
routing-instance-name
Topology
Figure 55 on page 1243 shows the topology used in this example.
On Logical System P1, an input lter classies packets received from Logical System PE3 and Logical
System PE4. The packets are routed based on the source addresses. Packets with source addresses in
the 10.1.1.0/24 and 10.1.2.0/24 networks are routed to Logical System PE1. Packets with source
addresses in the 10.2.1.0/24 and 10.2.2.0/24 networks are routed to Logical System PE2.
Figure 55: Logical Systems with Filter-Based Forwarding
To establish connecvity, OSPF is congured on all of the interfaces. For demonstraon purposes,
loopback interface addresses are congured on the roung devices to represent networks in the clouds.
The "CLI Quick Conguraon" on page 1244 secon shows the enre conguraon for all of the
devices in the topology. The "Conguring the Roung Instances on the Logical System P1" on page 1247
and "Conguring the Firewall Filter on the Main Router" on page 1246 secons shows the step-by-step
conguraon of the ingress roung device, Logical System P1.
1243
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1244
Conguring the Firewall Filter on the Main Router | 1246
Conguring the Roung Instances on the Logical System P1 | 1247
Results | 1249
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set firewall filter classify-customers term sp1-customers from source-address 10.1.1.0/24
set firewall filter classify-customers term sp1-customers from source-address 10.1.2.0/24
set firewall filter classify-customers term sp1-customers then log
set firewall filter classify-customers term sp1-customers then logical-system P1 routing-
instance sp1-route-table
set firewall filter classify-customers term sp2-customers from source-address 10.2.1.0/24
set firewall filter classify-customers term sp2-customers from source-address 10.2.2.0/24
set firewall filter classify-customers term sp2-customers then log
set firewall filter classify-customers term sp2-customers then logical-system P1 routing-
instance sp2-route-table
set firewall filter classify-customers term default then accept
set logical-systems P1 interfaces lt-1/2/0 unit 10 encapsulation ethernet
set logical-systems P1 interfaces lt-1/2/0 unit 10 peer-unit 9
set logical-systems P1 interfaces lt-1/2/0 unit 10 family inet filter input classify-customers
set logical-systems P1 interfaces lt-1/2/0 unit 10 family inet address 172.16.0.10/30
set logical-systems P1 interfaces lt-1/2/0 unit 13 encapsulation ethernet
set logical-systems P1 interfaces lt-1/2/0 unit 13 peer-unit 14
set logical-systems P1 interfaces lt-1/2/0 unit 13 family inet address 172.16.0.13/30
set logical-systems P1 interfaces lt-1/2/0 unit 17 encapsulation ethernet
set logical-systems P1 interfaces lt-1/2/0 unit 17 peer-unit 18
set logical-systems P1 interfaces lt-1/2/0 unit 17 family inet address 172.16.0.17/30
set logical-systems P1 protocols ospf rib-group fbf-group
set logical-systems P1 protocols ospf area 0.0.0.0 interface all
1244
set logical-systems P1 protocols ospf area 0.0.0.0 interface fxp0.0 disable
set logical-systems P1 routing-instances sp1-route-table instance-type forwarding
set logical-systems P1 routing-instances sp1-route-table routing-options static route 0.0.0.0/0
next-hop 172.16.0.13
set logical-systems P1 routing-instances sp2-route-table instance-type forwarding
set logical-systems P1 routing-instances sp2-route-table routing-options static route 0.0.0.0/0
next-hop 172.16.0.17
set logical-systems P1 routing-options rib-groups fbf-group import-rib inet.0
set logical-systems P1 routing-options rib-groups fbf-group import-rib sp1-route-table.inet.0
set logical-systems P1 routing-options rib-groups fbf-group import-rib sp2-route-table.inet.0
set logical-systems P2 interfaces lt-1/2/0 unit 2 encapsulation ethernet
set logical-systems P2 interfaces lt-1/2/0 unit 2 peer-unit 1
set logical-systems P2 interfaces lt-1/2/0 unit 2 family inet address 172.16.0.2/30
set logical-systems P2 interfaces lt-1/2/0 unit 6 encapsulation ethernet
set logical-systems P2 interfaces lt-1/2/0 unit 6 peer-unit 5
set logical-systems P2 interfaces lt-1/2/0 unit 6 family inet address 172.16.0.6/30
set logical-systems P2 interfaces lt-1/2/0 unit 9 encapsulation ethernet
set logical-systems P2 interfaces lt-1/2/0 unit 9 peer-unit 10
set logical-systems P2 interfaces lt-1/2/0 unit 9 family inet address 172.16.0.9/30
set logical-systems P2 protocols ospf area 0.0.0.0 interface all
set logical-systems P2 protocols ospf area 0.0.0.0 interface fxp0.0 disable
set logical-systems PE1 interfaces lt-1/2/0 unit 14 encapsulation ethernet
set logical-systems PE1 interfaces lt-1/2/0 unit 14 peer-unit 13
set logical-systems PE1 interfaces lt-1/2/0 unit 14 family inet address 172.16.0.14/30
set logical-systems PE1 interfaces lo0 unit 3 family inet address 172.16.1.1/32
set logical-systems PE1 protocols ospf area 0.0.0.0 interface all
set logical-systems PE1 protocols ospf area 0.0.0.0 interface fxp0.0 disable
set logical-systems PE2 interfaces lt-1/2/0 unit 18 encapsulation ethernet
set logical-systems PE2 interfaces lt-1/2/0 unit 18 peer-unit 17
set logical-systems PE2 interfaces lt-1/2/0 unit 18 family inet address 172.16.0.18/30
set logical-systems PE2 interfaces lo0 unit 4 family inet address 172.16.2.2/32
set logical-systems PE2 protocols ospf area 0.0.0.0 interface all
set logical-systems PE2 protocols ospf area 0.0.0.0 interface fxp0.0 disable
set logical-systems PE3 interfaces lt-1/2/0 unit 1 encapsulation ethernet
set logical-systems PE3 interfaces lt-1/2/0 unit 1 peer-unit 2
set logical-systems PE3 interfaces lt-1/2/0 unit 1 family inet address 172.16.0.1/30
set logical-systems PE3 interfaces lo0 unit 1 family inet address 10.1.1.1/32
set logical-systems PE3 interfaces lo0 unit 1 family inet address 10.1.2.1/32
set logical-systems PE3 protocols ospf area 0.0.0.0 interface all
set logical-systems PE3 protocols ospf area 0.0.0.0 interface fxp0.0 disable
set logical-systems PE4 interfaces lt-1/2/0 unit 5 encapsulation ethernet
set logical-systems PE4 interfaces lt-1/2/0 unit 5 peer-unit 6
set logical-systems PE4 interfaces lt-1/2/0 unit 5 family inet address 172.16.0.5/30
1245
set logical-systems PE4 interfaces lo0 unit 2 family inet address 10.2.1.1/32
set logical-systems PE4 interfaces lo0 unit 2 family inet address 10.2.2.1/32
set logical-systems PE4 protocols ospf area 0.0.0.0 interface all
set logical-systems PE4 protocols ospf area 0.0.0.0 interface fxp0.0 disable
Conguring the Firewall Filter on the Main Router
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure the rewall lter on the main router:
1. Congure the source addresses for SP1 customers.
[edit firewall filter classify-customers term sp1-customers]
user@host# set from source-address 10.1.1.0/24
user@host# set from source-address 10.1.2.0/24
2. Congure the acons that are taken when packets are received with the specied source addresses.
To track the acon of the rewall lter, a log acon is congured. The sp1-route-table.inet.0 roung
table on Logical System P1 routes the packets.
[edit firewall filter classify-customers term sp1-customers]
user@host# set then log
user@host# set then logical-system P1 routing-instance sp1-route-table
3. Congure the source addresses for SP2 customers.
[edit firewall filter classify-customers term sp2-customers]
user@host# set from source-address 10.2.1.0/24
user@host# set from source-address 10.2.2.0/24
4. Congure the acons that are taken when packets are received with the specied source addresses.
1246
To track the acon of the rewall lter, a log acon is congured. The sp2-route-table.inet.0 roung
table on Logical System P1 routes the packet.
[edit firewall filter classify-customers term sp2-customers]
user@host# set then log
user@host# set then logical-system P1 routing-instance sp2-route-table
5. Congure the acon to take when packets are received from any other source address.
All of these packets are simply accepted and routed using the default IPv4 unicast roung table,
inet.0.
[edit firewall filter classify-customers term default]
user@host# set then accept
Conguring the Roung Instances on the Logical System P1
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure the roung instances on a logical system:
1. Congure the interfaces on the logical system.
[edit logical-systems P1 interfaces lt-1/2/0]
user@host# set unit 10 encapsulation ethernet
user@host# set unit 10 peer-unit 9
user@host# set unit 10 family inet address 172.16.0.10/30
user@host# set unit 13 encapsulation ethernet
user@host# set unit 13 peer-unit 14
user@host# set unit 13 family inet address 172.16.0.13/30
user@host# set unit 17 encapsulation ethernet
user@host# set unit 17 peer-unit 18
user@host# set unit 17 family inet address 172.16.0.17/30
1247
2. Assign the classify-customers rewall lter to router interface lt-1/2/0.10 as an input packet lter.
[edit logical-systems P1 interfaces lt-1/2/0]
user@host# set unit 10 family inet filter input classify-customers
3. Congure connecvity, using either a roung protocol or stac roung.
As a best pracce, disable roung on the management interface.
[edit logical-systems P1 protocols ospf area 0.0.0.0]
user@host# set interface all
user@host# set interface fxp0.0 disable
4. Create the roung instances.
These roung instances are referenced in the classify-customers rewall lter.
The forwarding instance type provides support for lter-based forwarding, where interfaces are not
associated with instances. All interfaces belong to the default instance, in this case Logical System
P1.
[edit logical-systems P1 routing-instances]
user@host# set sp1-route-table instance-type forwarding
user@host# set sp2-route-table instance-type forwarding
5. Resolve the routes installed in the roung instances to directly connected next hops.
[edit logical-systems P1 routing-instances]
user@host# set sp1-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.13
user@host# set sp2-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.17
6. Group together the roung tables to form a roung table group.
The rst roung table, inet.0, is the primary roung table, and the addional roung tables are the
secondary roung tables.
The primary roung table determines the address family of the roung table group, in this case IPv4.
[edit logical-systems P1 routing-options]
user@host# set rib-groups fbf-group import-rib inet.0
1248
user@host# set rib-groups fbf-group import-rib sp1-route-table.inet.0
user@host# set rib-groups fbf-group import-rib sp2-route-table.inet.0
7. Apply the roung table group to OSPF.
This causes the OSPF routes to be installed into all the roung tables in the group.
[edit logical-systems P1 protocols ospf]
user@host# set rib-group fbf-group
8. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Results
Conrm your conguraon by issuing the show firewall and show logical-systems P1 commands.
user@host# show firewall
filter classify-customers {
term sp1-customers {
from {
source-address {
10.1.1.0/24;
10.1.2.0/24;
}
}
then {
log;
logical-system P1 routing-instance sp1-route-table;
}
}
term sp2-customers {
from {
source-address {
10.2.1.0/24;
10.2.2.0/24;
}
}
1249
then {
log;
logical-system P1 routing-instance sp2-route-table;
}
}
term default {
then accept;
}
}
user@host# show logical-systems P1
interfaces {
lt-1/2/0 {
unit 10 {
encapsulation ethernet;
peer-unit 9;
family inet {
filter {
input classify-customers;
}
address 172.16.0.10/30;
}
}
unit 13 {
encapsulation ethernet;
peer-unit 14;
family inet {
address 172.16.0.13/30;
}
}
unit 17 {
encapsulation ethernet;
peer-unit 18;
family inet {
address 172.16.0.17/30;
}
}
}
}
protocols {
ospf {
1250
rib-group fbf-group;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
}
routing-instances {
sp1-route-table {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.0.13;
}
}
}
sp2-route-table {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.0.17;
}
}
}
}
routing-options {
rib-groups {
fbf-group {
import-rib [ inet.0 sp1-route-table.inet.0 sp2-route-table.inet.0 ];
}
}
}
Vericaon
IN THIS SECTION
Pinging with Specied Source Addresses | 1252
1251
Verifying the Firewall Filter | 1253
Conrm that the conguraon is working properly.
Pinging with Specied Source Addresses
Purpose
Send some ICMP packets across the network to test the rewall lter.
Acon
1. Log in to Logical System PE3.
user@host> set cli logical-system PE3
Logical system: PE3
2. Run the ping command, pinging the lo0.3 interface on Logical System PE1.
The address congured on this interface is 172.16.1.1.
Specify the source address 10.1.2.1, which is the address congured on the lo0.1 interface on Logical
System PE3.
user@host:PE3> ping 172.16.1.1 source 10.1.2.1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=62 time=1.444 ms
64 bytes from 172.16.1.1: icmp_seq=1 ttl=62 time=2.094 ms
^C
--- 172.16.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.444/1.769/2.094/0.325 ms
1252
3. Log in to Logical System PE4.
user@host:PE3> set cli logical-system PE4
Logical system: PE4
4. Run the ping command, pinging the lo0.4 interface on Logical System PE2.
The address congured on this interface is 172.16.2.2.
Specify the source address 10.2.1.1, which is the address congured on the lo0.2 interface on Logical
System PE4.
user@host:PE4> ping 172.16.2.2 source 10.2.1.1
PING 172.16.2.2 (172.16.2.2): 56 data bytes
64 bytes from 172.16.2.2: icmp_seq=0 ttl=62 time=1.473 ms
64 bytes from 172.16.2.2: icmp_seq=1 ttl=62 time=1.407 ms
^C
--- 172.16.2.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.407/1.440/1.473/0.033 ms
Meaning
Sending these pings acvates the rewall lter acons.
Verifying the Firewall Filter
Purpose
Make sure the rewall lter acons take eect.
Acon
1. Log in to Logical System P1.
user@host> set cli logical-system P1
Logical system: P1
1253
2. Run the show firewall log command on Logical System P1.
user@host:P1> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
13:52:20 pfe A lt-1/2/0.10 ICMP 10.2.1.1 172.16.2.2
13:52:19 pfe A lt-1/2/0.10 ICMP 10.2.1.1 172.16.2.2
13:51:53 pfe A lt-1/2/0.10 ICMP 10.1.2.1 172.16.1.1
13:51:52 pfe A lt-1/2/0.10 ICMP 10.1.2.1 172.16.1.1
RELATED DOCUMENTATION
Conguring Filter-Based Forwarding
Copying and Redirecng Trac with Port Mirroring and Filter-Based Forwarding
Example: Conguring Filter-Based Forwarding on the Source Address
Using Filter-Based Forwarding to Export Monitored Trac to Mulple Desnaons
Filter-Based Forwarding Overview
Example: Conguring a Stateless Firewall Filter to Protect a Logical
System Against ICMP Floods
IN THIS SECTION
Requirements | 1255
Overview | 1255
Conguraon | 1256
Vericaon | 1259
This example shows how to congure a stateless rewall lter that protects against ICMP denial-of-
service aacks on a logical system.
1254
Requirements
In this example, no special conguraon beyond device inializaon is required.
Overview
IN THIS SECTION
Topology | 1255
This example shows a stateless rewall lter called protect-RE that polices ICMP packets. The icmp-
policer limits the trac rate of the ICMP packets to 1,000,000 bps and the burst size to 15,000 bytes.
Packets that exceed the trac rate are discarded.
The policer is incorporated into the acon of a lter term called icmp-term.
In this example, a ping is sent from a directly connected physical router to the interface congured on
the logical system. The logical system accepts the ICMP packets if they are received at a rate of up to 1
Mbps (bandwidth-limit). The logical system drops all ICMP packets when this rate is exceeded. The burst-
size-limit statement accepts trac bursts up to 15 Kbps. If bursts exceed this limit, all packets are
dropped. When the ow rate subsides, ICMP packets are again accepted.
Topology
Figure 56 on page 1256 shows the topology used in this example.
1255
Figure 56: Logical System with a Stateless Firewall
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1256
Procedure | 1257
Results | 1258
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet policer input icmp-policer
set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet address 10.0.45.2/30
set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from protocol icmp
set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then policer icmp-
policer
1256
set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then accept
set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit 1m
set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-limit 15k
set logical-systems LS1 firewall policer icmp-policer then discard
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Use the CLI Editor in Conguraon Mode
in the CLI User
Guide.
To congure an ICMP rewall lter on a logical system:
1. Congure the interface on the logical system.
[edit]
user@host# set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet address
10.0.45.2/30
2. Explicitly enable ICMP packets to be received on the interface.
[edit]
user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from
protocol icmp
user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then
accept
3. Create the policer.
[edit]
user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit
1m
user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-
limit 15k
user@host# set logical-systems LS1 firewall policer icmp-policer then discard
1257
4. Apply the policer to a lter term.
[edit]
user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then
policer icmp-policer
5. Apply the policer to the logical system interface.
[edit]
user@host# set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet policer input icmp-
policer
6. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Results
Conrm your conguraon by issuing the show logical-systems LS1 command.
user@host# show logical-systems LS1
interfaces {
so-0/0/2 {
unit 0 {
family inet {
policer {
input icmp-policer;
}
address 10.0.45.2/30;
}
}
}
}
firewall {
family inet {
filter protect-RE {
term icmp-term {
from {
1258
protocol icmp;
}
then {
policer icmp-policer;
accept;
}
}
}
}
policer icmp-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 15k;
}
then discard;
}
}
Vericaon
IN THIS SECTION
Verifying That Ping Works Unless the Limits Are Exceeded | 1259
Conrm that the conguraon is working properly.
Verifying That Ping Works Unless the Limits Are Exceeded
Purpose
Make sure that the logical system interface is protected against ICMP-based DoS aacks.
Acon
Log in to a system that has connecvity to the logical system and run the ping command.
user@R2> ping 10.0.45.2
PING 10.0.45.2 (10.0.45.2): 56 data bytes
1259
64 bytes from 10.0.45.2: icmp_seq=0 ttl=64 time=1.316 ms
64 bytes from 10.0.45.2: icmp_seq=1 ttl=64 time=1.277 ms
64 bytes from 10.0.45.2: icmp_seq=2 ttl=64 time=1.269 ms
user@R2> ping 10.0.45.2 size 20000
PING 10.0.45.2 (10.0.45.2): 20000 data bytes
^C
--- 10.0.45.2 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Meaning
When you send a normal ping, the packet is accepted. When you send a ping packet that exceeds the
lter limit, the packet is discarded.
RELATED DOCUMENTATION
Example: Creang an Interface on a Logical System
Example: Conguring a Stateless Firewall Filter to Protect a Logical
System Against ICMP Floods
IN THIS SECTION
Requirements | 1261
Overview | 1261
Conguraon | 1262
Vericaon | 1265
This example shows how to congure a stateless rewall lter that protects against ICMP denial-of-
service aacks on a logical system.
1260
Requirements
In this example, no special conguraon beyond device inializaon is required.
Overview
IN THIS SECTION
Topology | 1261
This example shows a stateless
rewall lter called protect-RE that polices ICMP packets. The icmp-
policer limits the trac rate of the ICMP packets to 1,000,000 bps and the burst size to 15,000 bytes.
Packets that exceed the trac rate are discarded.
The policer is incorporated into the acon of a lter term called icmp-term.
In this example, a ping is sent from a directly connected physical router to the interface congured on
the logical system. The logical system accepts the ICMP packets if they are received at a rate of up to 1
Mbps (bandwidth-limit). The logical system drops all ICMP packets when this rate is exceeded. The burst-
size-limit statement accepts trac bursts up to 15 Kbps. If bursts exceed this limit, all packets are
dropped. When the ow rate subsides, ICMP packets are again accepted.
Topology
Figure 57 on page 1262 shows the topology used in this example.
1261
Figure 57: Logical System with a Stateless Firewall
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1262
Procedure | 1263
Results | 1264
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set logical-systems LS1 interfaces ge-0/0/2 unit 0 family inet policer input icmp-policer
set logical-systems LS1 interfaces ge-0/0/2 unit 0 family inet address 10.0.45.2/30
set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from protocol icmp
set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then policer icmp-
policer
1262
set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then accept
set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit 1m
set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-limit 15k
set logical-systems LS1 firewall policer icmp-policer then discard
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in
the Junos OS CLI User Guide.
To congure an ICMP rewall lter on a logical system:
1. Congure the interface on the logical system.
[edit]
user@host# set logical-systems LS1 interfaces ge-0/0/2 unit 0 family inet address
10.0.45.2/30
2. Explicitly enable ICMP packets to be received on the interface.
[edit]
user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from
protocol icmp
user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then
accept
3. Create the policer.
[edit]
user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit
1m
user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-
limit 15k
user@host# set logical-systems LS1 firewall policer icmp-policer then discard
1263
4. Apply the policer to a lter term.
[edit]
user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then
policer icmp-policer
5. Apply the policer to the logical system interface.
[edit]
user@host# set logical-systems LS1 interfaces ge-0/0/2 unit 0 family inet policer input icmp-
policer
6. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Results
Conrm your conguraon by issuing the show logical-systems LS1 command.
user@host# show logical-systems LS1
interfaces {
ge-0/0/2 {
unit 0 {
family inet {
policer {
input icmp-policer;
}
address 10.0.45.2/30;
}
}
}
}
firewall {
family inet {
filter protect-RE {
term icmp-term {
from {
1264
protocol icmp;
}
then {
policer icmp-policer;
accept;
}
}
}
}
policer icmp-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 15k;
}
then discard;
}
}
Vericaon
IN THIS SECTION
Verifying That Ping Works Unless the Limits Are Exceeded | 1265
Conrm that the conguraon is working properly.
Verifying That Ping Works Unless the Limits Are Exceeded
Purpose
Make sure that the logical system interface is protected against ICMP-based DoS aacks.
Acon
Log in to a system that has connecvity to the logical system and run the ping command.
user@R2> ping 10.0.45.2
PING 10.0.45.2 (10.0.45.2): 56 data bytes
1265
64 bytes from 10.0.45.2: icmp_seq=0 ttl=64 time=1.316 ms
64 bytes from 10.0.45.2: icmp_seq=1 ttl=64 time=1.277 ms
64 bytes from 10.0.45.2: icmp_seq=2 ttl=64 time=1.269 ms
user@R2> ping 10.0.45.2 size 20000
PING 10.0.45.2 (10.0.45.2): 20000 data bytes
^C
--- 10.0.45.2 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Meaning
When you send a normal ping, the packet is accepted. When you send a ping packet that exceeds the
lter limit, the packet is discarded.
RELATED DOCUMENTATION
Example: Creang an Interface on a Logical System
Unsupported Firewall Filter Statements for Logical Systems
Table 63 on page 1267 shows statements that are supported at the [edit firewall] hierarchy level but not
at the [edit logical-systems
logical-system-name
firewall] hierarchy level.
1266
Table 63: Unsupported Firewall Statements for Logical Systems
Statement Example Descripon
accounting-profile
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter myfilter {
accounting-profile fw-
profile;
...
term accept-all {
then {
count counter1;
accept;
}
}
}
}
}
}
}
In this example, the accounting-
profile statement is not allowed
because the accounng prole fw-
profile is congured under the [edit
accounting-options] hierarchy.
hierarchical-policer
[edit]
logical-systems {
lr1 {
firewall {
hierarchical-policer {
...
}
}
}
}
In this example, the hierarchical
policer statement requires a class-of-
service conguraon, which is not
supported under logical systems.
1267
Table 63: Unsupported Firewall Statements for Logical Systems
(Connued)
Statement Example Descripon
load-balance-group
[edit]
logical-systems {
ls1 {
firewall {
load-balance-group lb-group {
next-hop-group nh-group;
}
}
}
}
This conguraon is not allowed
because the next-hop-group nh-group
statement must be congured at the
[edit forwarding-options next-hop-
group] hierarchy level—outside the
[edit logical-systems
logical-
system-name
firewall] hierarchy.
Currently, the forwarding-options
dhcp-relay statement is the only
forwarding opon supported for
logical systems.
virtual-channel
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter foo {
term one {
from {
source-address
10.1.0.0/16;
}
then {
virtual-channel
sammy;
}
}
}
}
}
}
}
This conguraon is not allowed
because the virtual channel sammy
refers to an object dened at the
[edit class-of-service] hierarchy
level, and class of service is not
supported for logical systems.
NOTE:
The virtual-channel statement is
supported for J Series devices only,
provided the rewall lter is
congured outside of a logical-
system.
1268
RELATED DOCUMENTATION
Firewall Filters in Logical Systems Overview | 1217
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
Unsupported Acons for Firewall Filters in Logical Systems | 1269
Introducon to Logical Systems
Junos OS Logical Systems User Guide for Roung Devices
Logical Systems Operaons and Restricons
Junos OS Logical Systems User Guide for Roung Devices
Unsupported Acons for Firewall Filters in Logical Systems
Table 64 on page 1269 describes the rewall lter acons that are supported at the [edit firewall]
hierarchy level, but not supported at the [edit logical-systems
logical-system-name
firewall] hierarchy level.
Table 64: Unsupported Acons for Firewall Filters in Logical Systems
Firewall Filter Acon Example Descripon
Terminang Acons Not Supported in a Logical System
1269
Table 64: Unsupported Acons for Firewall Filters in Logical Systems
(Connued)
Firewall Filter Acon Example Descripon
logical-system
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter foo {
term one {
from {
source-address
10.1.0.0/16;
}
then {
logical-system
fred;
}
}
}
}
}
}
}
Because the logical-system acon
refers to fred—a logical system
dened outside the local logical
system—, this acon is not
supported.
Nonterminang Acons Not Supported in a Logical System
1270
Table 64: Unsupported Acons for Firewall Filters in Logical Systems
(Connued)
Firewall Filter Acon Example Descripon
ipsec-sa
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter foo {
term one {
from {
source-address
10.1.0.0/16;
}
then {
ipsec-sa barney;
}
}
}
}
}
}
}
Because the ipsec-sa acon
modier references barney—a
security associaon dened outside
the local logical system—this acon
is not supported.
1271
Table 64: Unsupported Acons for Firewall Filters in Logical Systems
(Connued)
Firewall Filter Acon Example Descripon
next-hop-group
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter foo {
term one {
from {
source-address
10.1.0.0/16;
}
then {
next-hop-group
fred;
}
}
}
}
}
}
}
Because the next-hop-group acon
refers to fred—an object dened at
the [edit forwarding-options next-
hop-group] hierarchy level—this
acon is not supported.
1272
Table 64: Unsupported Acons for Firewall Filters in Logical Systems
(Connued)
Firewall Filter Acon Example Descripon
port-mirror
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter foo {
term one {
from {
source-address
10.1.0.0/16;
}
then {
port-mirror;
}
}
}
}
}
}
}
Because the port-mirror acon
relies on a conguraon dened at
the [edit forwarding-options port-
mirroring] hierarchy level, this
acon is not supported.
1273
Table 64: Unsupported Acons for Firewall Filters in Logical Systems
(Connued)
Firewall Filter Acon Example Descripon
sample
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter foo {
term one {
from {
source-address
10.1.0.0/16;
}
then {
sample;
}
}
}
}
}
}
}
In this example, the sample acon
depends on the sampling
conguraon dened under the
[edit forwarding-options] hierarchy.
Therefore, the sample acon is not
supported.
1274
Table 64: Unsupported Acons for Firewall Filters in Logical Systems
(Connued)
Firewall Filter Acon Example Descripon
syslog
[edit]
logical-systems {
ls1 {
firewall {
family inet {
filter icmp-syslog {
term icmp-match {
from {
address {
192.168.207.222/32;
}
protocol icmp;
}
then {
count packets;
syslog;
accept;
}
}
term default {
then accept;
}
}
}
}
}
}
In this example, there must be at
least one system log (system syslog
file
filename
) with the firewall
facility enabled for the icmp-syslog
lter's logs to be stored.
Because this rewall conguraon
relies on a conguraon outside the
logical system, the syslog acon
modier is not supported.
RELATED DOCUMENTATION
Firewall Filters in Logical Systems Overview | 1217
Guidelines for Conguring and Applying Firewall Filters in Logical Systems | 1219
Unsupported Firewall Filter Statements for Logical Systems | 1266
Introducon to Logical Systems
Logical Systems Operaons and Restricons
1275
Filter-Based Forwarding for Roung Instances
You can use stateless rewall lters in roung instances to control how packets travel in a network for
IPv4 and IPv6 trac. This is called lter-based forwarding.
You can dene a rewall ltering term that directs matching packets to a specied roung instance. This
type of ltering can be congured to route specic types of trac through a rewall or other security
device before the trac connues on its path. To congure a stateless
rewall lter
to direct trac to a
roung instance, congure a term with the routing-instance
routing-instance-name
terminang acon at the
[edit firewall family <inet | inet6>] hierarchy level to specify the roung instance to which matching
packets will be forwarded. You can apply a forwarding table lter to a roung instance of type
forwarding and also to the default roung instance inet.0. To congure the lter to direct trac to the
master roung instance, use the routing-instance default statement at the [edit firewall family <inet |
inet6>] hierarchy level.
The following limitaons apply to lter-based forwarding table congured on roung instances:
• You cannot congure any of the following acons in a rewall ltering term when the ltering term
contains the routing-instance
routing-instance-name
terminang acon:
• count
counter-name
• discard
• forwarding-class
class-name
• log
• loss-priority (high | medium-high | low)
• policer
policer-name
• port-mirror
• reject
message-type
• syslog
• three-color-policer (single-rate | two-rate)
policer-name
•
You cannot congure the fragment-flags
number
match condion in the lter term.
• You cannot aach a lter that is either default or physical interface-specic.
• You cannot aach a lter to the egress direcon of roung instances.
• IPv6 lter-based forwarding does not support the following L4 matches:
1276
• source-port
• desnaon-port
• icmp-type
• icmp-code
Although you can congure forwarding of packets from one VRF to another VRF, you cannot congure
forwarding from a VRF to the global roung instance.
The maximum number of roung instances supported is 64, which is the same as the maximum number
of virtual routers supported. Forwarding packets to the global table (default VRF) is not supported for
lter-based forwarding.
NOTE: Filter-based forwarding on the interface will not work when source MAC address lter is
congured because the source MAC address lter takes higher precedence over lter-based
forwarding.
RELATED DOCUMENTATION
Example: Conguring Filter-Based Forwarding on the Source Address | 1501
Forwarding Table Filters for Roung Instances on ACX Series Routers
Forwarding table lter is a mechanism by which all the packets forwarded by a certain forwarding table
are subjected to ltering and if a packet matches the lter condion, the congured acon is applied on
the packet. You can use the forwarding table lter mechanism to apply a lter on all interfaces
associated with a single roung instance with a simple conguraon. You can apply a forwarding table
lter to a roung instance of type forwarding and also to the default roung instance inet.0. To congure
a forwarding table lter, include the filter
filter-name
statement at the [edit firewall family <inet | inet6>]
hierarchy level.
The following limitaons apply to forwarding table lters congured on roung instances:
• You cannot aach the same lter to more than one roung instance.
• You cannot aach the same lter at both the [edit interfaces
interface-name
family <inet | inet6> filter
input
filter-name
] and [edit routing-instances
instance-name
forwarding-options family <inet | inet6> filter
input
filter-name
] hierarchy level.
1277
• You cannot aach a lter that is either interface-specic or a physical interface lter.
• You cannot aach a lter to the egress direcon of roung instances.
RELATED DOCUMENTATION
Conguring Forwarding Table Filters | 1278
Conguring Forwarding Table Filters
Forwarding table lters are dened the same as other rewall lters, but you apply them dierently:
• Instead of applying forwarding table lters to interfaces, you apply them to forwarding tables, each
of which is associated with a roung instance and a virtual private network (VPN).
• Instead of applying input and output lters by default, you can apply an input forwarding table lter
only.
All packets are subjected to the input forwarding table lter that applies to the forwarding table. A
forwarding table lter controls which packets the router accepts and then performs a lookup for the
forwarding table, thereby controlling which packets the router forwards on the interfaces.
When the router receives a packet, it determines the best route to the ulmate desnaon by looking in
a forwarding table, which is associated with the VPN on which the packet is to be sent. The router then
forwards the packet toward its desnaon through the appropriate interface.
NOTE: For transit packets exing the router through the tunnel, forwarding table ltering is not
supported on the interfaces you congure as the output interface for tunnel trac.
A forwarding table lter allows you to lter data packets based on their components and to perform an
acon on packets that match the lter; it essenally controls which bearer packets the router accepts
and forwards. To congure a forwarding table lter, include the firewall statement at the [edit] hierarchy
level:
[edit]
firewall {
family
family-name
{
filter
filter-name
{
term
term-name
{
1278
from {
match-conditions
;
}
then {
action
;
action-modifiers
;
}
}
}
}
}
family-name
is the family address type: IPv4 (inet), IPv6 (inet6), Layer 2 trac (bridge), or MPLS (mpls).
term-name
is a named structure in which match condions and acons are dened.
match-condions
are the criteria against which a bearer packet is compared; for example, the IP address
of a source device or a desnaon device. You can specify mulple criteria in a match condion.
acon
species what happens if a packet matches all criteria; for example, the gateway GPRS support
node (GGSN) accepng the bearer packet, performing a lookup in the forwarding table, and forwarding
the packet to its desnaon; discarding the packet; and discarding the packet and returning a rejecon
message.
acon-modiers
are acons that are taken in addion to the GGSN accepng or discarding a packet
when all criteria match; for example, counng the packets and logging a packet.
To create a forwarding table, include the instance-type statement with the forwarding opon at the [edit
routing-instances
instance-name
] hierarchy level:
[edit]
routing-instances
instance-name
{
instance-type forwarding;
}
To apply a forwarding table lter to a VPN roung and forwarding (VRF) table, include the lter and input
statements at the [edit routing-instance
instance-name
forwarding-options family
family-name
] hierarchy level:
[edit routing-instances
instance-name
]
instance-type forwarding;
forwarding-options {
family
family-name
{
filter {
1279
input
filter-name
;
}
}
}
To apply a forwarding table lter to a forwarding table, include the lter and input statements at the [edit
forwarding-options family
family-name
] hierarchy level:
[edit forwarding-options family
family-name
]
filter {
input
filter-name
;
}
To apply a forwarding table lter to the default forwarding table inet.0, which is not associated with a
specic roung instance, include the lter and input statements at the [edit forwarding-options family inet]
hierarchy level:
[edit forwarding-options family inet]
filter {
input
filter-name
;
}
RELATED DOCUMENTATION
Guidelines for Conguring Firewall Filters | 816
Guidelines for Applying Standard Firewall Filters | 823
Applying Forwarding Table Filters
1280
CHAPTER 18
Conguring Firewall Filter Accounng and Logging
IN THIS CHAPTER
Accounng for Firewall Filters Overview | 1281
System Logging Overview | 1282
System Logging of Events Generated for the Firewall Facility | 1283
Firewall Filter Logging Acons | 1286
Example: Conguring Stascs Collecon for a Firewall Filter | 1290
Example: Conguring Logging for a Firewall Filter Term | 1297
Accounng for Firewall Filters Overview
Juniper Networks devices can collect various kinds of data about trac passing through the device. You
can set up one or more accounng proles that specify some common characteriscs of this data,
including the following:
• Fields used in the accounng records.
• Number of les that the roung plaorm retains before discarding, and the number of bytes per le.
• Polling period that the system uses to record the data
There are several types of accounng proles: interface,
rewall lter
, source class and desnaon class
usage, and Roung Engine. If you apply the same prole name to both a rewall lter and an interface, it
causes an error.
RELATED DOCUMENTATION
Example: Conguring Stascs Collecon for a Firewall Filter | 1290
1281
System Logging Overview
The Junos OS generates system log messages (also called
syslog messages
) to record
system events
that
occur on the device. Events consist of roune operaons, failure and error condions, and crical
condions that might require urgent resoluon. This system logging ulity is similar to the UNIX syslogd
ulity.
Each Junos OS system log message belongs to a message category, called a
facility
, that reects the
hardware- or soware-based source of the triggering event. A group of messages belonging to the same
facility are either generated by the same soware process or concern a similar hardware condion or
user acvity (such as authencaon aempts). Each system log message is also preassigned a
severity
,
which indicates how seriously the triggering event aects router (or switch) funcons. Together, the
facility and severity of an event are known as the message
priority
. The content of a syslog message
idenes the Junos OS
process
that generates the message and briey describes the operaon or error
that occurred.
By default, syslog messages that have a severity of info or more serious are wrien to the main system
log le messages in the /var/log directory of the local Roung Engine. To congure global sengs and
facility-specic sengs that override these default values, you can include statements at the [edit system
syslog] hierarchy level.
For all syslog facilies or for a specied facility, you can congure the syslog message ulity to redirect
messages of a specied severity to a specied le instead of to the main system log le. You can also
congure the syslog message ulity to write syslog messages of a specied severity, for all syslog
facilies or for a specied facility, to addional desnaons. In addion to wring syslog messages to a
log le, you can write syslog messages to the terminal sessions of any logged-in users, to the router (or
switch) console, or to a remote host or the other Roung Engine.
At the global level—for all system logging messages, regardless of facility, severity, or desnaon—you
can override the default values for le-archiving properes and the default mestamp format.
RELATED DOCUMENTATION
System Logging of Events Generated for the Firewall Facility | 1283
Firewall Filter Logging Acons | 1286
Example: Conguring Logging for a Firewall Filter Term | 1297
1282
System Logging of Events Generated for the Firewall Facility
System log messages generated for
rewall lter
acons belong to the firewall facility. Just as you can
for any other Junos OS system logging facility, you can direct firewall facility syslog messages to one or
more specic desnaons: to a specied le, to the terminal session of one or more logged in users (or
to all users), to the router (or switch) console, or to a remote host or the other Roung Engine on the
router (or switch).
When you congure a syslog message desnaon for firewall facility syslog messages, you include a
statement at the [edit system syslog] hierarchy level, and you specify the firewall facility name together
with a severity level. Messages from the firewall that are rated at the specied level or more severe are
logged to the desnaon.
System log messages with the DFWD_ prex are generated by the rewall process (dfwd), which manages
compilaon and downloading of Junos OS rewall lters. System log messages with the PFE_FW_ prex are
messages about rewall lters, generated by the Packet Forwarding Engine controller, which manages
packet forwarding funcons. For more informaon, see the System Log Explorer.
Table 65 on page 1284 lists the system log desnaons you can congure for the firewall facility.
1283
Table 65: Syslog Message Desnaons for the Firewall Facility
Desnaon Descripon Conguraon Statements Under [edit system syslog]
File Conguring this opon keeps the
firewall syslog messages out of
the main system log le.
To include priority and facility
with messages wrien to the le,
include the explicit-priority
statement.
To override the default standard
message format, which is based
on a UNIX system log format,
include the structured-data
statement. When the structured-
data statement is included, other
statements that specify the
format for messages wrien to
the le are ignored (the explicit-
priority statement at the [edit
system syslog file
filename
]
hierarchy level and the time-format
statement at the [edit system
syslog] hierarchy level).
file
filename
{
firewall
severity
;
allow-duplicates;
archive
archive-options
;
explicit-priority;
structured-data;
}
allow-duplicates;
archive
archive-options
;
time-format (
option
);
Terminal session Conguring this opon causes a
copy of the firewall syslog
messages to be wrien to the
specied terminal sessions.
Specify one or more user names,
or specify * for all logged in users.
user (
username
| *) {
firewall
severity
;
}
time-format (
option
);
Router (or
switch) console
Conguring this opon causes a
copy of the rewall syslog
messages to be wrien to the
router (or switch) console.
console {
firewall
severity
;
}
time-format (
option
);
1284
Table 65: Syslog Message Desnaons for the Firewall Facility
(Connued)
Desnaon Descripon Conguraon Statements Under [edit system syslog]
Remote host or
the other
Roung Engine
Conguring this opon causes a
copy of the firewall syslog
messages to be wrien to the
specied remote host or to the
other Roung Engine.
To override the default alternave
facility for forwarding firewall
syslog messages to a remote
machine (local3), include the
facility-override firewall
statement.
To include priority and facility
with messages wrien to the le,
include the explicit-priority
statement.
host (
hostname
| other-routing-engine) {
firewall
severity
;
allow-duplicates;
archive
archive-options
;
facility-override firewall;
explicit-priority;
}
allow-duplicates; # All destinations
archive
archive-options
;
time-format (
option
);
By default, the mestamp recorded in a standard-format system log message species the month, date,
hour, minute, and second when the message was logged, as in the example:
Sep 07 08:00:10
To include the year, the millisecond, or both in the mestamp for all system logging messages, regardless
of the facility, include one of the following statement at the [edit system syslog] hierarchy level:
• time-format year;
• time-format millisecond;
• time-format year millisecond;
The following example illustrates the format for a mestamp that includes both the millisecond (401) and
the year (2010):
Sep 07 08:00:10.401.2010
1285
RELATED DOCUMENTATION
System Logging Overview | 1282
Firewall Filter Logging Acons | 1286
Example: Conguring Logging for a Firewall Filter Term | 1297
Junos OS System Logging Facilies and Message Severity Levels
Junos OS System Log Conguraon Hierarchy
Junos OS Default System Log Sengs
Logging Messages in Structured-Data Format
Including the Year or Millisecond in Timestamps
Changing the Alternave Facility Name for System Log Messages Directed to a Remote Desnaon
Alternate Facilies for System Log Messages Directed to a Remote Desnaon
Firewall Filter Logging Acons
For IPv4 and IPv6 rewall lters, you can congure the lter to write a summary of matching packet
headers to the log or syslog by specifying either the syslog or log acon. The main dierence between
the two is the permanence of the record. Logs are only buered in memory, and when that buer is full,
the oldest records are replaced with new ones as they come in. Syslogs, on the other hand, can be saved
to disk or forwarded to a remote syslog server. In both cases, a summary of the packet header is logged
(not a copy of the packet itself). Service lters and simple lters do not support either the log or syslog
acon.
NOTE: Both the syslog and log acons can consume signicant CPU and/or disk space on the
device. Juniper recommends that you o-load logs by wring them to a remote syslog server,
and that you constrain logging by using it for diagnoscs only.
Syslog
As noted, system logs can be wrien to disk and/or sent to a remote server. Saved logs are wrien to
the /var/log directory. You can view a list of all available log les on the device by running the show log
command without opons. Note, that within a given log le, the rewall acon logs may be interspersed
with event messages.
1286
The following syslog conguraon shows system logs being sent to a remote server at 172.27.1.1, and
also save them to a le named “rewall” on the local device.
host@device-RE0# show system syslog
host 172.27.1.1 {
firewall any;
}
<...>
file firewall {
firewall any;
}
To view system logs, run the show syslog message command.
To view the contents of a given system log le, run either the show log
filename
or the file show /var/log/
filename
command.
To clear system log le contents, run the clear log
filename
command. You can include the all opon to
delete all saved logs, including records being wrien to the current log le.
Conguraon details are shown here:
firewall {
family {
filter
filter-name
{
from {
match-conditions
;
}
then {
...
syslog;
terminating-action
;
}
}
}
}
Log
The log acon writes log informaon to a buer. There is no opon for wring logs to a remote server,
or for wring them to disk. Once the available buer is full, new logs will replace the oldest, so a
historical record is not kept. Logs are cleared whenever the device or PFE is restarted.
1287
Conguraon details are shown here:
firewall {
family {
filter
filter-name
{
from {
match-conditions
;
}
then {
...
log;
terminating-action
;
}
}
}
}
To view the logs, run the show firewall log command.
Log Details
The following shows what kind of informaon is typically included in syslog and log entries:
user@host> show log messages_firewall_any
Mar 20 08:08:45 hostname feb FW: ge-1/1/0.0 A icmp 192.168.207.222 192.168.207.223 0 0 (1
packets)
The elds are explained here:
• Date and Time—Date and me at which the packet was received (not shown in the default).
Hostname—Name of the device on which the match occurred..
Interface—Physical interface that the packet traversed.
• Filter acon. In the example above, it is A.
• A—Accept (or next term)
•
D—Discard
• R—Reject
1288
• Protocol—Packet protocol. May be a name or number, and may also include the source and
desnaon ports. In the example above, the protocol is ICMP, which may then include the ICMP type
and code.
• Source address—Source IP address of the packet.
• Destination address—Desnaon IP address of the packet.
• Source port—Source port of the packet (TCP and UDP packets only). In the example above, the port is
0.
• Destination port—Desnaon port of the packet (TCP and UDP packets only). In the example above,
the port is 0.
• Packets in sample interval—This example show only one matching packet was detected in the sample
interval (about a second). If packets arrive at faster rate, the system log automacally compresses the
informaon so that less output is generated.
RELATED DOCUMENTATION
System Logging Overview | 1282
System Logging of Events Generated for the Firewall Facility | 1283
Example: Conguring Logging for a Firewall Filter Term | 1297
System Log Explorer
System Log Explorer
1289
Example: Conguring Stascs Collecon for a Firewall Filter
IN THIS SECTION
Requirements | 1290
Overview | 1290
Conguraon | 1291
Vericaon | 1297
This example shows how to congure and apply a rewall lter that collects data according to
parameters specied in an associated accounng prole.
Requirements
Firewall lter accounng proles are supported for all trac types except family any.
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 1290
In this example, you create a rewall lter accounng prole and apply it to a rewall lter. The
accounng prole species how frequently to collect packet and byte count stascs and the name of
the le to which the stascs are wrien. The prole also species that stascs are to be collected for
three rewall lter counters.
Topology
The rewall lter accounng prole filter_acctg_profile species that stascs are collected every
60 minutes, and the stascs are wrien to the le /var/log/ff_accounting_file. Stascs are collected for
counters named counter1, counter2, and counter3.
1290
The IPv4 rewall lter named my_firewall_filter increments a counter for each of three lter terms. The
lter is applied to logical interface ge-0/0/1.0.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1291
Congure an Accounng Prole | 1292
Congure a Firewall Filter That References the Accounng Prole | 1293
Apply the Firewall Filter to an Interface | 1294
Conrm Your Candidate Conguraon | 1294
Clear the Counters and Commit Your Candidate Conguraon | 1296
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set accounting-options file ff_accounting_file files 10
set accounting-options file ff_accounting_file transfer-interval 10
set accounting-options filter-profile filter_acctg_profile file ff_accounting_file
set accounting-options filter-profile filter_acctg_profile interval 60
set accounting-options filter-profile filter_acctg_profile counters counter1
set accounting-options filter-profile filter_acctg_profile counters counter2
set accounting-options filter-profile filter_acctg_profile counters counter3
set firewall family inet filter my_firewall_filter accounting-profile filter_acctg_profile
set firewall family inet filter my_firewall_filter term term1 from protocol ospf
set firewall family inet filter my_firewall_filter term term1 then count counter1
set firewall family inet filter my_firewall_filter term term1 then discard
set firewall family inet filter my_firewall_filter term term2 from source-address 10.108.0.0/16
set firewall family inet filter my_firewall_filter term term2 then count counter2
set firewall family inet filter my_firewall_filter term term2 then discard
1291
set firewall family inet filter my_firewall_filter term accept-all then count counter3
set firewall family inet filter my_firewall_filter term accept-all then accept
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
set interfaces ge-0/0/1 unit 0 family inet filter input my_firewall_filter
Congure an Accounng Prole
Step-by-Step Procedure
To congure an accounng prole:
1. Create a log le to associate with the accounng prole.
[edit]
user@host# edit accounting-options file ff_accounting_file files 10
edit accounting-options file ff_accounting_file transfer-interval 10
2. Create the accounng prole filter_acctg_profile.
[edit]
user@host# edit accounting-options filter-profile filter_acctg_profile
3. Congure the accounng prole to lter and collect packet and byte count stascs every
60 minutes and write them to the /var/log/ff_accounting_file le.
[edit accounting-options filter-profile filter_acctg_profile]
user@host# set file ff_accounting_file
user@host# set interval 60
4. Congure the accounng prole to collect lter prole stascs (packet and byte counts) for three
counters.
[edit accounting-options filter-profile filter_acctg_profile]
user@host# set counters counter1
user@host# set counters counter2
user@host# set counters counter3
1292
Congure a Firewall Filter That References the Accounng Prole
Step-by-Step Procedure
To congure a rewall lter that references the accounng prole:
1. Create the rewall lter my_firewall_filter.
[edit]
user@host# edit firewall family inet filter my_firewall_filter
2. Apply the lter-accounng prole filter_acctg_profile to the rewall lter.
[edit firewall family inet filter my_firewall_filter]
user@host# set accounting-profile filter_acctg_profile
3. Congure the rst lter term and counter.
[edit firewall family inet filter my_firewall_filter]
user@host# set term term1 from protocol ospf
user@host# set term term1 then count counter1
user@host# set term term1 then discard
4. Congure the second lter term and counter.
[edit firewall family inet filter my_firewall_filter]
user@host# set term term2 from source-address 10.108.0.0/16
user@host# set term term2 then count counter2
user@host# set term term2 then discard
5. Congure the third lter term and counter.
[edit firewall family inet filter my_firewall_filter]
user@host# set term accept-all then count counter3
user@host# set term accept-all then accept
1293
Apply the Firewall Filter to an Interface
Step-by-Step Procedure
To apply the rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input my_firewall_filter
Conrm Your Candidate Conguraon
Step-by-Step Procedure
To conrm your candidate conguraon:
1. Conrm the conguraon of the accounng prole by entering the show accounting-options
conguraon mode command. If the command output does not display the intended conguraon,
repeat the instrucons in this example to correct the conguraon.
[edit]
user@host# show accounting-options
file ff_accounting_file {
files 10;
transfer-interval 10;
}
filter-profile filter_acctg_profile {
file ff_accounting_file;
1294
interval 60;
counters {
counter1;
counter2;
counter3;
}
}
2. Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter my_firewall_filter {
accounting-profile filter_acctg_profile;
term term1 {
from {
protocol ospf;
}
then {
count counter1;
discard;
}
}
term term2 {
from {
source-address {
10.108.0.0/16;
}
}
then {
count counter2;
discard;
}
}
term accept-all {
then {
count counter3;
accept;
}
1295
}
}
}
3. Conrm the conguraon of the interfaces by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
filter {
input my_firewall_filter;
}
address 10.1.2.3/30;
}
}
}
Clear the Counters and Commit Your Candidate Conguraon
Step-by-Step Procedure
To clear the counters and commit your candidate conguraon:
1. From operaonal command mode, use the clear firewall all command to clear the stascs for all
rewall lters.
To clear only the counters incremented in this example, include the name of the rewall lter.
[edit]
user@host> clear firewall filter my_firewall_filter
2. Commit your candidate conguraon.
[edit]
user@host# commit
1296
Vericaon
To verify that the lter is applied to the logical interface, run the show interfaces command with the detail
or extensive output level.
To verify that the three counters are collected separately, run the show firewall filter my_firewall_filter
command.
user@host> show firewall filter my_firewall_filter
Filter: my_firewall_filter
Counters:
Name Bytes Packets
counter1 0 0
counter2 0 0
counter3 0 0
RELATED DOCUMENTATION
Accounng for Firewall Filters Overview | 1281
Example: Conguring Logging for a Firewall Filter Term
IN THIS SECTION
Requirements | 1298
Overview | 1298
Conguraon | 1298
Vericaon | 1302
This example shows how to congure a rewall lter to log packet headers.
1297
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you use a rewall lter that logs and counts ICMP packets that have 192.168.207.222 as
either their source or desnaon.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1298
Congure the Syslog Messages File for the Firewall Facility | 1299
Congure the Firewall Filter | 1299
Apply the Firewall Filter to a Logical Interface | 1300
Conrm and Commit Your Candidate Conguraon | 1301
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set system syslog file messages_firewall_any firewall any
set system syslog file messages_firewall_any archive no-world-readable
set firewall family inet filter icmp_syslog term icmp_match from address 192.168.207.222/32
set firewall family inet filter icmp_syslog term icmp_match from protocol icmp
set firewall family inet filter icmp_syslog term icmp_match then count packets
set firewall family inet filter icmp_syslog term icmp_match then syslog
set firewall family inet filter icmp_syslog term icmp_match then accept
set firewall family inet filter icmp_syslog term default_term then accept
1298
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
set interfaces ge-0/0/1 unit 0 family inet filter input icmp_syslog
Congure the Syslog Messages File for the Firewall Facility
Step-by-Step Procedure
To congure a syslog messages le for the firewall facility:
1. Congure a messages le for all syslog messages generated for the firewall facility.
user@host# set system syslog file messages_firewall_any firewall any
2. Restrict permission to the archived firewall facility syslog les to the root user and users who have
the Junos OS maintenance permission.
user@host# set system syslog file messages_firewall_any archive no-world-readable
Congure the Firewall Filter
Step-by-Step Procedure
To congure the rewall lter icmp_syslog that logs and counts ICMP packets that have 192.168.207.222 as
either their source or desnaon:
1. Create the rewall lter icmp_syslog.
[edit]
user@host# edit firewall family inet filter icmp_syslog
2. Congure matching on the ICMP protocol and an address.
[edit firewall family inet filter icmp_syslog]
user@host# set term icmp_match from address 192.168.207.222/32
user@host# set term icmp_match from protocol icmp
1299
3. Count, log,, and accept matching packets.
[edit firewall family inet filter icmp_syslog]
user@host# set term icmp_match then count packets
user@host# set term icmp_match then syslog
user@host# set term icmp_match then accept
4. Accept all other packets.
[edit firewall family inet filter icmp_syslog]
user@host# set term default_term then accept
Apply the Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input icmp_syslog
1300
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the syslog message le for the firewall facility by entering the show system
conguraon mode command. If the command output does not display the intended conguraon,
repeat the instrucons in this example to correct the conguraon.
[edit]
user@host# show system
syslog {
file messages_firewall_any {
firewall any;
archive no-world-readable;
}
}
2. Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter icmp_syslog {
term icmp_match {
from {
address {
192.168.207.222/32;
}
protocol icmp;
}
then {
count packets;
syslog;
accept;
}
}
term default_term {
1301
then accept;
}
}
}
3. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
filter {
input icmp_syslog;
}
address 10.1.2.3/30;
}
}
}
4. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show log filter command:
user@host> show log messages_firewall_any
Mar 20 08:03:11 hostname feb FW: so-0/1/0.0 A icmp 192.168.207.222
192.168.207.223 0 0 (1 packets)
This output le contains the following elds:
•
Date and Time—Date and me at which the packet was received (not shown in the default).
• Filter acon:
1302
• A—Accept (or next term)
• D—Discard
• R—Reject
• Protocol—Packet’s protocol name or number.
• Source address—Source IP address in the packet.
• Destination address—Desnaon IP address in the packet.
NOTE: If the protocol is ICMP, the ICMP type and code are displayed. For all other protocols,
the source and desnaon ports are displayed.
The last two elds (both zero) are the source and desnaon TCP/UDP ports, respecvely, and are
shown for TCP or UDP packets only. This log message indicates that only one packet for this match has
been detected in about a 1-second interval. If packets arrive faster, the system log funcon compresses
the informaon so that less output is generated, and displays an output similar to the following:
user@host> show log messages_firewall_any
Mar 20 08:08:45 hostname feb FW: so-0/1/0.0 A icmp 192.168.207.222
192.168.207.223 0 0 (515 packets)
RELATED DOCUMENTATION
System Logging Overview | 1282
Firewall Filter Logging Acons | 1286
System Log Explorer
System Log Explorer
1303
CHAPTER 19
Aaching Mulple Firewall Filters to a Single
Interface
IN THIS CHAPTER
Applying Firewall Filters to Interfaces | 1304
Conguring Firewall Filters | 1305
Muleld Classier Example: Conguring Muleld Classicaon | 1308
Muleld Classier for Ingress Queuing on MX Series Routers with MPC | 1334
Assigning Muleld Classiers in Firewall Filters to Specify Packet-Forwarding Behavior (CLI
Procedure) | 1335
Understanding Mulple Firewall Filters in a Nested Conguraon | 1338
Guidelines for Nesng References to Mulple Firewall Filters | 1340
Understanding Mulple Firewall Filters Applied as a List | 1342
Guidelines for Applying Mulple Firewall Filters as a List | 1346
Example: Applying Lists of Mulple Firewall Filters | 1348
Example: Nesng References to Mulple Firewall Filters | 1356
Example: Filtering Packets Received on an Interface Set | 1362
Applying Firewall Filters to Interfaces
For a rewall lter to work, you must apply it to at least one Layer 3 interface. To do this, include the
filter statement when conguring a logical interface at the [edit interfaces] hierarchy level:
[edit interfaces]
user@switch# set
interface-name
unit
logical-unit-number
family (inet | inet6) filter (input |
output)
filter-name
In the input statement, specify a rewall lter to be evaluated when packets are received on the
interface. Input lters applied to a loopback interface aect only trac desned for the Roung Engine.
1304
In the output statement, specify a lter to be evaluated when packets exit the interface.
NOTE: When you create a loopback interface, it is important to apply an ingress lter to it so the
Roung Engine is protected. We recommend that when you apply a lter to the loopback
interface lo0, you include the apply-groups statement. Doing so ensures that the lter is
automacally inherited on every loopback interface, including lo0 and other loopback interfaces.
RELATED DOCUMENTATION
Conguring Firewall Filters | 1829
Conguring Firewall Filters
IN THIS SECTION
Conguring a Firewall Filter | 1305
Applying a Firewall Filter to a Layer 3 (Routed) Interface | 1307
You can congure rewall lters in a switch to control trac that enters or exits Layer 3 (routed)
interfaces. To use a rewall lter, you must congure the lter and then apply it to a Layer 3 interface.
Conguring a Firewall Filter
To congure a rewall lter:
1. Congure the family address type, lter name, term name, and at least one match condion—for
example, match on packets that contain a specic source address:
[edit]
user@switch# set firewall family (inet | inet6) filter ingress-port-filter term t1 from
source-address 192.0.2.14
Specify the family address type inet for IPv4 or inet6 for IPv6.
1305
The lter and term names can contain leers, numbers, and hyphens (-) and can be up to 64
characters long. Each lter name must be unique. A lter can contain one or more terms, and each
term name must be unique within a lter.
2. Congure addional match condions. For example, match on packets that contain a specic source
port:
[edit firewall family inet filter ingress-port-filter term t1 from]
user@switch# set source-port 80
You can specify one or more match condions in a single from statement. For a match to occur, the
packet must match all the condions in the term. The from statement is oponal, but if included in a
term, it cannot be empty. If you omit the from statement, all packets are considered to match.
3. If you want to apply a rewall lter to mulple interfaces and be able to see counters specic to each
interface, congure the interface-specific opon:
[edit firewall family inet filter ingress-port-filter]
user@switch# set interface-specific
4. In each rewall lter term, specify the acons to take if the packet matches all the condions in that
term. You can specify an acon and acon modiers:
• To specify a lter acon, for example, to discard packets that match the condions of the lter
term:
[edit firewall family inet filter ingress-port-filter term t1 then]
user@switch# set discard
You can specify no more than one acon (accept, discard, reject, routing-instance, or vlan) per term.
• To specify acon modiers, for example, to count and classify packets to a forwarding class. For
example:
[edit firewall family inet filter ingress-port-filter term t1 then]
user@switch# set count counter-one
user@switch# set loss-priority high
If you omit the then statement or do not specify an acon, packets that match all the condions in the
from statement are accepted. However, you should always explicitly congure an acon in the then
statement. You can include no more than one acon statement, but you can use any combinaon of
1306
acon modiers. For an acon or acon modier to take eect, all condions in the from statement
must match.
NOTE: Implicit discard is also applicable to a rewall lter applied to the loopback interface,
lo0.
NOTE: For the complete list of match condions, acons, and acon modiers, see Firewall Filter
Match Condions and Acons (EX4100, EX4100-F, EX4400, EX4600, EX4650, QFX5100,
QFX5110, QFX5120, QFX5200, QFX5210, QFX5700). Note that on the OCX1100 switch you
can use only those match condions that are valid for IPv4 and IPv6 interfaces.
Applying a Firewall Filter to a Layer 3 (Routed) Interface
To apply a rewall lter to a Layer 3 interface:
1. Provide a meaningful descripon of the rewall lter in the conguraon of the interface to which
the lter will be applied:
[edit]
user@switch# set interfaces xe-0/0/1 description "filter to count and monitor traffic on
layer 3 interface"
2. You can apply rewall lters to lter packets that enter or exit a Layer 3 interface:
• To apply a rewall lter to lter packets that enter a Layer 3 interface:
[edit]
user@switch# set interfaces xe-0/0/1 unit 0 family inet filter input ingress-router-filter
• To apply a rewall lter to lter packets that exit a Layer 3 interface:
[edit]
user@switch# set interfaces xe-0/0/2 unit 0 family inet filter output egress-router-filter
NOTE: You can apply only one lter to an interface for a given direcon (ingress or egress).
1307
RELATED DOCUMENTATION
Overview of Firewall Filters (OCX Series) | 848
Monitoring Firewall Filter Trac | 829
Conguring Port Mirroring
Muleld Classier Example: Conguring Muleld Classicaon
IN THIS SECTION
Muleld Classicaon Overview | 1308
Muleld Classicaon Requirements and Restricons | 1311
Muleld Classicaon Limitaons on M Series Routers | 1312
Example: Conguring Muleld Classicaon | 1315
Example: Conguring and Applying a Firewall Filter for a Muleld Classier | 1325
Muleld Classicaon Overview
IN THIS SECTION
Forwarding Classes and PLP Levels | 1308
Muleld Classicaon and BA Classicaon | 1309
Muleld Classicaon Used In Conjuncon with Policers | 1310
Forwarding Classes and PLP Levels
You can congure the Junos OS class of service (CoS) features to classify incoming trac by associang
each packet with a forwarding class, a packet loss priority (PLP) level, or both:
• Based on the associated forwarding class, each packet is assigned to an output queue, and the router
services the output queues according to the associated scheduling you congure.
1308
• Based on the associated PLP, each packet carries a lower or higher likelihood of being dropped if
congeson occurs. The CoS random early detecon (RED) process uses the drop probability
conguraon, output queue fullness percentage, and packet PLP to drop packet as needed to control
congeson at the output stage.
Muleld Classicaon and BA Classicaon
The Junos OS supports two general types of packet classicaon: behavior aggregate (BA) classicaon
and muleld classicaon:
• BA classicaon, or CoS value trac classicaon, refers to a method of packet classicaon that
uses a CoS conguraon to set the forwarding class or PLP of a packet based on the
CoS value
in the
IP packet header. The CoS value examined for BA classicaon purposes can be the Dierenated
Services code point (DSCP) value, DSCP IPv6 value, IP precedence value, MPLS EXP bits, and IEEE
802.1p value. The default classier is based on the IP precedence value.
• Muleld classicaon refers to a method of packet classicaon that uses a standard stateless
rewall lter
conguraon to set the forwarding class or PLP for each packet entering or exing the
interface based on
mulple elds
in the IP packet header, including the DSCP value (for IPv4 only),
the IP precedence value, the MPLS EXP bits, and the IEEE 802.1p bits. Muleld classicaon
commonly matches on IP address elds, the IP protocol type eld, or the port number in the UDP or
TCP pseudoheader eld. Muleld classicaon is used instead of BA classicaon when you need
to classify packets based on informaon in the packet informaon other than the CoS values only.
With muleld classicaon, a rewall lter term can specify the packet classicaon acons for
matching packets though the use of the forwarding-class
class-name
or loss-priority (high | medium-high |
medium-low | low) nonterminang acons in the term’s then clause.
NOTE: BA classicaon of a packet can be overridden by the stateless rewall lter acons
forwarding-class and loss-priority.
NOTE: Misclassicaon of trac via Muleld classier on QFX5k:
• If BUM trac is forced to take unicast queue via MF classier, packets will be classied to
MCQ9. Junos releases 21.4R3 , 22.1R3 and from Junos release version 22.2 these packets
will be classied to MCQ8.
• If unicast trac is forced to take mulcast queue via MF classier, packets will be classied to
MCQ9 and from release 19.1R3 it will be classied to best-eort queue.
1309
Muleld Classicaon Used In Conjuncon with Policers
To congure muleld classicaon in conjuncon with rate liming, a rewall lter term can specify
the packet classicaon acons for matching packets through the use of a policer nonterminang acon
that references a single-rate two-color policer.
When muleld classicaon is congured to perform classicaon through a policer, the lter-matched
packets in the trac ow are rate-limited to the policer-specied trac limits. Packets in a conforming
ow of lter-matched packets are implicitly set to a low PLP. Packets in a nonconforming trac ow can
be discarded, or the packets can be set to a specied forwarding class, set to a specied PLP level, or
both, depending on the type of policer and how the policer is congured to handle nonconforming
trac.
NOTE: Before you apply a rewall lter that performs muleld classicaon and also a policer
to the same
logical interface
and for the same trac direcon, make sure that you consider the
order of policer and rewall lter operaons.
As an example, consider the following scenario:
• You congure a rewall lter that performs muleld classicaon (acts on matched packets
by seng the forwarding class, the PLP, or both) based on the packet's exisng forwarding
class or PLP. You apply the rewall lter at the input of a logical interface.
• You also congure a single-rate two-color policer that acts on a red trac ow by re-marking
(seng the forwarding class, the PLP, or both) rather than discarding those packets. You apply
the policer as an interface policer at the input of the same logical interface to which you apply
the rewall lter.
Because of the order of policer and rewall operaons, the input policer is executed before the
input rewall lter. This means that the muleld classicaon specied by the rewall lter is
performed on input packets that have already been re-marked once by policing acons.
Consequently, any input packet that matches the condions specied in a rewall lter term is
then subject to a second re-marking according to the forwarding-class or loss-priority
nonterminang acons also specied in that term.
SEE ALSO
Firewall Filter Nonterminang Acons | 873
Junos OS Roung Policies, Firewall Filters and Trac Policers User Guide for Roung Devices
Order of Policer and Firewall Filter Operaons | 1930
Two-Color Policer Conguraon Overview | 2038
1310
Muleld Classicaon Requirements and Restricons
Muleld Classicaon Limitaons on M Series Routers
Example: Conguring Muleld Classicaon
The Junos OS CoS Components Used to Manage Congeson and Control Service Levels
Understanding How Behavior Aggregate Classiers Priorize Trusted Trac
Understanding How Forwarding Classes Assign Classes to Output Queues
Default Forwarding Classes
Managing Congeson Using RED Drop Proles and Packet Loss Priories
Muleld Classicaon Requirements and Restricons
IN THIS SECTION
Supported Plaorms | 1311
CoS Tricolor Marking Requirement | 1311
Restricons | 1312
Supported Plaorms
The loss-priority
rewall lter
acon is supported on the following roung plaorms only:
• EX Series switches
• M7i and M10i routers with the Enhanced CFEB (CFEB-E)
• M120 and M320 routers
• MX Series routers
• T Series routers with Enhanced II Flexible PIC Concentrators (FPCs)
• PTX Series routers
CoS Tricolor Marking Requirement
The loss-priority rewall lter acon has plaorm-specic requirements dependencies on the CoS
tricolor marking feature, as dened in RFC 2698:
•
On an M320 router, you cannot commit a conguraon that includes the loss-priority rewall lter
acon unless you enable the CoS tricolor marking feature.
1311
• On all roung plaorms that support the loss-priority rewall lter acon, you cannot set the loss-
priority rewall lter acon to medium-low or medium-high unless you enable the CoS tricolor marking
feature. .
To enable the CoS tricolor marking feature, include the tri-color statement at the [edit class-of-service]
hierarchy level.
Restricons
You cannot congure the loss-priority and three-color-policer nonterminang acons for the same
rewall lter term. These two nonterminang acons are mutually exclusive.
NOTE: On a PTX Series router, you must congure the policer acon in a separate rule and not
combine it with the rule conguring the forwarding-class, and loss-priority acons. See "Firewall
and Policing Dierences Between PTX Series Packet Transport Routers and T Series Matrix
Routers" on page 1826.
SEE ALSO
Firewall Filter Nonterminang Acons | 873
Two-Color Policer Conguraon Overview | 2038
Muleld Classicaon Overview
Muleld Classicaon Limitaons on M Series Routers
Example: Conguring Muleld Classicaon
tri-color
Muleld Classicaon Limitaons on M Series Routers
IN THIS SECTION
Problem: Output-Filter Matching on Input-Filter Classicaon | 1313
Workaround: Congure All Acons in the Ingress Filter | 1314
1312
Problem: Output-Filter Matching on Input-Filter Classicaon
On M Series routers (except M120 routers), you cannot classify packets with an output lter match
based on the ingress classicaon that is set with an input lter applied to the same IPv4
logical
interface
.
For example, in the following conguraon, the lter called ingress assigns all incoming IPv4 packets to
the expedited-forwarding class. The lter called egress counts all packets that were assigned to the expedited-
forwarding class in the ingress lter. This conguraon does not work on most M Series routers. It works
on all other roung plaorms, including M120 routers, MX Series routers, and T Series routers.
[edit]
user@host # show firewall
family inet {
filter ingress {
term 1 {
then {
forwarding-class expedited-forwarding;
accept;
}
}
term 2 {
then accept;
}
}
filter egress {
term 1 {
from {
forwarding-class expedited-forwarding;
}
then count ef;
}
term 2 {
then accept;
}
}
}
[edit]
user@host# show interfaces
ge-1/2/0 {
unit 0 {
1313
family inet {
filter {
input ingress;
output egress;
}
}
}
}
Workaround: Congure All Acons in the Ingress Filter
As a workaround, you can congure all of the acons in the ingress lter.
user@host # show firewall
family inet {
filter ingress {
term 1 {
then {
forwarding-class expedited-forwarding;
accept;
count ef;
}
}
term 2 {
then accept;
}
}
}
[edit]
user@host# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
filter {
input ingress;
}
}
}
}
1314
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Muleld Classicaon Overview
Muleld Classicaon Requirements and Restricons
Example: Conguring Muleld Classicaon
Example: Conguring Muleld Classicaon
IN THIS SECTION
Requirements | 1315
Overview | 1316
Conguraon | 1317
Vericaon | 1323
This example shows how to congure muleld classicaon of IPv4 trac by using rewall lter
acons and two rewall lter policers.
Requirements
Before you begin, make sure that your environment supports the features shown in this example:
1. The loss-priority rewall lter acon must be supported on the router and congurable to all four
values.
a. To be able to set a loss-priority rewall lter acon, congure this example on logical interface
ge-1/2/0.0 on one of the following roung plaorms:
• MX Series router
• M120 or M320 router
• M7i or M10i router with the Enhanced CFEB (CFEB-E)
• T Series router with Enhanced II Flexible PIC Concentrator (FPC)
b.
To be able to set a loss-priority rewall lter acon to medium-low or medium-high, make sure that the
CoS tricolor marking feature is enabled. To enable the CoS tricolor marking feature, include the
tri-color statement at the [edit class-of-service] hierarchy level.
1315
2. The expedited-forwarding and assured-forwarding forwarding classes must be scheduled on the underlying
physical interface ge-1/2/0.
a. Make sure that the following forwarding classes are assigned to output queues:
• expedited-forwarding
• assured-forwarding
Forwarding-class assignments are congured at the [edit class-of-service forwarding-classes queue
queue-number
] hierarchy level.
NOTE: You cannot commit a conguraon that assigns the same forwarding class to two
dierent queues.
b. Make sure that the output queues to which the forwarding classes are assigned are associated
with schedulers. A scheduler denes the amount of interface bandwidth assigned to the queue,
the size of the memory buer allocated for storing packets, the priority of the queue, and the
random early detecon (RED) drop proles associated with the queue.
• You congure output queue schedulers at the [edit class-of-service schedulers] hierarchy level.
• You associate output queue schedulers with forwarding classes by means of a scheduler map
that you congure at the [edit class-of-service scheduler-maps
map-name
] hierarchy level.
c. Make sure that output-queue scheduling is applied to the physical interface ge-1/2/0.
You apply a scheduler map to a physical interface at the [edit class-of-service interfaces ge-1/2/0
scheduler-map
map-name
] hierarchy level.
Overview
IN THIS SECTION
Topology | 1317
In this example, you apply muleld classicaon to the input IPv4 trac at a logical interface by using
stateless rewall lter acons and two rewall lter policers that are referenced from the rewall lter.
Based on the source address eld, packets are either set to the low loss priority or else policed. Neither
of the policers discards nonconforming trac. Packets in nonconforming ows are marked for a specic
1316
forwarding class (expedited-forwarding or assured-forwarding), set to a specic loss priority, and then
transmied.
NOTE: Single-rate two-color policers always transmit packets in a conforming trac ow aer
implicitly seng a low loss priority.
Topology
In this example, you apply muleld classicaon to the IPv4 trac on logical interface ge-1/2/0.0. The
classicaon rules are specied in the IPv4 stateless rewall lter mfc-filter and two single-rate two-
color policers, ef-policer and af-policer.
The IPv4 standard stateless rewall lter mfc-filter denes three lter terms:
• isp1-customers—The rst lter term matches packets with the source address 10.1.1.0/24 or
10.1.2.0/24. Matched packets are assigned to the expedited-forwarding forwarding class and set to the
low loss priority.
• isp2-customers—The second lter term matches packets with the source address 10.1.3.0/24 or
10.1.4.0/24. Matched packets are passed to ef-policer, a policer that rate-limits trac to a bandwidth
limit of 300 Kbps with a burst-size limit of 50 KB. This policer species that packets in a
nonconforming ow are marked for the expedited-forwarding forwarding class and set to the high loss
priority.
• other-customers—The third and nal lter term passes all other packets to af-policer, a policer that rate-
limits trac to a bandwidth limit of 300 Kbps and a burst-size limit of 50 KB (the same trac limits
as dened by ef-policer). This policer species that packets in a nonconforming ow are marked for
the assured-forwarding forwarding class and set to the medium-high loss priority.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1318
Conguring Policers to Rate-Limit Expedited-Forwarding and Assured-Forwarding Trac | 1318
Conguring a Muleld Classicaon Filter That Also Applies Policing | 1320
Applying Muleld Classicaon Filtering and Policing to the Logical Interface | 1322
1317
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall policer ef-policer if-exceeding bandwidth-limit 300k
set firewall policer ef-policer if-exceeding burst-size-limit 50k
set firewall policer ef-policer then loss-priority high
set firewall policer ef-policer then forwarding-class expedited-forwarding
set firewall policer af-policer if-exceeding bandwidth-limit 300k
set firewall policer af-policer if-exceeding burst-size-limit 50k
set firewall policer af-policer then loss-priority high
set firewall policer af-policer then forwarding-class assured-forwarding
set firewall family inet filter mfc-filter term isp1-customers from source-address 10.1.1.0/24
set firewall family inet filter mfc-filter term isp1-customers from source-address 10.1.2.0/24
set firewall family inet filter mfc-filter term isp1-customers then loss-priority low
set firewall family inet filter mfc-filter term isp1-customers then forwarding-class expedited-
forwarding
set firewall family inet filter mfc-filter term isp2-customers from source-address 10.1.3.0/24
set firewall family inet filter mfc-filter term isp2-customers from source-address 10.1.4.0/24
set firewall family inet filter mfc-filter term isp2-customers then policer ef-policer
set firewall family inet filter mfc-filter term other-customers then policer af-policer
set interfaces ge-1/2/0 unit 0 family inet address 192.168.1.1/24
set interfaces ge-1/2/0 unit 0 family inet filter input mfc-filter
Conguring Policers to Rate-Limit Expedited-Forwarding and Assured-Forwarding Trac
Step-by-Step Procedure
To congure policers to rate-limit expedited-forwarding and assured-forwarding trac:
1. Dene trac limits for expedited-forwarding trac.
[edit]
user@host# edit firewall policer ef-policer
1318
[edit firewall policer ef-policer]
user@host# set if-exceeding bandwidth-limit 300k
user@host# set if-exceeding burst-size-limit 50k
user@host# set then loss-priority high
user@host# set then forwarding-class expedited-forwarding
2. Congure a policer for assured-forwarding trac.
[edit firewall policer ef-policer]
user@host# up
[edit firewall]
user@host# edit policer af-policer
[edit firewall policer af-policer]
user@host# set if-exceeding bandwidth-limit 300k
user@host# set if-exceeding burst-size-limit 50k
user@host# set then loss-priority high
user@host# set then forwarding-class assured-forwarding
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
policer af-policer {
if-exceeding {
bandwidth-limit 300k;
burst-size-limit 50k;
}
then {
loss-priority high;
forwarding-class assured-forwarding;
}
}
policer ef-policer {
if-exceeding {
1319
bandwidth-limit 300k;
burst-size-limit 50k;
}
then {
loss-priority high;
forwarding-class expedited-forwarding;
}
}
Conguring a Muleld Classicaon Filter That Also Applies Policing
Step-by-Step Procedure
To congure a muleld classicaon lter that addionally applies policing:
1. Enable conguraon of a rewall lter term for IPv4 trac.
[edit]
user@host# edit firewall family inet filter mfc-filter
2. Congure the rst term to match on source addresses and then classify the matched packets.
[edit firewall family inet filter mfc-filter]
user@host# set term isp1-customers from source-address 10.1.1.0/24
user@host# set term isp1-customers from source-address 10.1.2.0/24
user@host# set term isp1-customers then loss-priority low
user@host# set term isp1-customers then forwarding-class expedited-forwarding
3. Congure the second term to match on dierent source addresses and then police the matched
packets.
[edit firewall family inet filter mfc-filter]
user@host# set term isp2-customers from source-address 10.1.3.0/24
user@host# set term isp2-customers from source-address 10.1.4.0/24
user@host# set term isp2-customers then policer ef-policer
1320
4. Congure the third term to police all other packets to a dierent set of trac limits and acons.
[edit firewall family inet filter mfc-filter]
user@host# set term other-customers then policer af-policer
Results
Conrm the conguraon of the lter by entering the show firewall conguraon mode command. If the
command output does not display the intended conguraon, repeat the instrucons in this procedure
to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter mfc-filter {
term isp1-customers {
from {
source-address 10.1.1.0/24;
source-address 10.1.2.0/24;
}
then {
loss-priority low;
forwarding-class expedited-forwarding;
}
}
term isp2-customers {
from {
source-address 10.1.3.0/24;
source-address 10.1.4.0/24;
}
then {
policer ef-policer;
}
}
term other-customers {
then {
policer af-policer;
}
}
}
}
1321
policer af-policer {
if-exceeding {
bandwidth-limit 300k;
burst-size-limit 50k;
}
then discard;
}
policer ef-policer {
if-exceeding {
bandwidth-limit 200k;
burst-size-limit 50k;
}
then {
loss-priority high;
forwarding-class expedited-forwarding;
}
}
Applying Muleld Classicaon Filtering and Policing to the Logical Interface
Step-by-Step Procedure
To apply muleld classicaon ltering and policing to the logical interface:
1. Enable conguraon of IPv4 on the logical interface.
[edit]
user@host# edit interfaces ge-1/2/0 unit 0 family inet
2. Congure an IP address for the logical interface.
[edit interfaces ge-1/2/0 unit 0 family inet ]
user@host# set address 192.168.1.1/24
3. Apply the rewall lter to the logical interface input.
[edit interfaces ge-1/2/0 unit 0 family inet ]
user@host# set filter input mfc-filter
1322
NOTE: Because the policer is executed before the lter, if an input policer is also congured
on the logical interface, it cannot use the forwarding class and PLP of a muleld classier
associated with the interface.
Results
Conrm the conguraon of the interface by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
filter {
input mfc-filter;
}
address 192.168.1.1/24;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying the Number of Packets Processed by the Policer at the Logical Interface | 1324
Conrm that the conguraon is working properly.
1323
Displaying the Number of Packets Processed by the Policer at the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show firewall operaonal mode command for the lter you applied to the logical interface.
user@host> show firewall filter rate-limit-in
Filter: rate-limit-in
Policers:
Name Packets
ef-policer-isp2-customers 32863
af-policer-other-customers 3870
The command output lists the policers applied by the rewall lter rate-limit-in, and the number of
packets that matched the lter term.
NOTE: The packet count includes the number of out-of-specicaon (out-of-spec) packet
counts, not all packets policed by the policer.
The policer name is displayed concatenated with the name of the rewall lter term in which the policer
is referenced as an acon.
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Muleld Classicaon Overview
Muleld Classicaon Requirements and Restricons
Muleld Classicaon Limitaons on M Series Routers
tri-color
1324
Example: Conguring and Applying a Firewall Filter for a Muleld Classier
IN THIS SECTION
Requirements | 1325
Overview | 1325
Conguraon | 1327
Vericaon | 1331
This example shows how to congure a rewall lter to classify trac using a muleld classier. The
classier detects packets of interest to class of service (CoS) as they arrive on an interface. Muleld
classiers are used when a simple behavior aggregate (BA) classier is insucient to classify a packet,
when peering routers do not have CoS bits marked, or the peering router’s marking is untrusted.
Requirements
To verify this procedure, this example uses a trac generator. The trac generator can be hardware-
based or it can be soware running on a server or host machine.
The funconality in this procedure is widely supported on devices that run Junos OS. The example
shown here was tested and veried on MX Series routers running Junos OS Release 10.4.
Overview
IN THIS SECTION
Topology | 1326
A classier is a soware operaon that inspects a packet as it enters the router or switch. The packet
header contents are examined, and this examinaon determines how the packet is treated when the
network becomes too busy to handle all of the packets and you want your devices to drop packets
intelligently, instead of dropping packets indiscriminately. One common way to detect packets of
interest is by source port number. The TCP port numbers 80 and 12345 are used in this example, but
many other matching criteria for packet detecon are available to muleld classiers, using rewall
lter match condions. The conguraon in this example species that TCP packets with source port 80
1325
are classied into the BE-data forwarding class and queue number 0. TCP packets with source port
12345 are classied into the Premium-data forwarding class and queue number 1.
Muleld classiers are typically used at the network edge as packets enter an autonomous system (AS).
In this example, you congure the rewall lter mf-classier and specify some custom forwarding
classes on Device R1. In specifying the custom forwarding classes, you also associate each class with a
queue.
The classier operaon is shown in Figure 58 on page 1326.
Figure 58: Muleld Classier Based on TCP Source Ports
You apply the muleld classier’s rewall lter as an input lter on each customer-facing or host-facing
interface that needs the lter. The incoming interface is ge-1/0/1 on Device R1. The classicaon and
queue assignment is veried on the outgoing interface. The outgoing interface is Device R1’s ge-1/0/9
interface.
Topology
Figure 59 on page 1327 shows the sample network.
1326
Figure 59: Muleld Classier Scenario
"CLI Quick Conguraon" on page 1327 shows the conguraon for all of the Juniper Networks devices
in Figure 59 on page 1327.
"Step-by-Step Procedure" on page 1328 describes the steps on Device R1.
Classiers are described in more detail in the following Juniper Networks Learning Byte video.
Video: Class of Service Basics, Part 2: Classicaon Learning Byte
Conguraon
IN THIS SECTION
Procedure | 1327
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from the conguraon mode.
1327
Device R1
set interfaces ge-1/0/1 description to-host
set interfaces ge-1/0/1 unit 0 family inet filter input mf-classifier
set interfaces ge-1/0/1 unit 0 family inet address 172.16.50.2/30
set interfaces ge-1/0/9 description to-R2
set interfaces ge-1/0/9 unit 0 family inet address 10.30.0.1/30
set class-of-service forwarding-classes class BE-data queue-num 0
set class-of-service forwarding-classes class Premium-data queue-num 1
set class-of-service forwarding-classes class Voice queue-num 2
set class-of-service forwarding-classes class NC queue-num 3
set firewall family inet filter mf-classifier term BE-data from protocol tcp
set firewall family inet filter mf-classifier term BE-data from port 80
set firewall family inet filter mf-classifier term BE-data then forwarding-class BE-data
set firewall family inet filter mf-classifier term Premium-data from protocol tcp
set firewall family inet filter mf-classifier term Premium-data from port 12345
set firewall family inet filter mf-classifier term Premium-data then forwarding-class Premium-
data
set firewall family inet filter mf-classifier term accept-all-else then accept
Device R2
set interfaces ge-1/0/9 description to-R1
set interfaces ge-1/0/9 unit 0 family inet address 10.30.0.2/30
Step-by-Step Procedure
The following example requires that you navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R1:
1. Congure the device interfaces.
[edit interfaces]
user@R1# set ge-1/0/1 description to-host
user@R1# set ge-1/0/1 unit 0 family inet address 172.16.50.2/30
user@R1# set ge-1/0/9 description to-R2
user@R1# set ge-1/0/9 unit 0 family inet address 10.30.0.1/30
1328
2. Congure the custom forwarding classes and associated queue numbers.
[edit class-of-service forwarding-classes]
user@R1# set BE-data queue-num 0
user@R1# set Premium-data queue-num 1
user@R1# set Voice queue-num 2
user@R1# set NC queue-num 3
3. Congure the rewall lter term that places TCP trac with a source port of 80 (HTTP trac) into
the BE-data forwarding class, associated with queue 0.
[edit firewall family inet filter mf-classifier]
user@R1# set term BE-data from protocol tcp
user@R1# set term BE-data from port 80
user@R1# set term BE-data then forwarding-class BE-data
4. Congure the rewall lter term that places TCP trac with a source port of 12345 into the
Premium-data forwarding class, associated with queue 1.
[edit firewall family inet filter mf-classifier]
user@R1# set term Premium-data from protocol tcp
user@R1# set term Premium-data from port 12345
user@R1# set term Premium-data then forwarding-class Premium-data
5. At the end of your rewall lter, congure a default term that accepts all other trac.
Otherwise, all trac that arrives on the interface and is not explicitly accepted by the rewall lter is
discarded.
[edit firewall family inet filter mf-classifier]
user@R1# set term accept-all-else then accept
6. Apply the rewall lter to the ge-1/0/1 interface as an input lter.
[edit interfaces]
user@R1# set ge-1/0/1 unit 0 family inet filter input mf-classifier
1329
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show class-of-service,
show firewall commands. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
user@R1# show interfaces
ge-1/0/1 {
description to-host;
unit 0 {
family inet {
filter {
input mf-classifier;
}
address 172.16.50.2/30;
}
}
}
ge-1/0/9 {
description to-R2;
unit 0 {
family inet {
address 10.30.0.1/30;
}
}
}
user@R1# show class-of-service
forwarding-classes {
class BE-data queue-num 0;
class Premium-data queue-num 1;
class Voice queue-num 2;
class NC queue-num 3;
}
user@R1# show firewall
family inet {
filter mf-classifier {
term BE-data {
1330
from {
protocol tcp;
port 80;
}
then forwarding-class BE-data;
}
term Premium-data {
from {
protocol tcp;
port 12345;
}
then forwarding-class Premium-data;
}
term accept-all-else {
then accept;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Checking the CoS Sengs | 1331
Sending TCP Trac into the Network and Monitoring the Queue Placement | 1332
Conrm that the conguraon is working properly.
Checking the CoS Sengs
Purpose
Conrm that the forwarding classes are congured correctly.
1331
Acon
From Device R1, run the show class-of-service forwardng-classes command.
user@R1> show class-of-service forwarding-class
Forwarding class ID Queue Restricted queue Fabric priority
Policing priority SPU priority
BE-data 0 0 0 low
normal low
Premium-data 1 1 1 low
normal low
Voice 2 2 2 low
normal low
NC 3 3 3 low
normal low
Meaning
The output shows the congured custom classier sengs.
Sending TCP Trac into the Network and Monitoring the Queue Placement
Purpose
Make sure that the trac of interest is sent out the expected queue.
Acon
1. Clear the interface stascs on Device R1’s outgoing interface.
user@R1> clear interfaces statistics ge-1/0/9
2. Use a trac generator to send 50 TCP port 80 packets to Device R2 or to some other downstream
device.
3. On Device R1, check the queue counters.
1332
Noce that you check the queue counters on the downstream output interface, not on the incoming
interface.
user@R1> show interfaces extensive ge-1/0/9 | find "Queue counters"
Queue counters: Queued packets Transmitted packets Dropped packets
0 50 50 0
1 0 57 0
2 0 0 0
3 0 0 0
4. Use a trac generator to send 50 TCP port 12345 packets to Device R2 or to some other
downstream device.
[root@host]# hping 172.16.60.1 -c 50 -s 12345 -k
5. On Device R1, check the queue counters.
user@R1> show interfaces extensive ge-1/0/9 | find "Queue counters"
Queue counters: Queued packets Transmitted packets Dropped packets
0 50 50 0
1 50 57 0
2 0 0 0
3 0 0 0
Meaning
The output shows that the packets are classied correctly. When port 80 is used in the TCP packets,
queue 0 is incremented. When port 12345 is used, queue 1 is incremented.
SEE ALSO
Example: Conguring a Two-Rate Three-Color Policer | 2161
1333
RELATED DOCUMENTATION
Firewall Filter Nonterminang Acons | 873
Order of Policer and Firewall Filter Operaons | 1930
Two-Color Policer Conguraon Overview | 2038
Guidelines for Applying Trac Policers | 1938
The Junos OS CoS Components Used to Manage Congeson and Control Service Levels
Understanding How Behavior Aggregate Classiers Priorize Trusted Trac
Understanding How Forwarding Classes Assign Classes to Output Queues
Default Forwarding Classes
Managing Congeson Using RED Drop Proles and Packet Loss Priories
tri-color
Muleld Classier for Ingress Queuing on MX Series Routers with MPC
Beginning with Junos OS Release 16.1, the muleld classier for ingress queuing is an implementaon
point for rewall lters congured with specic trac shaping acons. These lters allow you to set the
forwarding class and packet loss priority for packets, or drop the packets prior to ingress queue
selecon. The lters are applied as ingress queue lters. Class-of-service (CoS) commands can then be
used to select ingress queue, set rate liming and so forth.
Firewall lters congured at the protocol family level are able to disnguish specic types of trac from
other types by matching on mulple elds within the packet header. The number and types of matches
available depend on which protocol family is used in the lter. Before the introducon of the ingress
queuing lter, these rewall lters could only be applied to trac aer the ingress queue had been
selected based solely on the behavior aggregate (BA). With the introducon of the ingress queuing lter,
rewall lters can be used to set forwarding classicaon and packet loss priority based on mulple
elds within the packet header prior to forwarding queue selecon. CoS funcons provide trac
classicaon opons and the ability to assign that classied trac to specic forwarding queues.
NOTE: Ingress queuing lters are only available when the trac manager mode is set to ingress-
and-egress at the [edit chassis fpc
fpc-id
pic
pic-id
traffic-manager mode] hierarchy level.
The ingress-queuing-filter conguraon statement is used at the [edit interfaces
interface-name
unit
unit-
number
family
family-name
] hierarchy level to designate a previously congured rewall lter to be used as
an ingress queuing lter. The following list shows which protocol families are compable with the
ingress-queuing-filter statement:
1334
• bridge
• ccc
• inet
• inet6
• mpls
• vpls
The named rewall lter is a normal rewall lter that must be congured with at least one of the
following acons: accept, discard, forwarding-class, and loss-priority.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release Descripon
16.1 Beginning with Junos OS Release 16.1, the muleld classier for ingress queuing is an implementaon
point for rewall lters congured with specic trac shaping acons.
RELATED DOCUMENTATION
Understanding How Behavior Aggregate Classiers Priorize Trusted Trac
ingress-queuing-lter
Example: Conguring a Filter for Use as an Ingress Queuing Filter | 1142
Assigning Muleld Classiers in Firewall Filters to Specify Packet-
Forwarding Behavior (CLI Procedure)
You can congure rewall lters with muleld classiers to classify packets transing a port, VLAN, or
Layer 3 interface on an EX Series switch.
You specify muleld classiers in a rewall lter conguraon to set the forwarding class and packet
loss priority (PLP) for incoming or outgoing packets. By default, the data trac that is not classied is
assigned to the best-eort class associated with queue 0.
You can specify any of the following default forwarding classes:
1335
Forwarding class Queue
best-eort 0
assured-forwarding 1
expedited-forwarding 5
network-control 7
To assign muleld classiers in rewall lters:
1. Congure the family name and lter name for the lter at the [edit firewall] hierarchy level, for
example:
[edit firewall]
user@switch# set family ethernet-switching
user@switch# set family ethernet-switching filter ingress-filter
2. Congure the terms of the lter, including the forwarding-class and loss-priority acon modiers as
appropriate. When you specify a forwarding class you must also specify the packet loss priority. For
example, each of the following terms examines dierent packet header elds and assigns an
appropriate classier and the packet loss priority:
• The term voice-trac matches packets on the voice-vlan and assigns the forwarding class
expedited-forwarding and packet loss priority low:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term voice-traffic from vlan-id voice-vlan
user@switch# set term voice-traffic then forwarding-class expedited-forwarding
user@switch# set term voice-traffic then loss-priority low
• The term data-trac matches packets on employee-vlan and assigns the forwarding class
assured-forwarding and packet loss priority low:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term data-traffic from vlan-id employee-vlan
1336
user@switch# set term data-traffic then forwarding-class assured-forwarding
user@switch# set term data-traffic then loss-priority low
• Because loss of network-generated packets can jeopardize proper network operaon, delay is
preferable to discard of packets. The following term, network-trac, assigns the forwarding class
network-control and packet loss priority low:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term network-traffic from precedence net-control
user@switch# set term network-traffic then forwarding-class network
user@switch# set term network-traffic then loss-priority low
• The last term accept-trac matches any packets that did not match on any of the preceding
terms and assigns the forwarding class best-eort and packet loss priority low:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term accept-traffic from precedence net-control
user@switch# set term accept-traffic then forwarding-class best-effort
user@switch# set term accept-traffic then loss-priority low
3. Apply the lter ingress-lter to a port, VLAN or Layer 3 interface. For informaon about applying the
lter, see "Conguring Firewall Filters (CLI Procedure)" on page 1642.
RELATED DOCUMENTATION
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Verifying That Firewall Filters Are Operaonal | 1869
Monitoring Firewall Filter Trac | 1870
Dening CoS Classiers (CLI Procedure)
Dening CoS Classiers (J-Web Procedure)
Conguring Firewall Filters (CLI Procedure) | 1642
1337
Understanding Mulple Firewall Filters in a Nested Conguraon
IN THIS SECTION
The Challenge: Simplify Large-Scale Firewall Filter Administraon | 1338
A Soluon: Congure Nested References to Firewall Filters | 1338
Conguraon of Nested Firewall Filters | 1339
Applicaon of Nested Firewall Filters to a Router or Switch Interface | 1339
The Challenge: Simplify Large-Scale Firewall Filter Administraon
Typically, you apply a single
rewall lter
to an interface in the input or output direcon or both. This
approach might not be praccal, however, when you have a router (or switch) congured with many,
even hundreds of interfaces. In an environment of this scale, you want the exibility of being able to
modify ltering terms common to mulple interfaces without having to recongure the lter of every
aected interface.
In general, the soluon is to apply an eecvely “chained” structure of mulple stateless rewall lters
to a single interface. You paron your ltering terms into mulple rewall lters congured so that you
can apply a unique lter to each router (or switch) interface but also apply common lters to mulple
router (or switch) interfaces as required. The Junos OS policy framework provides two opons for
managing the applicaon of mulple separate rewall lters to individual router (or switch) interfaces.
One opon is to apply mulple lters as a single input list or output list. The other opon is to reference
a stateless rewall lter from within the term of another stateless rewall lter.
A Soluon: Congure Nested References to Firewall Filters
The most structured way to avoid conguring duplicate ltering terms common to mulple rewall
lters is to congure mulple rewall lters so that each lter includes the shared ltering terms by
referencing
a separate lter that contains the common ltering terms. The Junos OS uses the lter terms
—in the order in which they appear in the lter denion—to evaluate packets that transit the interface.
If you need to modify ltering terms shared across mulple interfaces, you only need to modify one
rewall lter.
NOTE: Similar to the alternave approach (applying a list of rewall lters), conguring a nested
rewall lter combines mulple rewall lters into a new rewall lter denion.
1338
Conguraon of Nested Firewall Filters
Conguring a nested rewall lter for each router (or switch) interface involves separang shared
packet-ltering rules from interface-specic packet-ltering rules as follows:
• For each set of packet-ltering rules common across mulple interfaces, congure a separate rewall
lter that contains the shared ltering terms.
• For each router (or switch) interface, congure a separate rewall lter that contains:
• All the ltering terms unique to that interface.
• An addional ltering term that includes a filter reference to the rewall lter that contains the
common ltering terms.
Applicaon of Nested Firewall Filters to a Router or Switch Interface
Applying nested rewall lters is no dierent from applying an unnested rewall lter. For each
interface, you can include an input or output statement (or both) within the filter stanza to specify the
appropriate nested rewall lter.
Applying nested rewall lters to an interface, the shared ltering terms and the interface-specic
rewall lters are applied through
a single nested rewall lter
that includes other lters through the
filter statement within a separate ltering term.
NOTE: Commit check and commit do not fail for unsupported nested lters. Unsupported nested
lters are the lter combinaons which are are not menoned in vty command show jexpr dfw
filter-types.
RELATED DOCUMENTATION
Guidelines for Nesng References to Mulple Firewall Filters | 1340
Example: Nesng References to Mulple Firewall Filters | 1356
1339
Guidelines for Nesng References to Mulple Firewall Filters
IN THIS SECTION
Statement Hierarchy for Conguring Nested Firewall Filters | 1340
Filter-Dening Terms and Filter-Referencing Terms | 1340
Types of Filters Supported in Nested Conguraons | 1341
Number of Filter References in a Single Filter | 1341
Depth of Filter Nesng | 1341
Statement Hierarchy for Conguring Nested Firewall Filters
To reference a lter from within a lter, include the filter
filter-name
statement as a separate lter term:
firewall
firewall-name
{
family
family-name
{
filter
filter-name
{
term
term-name
{
filter
filter-name
;
}
}
}
}
You can include the rewall conguraon at one of the following hierarchy levels:
• [edit]
• [edit logical-systems
logical-system-name
]
Filter-Dening Terms and Filter-Referencing Terms
You cannot congure a
rewall lter
term that both references another rewall lter and denes a
match condion or acon. If a rewall lter term includes the filter statement, then it cannot also
include the from or then statement.
1340
For example, the rewall lter term term term1 in the conguraon is
not
valid:
[edit]
firewall {
family inet {
filter filter_1 {
term term1 {
filter filter_2;
from {
source-address 172.16.1.1/32;
}
then {
accept;
}
}
}
}
}
In order for term term1 to be a valid lter term, you must either remove the filter filter_2 statement or
remove both the from and then stanzas.
Types of Filters Supported in Nested Conguraons
Nested conguraons of rewall lters support rewall lters only. You cannot use service lters or
simple lters in a nested rewall lter conguraon.
Number of Filter References in a Single Filter
The total number of lters referenced from within a lter cannot exceed 256.
Depth of Filter Nesng
The Junos OS supports a single level of rewall lter nesng. If filter_1 references filter_2, you cannot
congure a lter that references a lter that references filter_1.
RELATED DOCUMENTATION
Understanding Mulple Firewall Filters in a Nested Conguraon | 1338
Example: Nesng References to Mulple Firewall Filters | 1356
1341
Understanding Mulple Firewall Filters Applied as a List
IN THIS SECTION
The Challenge: Simplify Large-Scale Firewall Filter Administraon | 1342
A Soluon: Apply Lists of Firewall Filters | 1343
Conguraon of Mulple Filters for Filter Lists | 1343
Applicaon of Filter Lists to a Router Interface | 1343
Interface-Specic Names for Filter Lists | 1343
How Filter Lists Evaluate Packets When the Matched Term Includes Terminang or Next Term
Acons | 1344
How Filter Lists Evaluate Packets When the List Includes Protocol-Independent and IP Firewall
Filters | 1346
This topic covers the following informaon:
The Challenge: Simplify Large-Scale Firewall Filter Administraon
Typically, you apply a single
rewall lter
to an interface in the input or output direcon or both.
However, this approach might not be praccal when you have a device congured with many interfaces.
In large environments, you want the exibility of being able to modify ltering terms common to
mulple interfaces without having to recongure the lter of every aected interface.
In general, the soluon is to apply an eecvely “chained” structure of mulple rewall lters to a single
interface. You paron your ltering terms into mulple rewall lters that each perform a ltering task.
You can then choose which ltering tasks you want to perform for a given interface and apply the
ltering tasks to that interface. In this way, you only manage the conguraon for a ltering task in a
single rewall lter. If you need to modify ltering terms shared across mulple interfaces, you only
need to modify one rewall lter that contains those terms.
The Junos OS policy framework provides two opons for managing the applicaon of mulple separate
rewall lters to individual router interfaces. One opon is to apply mulple lters as a single input list
or output list. The other opon is to reference a rewall lter from within the term of another rewall
lter. This opon is not supported on the PTX10003 router.
1342
A Soluon: Apply Lists of Firewall Filters
The most straighorward way to avoid conguring duplicate ltering terms common to mulple rewall
lters is to congure mulple rewall lters and then apply a customized
list
of lters to each interface.
The Junos OS uses the lters—in the order in which they appear in the list—to evaluate packets that
transit the interface.
Conguraon of Mulple Filters for Filter Lists
Conguring rewall lters to be applied in unique lists for each router interface involves separang
shared packet-ltering rules from interface-specic packet-ltering rules as follows:
• Unique lters—For each set of packet-ltering rules unique to a specic interface, congure a
separate rewall lter that contains only the ltering terms for that interface.
• Shared lters—For each set of packet-ltering rules common across two or more interfaces, consider
conguring a separate rewall lter that contains the shared ltering terms.
TIP: When planning for a large number rewall lters to be applied using lter lists,
administrators oen organize the shared lters by ltering criteria, by the services to which
customers subscribe, or by the purposes of the interfaces.
Applicaon of Filter Lists to a Router Interface
Applying a list of rewall lters to an interface is a maer of selecng the lters that meet the packet-
ltering requirements of that interface. For each interface, you can include an input-list or output-list
statement (or both) within the filter stanza to specify the relevant lters in the order in which they are
to be used:
• Include any lters that contain common ltering terms relevant to the interface.
• Include the lter that contain only the ltering terms unique to the interface.
Interface-Specic Names for Filter Lists
Because a lter list is congured under an interface, the resulng concatenated lter is
interface-
specic
.
NOTE: When a lter list is congured under an interface, the resulng concatenated lter is
interface-specic, regardless whether the rewall lters in the lter list are congured as
1343
interface-specic or not. Furthermore, the instanaon of interface-specc rewall lters not
only creates separate instances of any rewall lter counters, but also separate instances of any
policer acons. Any policers applied through an acon specied in the rewall lter conguraon
are applied separately to each interface in the interface group.
The system-generated name of an interface-specic lter consists of the full interface name followed by
either ’-i’ for an input lter list or ’-o’ for an output lter list.
• Input lter list name—For example, if you use the input-list statement to apply a chain of lters to
logical interface
ge-1/3/0.0, the Junos OS uses the following name for the lter:
ge-1/3/0.0-inet-i
• Output lter list name—For example, if you use the output-list statement to apply a chain of lters to
logical interface fe-0/1/2.0, the Junos OS uses the following name for the lter:
fe-0/1/2.0-inet-o
NOTE: For Junos OS Evolved, the lter names are similar to Junos OS. For example, if the lters
are bound to the inet family, the lters are named ge-1/3/0/0-inet-i and fe-0/1/2.0-inet-o.
You can use the interface-specic name of a lter list when you enter a Junos OS
operaonal mode
command
that species a rewall lter name.
How Filter Lists Evaluate Packets When the Matched Term Includes Terminang or
Next Term Acons
The device evaluates a packet against the lters in a list sequenally, beginning with the rst lter in the
list unl either a terminang acon occurs or the packet is implicitly discarded.
Table 66 on page 1345 describes how a rewall lter list evaluates a packet based on whether the
matched term species a terminang acon and the next term acon. The next term acon is neither a
terminang acon nor a nonterminang acon but a
ow control
acon.
1344
Table 66: Firewall Filter List Behavior
Firewall Filter Acons Include
d in the Matched Term
Term Descripon Packet-Filtering Behavior
Terminang next term
Yes —
The matched term includes a
terminang acon (such as
discard) but not the next term
acon
The device executes the terminang acon. No
subsequent terms in the lter and no
subsequent lters in the list are used to
evaluate the packet.
— Yes The matched term includes
the next term acon, but it
does not include any
terminang acons.
The device executes any nonterminang
acons, then the device evaluates the packet
against the next term in the lter or the next
lter in the list.
NOTE: On Junos OS Evolved, next term cannot
appear as the last term of the acon. A lter
term where next term is specied as an acon
but without any match condions congured is
not supported.
— — The matched term includes
neither the next term acon
nor any terminang acons.
The device executes any nonterminang
acons, then the device implicitly accepts the
packet. Because the accept acon is a
terminang acon, no subsequent terms in the
lter and no subsequent lters in the list are
used to evaluate the packet.
For informaon about terminang acons, see "Firewall Filter Terminang Acons" on page 886.
NOTE: You cannot congure the next term acon with a terminang acon in the same rewall
lter term.
1345
How Filter Lists Evaluate Packets When the List Includes Protocol-Independent and
IP Firewall Filters
On a single interface associated with a protocol-independent (family any) rewall lter and a protocol-
specic (family inet or family inet6) rewall lter simultaneously, the protocol-independent rewall lter
executes rst.
The terminang acon of the rst lter determines whether the second lter also evaluates the packet:
• If the rst lter terminates by execung the accept acon, the second lter doesn't evaluate the
packet.
• If the rst lter terminates without any terms matching the packet (an
implicit
discard acon), the
second lter also evaluates the packet.
• If the rst lter terminates by execung an
explicit
discard acon, the second lter does not evaluate
the packet.
The PTX10003 router does not support a combinaon of protocol-independent and other lters in
lter-lists.
RELATED DOCUMENTATION
How Standard Firewall Filters Evaluate Packets | 795
Guidelines for Applying Mulple Firewall Filters as a List | 1346
Example: Applying Lists of Mulple Firewall Filters | 1348
Guidelines for Applying Mulple Firewall Filters as a List
IN THIS SECTION
Statement Hierarchy for Applying Lists of Mulple Firewall Filters | 1347
Filter Input Lists and Output Lists for Router or Switch Interfaces | 1347
Types of Filters Supported in Lists | 1348
Restricons on Applying Filter Lists for MPLS or Layer 2 CCC Trac | 1348
1346
Statement Hierarchy for Applying Lists of Mulple Firewall Filters
To apply a single lter to the input or output direcon of a router (or switch)
logical interface
, you
include the input
filter-name
or output
filter-name
statement under the filter stanza for a protocol family.
To apply a list of mulple lters to the input or output direcon of a router (or switch) logical interface,
include the input-list [
filter-names
] or output-list [
filter-names
] statement under the filter stanza for
a protocol family:
interfaces {
interface-name
{
unit
logical-unit-number
{
family
family-name
{
filter {
...
filter-options
...
input-list [
filter-names
];
output-list [
filter-names
];
}
}
}
}
}
You can include the interface conguraon at one of the following hierarchy levels:
• [edit]
• [edit logical-systems
logical-system-name
]
NOTE: (PTX10003) The router does not support output-list lter binding on the loopback
address (lo0) or management interface.
Filter Input Lists and Output Lists for Router or Switch Interfaces
When applying a list of rewall lters as a list, the following limitaons apply:
• You can specify up to 16 rewall lters for a lter input list.
• You can specify up to 16 rewall lters for a lter output list.
1347
Types of Filters Supported in Lists
Lists of mulple rewall lters applied to a router (or switch) interface support standard stateless rewall
lters only. You cannot apply lists containing service lters or simple lters to a router (or switch)
interface.
Restricons on Applying Filter Lists for MPLS or Layer 2 CCC Trac
NOTE: These restricons do not apply to the PTX10003 router. The router only supports
applying lter lists on IPv4 (inet) or IPv6 (inet6) trac.
When applying rewall lters that evaluate MPLS trac (family mpls) or Layer 2 circuit cross-connecon
trac (family ccc), you can use the input-list [
filter-names
] and output-list [
filter-names
] statements
for all interfaces except the following:
• Management and internal Ethernet (fxp) interfaces
• Loopback (lo0) interfaces
• USB modem (umd) interfaces
RELATED DOCUMENTATION
Understanding Mulple Firewall Filters Applied as a List | 1342
Example: Applying Lists of Mulple Firewall Filters | 1348
Example: Applying Lists of Mulple Firewall Filters
IN THIS SECTION
Requirements | 1349
Overview | 1349
Conguraon | 1350
Vericaon | 1355
1348
This example shows how to apply lists of mulple rewall lters.
Requirements
Before you begin, be sure that you have:
• Installed your router or switch, and supported PIC, DPC, or MPC and performed the inial router or
switch conguraon.
• Congured basic Ethernet in the topology.
• Congured a logical interface to run the IP version 4 (IPv4) protocol (family inet) and congured the
logical interface with an interface address. This example uses logical interface ge-1/3/0.0 congured
with the IP address 172.16.1.2/30.
NOTE: For completeness, the conguraon secon of this example includes seng an IP
address for logical interface ge-1/3/0.0.
• Veried that trac is owing in the topology and that ingress and egress IPv4 trac is owing
through logical interface ge-1/3/0.0.
• Veried that you have access to the remote host that is connected to this router’s or switch’s logical
interface ge-1/3/0.0.
NOTE: Physical interface policers/lters are not supported for list lters.
Overview
IN THIS SECTION
Topology | 1350
In this example, you congure three IPv4 rewall lters and apply each lter directly to the same logical
interface by using a list.
1349
Topology
This example applies the following rewall lters as a
list of input lters
at logical interface ge-1/3/0.0.
Each lter contains a single term that evaluates IPv4 packets and accepts packets based on the value of
the destination port eld in the TCP header:
• Filter filter_FTP matches on the FTP port number (21).
• Filter filter_SSH matches on the SSH port number (22).
• Filter filter_Telnet matches on the Telnet port number (23).
If an inbound packet does not match any of the lters in the input list, the packet is discarded.
NOTE: The Junos OS uses lters in a list in the order in which the lter names appear in the list.
In this simple example, the order is irrelevant because all of the lters specify the same acon.
Any of the lters can be applied to other interfaces, either alone (using the input or output statement) or
in combinaon with other lters (using the input-list or output-list statement). The objecve is to
congure mulple “minimalist” rewall lters that you can reuse in interface-specic lter lists.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1351
Congure Mulple IPv4 Firewall Filters | 1351
Apply the Filters to a Logical Interface as an Input List and an Output List | 1352
Conrm and Commit Your Candidate Conguraon | 1353
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
1350
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter filter_FTP term 0 from protocol tcp
set firewall family inet filter filter_FTP term 0 from destination-port 21
set firewall family inet filter filter_FTP term 0 then count pkts_FTP
set firewall family inet filter filter_FTP term 0 then accept
set firewall family inet filter filter_SSH term 0 from protocol tcp
set firewall family inet filter filter_SSH term 0 from destination-port 22
set firewall family inet filter filter_SSH term 0 then count pkts_SSH
set firewall family inet filter filter_SSH term 0 then accept
set firewall family inet filter filter_Telnet term 0 from protocol tcp
set firewall family inet filter filter_Telnet term 0 from destination-port 23
set firewall family inet filter filter_Telnet term 0 then count pkts_Telnet
set firewall family inet filter filter_Telnet term 0 then accept
set firewall family inet filter filter_discard term 1 then count pkts_discarded
set firewall family inet filter filter_discard term 1 then discard
set interfaces ge-1/3/0 unit 0 family inet address 172.16.1.2/30
set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_FTP
set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_SSH
set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_Telnet
set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_discard
Congure Mulple IPv4 Firewall Filters
Step-by-Step Procedure
To congure the IPv4 rewall lters:
1. Navigate the CLI to the hierarchy level at which you congure IPv4 rewall lters.
[edit]
user@host# edit firewall family inet
2. Congure the rst rewall lter to count and accept packets for port 21.
[edit firewall family inet]
user@host# set filter filter_FTP term 0 from protocol tcp
1351
user@host# set filter filter_FTP term 0 from destination-port 21
user@host# set filter filter_FTP term 0 then count pkts_FTP
user@host# set filter filter_FTP term 0 then accept
3. Congure the second rewall lter to count and accept packets for port 22.
[edit firewall family inet]
user@host# set filter filter_SSH term 0 from protocol tcp
user@host# set filter filter_SSH term 0 from destination-port 22
user@host# set filter filter_SSH term 0 then count pkt_SSH
user@host# set filter filter_SSH term 0 then accept
4. Congure the third rewall lter to count and accept packets from port 23.
[edit firewall family inet]
user@host# set filter filter_Telnet term 0 from protocol tcp
user@host# set filter filter_Telnet term 0 from destination-port 23
user@host# set filter filter_Telnet term 0 then count pkts_Telnet
user@host# set filter filter_Telnet term 0 then accept
5. Congure the last rewall lter to count the discarded packets.
[edit firewall family inet]
user@host# set filter filter_discard term 1 then count pkts_discarded
user@host# set filter filter_discard term 1 then discard
Apply the Filters to a Logical Interface as an Input List and an Output List
Step-by-Step Procedure
To apply the six IPv4 rewall lters as a list of input lters and a list of output lters:
1. Navigate the CLI to the hierarchy level at which you apply IPv4 rewall lters to logical interface
ge-1/3/0.0.
[edit]
user@host# edit interfaces ge-1/3/0 unit 0 family inet
1352
2. Congure the IPv4 protocol family for the logical interface.
[edit interfaces ge-1/3/0 unit 0 family inet]
user@host# set address 172.16.1.2/30
3. Apply the lters as a list of input lters.
[edit interfaces ge-1/3/0 unit 0 family inet]
user@host# set filter input-list [ filter_FTP filter_SSH filter_Telnet filter_discard ]
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the rewall lters by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter filter_FTP {
term 0 {
from {
protocol tcp;
destination-port 21;
}
then {
count pkts_FTP;
accept;
}
}
}
filter filter_SSH {
term 0 {
from {
protocol tcp;
destination-port 22;
1353
}
then {
count pkts_SSH;
accept;
}
}
}
filter filter_Telnet {
term 0 {
from {
protocol tcp;
destination-port 23;
}
then {
count pkts_Telnet;
accept;
}
}
}
filter filter_discard {
term 1 {
then {
count pkts_discarded;
discard;
}
}
}
}
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/0 {
unit 0 {
family inet {
filter {
input-list [ filter_FTP filter_SSH filter_Telnet filter_discard ];
}
address 172.16.1.2/30;
1354
}
}
}
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
IN THIS SECTION
Verifying That Inbound Packets Are Accepted Only If Desned for the FTP, SSH or Telnet Port | 1355
Conrm that the conguraon is working properly.
Verifying That Inbound Packets Are Accepted Only If Desned for the FTP, SSH or Telnet Port
Purpose
Verify that all three lters are acve for the logical interface.
Acon
To verify that input packets are accepted according to the three lters:
1. From the remote host that is connected to this router’s (or switch’s) logical interface ge-1/3/0.0, send a
packet with desnaon port number 21 in the header. The packet should be accepted.
2. From the remote host that is connected to this router’s (or switch’s) logical interface ge-1/3/0.0, send a
packet with desnaon port number 22 in the header. The packet should be accepted.
3.
From the remote host that is connected to this router’s (or switch’s) logical interface ge-1/3/0.0, send a
packet with desnaon port number 23 in the header. The packet should be accepted.
4. From the remote host that is connected to this router’s (or switch’s) logical interface ge-1/3/0.0, send a
packet with a desnaon port number
other than
21, 22, or 23. The packet should be discarded.
1355
5. To display counter informaon for the list of lters applied to the input at ge-1/3/0.0 enter the show
firewall filter ge-1/3/0.0-inet-i operaonal mode command. The command output displays the
number of bytes and packets that match lter terms associated with the following counters:
• pkts_FTP-ge-1/3/0.0-inet-i
• pkts_SSH-ge-1/3/0.0-inet-i
• pkts_Telnet-ge-1/3/0.0-inet-i
• pkts_discard-ge-1/3/0.0-inet-i
RELATED DOCUMENTATION
Understanding Mulple Firewall Filters Applied as a List | 1342
Guidelines for Applying Mulple Firewall Filters as a List | 1346
Example: Nesng References to Mulple Firewall Filters
IN THIS SECTION
Requirements | 1356
Overview | 1357
Conguraon | 1357
Vericaon | 1361
This example shows how to congure nested references to mulple rewall lters.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
1356
Overview
IN THIS SECTION
Topology | 1357
In this example, you congure a rewall lter for a match condion and acon combinaon that can be
shared among mulple rewall lters. You then congure two rewall lters that reference the rst
rewall lter. Later, if the common ltering criteria needs to be changed, you would modify only the one
shared rewall lter conguraon.
Topology
The common_filter rewall lter discards packets that have a UDP source or desnaon port eld number
of 69. Both of the two addional rewall lters, filter1 and filter2, reference the common_filter.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1357
Congure the Nested Firewall Filters | 1358
Apply Both Nested Firewall Filters to Interfaces | 1359
Conrm and Commit Your Candidate Conguraon | 1359
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter common_filter term common_term from protocol udp
set firewall family inet filter common_filter term common_term from port tftp
1357
set firewall family inet filter common_filter term common_term then discard
set firewall family inet filter filter1 term term1 filter common_filter
set firewall family inet filter filter1 term term2 from address 192.168.0.0/16
set firewall family inet filter filter1 term term2 then reject
set firewall family inet filter filter2 term term1 filter common_filter
set firewall family inet filter filter2 term term2 from protocol udp
set firewall family inet filter filter2 term term2 from port bootps
set firewall family inet filter filter2 term term2 then accept
set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24
set interfaces ge-0/0/0 unit 0 family inet filter input filter1
set interfaces ge-0/0/3 unit 0 family inet address 10.1.3.1/24
set interfaces ge-0/0/3 unit 0 family inet filter input filter2
Congure the Nested Firewall Filters
Step-by-Step Procedure
To congure two nested rewall lters that share a common lter:
1. Navigate the CLI to the hierarchy level at which you congure IPv4 rewall lters.
[edit]
user@host# edit firewall family inet
2. Congure the common lter that will be referenced by mulple other lters.
[edit firewall family inet]
user@host# set filter common_filter term common_term from protocol udp
user@host# set filter common_filter term common_term from port tftp
user@host# set filter common_filter term common_term then discard
3. Congure a lter that references the common lter.
[edit firewall family inet]
user@host# set filter filter1 term term1 filter common_filter
user@host# set filter filter1 term term2 from address 192.168.0.0/16
user@host# set filter filter1 term term2 then reject
1358
4. Congure a second lter that references the common lter.
[edit firewall family inet]
user@host# set filter filter2 term term1 filter common_filter
user@host# set filter filter2 term term2 from protocol udp
user@host# set filter filter2 term term2 from port bootps
user@host# set filter filter2 term term2 then accept
Apply Both Nested Firewall Filters to Interfaces
Step-by-Step Procedure
To apply both nested rewall lters to logical interfaces:
1. Apply the rst nested lter to a logical interface input.
[edit]
user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24
user@host# set interfaces ge-0/0/0 unit 0 family inet filter input filter1
2. Apply the second nested lter to a logical interface input.
[edit]
user@host# set interfaces ge-0/0/3 unit 0 family inet address 10.1.3.1/24
user@host# set interfaces ge-0/0/3 unit 0 family inet filter input filter2
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
1359
filter common_filter {
term common_term {
from {
protocol udp;
port tftp;
}
then {
discard;
}
}
}
filter filter1 {
term term1 {
filter common_filter;
}
term term2 {
from {
address 192.168/16;
}
then {
reject;
}
}
}
filter filter2 {
term term1 {
filter common_filter;
}
term term2 {
from {
protocol udp;
port bootps;
}
then {
accept;
}
}
}
}
1360
2. Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
filter {
input filter1;
}
address 10.1.0.1/24;
}
}
}
ge-0/0/3 {
unit 0 {
family inet {
filter {
input filter2;
}
address 10.1.3.1/24;
}
}
}
3. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show firewall filter filter1 and show
firewall filter filter2 operaonal mode commands.
RELATED DOCUMENTATION
Understanding Mulple Firewall Filters in a Nested Conguraon | 1338
1361
Guidelines for Nesng References to Mulple Firewall Filters | 1340
Example: Filtering Packets Received on an Interface Set
IN THIS SECTION
Requirements | 1362
Overview | 1362
Conguraon | 1363
Vericaon | 1371
This example shows how to congure a standard stateless rewall lter to match packets tagged for a
parcular interface set.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 1362
In this example, you apply a stateless rewall lter to the input of the router or switch loopback
interface. The rewall lter includes a term that matches packets tagged for a parcular interface set.
Topology
You create the rewall lter L2_filter to apply rate limits to the protocol-independent trac received on
the following interfaces:
•
fe-0/0/0.0
1362
• fe-1/0/0.0
• fe-1/1/0.0
NOTE: The interface type in this topic is just an example. The fe- interface type is not supported
by EX Series switches.
First, for protocol-independent trac received on fe-0/0/0.0, the rewall lter term t1 applies policer p1.
For protocol-independent trac received on any other Fast Ethernet interfaces, rewall lter term t2
applies policer p2. To dene an interface set that consists of all Fast Ethernet interfaces, you include the
interface-set
interface-set-name
interface-name
statement at the [edit firewall] hierarchy level. To dene a
packet-matching criteria based on the interface on which a packet arrives to a specied interface set,
you congure a term that uses the interface-set rewall lter match condion.
Finally, for any other protocol-independent trac, rewall lter term t3 applies policer p3.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1364
Conguring the Interfaces for Which the Stateless Firewall Filter Terms Take Rate-Liming
Acons | 1364
Conguring the Stateless Firewall Filter That Rate-Limits Protocol-Independent Trac Based on the
Interfaces on Which Packets Arrive | 1366
Applying the Stateless Firewall Filter to the Roung Engine Input Interface | 1369
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
1363
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces fe-0/0/0 unit 0 family inet address 10.1.1.1/30
set interfaces fe-1/0/0 unit 0 family inet address 10.2.2.1/30
set interfaces fe-1/1/0 unit 0 family inet address 10.4.4.1/30
set firewall policer p1 if-exceeding bandwidth-limit 5m
set firewall policer p1 if-exceeding burst-size-limit 10m
set firewall policer p1 then discard
set firewall policer p2 if-exceeding bandwidth-limit 40m
set firewall policer p2 if-exceeding burst-size-limit 100m
set firewall policer p2 then discard
set firewall policer p3 if-exceeding bandwidth-limit 600m
set firewall policer p3 if-exceeding burst-size-limit 1g
set firewall policer p3 then discard
set firewall interface-set ifset fe-*
set firewall family any filter L2_filter term t1 from interface fe-0/0/0.0
set firewall family any filter L2_filter term t1 then count c1
set firewall family any filter L2_filter term t1 then policer p1
set firewall family any filter L2_filter term t2 from interface-set ifset
set firewall family any filter L2_filter term t2 then count c2
set firewall family any filter L2_filter term t2 then policer p2
set firewall family any filter L2_filter term t3 then count c3
set firewall family any filter L2_filter term t3 then policer p3
set interfaces lo0 unit 0 family inet address 172.16.1.157/30
set interfaces lo0 unit 0 family inet address 172.16.1.157/30
set interfaces lo0 unit 0 filter input L2_filter
Conguring the Interfaces for Which the Stateless Firewall Filter Terms Take Rate-Liming Acons
Step-by-Step Procedure
To congure the interfaces for which the stateless rewall lter terms take rate-liming acons:
1364
1. Congure the logical interface whose input trac will be matched by the rst term of the rewall
lter.
[edit]
user@host# set interfaces fe-0/0/0 unit 0 family inet address 10.1.1.1/30
2. Congure the logical interfaces whose input trac will be matched by the second term of the rewall
lter.
[edit ]
user@host# set interfaces fe-1/0/0 unit 0 family inet address 10.2.2.1/30
user@host# set interfaces fe-1/1/0 unit 0 family inet address 10.4.4.1/30
3. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Results
Conrm the conguraon of the router (or switch) transit interfaces by entering the show interfaces
conguraon mode command. If the command output does not display the intended conguraon,
repeat the instrucons in this procedure to correct the conguraon.
[edit]
user@host# show interfaces
fe-0/0/0 {
unit 0 {
family inet {
address 10.1.1.1/30;
}
}
}
fe-1/0/0 {
unit 0 {
family inet {
address 10.2.2.1/30;
}
}
1365
}
fe-1/1/0 {
unit 0 {
family inet {
address 10.4.4.1/30;
}
}
}
Conguring the Stateless Firewall Filter That Rate-Limits Protocol-Independent Trac Based on the
Interfaces on Which Packets Arrive
Step-by-Step Procedure
To congure the standard stateless rewall L2_filter that uses policers (p1, p2, and p3) to rate-limit
protocol-independent trac based on the interfaces on which the packets arrive:
1. Congure the rewall statements.
[edit]
user@host# edit firewall
2. Congure the policer p1 to discard trac that exceeds a trac rate of 5m bps or a burst size of
10m bytes.
[edit firewall]
user@host# set policer p1 if-exceeding bandwidth-limit 5m
user@host# set policer p1 if-exceeding burst-size-limit 10m
user@host# set policer p1 then discard
3. Congure the policer p2 to discard trac that exceeds a trac rate of 40m bps or a burst size of
100m bytes .
[edit firewall]
user@host# set policer p2 if-exceeding bandwidth-limit 40m
user@host# set policer p2 if-exceeding burst-size-limit 100m
user@host# set policer p2 then discard
1366
4. Congure the policer p3 to discard trac that exceeds a trac rate of 600m bps or a burst size of
1g bytes.
[edit firewall]
user@host# set policer p3 if-exceeding bandwidth-limit 600m
user@host# set policer p3 if-exceeding burst-size-limit 1g
user@host# set policer p3 then discard
5. Dene the interface set ifset to be the group of all Fast Ethernet interfaces on the router.
[edit firewall]
user@host# set interface-set ifset fe-*
6. Create the stateless rewall lter L2_filter.
[edit firewall]
user@host# edit family any filter L2_filter
7. Congure lter term t1 to match IPv4, IPv6, or MPLS packets received on interface fe-0/0/0.0 and
use policer p1 to rate-limit that trac.
[edit firewall family any filter L2_filter]
user@host# set term t1 from interface fe-0/0/0.0
user@host# set term t1 then count c1
user@host# set term t1 then policer p1
8. Congure lter term t2 to match packets received on interface-set ifset and use policer p2 to rate-
limit that trac.
[edit firewall family any filter L2_filter]
user@host# set term t2 from interface-set ifset
user@host# set term t2 then count c2
user@host# set term t2 then policer p2
1367
9. Congure lter term t3 to use policer p3 to rate-limit all other trac.
[edit firewall family any filter L2_filter]
user@host# set term t3 then count c3
user@host# set term t3 then policer p3
10. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Results
Conrm the conguraon of the stateless rewall lter and the policers referenced as rewall lter
acons by entering the show firewall conguraon mode command. If the command output does not
display the intended conguraon, repeat the instrucons in this procedure to correct the conguraon.
[edit]
user@host# show firewall
family any {
filter L2_filter {
term t1 {
from {
interface fe-0/0/0.0;
}
then {
policer p1;
count c1;
}
}
term t2 {
from {
interface-set ifset;
}
then {
policer p2;
count c2;
}
}
1368
term t3 {
then {
policer p3;
count c3;
}
}
}
}
policer p1 {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 10m;
}
then discard;
}
policer p2 {
if-exceeding {
bandwidth-limit 40m;
burst-size-limit 100m;
}
then discard;
}
policer p3 {
if-exceeding {
bandwidth-limit 600m;
burst-size-limit 1g;
}
then discard;
}
interface-set ifset {
fe-*;
}
Applying the Stateless Firewall Filter to the Roung Engine Input Interface
Step-by-Step Procedure
To apply the stateless rewall lter to the Roung Engine input interface:
1369
1. Apply the stateless rewall lter to the Roung Engine interface in the input direcon.
[edit]
user@host# set interfaces lo0 unit 0 family inet address 172.16.1.157/30
user@host# set interfaces lo0 unit 0 filter input L2_filter
2. If you are done conguring the device, commit the conguraon.
[edit]
user@host# commit
Results
Conrm the applicaon of the rewall lter to the Roung Engine input interface by entering the show
interfaces command again. If the command output does not display the intended conguraon, repeat
the instrucons in this procedure to correct the conguraon.
user@host# show interfaces
fe-0/0/0 {
...
}
fe-1/0/0 {
...
}
fe-1/1/0 {
...
}
lo0 {
unit 0 {
filter {
input L2_filter;
}
family inet {
address 172.16.1.157/30;
}
}
}
1370
Vericaon
To conrm that the conguraon is working properly, use the show firewall filter L2_filter operaonal
mode command to monitor trac stascs about the rewall lter and three counters.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Filtering Packets Received on an Interface Set Overview | 1378
1371
CHAPTER 20
Aaching a Single Firewall Filter to Mulple
Interfaces
IN THIS CHAPTER
Interface-Specic Firewall Filter Instances Overview | 1372
Interface-Specic Firewall Filter Instances Overview | 1375
Filtering Packets Received on a Set of Interface Groups Overview | 1377
Filtering Packets Received on an Interface Set Overview | 1378
Example: Conguring Interface-Specic Firewall Filter Counters | 1379
Example: Conguring a Stateless Firewall Filter on an Interface Group | 1386
Interface-Specic Firewall Filter Instances Overview
IN THIS SECTION
Instanaon of Interface-Specic Firewall Filters | 1372
Interface-Specic Names for Firewall Filter Instances | 1373
Interface-Specic Firewall Filter Counters | 1374
Interface-Specic Firewall Filter Policers | 1374
Instanaon of Interface-Specic Firewall Filters
On T Series, M120, M320, MX Series routers, and EX Series switches, you can enable the Junos OS to
automacally create an interface-specic instance of a rewall lter for each interface to which you
apply the lter. If you enable interface-specic instanaon of a rewall lter and then apply that lter
to mulple interfaces, any count acons or policer acons congured in the lter terms act on the trac
1372
stream entering or exing each individual interface, regardless of the sum of trac on the mulple
interfaces.
You can enable this opon per rewall lter by including the interface-specific statement in the lter
conguraon.
NOTE: On T Series, M120, M320, MX Series routers, and EX Series switches, interfaces are
distributed among mulple packet-forwarding components.
Interface-specic rewall ltering is not supported on M Series routers other than the M120 and M320
routers. If you apply a rewall lter to mulple interfaces on an M Series router other than the M120 or
M320 routers, the lter acts on the sum of trac entering or exing those interfaces.
Interface-specic rewall ltering is supported for standard stateless rewall lters and for service
lters. Interface-specic instances are not supported for simple lters.
Interface-Specic Names for Firewall Filter Instances
When the Junos OS creates a separate instance of a rewall lter for a logical interface, the instance is
associate with an interface-specic name. The system-generated name of a rewall lter instance
consists of the name of the congured lter followed by a hyphen (’-’), the full interface name, and
either ’-i’ for an input lter instance or ’-o’ for an output lter instance.
• Input lter instance name—For example, if you apply the interface-specic rewall lter lter_s_tcp
to the input at logical interface at-1/1/1.0, the Junos OS instanates an interface-specic lter
instance with the following system-generated name:
filter_s_tcp-at-1/1/1.0-i
• Output lter instance name—For example, if you apply the interface-specic rewall lter
lter_s_tcp to the output at logical interface ge-2/2/2.2, the Junos OS instanates an interface-
specic lter instance with the following system-generated name:
count_s_tcp-ge-2/2/2.2-o
You can use the interface-specic name of a lter instance when you enter a Junos OS operaonal
mode command that species a stateless rewall lter name.
1373
TIP: When you congure a rewall lter with interface-specic instances enabled, we
recommend you limit the lter name to
52 bytes
in length. This is because rewall lter names
are restricted to
64 bytes
in length. If a system-generated lter instance name exceeds this
maximum length, the policy framework soware might reject the instance name.
Interface-Specic Firewall Filter Counters
Instanaon of interface-specic rewall lters causes the Packet Forwarding Engine to maintain any
counters for the rewall lter separately for each interface. You specify interface-specic counters per
rewall lter term by specifying the count
counter-name
non-terminang acon.
The system-generated name of an interface-specic rewall lter counter consists of the name of the
congured counter followed by a hyphen (’-’), the full interface name, and either ’-i’ for an input lter
instance or ’-o’ for an output lter instance.
• Interface-specic input lter counter name—For example, suppose you congure the lter counter
count_tcp for an interface-specic rewall lter. If the lter is applied to the input at logical interface
at-1/1/1.0, the Junos OS creates the following system-generated counter name:
count_tcp-at-1/1/1.0-i
• Interface-specic output lter counter name—For example, suppose you congure the lter counter
count_udp for an interface-specic rewall lter. If the lter is applied to the output at logical
interface ge-2/2/2.2, the Junos OS creates the following system-generated counter name:
count_udp-ge-2/2/2.2-o
Interface-Specic Firewall Filter Policers
Instanaon of interface-specic rewall lters not only creates separate instances of any rewall lter
counters but also creates separate instances of any policer acons. Any policers applied through an
acon specied in the rewall lter conguraon are applied separately to each interface in the
interface group. You specify interface-specic policers per rewall lter term by specifying the
policer
policer-name
non-terminang acon.
1374
RELATED DOCUMENTATION
Example: Conguring Interface-Specic Firewall Filter Counters | 1379
Interface-Specic Firewall Filter Instances Overview
IN THIS SECTION
Instanaon of Interface-Specic Firewall Filters | 1375
Interface-Specic Names for Firewall Filter Instances | 1376
Interface-Specic Firewall Filter Counters | 1376
Interface-Specic Firewall Filter Policers | 1377
Instanaon of Interface-Specic Firewall Filters
On T Series, M120, M320, and MX Series routers, you can enable the Junos OS to automacally create
an interface-specic instance of a
rewall lter
for each interface to which you apply the lter. If you
enable interface-specic instanaon of a rewall lter and then apply that lter to mulple interfaces,
any count acons or policer acons congured in the lter terms act on the trac stream entering or
exing each individual interface, regardless of the sum of trac on the mulple interfaces.
You can enable this opon per rewall lter by including the interface-specific statement in the lter
conguraon.
NOTE: On T Series, M120, M320, and MX Series routers, interfaces are distributed among
mulple packet-forwarding components.
Interface-specic rewall ltering is not supported on M Series routers other than the M120 and M320
routers. If you apply a rewall lter to mulple interfaces on an M Series router other than the M120 or
M320 routers, the lter acts on the sum of trac entering or exing those interfaces.
Interface-specic rewall ltering is supported for standard stateless rewall lters and for service
lters. Interface-specic instances are not supported for simple lters.
1375
NOTE: A rewall lter cannot be both interface-specic and interface-shared.
Interface-Specic Names for Firewall Filter Instances
When the Junos OS creates a separate instance of a rewall lter for a
logical interface
, the instance is
associate with an interface-specic name. The system-generated name of a rewall lter instance
consists of the name of the congured lter followed by a hyphen (’-’), the full interface name, and
either ’-i’ for an input lter instance or ’-o’ for an output lter instance.
• Input lter instance name—For example, if you apply the interface-specic rewall lter filter_s_tcp
to the input at logical interface at-1/1/1.0, the Junos OS instanates an interface-specic lter
instance with the following system-generated name:
filter_s_tcp-at-1/1/1.0-i
• Output lter instance name—For example, if you apply the interface-specic rewall lter
filter_s_tcp to the output at logical interface so-2/2/2.2, the Junos OS instanates an interface-specic
lter instance with the following system-generated name:
count_s_tcp-so-2/2/2.2-o
You can use the interface-specic name of a lter instance when you enter a Junos OS
operaonal
mode command
that species a stateless rewall lter name.
TIP: When you congure a rewall lter with interface-specic instances enabled, we
recommend you limit the lter name to
52 bytes
in length. This is because rewall lter names
are restricted to
64 bytes
in length. If a system-generated lter instance name exceeds this
maximum length, the policy framework soware might reject the instance name.
Interface-Specic Firewall Filter Counters
Instanaon of interface-specic rewall lters causes the Packet Forwarding Engine to maintain any
counters for the rewall lter separately for each interface. You specify interface-specic counters per
rewall lter term by specifying the count
counter-name
non-terminang acon.
1376
The system-generated name of an interface-specic rewall lter counter consists of the name of the
congured counter followed by a hyphen (’-’), the full interface name, and either ’-i’ for an input lter
instance or ’-o’ for an output lter instance.
• Interface-specic input lter counter name—For example, suppose you congure the lter counter
count_tcp for an interface-specic rewall lter. If the lter is applied to the input at logical interface
at-1/1/1.0, the Junos OS creates the following system-generated counter name:
count_tcp-at-1/1/1.0-i
• Interface-specic output lter counter name—For example, suppose you congure the lter counter
count_udp for an interface-specic rewall lter. If the lter is applied to the output at logical interface
so-2/2/2.2, the Junos OS creates the following system-generated counter name:
count_udp-so-2/2/2.2-o
Interface-Specic Firewall Filter Policers
Instanaon of interface-specic rewall lters not only creates separate instances of any rewall lter
counters but also creates separate instances of any policer acons. Any policers applied through an
acon specied in the rewall lter conguraon are applied separately to each interface in the
interface group. You specify interface-specic policers per rewall lter term by specifying the
policer
policer-name
non-terminang acon.
RELATED DOCUMENTATION
Example: Conguring Interface-Specic Firewall Filter Counters | 1379
Filtering Packets Received on a Set of Interface Groups Overview
You can congure a
rewall lter
term that matches packets tagged for a specied
interface group
or set
of interface groups. An interface group consists of one or more logical interfaces with the same group
number. Packets received on an interface in an interface group are tagged as being part of that group.
1377
NOTE: EX9200 switches do not support
interface groups
. Use the interface-set conguraon
command as a workaround.
For standard stateless rewall lters, you can lter packets received on an interface group for IPv4, IPv6,
virtual private LAN service ( VPLS), Layer 2 circuit cross-connecon (CCC), and Layer 2 bridging trac.
For service lters, you can lter packets received on an interface group for either IPv4 or IPv6 trac.
NOTE: You can also congure a rewall lter term that matches on packets tagged for a specied
interface set
. For more informaon, see "Filtering Packets Received on an Interface Set
Overview" on page 1378.
RELATED DOCUMENTATION
Example: Conguring a Stateless Firewall Filter on an Interface Group | 1386
Filtering Packets Received on an Interface Set Overview
You can congure a standard stateless
rewall lter
term that matches packets tagged for a specied
interface set
. An interface set groups two or more physical or logical interfaces into a single interface-set
name. You can lter packets received on an interface set for protocol-independent, IPv4, IPv6, MPLS,
VPLS, or bridging trac.
NOTE: You can also congure a standard stateless rewall lter term or a service lter term that
matches on packets tagged for a specied
interface group
. For more informaon, see "Filtering
Packets Received on a Set of Interface Groups Overview" on page 1377.
RELATED DOCUMENTATION
Example: Conguring a Rate-Liming Filter Based on Desnaon Class | 1212
Example: Filtering Packets Received on an Interface Set | 1362
1378
Example: Conguring Interface-Specic Firewall Filter Counters
IN THIS SECTION
Requirements | 1379
Overview | 1379
Conguraon | 1380
Vericaon | 1384
This example shows how to congure and apply an interface-specic standard stateless rewall lter.
Requirements
Interface-specic stateless rewall lters are supported on T Series, M120, M320, and MX Series
routers only.
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 1379
In this example, you create an interface-specic stateless rewall lter that counts and accepts packets
with source or desnaon addresses in a specied prex and the IP protocol type eld set to a specic
value.
Topology
You congure the interface-specic stateless rewall lter filter_s_tcp to count and accept packets with
IP source or desnaon addresses in the 10.0.0.0/12 prex and the IP protocol type eld set to tcp (or the
numeric value 6).
The name of the rewall lter counter is count_s_tcp.
1379
You apply the rewall lter to mulple logical interfaces:
• at-1/1/1.0 input
• so-2/2/2.2 output
Applying the lter to these two interfaces results in two instances of the lter: filter_s_tcp-at-1/1/1.0-i
and filter_s_tcp-so-2/2/2.2-o, respecvely.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1380
Congure the Interface-Specic Firewall Filter | 1381
Apply the Interface-Specic Firewall Filter to Mulple Interfaces | 1381
Conrm Your Candidate Conguraon | 1382
Clear the Counters and Commit Your Candidate Conguraon | 1383
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter filter_s_tcp interface-specific
set firewall family inet filter filter_s_tcp term 1 from address 10.0.0.0/12
set firewall family inet filter filter_s_tcp term 1 from protocol tcp
set firewall family inet filter filter_s_tcp term 1 then count count_s_tcp
set firewall family inet filter filter_s_tcp term 1 then accept
set interfaces at-1/1/1 unit 0 family inet filter input filter_s_tcp
set interfaces so-2/2/2 unit 2 family inet filter filter_s_tcp
1380
Congure the Interface-Specic Firewall Filter
Step-by-Step Procedure
To congure the interface-specic rewall lter:
1. Create the IPv4 rewall lter filter_s_tcp.
[edit]
user@host# edit firewall family inet filter filter_s_tcp
2. Enable interface-specic instances of the lter.
[edit firewall family inet filter filter_s_tcp]
user@host# set interface-specific
3. Congure the match condions for the term.
[edit firewall family inet filter filter_s_tcp]
user@host# set term 1 from address 10.0.0.0/12
user@host# set term 1 from protocol tcp
4. Congure the acons for the term.
[edit firewall family inet filter filter_s_tcp]
user@host# set term 1 then count count_s_tcp
user@host# set term 1 then accept
Apply the Interface-Specic Firewall Filter to Mulple Interfaces
Step-by-Step Procedure
To apply the lter filter_s_tcp to logical interfaces at-1/1/1.0 and so-2/2/2.2:
1381
1. Apply the interface-specic lter to packets received on logical interface at-1/1/1.0.
[edit]
user@host# set interfaces at-1/1/1 unit 0 family inet filter input filter_s_tcp
2. Apply the interface-specic lter to packets transmied from logical interface so-2/2/2.2.
[edit]
user@host# set interfaces so-2/2/2 unit 2 family inet filter filter_s_tcp
Conrm Your Candidate Conguraon
Step-by-Step Procedure
To conrm your candidate conguraon:
1. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter filter_s_tcp {
interface-specific;
term 1 {
from {
address {
10.0.0.0/12;
}
protocol tcp;
}
then {
count count_s_tcp;
accept;
}
}
}
}
1382
2. Conrm the conguraon of the interfaces by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
at-1/1/1 {
unit 0
family inet {
filter {
input filter_s_tcp;
}
}
]
}
so-2/2/2 {
unit 2
family inet {
filter {
output filter_s_tcp;
}
}
}
}
Clear the Counters and Commit Your Candidate Conguraon
Step-by-Step Procedure
To clear the counters and commit your candidate conguraon:
1. From operaonal command mode, use the clear firewall all command to clear the stascs for all
rewall lters.
To clear only the counters used in this example, include the interface-specic lter instance names:
[edit]
user@host> clear firewall filter filter_s_tcp-at-1/1/1.0-i
user@host> clear firewall filter filter_s_tcp-so-2/2/2.2-o
1383
2. Commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
IN THIS SECTION
Verifying That the Filter Is Applied to Each of the Mulple Interfaces | 1384
Verifying That the Counters Are Collected Separately by Interface | 1385
Conrm that the conguraon is working properly.
Verifying That the Filter Is Applied to Each of the Mulple Interfaces
Purpose
Verify that the lter is applied to each of the mulple interfaces.
Acon
Run the show interfaces command with the detail or extensive output level.
1. Verify that the lter is applied to the input for at-1/1/1.0:
user@host> show interfaces at-1/1/1 detail
Physical interface: at-1/1/1, Enabled, Physical link is Up
Interface index: 300, SNMP ifIndex: 194, Generation: 183
...
Logical interface at-1/1/1.0 (Index 64) (SNMP ifIndex 204) (Generation 5)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: ATM-SNAP
...
Protocol inet, MTU: 4470, Generation: 13, Route table: 0
Flags: Sendbcast-pkt-to-re
Input Filters: filter_s_tcp-at-1/1/1.0-i,,,,,
1384
2. Verify that the lter is applied to the output for so-2/2/2.2:
user@host> show interfaces so-2/2/2 detail
Physical interface: so-2/2/2, Enabled, Physical link is Up
Interface index: 129, SNMP ifIndex: 502, Generation: 132
...
Logical interface so-2/2/2.2 (Index 70) (SNMP ifIndex 536) (Generation 135)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPP
...
Protocol inet, MTU: 4470, Generation: 146, Route table: 0
Flags: Sendbcast-pkt-to-re
Output Filters: filter_s_tcp-so-2/2/2.2-o,,,,,
Verifying That the Counters Are Collected Separately by Interface
Purpose
Make sure that the count_s_tcp counters are collected separately for the two logical interfaces.
Acon
Run the show firewall command.
user@host> show firewall filter filter_s_tcp
Filter: filter_s_tcp
Counters:
Name Bytes Packets
count_s_tcp-at-1/1/1.0-i 420 5
count_s_tcp-so-2/2/2.2-o 8888 101
RELATED DOCUMENTATION
Interface-Specic Firewall Filter Instances Overview | 1375
1385
Example: Conguring a Stateless Firewall Filter on an Interface Group
IN THIS SECTION
Requirements | 1386
Overview | 1386
Conguraon | 1387
Vericaon | 1392
Firewall lters are essenal for securing a network and simplifying network management. In Junos OS,
you can congure a stateless rewall lters to control the transit of data packets through the system and
to manipulate packets as necessary. Applying a stateless rewall lter to an interface group helps to
lter packets transing through each interface in the interface group. This example shows how to
congure a standard stateless rewall lter to match packets tagged for a parcular interface group.
Requirements
This example uses the following hardware and soware components:
• Any two Juniper Networks routers or switches that are physically or logically connected to each
other through interfaces belonging to a roung instance
• Junos OS Release 7.4 or later
Overview
You can apply a stateless rewall lter to an interface group to apply it across all the interfaces in the
interface group. This helps you to manage the packet ltering on various interfaces simultaneously.
In this example, you congure two router or switch interfaces to belong to the interface group. You also
congure a stateless rewall lter with three terms. In term term1, the lter matches packets that have
been tagged as received on that interface group and contain an ICMP protocol tag. The lter counts,
logs, and rejects packets that match the condions. In term term2, the lter matches packets that contain
the ICMP protocol tag. The lter counts, logs, and accepts all packets that match the condion. In term
term3, the lter counts all the transit packets.
By applying the rewall lter to the roung instance, you can simultaneously apply the ltering
mechanism on all the interfaces in the interface group. For this to happen, all the interfaces in the
interface group must belong to a single roung instance.
1386
NOTE: When you apply a rewall lter to a loopback interface, the interface lters all the
packets desned to the Roung Engine.
Figure 60: Conguring a Stateless Firewall Filter on an Interface Group
CLI Quick Conguraon shows the conguraon for all of the devices in Figure 60 on page 1387. The
secon Step-by-Step Procedure describes the steps on Device R1.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1387
Congure and Apply the Stateless Firewall Filter on an Interface Group | 1388
Results | 1390
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from conguraon mode.
1387
Device R0
set interfaces ge-0/0/0 unit 0 family inet address 172.16.17.1/30
set interfaces ge-0/0/1 unit 0 family inet address 172.16.19.1/30
set interfaces ge-0/0/2 unit 0 family inet address 20.1.1.1/30
set interfaces lo0 unit 0 family inet address 10.0.0.1/32
Device R1
set firewall family inet filter filter_if_group term term1 from interface-group 1
set firewall family inet filter filter_if_group term term1 from protocol icmp
set firewall family inet filter filter_if_group term term1 then count if_group_counter1
set firewall family inet filter filter_if_group term term1 then log
set firewall family inet filter filter_if_group term term1 then reject
set firewall family inet filter filter_if_group term term2 from protocol icmp
set firewall family inet filter filter_if_group term term2 then count if_group_counter2
set firewall family inet filter filter_if_group term term2 then log
set firewall family inet filter filter_if_group term term2 then accept
set firewall family inet filter filter_if_group term term3 then count default
set interfaces ge-0/0/0 unit 0 family inet filter group 1
set interfaces ge-0/0/0 unit 0 family inet address 172.16.17.2/30
set interfaces ge-0/0/1 unit 0 family inet address 172.16.19.2/30
set interfaces ge-0/0/2 unit 0 family inet filter group 1
set interfaces ge-0/0/2 unit 0 family inet address 20.1.1.2/30
set interfaces lo0 unit 0 family inet address 20.0.0.1/32
set forwarding-options family inet filter input filter_if_group
Congure and Apply the Stateless Firewall Filter on an Interface Group
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in
the CLI User Guide.
To congure the stateless rewall lter filter_if_group on an interface group:
1388
1. Create the stateless rewall lter filter_if_group.
[edit firewall]
user@R1# edit family inet filter filter_if_group
2. Congure the interfaces and assign two interfaces to interface group 1.
[edit interfaces]
user@R1# set ge-0/0/0 unit 0 family inet filter group 1
user@R1# set ge-0/0/0 unit 0 family inet address 172.16.17.2/30
user@R1# set ge 0/0/1 unit 0 family inet address 172.16.19.2/30
user@R1# set ge-0/0/2 unit 0 family inet filter group 1
user@R1# set ge-0/0/2 unit 0 family inet address 20.1.1.2/30
user@R1# set lo0 unit 0 family inet address 20.0.0.1/32
3.
Congure term term1 to match packets received on interface group 1 and with the ICMP protocol.
[edit firewall]
user@R1# set family inet filter filter_if_group term term1 from interface-group 1
user@R1# set family inet filter filter_if_group term term1 from protocol icmp
4. Congure term term1 to count, log, and reject all the matching packets.
[edit firewall]
user@R1# set family inet filter filter_if_group term term1 then count if_group_counter1
user@R1# set family inet filter filter_if_group term term1 then log
user@R1# set family inet filter filter_if_group term term1 then reject
5. Congure term term2 to match packets with the ICMP protocol.
[edit firewall]
user@R1# set family inet filter filter_if_group term term2 from protocol icmp
6.
Congure term term2 to count, log, and accept all the matching packets.
[edit firewall]
user@R1# set family inet filter filter_if_group term term2 then count if_group_counter2
1389
user@R1# set family inet filter filter_if_group term term2 then log
user@R1# set family inet filter filter_if_group term term2 then accept
7. Congure term term3 to count all the transit packets.
[edit firewall]
user@R1# set family inet filter filter_if_group term term3 then count default
8. Apply the rewall lter to the router’s (or switch’s) interface group by applying it to the roung
instance.
[edit]
user@R1# set forwarding-options family inet filter input filter_if_group
9. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Results
From conguraon mode, conrm your conguraon by issuing the show interfaces, show firewall, and show
forwarding-options commands. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
filter {
group 1;
}
address 172.16.17.2/30;
}
}
}
ge-0/0/1 {
1390
unit 0 {
family inet {
address 172.16.19.2/30;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
filter {
group 1;
}
address 20.1.1.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 20.0.0.1/32;
}
}
}
[edit]
user@R1# show firewall
family inet {
filter filter_if_group {
term term1 {
from {
interface-group 1;
protocol icmp;
}
then {
count if_group_counter1;
log;
reject;
}
}
term term2 {
from {
1391
protocol icmp;
}
then {
count if_group_counter2;
log;
accept;
}
}
term term3 {
then count default;
}
}
}
[edit]
user@R1# show forwarding-options
family inet {
filter {
input filter_if_group;
}
}
Vericaon
IN THIS SECTION
Verifying the Conguraon of the Interfaces | 1392
Verifying Stateless Firewall Filter Conguraon | 1394
Conrm that the conguraon is working properly.
Verifying the Conguraon of the Interfaces
Purpose
Verify that the interfaces are properly congured.
1392
Acon
To display the state of the interfaces, use the show interfaces terse operaonal mode command.
Device R0
user@R0> show interfaces terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.16.17.1/30
multiservice
ge-0/0/1 up up
ge-0/0/1.0 up up inet 172.16.19.1/30
multiservice
ge-0/0/2 up up
ge-0/0/2.0 up up inet 20.1.1.1/30
multiservice
lo0 up up
lo0.0 up up inet 10.0.0.1 --> 0/0
Device R1
user@R1> show interfaces terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.16.17.2/30
multiservice
...
ge-0/0/1 up up
ge-0/0/1.0 up up inet 172.16.19.2/30
multiservice
ge-0/0/2 up up
ge-0/0/2.0 up up inet 20.1.1.2/30
multiservice
...
Meaning
All the interfaces on Devices R0 and R1 are physically connected and up. The interface group 1 on
Device R1 consists of two interfaces, namely ge-0/0/0.0 and ge-0/0/2.0.
1393
Verifying Stateless Firewall Filter Conguraon
Purpose
Verify that the rewall lter match condions are congured properly.
Acon
• To display the rewall lter counters, enter the show firewall filter filter_if_group operaonal mode
command.
user@R1> show firewall filter filter_if_group
Filter: filter_if_group
Counters:
Name Bytes Packets
default 192975 3396
if_group_counter1 2520 30
if_group_counter2 2604 41
• To display the local log of packet headers for packets evaluated by the rewall lter, enter the show
firewall log operaonal mode command.
user@R1> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr
Dest Addr
22:27:33 pfe A lo0.0 ICMP 20.1.1.2
20.1.1.1
22:27:33 pfe R ge-0/0/2.0 ICMP 20.1.1.1
20.1.1.2
22:27:32 pfe A lo0.0 ICMP 20.1.1.2
20.1.1.1
22:27:32 pfe R ge-0/0/2.0 ICMP 20.1.1.1
20.1.1.2
22:27:31 pfe A lo0.0 ICMP 20.1.1.2
20.1.1.1
22:27:31 pfe R ge-0/0/2.0 ICMP 20.1.1.1
20.1.1.2
22:27:30 pfe A lo0.0 ICMP 20.1.1.2
20.1.1.1
1394
22:27:30 pfe R ge-0/0/2.0 ICMP 20.1.1.1
20.1.1.2
22:27:29 pfe A lo0.0 ICMP 20.1.1.2
20.1.1.1
22:27:29 pfe A lo0.0 ICMP 20.1.1.2
20.1.1.1
22:27:29 pfe R ge-0/0/2.0 ICMP 20.1.1.1
20.1.1.2
22:27:21 pfe A ge-0/0/1.0 ICMP 172.16.19.1
172.16.19.2
22:27:20 pfe A ge-0/0/1.0 ICMP 172.16.19.1
172.16.19.2
22:27:19 pfe A ge-0/0/1.0 ICMP 172.16.19.1
172.16.19.2
22:27:18 pfe A ge-0/0/1.0 ICMP 172.16.19.1
172.16.19.2
22:27:04 pfe A lo0.0 ICMP 172.16.17.2
172.16.17.1
22:27:04 pfe R ge-0/0/0.0 ICMP 172.16.17.1
172.16.17.2
22:27:04 pfe A lo0.0 ICMP 172.16.17.2
172.16.17.1
22:27:04 pfe R ge-0/0/0.0 ICMP 172.16.17.1
172.16.17.2
22:27:02 pfe A lo0.0 ICMP 172.16.17.2
172.16.17.1
22:27:02 pfe R ge-0/0/0.0 ICMP 172.16.17.1
172.16.17.2
22:27:01 pfe A lo0.0 ICMP 172.16.17.2
172.16.17.1
22:27:01 pfe R ge-0/0/0.0 ICMP 172.16.17.1
172.16.17.2
22:27:00 pfe A lo0.0 ICMP 172.16.17.2
172.16.17.1
22:27:00 pfe R ge-0/0/0.0 ICMP 172.16.17.1
172.16.17.2
22:24:48 filter_if_group A fxp0.0 ICMP 10.92.16.2
10.92.26.176
1395
• To make sure that the rewall lters are acve on interface group 1 on Device R1, use the ping
<address>
operaonal mode command on the CLI of Device R0.
user@R0> ping 172.16.17.2
PING 172.16.17.2 (172.16.17.2): 56 data bytes
36 bytes from 172.16.17.2: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f46b 0 0000 40 01 6239 172.16.17.1 172.16.17.2
36 bytes from 172.16.17.2: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f479 0 0000 40 01 622b 172.16.17.1 172.16.17.2
36 bytes from 172.16.17.2: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f487 0 0000 40 01 621d 172.16.17.1 172.16.17.2
user@R0> ping 20.1.1.2
PING 20.1.1.2 (20.1.1.2): 56 data bytes
36 bytes from 20.1.1.2: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f5bd 0 0000 40 01 5ae7 20.1.1.1 20.1.1.2
36 bytes from 20.1.1.2: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f5cd 0 0000 40 01 5ad7 20.1.1.1 20.1.1.2
36 bytes from 20.1.1.2: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f5d9 0 0000 40 01 5acb 20.1.1.1 20.1.1.2
36 bytes from 20.1.1.2: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f5f6 0 0000 40 01 5aae 20.1.1.1 20.1.1.2
•
To make sure that the rewall lter is not applied on an interface that is not in interface group 1, use
the ping
<address>
operaonal mode command on the CLI of Device R0.
user@R0> ping 172.16.19.2
PING 172.16.19.2 (172.16.19.2): 56 data bytes
1396
64 bytes from 172.16.19.2: icmp_seq=0 ttl=64 time=8.689 ms
64 bytes from 172.16.19.2: icmp_seq=1 ttl=64 time=4.076 ms
64 bytes from 172.16.19.2: icmp_seq=2 ttl=64 time=8.501 ms
64 bytes from 172.16.19.2: icmp_seq=3 ttl=64 time=3.954 ms
...
Meaning
The stateless rewall lter is applied to all interfaces in interface group 1. The term term1 match condion
in the stateless rewall lter counts, logs, and rejects packets that are received on or sent from the
interfaces in interface group 1 and with a source ICMP protocol. The term term2 match condion matches
packets tagged with the ICMP protocol and counts, logs, and accepts those packets. The term term3
match condion counts all the transit packets.
RELATED DOCUMENTATION
Filtering Packets Received on a Set of Interface Groups Overview | 1377
1397
CHAPTER 21
Conguring Filter-Based Tunneling Across IP
Networks
IN THIS CHAPTER
Understanding Filter-Based Tunneling Across IPv4 Networks | 1398
Firewall Filter-Based L2TP Tunneling in IPv4 Networks Overview | 1401
Interfaces That Support Filter-Based Tunneling Across IPv4 Networks | 1405
Components of Filter-Based Tunneling Across IPv4 Networks | 1407
Example: Transporng IPv6 Trac Across IPv4 Using Filter-Based Tunneling | 1413
Understanding Filter-Based Tunneling Across IPv4 Networks
IN THIS SECTION
Understanding Filter-Based Tunneling Across IPv4 Networks | 1398
Characteriscs of Filter-Based Tunneling Across IPv4 Networks | 1399
Tunneling with Firewall Filters and Tunneling with Tunnel Interfaces | 1400
Understanding Filter-Based Tunneling Across IPv4 Networks
Generic roung encapsulaon (GRE) in its simplest form is the encapsulaon of any network layer
protocol over any other network layer protocol to connect disjointed networks that lack a nave roung
path between them. It is a conneconless and stateless Layer 3 encapsulaon protocol, and it oers no
mechanisms for reliability, ow control, or sequencing.
GRE tunneling is iniated with standard
rewall lter
acons. Trac ows through the tunnel provided
that the tunnel desnaon is routable. For MX series routers, this feature is also supported in logical
systems.
1398
For MX Series 5G Universal Roung Plaorms, when you congure GRE tunneling with rewall lters,
you do not need to create tunnel interfaces on Tunnel Services physical interface cards (PICs) or on
MPC3E Modular Port Concentrators (MPCs). Instead, PFEs on the Modular Interface Cards (MICs) or
MPCs handle the GRE payload encapsulaon and decapsulaon and provide the tunnel services to the
relevant interfaces. As such, a pair of MX Series routers can be installed as provider edge (PE) routers to
provide connecvity to customer edge (CE) routers on two disjoint networks.
For PTX Series routers, network services must be set to enhanced-mode for lter-based GRE tunneling to
work. For more informaon on lter based tunneling on the PTX, see tunnel-end-point .
Ingress Firewall Filter on the Ingress PE Router
On the ingress PE router, you congure a tunnel denion that species a unidireconal GRE tunnel. For
MX series routers with a MIC or MPC ingress
logical interface
, you aach an encapsulang rewall lter.
The rewall lter acon references a tunnel denion and iniates the encapsulaon of matched
packets. The encapsulaon process aaches an IPv4 header and a GRE header to the payload packet
and then forwards the resulng GRE packet to the lter-specied tunnel.
Ingress Firewall Filter on the Egress PE Router
On the egress PE router, you aach a de-encapsulang rewall lter to the input of all MIC or MPC
logical interfaces that are adversed addresses for the router. The rewall lter iniates the de-
encapsulaon of GRE protocol packets. De-encapsulaon removes the inner GRE header and then
forwards the original payload packet to its original desnaon on the desnaon customer network. If
the acon species an oponal roung instance, route lookup is performed using that secondary table
instead of the primary table.
Characteriscs of Filter-Based Tunneling Across IPv4 Networks
Filter-based tunnels across IPv4 networks are unidireconal. They transport transit packets only, and
they do not require tunnel interfaces.
Unidireconal Tunneling
To use lter-based GRE tunnels, start by aaching standard rewall lters at the
input
of each tunnel
endpoint (at both the ingress PE router and the egress PE router). At the input to the ingress PE router,
you apply an encapsulang rewall lter. At the input to the egress PE router, apply a de-encapsulang
rewall lter.
1399
Bidireconal Tunneling
For bidireconal GRE tunneling, you can use the same pair of PE routers, but you must congure a
second tunnel in the reverse direcon.
Transit Trac Payloads
A lter-based GRE IPv4 tunnel can transport unicast or mulcast transit trac payloads only. Filter-
iniated encapsulaon and decapsulaon operaons execute on PFEs for Ethernet logical interfaces and
aggregated Ethernet interfaces. This design enables more ecient use of PFE bandwidth as compared to
GRE tunneling using tunnel interfaces. Roung protocol sessions can not be congured on top of the
rewall based tunnels.
The PFEs operate in the
forwarding plane
to process packets by forwarding them between input and
output interfaces using a locally stored forwarding table, which is a local copy of the informaon from
the Roung Engine (RE).
On the other hand, REs operate in the
control plane
to handle system management, user access to the
router, and processes for roung protocols, router interface control, and some chassis component
control. The Junos OS architecture separates the funcons of these planes to enable exibility of
plaorm support and scalability of plaorm performance. Ingress control packets are directed to the
control plane where the GRE encapsulaon and de-encapsulaon processes of the PFEs are not
available.
Although you can apply rewall lters to loopback addresses, GRE encapsulang and de-encapsulang
rewall lter acons are not supported on router loopback interfaces.
Compact Conguraon for Mulple GRE Tunnels
Firewall lters support a wide variety of match criteria and, by extension, the ability to terminate
mulple GRE tunnels that match criteria specied in a single rewall lter denion. By creang
mulple tunnels, each with its own set of match condions, you can create tunnels that do not interfere
with customer GRE packets or with one another and that re-inject packets to separate roung tables
aer de-encapsulaon.
Tunneling with Firewall Filters and Tunneling with Tunnel Interfaces
Tunneling with tunnel interfaces supports both router control trac and transit trac, as well as
encrypon. Tunneling with rewall lters does not. However, tunneling with rewall lters does provide
benets in performance and scaling.
1400
Forwarding Performance
Filter-based tunneling across IPv4 networks enables more ecient use of PFE bandwidth as compared
to GRE tunneling using tunnel interfaces. Encapsulaon, de-encapsulaon, and route lookup are packet
header-processing acvies that, for rewall lter-based tunneling, are performed on the PFE.
Consequently, the encapsulator never needs to send payload packets to a separate tunnel interface
(which might reside on a PIC in a dierent slot than the interface that receives payload packets).
RELATED DOCUMENTATION
Interfaces That Support Filter-Based Tunneling Across IPv4 Networks | 1405
Components of Filter-Based Tunneling Across IPv4 Networks | 1407
Firewall Filter Terminang Acons | 886
tunnel-end-point
Example: Transporng IPv6 Trac Across IPv4 Using Filter-Based Tunneling | 1413
Firewall Filter-Based L2TP Tunneling in IPv4 Networks Overview
IN THIS SECTION
Unidireconal Tunneling | 1403
Tunnel Security | 1403
Forwarding Performance | 1404
Forwarding Scalability | 1404
The Layer 2 Tunneling Protocol (L2TP) is a client-server protocol that allows the Point-to-Point Protocol
(PPP) to be tunneled across a network. L2TP encapsulates Layer 2 packets, such as PPP, for transmission
across a network. An L2TP access concentrator (LAC), congured on an access device, receives packets
from a remote client and forwards them to an L2TP network server (LNS) on a remote network. L2TPv3
denes the base control protocol and encapsulaon for tunneling mulple Layer 2 connecons between
two IPv6 nodes. The signicant dierences between L2TPv2 and L2TPv3 include the following:
• Separaon of all PPP-related AVPs and references, which enables the inclusion of a poron of the
L2TP data header that was specic to the needs of PPP.
1401
• Transion from a 16-bit Session ID and Tunnel ID to a 32-bit Session ID and Control Connecon ID
respecvely.
• Extension of the tunnel authencaon mechanism to cover the enre control message rather than
just a poron of certain messages.
• L2TPv3 is supported for IPv6 only.
• For rewall lters, only data plane L2TPv3 encapsulaon/ decapsulaon is supported.
L2TP is comprised of two types of messages, control messages and data messages (somemes referred
to as control packets and data packets respecvely). Control messages are used in the establishment,
maintenance, and clearing of control connecons and sessions. These messages ulize a reliable control
channel within L2TP to guarantee delivery. Data messages are used to encapsulate the L2 trac being
carried over the L2TP session.
You can congure an IPv4 network to transport IPv4, IPv6, or MPLS transit trac by using GRE
tunneling protocol mechanisms iniated by two standard rewall lter acons. This feature is also
supported in logical systems. When you congure L2TP tunneling with rewall lters, you do not need
to create tunnel interfaces on Tunnel Services physical interface cards (PICs) or on MPC3E Modular Port
Concentrators (MPCs). Instead, Packet Forwarding Engines provide tunnel services to Ethernet logical
interfaces or aggregated Ethernet interfaces hosted on Modular Interface Cards (MICs) or MPCs in MX
Series 5G Universal Roung Plaorms.
Two MX Series routers installed as provider edge (PE) routers provide connecvity to customer edge
(CE) routers on two disjoint networks. MIC or MPC interfaces on the PE routers perform L2TP IPv4
encapsulaon and de-encapsulaon of payloads. Aer decapsulaon, packets are sent to the local
interface of a roung table specied in the acon, or to the default roung table, based on the protocol
eld of the L2TP header. However, an L2TP packet can oponally be sent across the fabric with a token
equal to an output interface index to perform Layer 2 cross- connect. You can specify the output
interface specier to be used for the L2TP packet to be sent by including the decapsulate l2tp output-
interface
interface-name
cookie
l2tpv3-cookie
statement at the [edit firewall family
family-name
filter
filter-
name
term
term-name
then] hierarchy level.
During decapsulaon, the inner header must be Ethernet for L2TP tunnels. Forwarding class by default
is applied before the rewall and it is not preserved for the decapsulated packet (by using the forwarding-
class
class-name
statement at the [edit firewall family family-name] hierarchy level, which is a
nonterminang lter acon). However, you can specify the forwarding class that the packet must be
classied against by including the lter acon for a decapsulated packet by using the decapsulate l2tp
forwarding-class
class-name
statement at the [edit firewall family
family-name
filter filter-name term
term-name
then] hierarchy level.
The following eld denions are dened for use in all L2TP Session Header encapsulaons.
• The Session ID eld is a 32-bit eld containing a non-zero idener for a session. L2TP sessions are
named by ideners that have local signicance only. The same logical session will be given dierent
1402
Session IDs by each end of the control connecon for the life of the session. When the L2TP control
connecon is used for session establishment, Session IDs are selected and exchanged as Local
Session ID AVPs during the creaon of a session. The Session ID alone provides the necessary
context for all further packet processing, including the presence, size, and value of the Cookie, the
type of L2-Specic Sublayer, and the type of payload being tunneled.
• The oponal Cookie eld contains a variable-length value (maximum 64 bits) used to check the
associaon of a received data message with the session idened by the Session ID. The Cookie eld
must be set to the congured or signaled random value for this session. The Cookie provides an
addional level of guarantee that a data message has been directed to the proper session by the
Session ID. A well-chosen Cookie might prevent inadvertent misdirecon of random packets with
recently reused Session IDs or for Session IDs subject to packet corrupon. The Cookie might also
provide protecon against some specic malicious packet inseron aacks. When the L2TP control
connecon is used for session establishment, random Cookie values are selected and exchanged as
Assigned Cookie AVPs during session creaon.
A session is a logical connecon created between the LAC and the LNS when an end-to-end PPP
connecon is established between a remote system and the LNS. There is a one-to-one relaonship
between established L2TP sessions and their associated PPP connecons. A tunnel is an aggregaon of
one or more L2TP sessions.
Starng with Junos OS Release 15.1, decapsulaon of IP packets that are sent through an L2TP tunnel
with standard rewall lter match condions and acons specied is performed using a Layer 3 lookup.
In Junos OS release 14.2 and earlier, decapsulaon of trac over an L2TP tunnel with rewall lter
acons congured is performed using Layer 2 interface properes.
Unidireconal Tunneling
Filter-based L2TP tunnels across IPv4 networks are unidireconal. They transport transit packets only,
and they do not require tunnel interfaces. Although you can apply rewall lters to loopback addresses,
GRE encapsulang and de-encapsulang rewall lter acons are not supported on router loopback
interfaces. Filter-iniated encapsulaon and decapsulaon operaons of L2TP packets execute on
Packet Forwarding Engines for Ethernet logical interfaces and aggregated Ethernet interfaces. This
design enables more ecient use of Packet Forwarding Engine bandwidth as compared to GRE
tunneling using tunnel interfaces. Roung protocol sessions can not be congured on top of the rewall
based tunnels.
Tunnel Security
Filter-based tunneling across IPv4 networks is not encrypted. If you require secure tunneling, you must
use IP Security (IPsec) encrypon, which is not supported on MIC or MPC interfaces. However,
Mulservices DPC (MS-DPC) interfaces on MX240, MX480, and MX960 routers support IPsec tools for
1403
conguring manual or dynamic security associaons (SAs) for encrypon of data trac as well as trac
desned to or originang at the Roung Engine.
Forwarding Performance
Filter-based tunneling across IPv4 networks enables more ecient use of Packet Forwarding Engine
bandwidth as compared to L2TP tunneling using tunnel interfaces. Encapsulaon, de-encapsulaon, and
route lookup are packet header-processing acvies that, for rewall lter-based tunneling, are
performed on the Junos Trio chipset-based Packet Forwarding Engine. Consequently, the encapsulator
never needs to send payload packets to a separate tunnel interface (which might reside on a PIC in a
dierent slot than the interface that receives payload packets).
Forwarding Scalability
Forwarding L2TP trac with tunnel interfaces requires trac to be sent to a slot that hosts the tunnel
interfaces. When you use tunnel interfaces to forward GRE trac, this requirement limits the amount of
trac that can be forwarded per GRE tunnel desnaon address. As an example, suppose you want to
send 100 Gbps of L2TP trac from Router A to Router B and you have only 10 Gbps interfaces. To
ensure that your conguraon does not encapsulate all the trac on the same board going to the same
10 Gbps interface, you must distribute the trac across mulple encapsulaon points.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
15.1 Starng with Junos OS Release 15.1, decapsulaon of IP packets that are sent through an L2TP tunnel
with standard rewall lter match condions and acons specied is performed using a Layer 3 lookup.
14.2 In Junos OS release 14.2 and earlier, decapsulaon of trac over an L2TP tunnel with rewall lter
acons congured is performed using Layer 2 interface properes.
RELATED DOCUMENTATION
Interfaces That Support Filter-Based Tunneling Across IPv4 Networks | 1405
Components of Filter-Based Tunneling Across IPv4 Networks | 1407
Firewall Filter Terminang Acons | 886
tunnel-end-point
Example: Transporng IPv6 Trac Across IPv4 Using Filter-Based Tunneling | 1413
1404
Interfaces That Support Filter-Based Tunneling Across IPv4 Networks
IN THIS SECTION
Interfaces on MX240, MX480, MX960, MX2010, and MX2020 Routers | 1405
Interfaces on MX5, MX10, MX40, and MX80 Routers | 1405
CLI Commit Check for Filter-Based Tunneling Across IPv4 Networks | 1406
You can aach IPv4 encapsulaon and de-encapsulaon rewall lters to the input of Ethernet logical
interfaces or aggregated Ethernet interfaces hosted on Modular Interface Cards (MICs) or Modular Port
Concentrators (MPCs) in MX Series routers.
NOTE: Filter-based generic roung encapsulaon (GRE) tunneling is supported on PTX Series
routers only when network services is set to enhanced-mode. For more informaon, see enhanced-mode.
Interfaces on MX240, MX480, MX960, MX2010, and MX2020 Routers
On MX240, MX480, MX960, MX2010, and MX2020 routers,
rewall lter
acons for IPv4 tunneling are
supported on Ethernet logical interfaces or aggregated Ethernet interfaces congured on the following
types of ports:
• Ports on MICs that insert into slots in MPCs, which have two Packet Forwarding Engines.
• Ports on a 16-port 10-Gigabit Ethernet MPC (MPC-3D-16XGE-SFPP), a specialized xed-
conguraon MPC that has four Packet Forwarding Engines and contains no slots for MICs.
For these physical interfaces, Trio chipset-based Packet Forwarding Engine processes operate in
fabric
mode
to provide forwarding and storage funcons and lookup and processing funcons between
Ethernet interfaces and the roung fabric of the chassis.
For informaon about MPCs, see MX Series MPC Overview and MPCs Supported by MX Series Routers.
For informaon about MICs, see MX Series MIC Overview and MICs Supported by MX Series Routers.
Interfaces on MX5, MX10, MX40, and MX80 Routers
On the MX Series midrange family of routers (MX5, MX10, MX40, and MX80 routers), rewall lter
acons for IPv4 tunneling are supported on Ethernet logical interfaces and aggregated Ethernet
1405
interfaces congured on ports on a built-in MIC or on MICs that install into dedicated slots in the router
chassis.
• The MX80 router—available as a modular (MX80) or xed (MX80-48T) chassis—has a built-in 4-port
10-Gigabit Ethernet MIC. The modular chassis has two dedicated slots for MICs. The xed chassis
has 48 built-in tri-rate (10/100/1000Base-T) RJ-45 ports in place of two front-pluggable MIC slots.
• On the MX40 router, only the rst two of the four built-in 10-Gigabit Ethernet MIC ports are
enabled. As with the modular MX80, the two front-pluggable MIC slots are enabled and support
dual-wide MICs that span the two slots.
• The MX5 and MX10 routers are pre-populated with a front-pluggable 20-port Gigabit Ethernet MIC
with SFP, and none of the four built-in 10-Gigabit Ethernet MIC ports is enabled. The MX10 supports
MICs in both front-pluggable slots, but the MX5 supports MICs in the second slot only.
For more informaon, see MX5, MX10, MX40, and MX80 Modular Interface Card Descripon.
The MX Series midrange routers have no switching fabric, and the single Packet Forwarding Engine
resides on the base board of the chassis and operates in
standalone mode
. In standalone mode, the
Packet Forwarding Engine provides—in addion to forwarding and storage funcons and lookup and
processing funcons—hierarchical queuing, congeson management, and granular stascal funcons.
CLI Commit Check for Filter-Based Tunneling Across IPv4 Networks
If you commit a conguraon that aaches an encapsulang or de-encapsulang rewall lter to an
interface that does not support lter-based tunneling across IPv4 networks, a system event writes a
syslog warning message that the interface does not support the lter.
RELATED DOCUMENTATION
Understanding Filter-Based Tunneling Across IPv4 Networks | 1398
Components of Filter-Based Tunneling Across IPv4 Networks | 1407
Firewall Filter Terminang Acons | 886
tunnel-end-point
Example: Transporng IPv6 Trac Across IPv4 Using Filter-Based Tunneling | 1413
1406
Components of Filter-Based Tunneling Across IPv4 Networks
IN THIS SECTION
Topology of Filter-Based Tunneling Across IPv4 Networks | 1407
Terminology at the Network Layer Protocols Level | 1409
Terminology at the Ingress PE Router | 1409
Terminology at the Egress PE Router | 1410
GRE Protocol Format for Filter-Based Tunneling Across IPv4 Networks | 1410
Topology of Filter-Based Tunneling Across IPv4 Networks
NOTE: Filter-based generic roung encapsulaon (GRE) tunneling is supported on PTX Series
routers only when network services is set to enhanced-mode. For more informaon, see enhanced-mode.
Figure 61 on page 1408 shows the path of passenger protocol packets from customer network C1 as
they are transported across a service provider IPv4 network to customer network C2.
1407
Figure 61: Unidireconal Filter-Based Tunnel Across an IPv4 Network
In this example topology, C1 and C2 are disjoint networks that lack a nave roung path between them.
The IPv4 transport network is congured with a unidireconal generic roung encapsulaon (GRE)
tunnel from PE1 to PE2 using rewall lters and without requiring tunnel interfaces. The GRE tunnel
from PE1 to PE2 provides a logical path from C1 to C2 across the IPv4 transport network.
Roung of GRE Packets Across the Tunnel
Trac ows through the tunnel provided that PE2 is routable from PE1. Roung paths from PE1 to PE2
can be provided by stac routes manually added to roung tables or by stac or dynamic route-sharing
protocols.
Roung of Passenger Protocol Packets from PE2 to C2
By default, PE2 forwards packets based on interface routes (direct routes) imported from the primary
roung table. As an opon, the de-encapsulang lter can specify that the Packet Forwarding Engine
uses an alternate roung table to forward payload packets to the desnaon customer network. Specify
the alternate roung table in a roung instance installed with routes into C2, then use a roung
informaon base (RIB) group denion to share the primary routes with the alternate routes. A RIB
group species the sharing of roung informaon (including routes learned from peers, local routes
resulng from the applicaon of protocol policies to the learned routes, and the routes adversed to
peers) of mulple roung tables.
1408
Terminology at the Network Layer Protocols Level
In lter-based tunneling across an IPv4 network, the network-layer protocols are described in the
following terms:
passenger
protocol
The type of protocol (IPv4, IPv6, or MPLS) used by the networks that are
connected by a GRE tunnel. Packets that are encapsulated and routed across the
transport network are
payload packets
.
encapsulaon
protocol
The type of network layer protocol (GRE) used to encapsulate passenger protocol
packets so that the resulng GRE packets can be carried over the transport
protocol network as the packet payload.
transport protocol
The type of protocol (IPv4) used by the network that routes passenger protocol
packets through a GRE tunnel. The transport protocol is also called the
delivery
protocol
.
Terminology at the Ingress PE Router
In lter-based tunneling across an IPv4 network, an egress PE router is described in the following terms:
encapsulator
A PE router that receives packets from a passenger protocol source network, adds an
encapsulaon protocol (GRE) header and a transport protocol (IPv4) header to this
payload, and forwards the resulng GRE packet to the GRE tunnel. This ingress node
is also known as the
tunnel source
.
encapsulang
interface
On the encapsulator, an Ethernet
logical interface
or an aggregated Ethernet
interface congured on a customer-facing interface hosted on a MIC or an MPC. The
encapsulang interface receives passenger protocol packets from a CE router. For
more informaon, see "Interfaces That Support Filter-Based Tunneling Across IPv4
Networks" on page 1405.
encapsulaon
lter
On the encapsulator, a
rewall lter
that you apply to the input of the encapsulang
interface. The encapsulang lter acon causes the Packet Forwarding Engine to use
informaon in the specied tunnel template to encapsulate matched packets and
forward the resulng GRE packets.
tunnel source
interface
On the encapsulator, one or more core-facing egress interfaces to the tunnel.
tunnel template
On the encapsulator, a named CLI construct that denes the characteriscs of a
tunnel:
1409
• Transport protocol family (IPv4).
• IP address or address range of tunnel-facing
egress
interfaces on the
encapsulator.
• IP address or address range of tunnel-facing
ingress
interfaces on the de-
encapsulator (the egress PE router).
• Encapsulaon protocol (GRE).
Terminology at the Egress PE Router
In lter-based tunneling across IPv4 networks, an egress PE router is described in the following terms:
de-encapsulator
A PE router that receives GRE packets routed through a lter-based GRE tunnel,
removes the transport protocol header and GRE header, and forwards the resulng
payload protocol packets to the desnaon network CE router. The de-encapsulator
node is also known as a
de-encapsulang tunnel endpoint
or the
tunnel desnaon
.
de-
encapsulang
interfaces
On the de-encapsulator, any Ethernet logical interface or aggregated Ethernet
interface congured on any core-facing ingress interface that can receive GRE
packets from a GRE tunnel. The underlying physical interface must be hosted on a
MIC or an MPC. For more informaon, see "Interfaces That Support Filter-Based
Tunneling Across IPv4 Networks" on page 1405.
de-
encapsulaon
lter
On the de-encapsulator, a rewall lter that causes the Packet Forwarding Engine to
de-encapsulate matched GRE packets and then forward the original passenger
protocol packets to desnaon network CE routers.
GRE packets transported through a single GRE tunnel can arrive at the de-
encapsulator node on any of mulple ingress interfaces, depending on how roung is
congured. Therefore, you must apply the de-encapsulaon rewall lter to the input
of every core-facing interface that is an adversed address for the de-encapsulator.
GRE Protocol Format for Filter-Based Tunneling Across IPv4 Networks
In lter-based tunneling across IPv4 networks, the encapsulang interface is an
RFC 1701-compliant
transmier
and the de-encapsulang interfaces are
RFC 1701-compliant receivers
. The packet
encapsulaon structure implemented in this feature uses a GRE header format that complies with
informaonal RFC 1701,
Generic Roung Encapsulaon (GRE)
, October 1994, and with standards track
RFC 2784,
Generic Roung Encapsulaon (GRE)
, March 2000.
1410
Packet Encapsulaon Structure
Filter-based tunneling encapsulates the original passenger protocol packet in an outer shell. For lter-
based tunneling across IPv4 networks, the shell adds 24 bytes or 28 bytes of overhead, including
20 bytes of IPv4 header. Figure 62 on page 1411 shows the structure of a passenger protocol packet
(the GRE payload) with a GRE header and IPv4 header aached.
Figure 62: Encapsulaon Structure for Filter-Based Tunneling Across an IPv4 Network
As specied in RFC 1701, ve GRE ag bits indicate whether a parcular GRE header includes any
oponal elds (Checksum, Oset, Key, Sequence Number, and Roung). Of the ve oponal elds,
lter-based GRE IPv4 tunneling uses the Key eld only.
GRE Header Format
Figure 63 on page 1411 shows the format of the variable-size GRE header used for lter-based
tunneling across IPv4 networks, with bit 0 the most signicant bit and bit 15 the least signicant bit.
Figure 63: GRE Header Format for Filter-Based Tunneling Across IPv4 Networks
The rst two octets encode GRE ags, as described in Table 67 on page 1412.
1411
The 2-octet Protocol Type eld contains the value 0x0800 to specify the EtherType value for the IPv4
protocol.
The 4-octet Key eld is included only if the Key Present bit is set to 1. The Key eld carries the key value
of the tunnel dened on the encapsulator. If the GRE tunnel denion species a key, the Packet
Forwarding Engine for the encapsulang endpoint sets the Key Present bit and adds the Key to the GRE
header.
Table 67: GRE Flag Values for Filter-Based Tunneling Across IPv4 Networks
Bit Oset and Field Name Transmied Value for Filter-Based GRE Tunneling
0 C = Checksum Present 0 Checksum eld is not used.
1 R = Roung Present 0 Oset and Roung elds are not used.
2 K = Key Present 0 or 1 Transmied as 0 for a keyless tunnel or 1 for a keyed
tunnel.
3 S = Sequence Number Present 0 Sequence Number eld is not used.
4 s = Strict Source Route 0 Not all roung informaon is Strict Source Routes.
5 - 7 Recur = Recursion Control inform
aon
000 No addional encapsulaons are permied.
8 - 12 Flags = Flag bits 0000
0
Reserved.
13 - 15 Ver = Version number 000 Reserved.
When the Packet Forwarding Engine performs encapsulaon for a keyed GRE IPv4 tunnel, the process
constructs the rst two octets of the GRE header as 0x0000. When the Packet Forwarding Engine
performs encapsulaon for a non-keyed GRE IPv4 tunnel, the process constructs the rst two octets of
the GRE header as 0x2000.
1412
RELATED DOCUMENTATION
Understanding Filter-Based Tunneling Across IPv4 Networks | 1398
Interfaces That Support Filter-Based Tunneling Across IPv4 Networks | 1405
Firewall Filter Terminang Acons | 886
tunnel-end-point
Example: Transporng IPv6 Trac Across IPv4 Using Filter-Based Tunneling | 1413
Example: Transporng IPv6 Trac Across IPv4 Using Filter-Based
Tunneling
IN THIS SECTION
Requirements | 1413
Overview | 1415
Conguraon | 1418
Vericaon | 1429
This example shows how to congure a unidireconal generic roung encapsulaon (GRE) tunnel to
transport IPv6 unicast transit trac across an IPv4 transport network. To provide network connecvity
to the two disjoint IPv6 networks, two MX Series 5G Universal Roung Plaorms are congured with
interfaces that can originate and understand both IPv4 and IPv6 packets. The conguraon does not
require the creaon of tunnel interfaces on Tunnel Services physical interface cards (PICs) or on MPC3E
Modular Port Concentrators (MPCs). Instead, you aach rewall lters to Ethernet logical interfaces
hosted on Modular Interface Cards (MICs) or MPCs in the two MX Series routers.
NOTE: Filter-based GRE tunneling is supported on PTX Series routers only when network
services is set to enhanced-mode. For more informaon, see enhanced-mode.
Requirements
This example uses the following Juniper Networks hardware and Junos OS soware:
• Transport network—An IPv4 network running Junos OS Release 12.3R2 or later.
1413
• PE routers—Two MX80 routers installed as provider edge (PE) routers that connect the IPv4 network
to two disjoint IPv6 networks that require a logical path from one network to the other.
• Encapsulang interface—On the encapsulator (the ingress PE router), one Ethernet logical interface
congured on the built-in 10-Gigabit Ethernet MIC.
• De-encapsulang interfaces—On the de-encapsulator (the egress PE router), Ethernet logical
interfaces congured on three ports of the built-in 10-Gigabit Ethernet MIC.
Before you begin conguring this example:
1. On each PE router, use the show chassis fpc pic-status operaonal mode command to determine
which router line cards support lter-based GRE IPv4 tunneling and then use the interfaces
conguraon statement to congure encapsulang and de-encapsulang interfaces.
• At PE1, the encapsulator, congure
one encapsulang interface
on a supported line card.
• At PE2, the de-encapsulator, congure
three de-encapsulang interfaces
on a supported line card.
2. Check that IPv4 roung protocols are enabled across the network to support roung paths from the
encapsulator to the de-encapsulator.
Congure roung informaon by manually adding stac routes to route tables or by conguring
stac or dynamic route-sharing protocols. For more informaon, see Transport and Internet Protocols
User Guide.
3. At PE1,
ping
the PE2 IPv4 loopback address to verify that the de-encapsulator is reachable from the
encapsulator.
4. At PE2,
ping
the CE2 router IPv6 loopback address to verify that the desnaon customer edge
router is reachable from the de-encapsulator..
IPv6 roung paths from PE2 to CE2 can be provided by stac routes manually added to roung
tables or by stac or dynamic route-sharing protocols.
• By default, PE2 forwards packets based on interface routes (direct routes) imported from the
primary roung table.
• As an opon, the de-encapsulang lter can specify that the Packet Forwarding Engine uses an
alternate roung table to forward payload packets to the desnaon customer network. In an
oponal conguraon task in this example, you specify an alternate roung table by installing
stac routes from PE2 to C1 in the roung instance blue. You congure the roung informaon
base (RIB) group blue_group to specify that the route informaon of inet6.0 is shared with
blue.inet6.0, then you associate the PE2 interfaces with routes stored in both the default routes
and the roung instance.
1414
Overview
IN THIS SECTION
Topology | 1415
In this example you congure a unidireconal lter-based GRE IPv4 tunnel from Router PE1 to Router
PE2, providing a logical path from IPv6 network C1 to IPv6 network C2.
NOTE: To enable
bidireconal
lter-based GRE tunneling, you must congure a second tunnel in
the reverse direcon.
As an oponal task in this example, you can create a RIB group, which species the sharing of roung
informaon (including routes learned from peers, local routes resulng from the applicaon of protocol
policies to the learned routes, and the routes adversed to peers) of mulple roung tables.
Topology
Figure 64 on page 1416 shows the path of IPv6 trac transported from network C1 to network C2,
across an IPv4 transport network using a lter-based tunnel from PE1 to PE2 and without requiring
tunnel interfaces.
1415
Figure 64: Filter-Based Tunnel from PE1 to PE2 in an IPv4 Network
Table 68 on page 1416 summarizes the conguraon of Router PE1 as the encapsulator. Table 69 on
page 1417 summarizes the conguraon of Router PE2 as the de-encapsulator.
Table 68: Encapsulator Components on PE1
Component CLI Names Descripon
Encapsulator Device name:
IPv4 loopbac
k:
IPv6
loopback:
PE1
10.255.1.1
2001:db8::1
MX80 router installed as an ingress PE router. PE1
connects the IPv4 network the customer edge
router CE1 in the IPv6 source network C1.
Encapsulang
interface
Interface na
me:
IPv4 address:
IPv6 address:
xe-0/0/0.0
10.0.1.10/30
::10.34.1.10/120
Customer-facing logical interface hosted on a 10-
Gigabit Ethernet MIC. CE1 sends this interface
IPv6 trac that originates at end-user hosts and is
desned for applicaons or hosts on the IPv6
desnaon network C2.
1416
Table 68: Encapsulator Components on PE1
(Connued)
Component CLI Names Descripon
Encapsulaon lter Filter name:
gre_encap_1
IPv6 rewall lter whose acon causes the Packet
Forwarding Engine to encapsulate matched
packets using the specied tunnel characteriscs.
Encapsulaon consists of adding a GRE header,
adding an IPv4 packet header, and then forwarding
the resulng GRE packet through the GRE IPv4
tunnel.
Tunnel source
interface
Interface na
me:
IPv4 address:
xe-0/0/2.0
10.0.1.12
Core-facing egress interface to the tunnel.
GRE tunnel template Tunnel name:
tunnel_1
Denes the GRE IPv4 tunnel from Router PE1
(10.255.1.1) to Router PE2(10.255.2.2), using the
tunneling protocol supported on IPv4 (gre).
Table 69: De-Encapsulator Components on PE2
Component CLI Names Descripon
De-encapsulator Device name:
IPv4
loopback:
IPv6
loopback:
PE2
10.255.2.2
2001:fc3::2
MX80 router installed as an egress PE router to
receive GRE packets forwarded from ingress router
PE1 across a GRE IPv4 tunnel.
De-encapsulang
interfaces
Interface na
me:
IPv4 address:
Interface na
me:
IPv4 address:
Interface na
me:
IPv4 address:
xe-0/0/0.0
10.0.2.24/30
xe-0/0/1.0
10.0.2.21/30
xe-0/0/2.0
10.0.2.22/30
Core-facing ingress logical interfaces hosted on 10-
Gigabit Ethernet MICs. The interfaces receive GRE
packets routed through the GRE IPv4 tunnel from
PE1.
1417
Table 69: De-Encapsulator Components on PE2
(Connued)
Component CLI Names Descripon
De-encapsulaon
lter
Filter name:
gre_decap_1
IPv4 rewall lter that applies the decapsulate
acon to GRE packets. The lter acon causes the
Packet Forwarding Engine to de-encapsulate
matched packets.
De-encapsulaon consists of removing the outer
GRE header and then forwarding the inner IPv6
payload packet to its original desnaon on the
desnaon IPv6 network by performing desnaon
lookup on the default roung table.
Tunnel egress
interface
Interface na
me:
IPv4 address:
IPv6 address:
xe-0/0/3.0
10.0.2.23/30
::20.34.2.23/1
20
Customer-facing interface though which the router
forwards de-encapsulated IPv6 packets to the
desnaon IPv6 network C2.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1418
Conguring PE1 to Encapsulate IPv6 Packets | 1420
Conguring PE2 to De-Encapsulate GRE Packets | 1423
Oponal: Conguring PE2 with an Alternate Roung Table | 1427
To transport IPv6 packets from CE1 to CE2 across an IPv4 transport network using a lter-based tunnel
from PE1 to PE2 and without conguring tunnel interfaces, perform these tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
1418
Conguring PE1 to Encapsulate IPv6 Packets
set interfaces lo0 unit 0 family inet address 10.255.1.1
set interfaces lo0 unit 0 family inet6 address 2001:db8::1
set interfaces xe-0/0/0 unit 0 family inet address 10.0.1.10/30
set interfaces xe-0/0/0 unit 0 family inet6 address 2001::10.34.1.10/120
set interfaces xe-0/0/0 unit 0 family inet6 filter input gre_encap_1
set interfaces xe-0/0/2 unit 0 family inet address 10.0.1.12/30
set firewall family inet6 filter gre_encap_1 term t1 then count c_gre_encap_1
set firewall family inet6 filter gre_encap_1 term t1 then encapsulate tunnel_1
set firewall tunnel-end-point tunnel_1 ipv4 source-address 10.255.1.1
set firewall tunnel-end-point tunnel_1 ipv4 destination-address 10.255.2.2
set firewall tunnel-end-point tunnel_1 gre
Conguring PE2 to De-Encapsulate GRE Packets
set interfaces lo0 unit 0 family inet address 10.255.2.2
set interfaces lo0 unit 0 family inet6 address 2001:fc3::2
set interfaces xe-0/0/0 unit 0 family inet address 10.0.2.20/30
set interfaces xe-0/0/1 unit 0 family inet address 10.0.2.21/30
set interfaces xe-0/0/2 unit 0 family inet address 10.0.2.22/30
set interfaces xe-0/0/3 unit 0 family inet address 10.0.2.23/30
set interfaces xe-0/0/3 unit 0 family inet6 address ::20.34.2.23/120
set forwarding-options family inet filter input gre_decap_1
set firewall family inet filter gre_decap_1 term t1 from source-address 10.255.1.1/32
set firewall family inet filter gre_decap_1 term t1 from destination-address 10.255.2.2/32
set firewall family inet filter gre_decap_1 term t1 then count c_gre_decap_1
set firewall family inet filter gre_decap_1 term t1 then decapsulate gre
Oponal: Conguring PE2 with an Alternate Roung Table
set routing-instances blue instance-type forwarding
set routing-instances blue routing-options rib blue.inet6.0 static route 0::/0 next-hop
fec0:0:2003::2
set routing-options passive
set routing-options rib inet6.0
set routing-options rib-groups blue_group import-rib inet6.0
set routing-options rib-groups blue_group import-rib blue.inet6.0
1419
set routing-options interface-routes rib-group inet6 blue_group
set firewall family inet filter gre_decap_1 term t1 then decapsulate gre routing-instance blue
Conguring PE1 to Encapsulate IPv6 Packets
Step-by-Step Procedure
To congure Router PE1 to encapsulate IPv6 packets arriving from CE1:
1. Congure the router loopback addresses.
[edit]
user@PE1# set interfaces lo0 unit 0 family inet address 10.255.1.1
user@PE1# set interfaces lo0 unit 0 family inet6 address 2001:db8::1
2. Congure the encapsulang interface IPv4 and IPv6 addresses and aach the encapsulang lter to
the IPv6 input.
[edit]
user@PE1# set interfaces xe-0/0/0 unit 0 family inet address 10.0.1.10/30
user@PE1# set interfaces xe-0/0/0 unit 0 family inet6 address ::10.34.1.10/120
user@PE1# set interfaces xe-0/0/0 unit 0 family inet6 filter input gre_encap_1
3. Congure the core-facing egress interface to the tunnel.
[edit]
user@PE2# set interfaces xe-0/0/2 unit 0 family inet address 10.0.1.12/30
4. Dene an IPv6 rewall lter that causes the Packet Forwarding Engine to encapsulate all packets.
[edit]
user@PE1# set firewall family inet6 filter gre_encap_1 term t1 then count c_gre_encap_1
user@PE1# set firewall family inet6 filter gre_encap_1 term t1 then encapsulate tunnel_1
1420
NOTE: The encapsulate rewall lter acon is a
terminang
lter acon. A lter-terminang
acon halts all evaluaon of a rewall lter for a specic packet. The router performs the
specied acon, and no addional terms are examined.
5. Dene a GRE IPv4 tunnel template named tunnel_1 that species the host IP addresses of the one
tunnel source interface and three tunnel desnaon interfaces.
[edit]
user@PE1# set firewall tunnel-end-point tunnel_1 ipv4 source-address 10.255.1.1
user@PE1# set firewall tunnel-end-point tunnel_1 ipv4 destination-address 10.255.2.2
user@PE1# set firewall tunnel-end-point tunnel_1 gre
NOTE: You can tunnel mulple but disnct ows from 10.0.1.10 (the tunnel source interface
on PE1) to 10.0.2.20 – 10.0.2.22 (the de-encapsulang interfaces on PE2) if you use the GRE
opon key
number
to uniquely idenfy each tunnel.
6. If you are done conguring the device, commit the conguraon.
[edit ]
user@PE1# commit
Results
From conguraon mode, conrm your conguraon by entering the show firewall and show interfaces
commands. If the output does not display the intended conguraon, repeat the instrucons in this
example to correct the conguraon.
Router PE1
Conrm the rewall lter and tunnel template on the encapsulator.
user@PE2# show firewall
family inet6 {
filter gre_encap_1 {
term t1 {
then {
count c_gre_encap_1;
1421
encapsulate tunnel_1;
}
}
}
}
tunnel-end-point tunnel_1 {
ipv4 {
source-address 10.255.1.1;
destination-address 10.255.2.2;
}
gre;
}
Router PE1
Conrm the interfaces on the encapsulator.
user@PE1# show interfaces
lo0 {
unit 0 {
family inet {
address 10.255.1.1;
}
family inet6 {
address 2001:db8::1;
}
}
}
xe-0/0/0 {
unit 0 {
family inet {
address 10.0.1.10/30;
}
family inet6 {
address ::10.34.1.10/120;
filter input gre_encap_1;
}
}
}
xe-0/0/2 {
unit 0 {
family inet {
1422
address 10.0.1.12/30;
}
}
}
Conguring PE2 to De-Encapsulate GRE Packets
Step-by-Step Procedure
To congure Router PE2 to de-encapsulate GRE packets arriving from the IPv4 tunnel:
1. Congure the router loopback address.
[edit]
user@PE2# set interfaces lo0 unit 0 family inet address 10.255.2.2
user@PE2# set interfaces lo0 unit 0 family inet6 address 2001:fc3::2
2. Congure the de-encapsulang interfaces.
[edit]
user@PE2# set interfaces xe-0/0/0 unit 0 family inet address 10.0.2.20/30
user@PE2# set interfaces xe-0/0/1 unit 0 family inet address 10.0.2.21/30
user@PE2# set interfaces xe-0/0/2 unit 0 family inet address 10.0.2.22/30
3. Congure the customer-facing egress interface to CE2.
[edit]
user@PE2# set interfaces xe-0/0/3 unit 0 family inet address 10.0.2.23/30
user@PE2# set interfaces xe-0/0/3 unit 0 family inet6 address ::20.34.2.23/120
4. Apply the ingress de-encapsulang rewall lter to all forwarded packets.
[edit]
user@PE2# set forwarding-options family inet filter input gre_decap_1
5. Dene IPv4 lter gre_decap_1.
1423
Dene an IPv4 lter that de-encapsulates and forwards all GRE packets.
[edit]
user@PE2# set firewall family inet filter gre_decap_1
6. Congure term t1 to match packets transported across the tunnel tunnel_1 dened on Router PE1.
The tunnel sends packets from Router PE1 (congured with IPv4 loopback address 10.255.1.1) to
Router PE2 (congured with IPv4 loopback address 10.255.2.2).
[edit firewall family inet filter gre_decap_1]
user@PE2# set term t1 from source-address 10.255.1.1
user@PE2# set term t1 from destination-address 10.255.2.2
7. Congure term t1 to count and de-encapsulate matched packets.
[edit firewall family inet filter gre_decap_1]
user@PE2# set term t1 then count c_gre_decap_1
user@PE2# set term t1 then decapsulate gre
If the de-encapsulang lter acon decapsulate references the blue roung instance, make sure that
the roung instance is congured and that the RIB group blue_group denes the sharing of the
alternate routes into the primary table.
8. If you are done conguring the device, commit the conguraon.
[edit]
user@PE2# commit
Results
From conguraon mode, conrm your conguraon by entering the show firewall, show forwarding-options,
and show interfaces commands. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
Router PE2
1424
Conrm the rewall lter on the de-encapsulator.
user@PE2# show firewall
family inet {
filter gre_decap_1 {
term t1 {
from {
source-address 10.255.1.1;
destination-address 10.255.2.2;
}
then {
count c_gre_decap_1;
decapsulate gre routing-instance blue;
}
}
}
}
NOTE: If the de-encapsulang lter acon decapsulate references the blue roung instance,
make sure that the roung instance is congured and that the RIB group blue_group denes the
sharing of the alternate routes into the primary table.
Router PE2
Conrm the forwarding opons (for aaching the de-encapsulang rewall lter to all input forwarded
packets) on the de-encapsulator.
user@PE2# show forwarding-options
forwarding-options {
family inet {
filter {
input gre_decap_1;
}
}
}
Router PE2
1425
Conrm the interfaces on the de-encapsulator.
user@PE2# show interfaces
lo0 {
unit 0 {
family inet {
address 10.255.2.2;
}
family inet6 {
address 2001:fc3::2;
}
}
}
xe-0/0/0 {
unit 0 {
family inet {
address 10.0.2.20/30;
filter input gre_decap_1;
}
}
}
xe-0/0/1 {
unit 0 {
family inet {
address 10.0.2.21/30;
filter input gre_decap_1;
}
}
}
xe-0/0/2 {
unit 0 {
family inet {
address 10.0.2.22/30;
filter input gre_decap_1;
}
}
}
xe-0/0/3 {
unit 0 {
family inet {
address 10.0.2.23/30;
}
1426
family inet6 {
address ::20.34.2.23/120;
}
}
}
Oponal: Conguring PE2 with an Alternate Roung Table
Step-by-Step Procedure
To congure Router PE2 with an alternate roung table:
1. Congure the roung instance blue, and add stac routes to CE2.
[edit ]
user@PE2# set routing-instances blue instance-type forwarding
user@PE2# set routing-instances blue routing-options rib blue.inet6.0 static route 0::/0 next-
hop fec0:0:2003::2
The Junos OS soware generates the roung table blue.inet6.0 using the roung informaon
learned within the instance.
2. Enable routes to remain in roung and forwarding tables, even if the routes become inacve. This
allows a stac route to remain in the table if the next hop is unavailable.
[edit ]
user@PE2# set routing-options passive
3. Create a RIB group by explicitly creang the default roung table.
[edit ]
user@PE2# set routing-options rib inet6.0
4. Dene the RIB group blue_group.
[edit ]
user@PE2# set routing-options rib-groups blue_group import-rib inet6.0
user@PE2# set routing-options rib-groups blue_group import-rib blue.inet6.0
1427
In the import-rib statement, specify the primary roung table rst.
5. Associate the router interfaces with roung informaon specied by the RIB group.
[edit ]
user@PE2# set routing-options interface-routes rib-group inet6 blue_group
6. If you are done conguring the device, commit the conguraon.
[edit ]
user@PE2# commit
Results
From conguraon mode, conrm your conguraon by entering the show firewall, show routing-instances,
and show routing-optionscommands. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
Router PE2
If you congured an alternate roung table on Router PE2, conrm the roung instance conguraon.
user@PE2# show routing-instances
blue {
instance-type forwarding;
routing-options {
static route 0::/0 next-hop fec0:0:2003::2;
}
}
Router PE2
If you congured an alternate roung table on Router PE2, conrm the RIB group and direct roung
conguraons.
user@PE2# show routing-options
interface-routes {
rib-group blue_group;
}
passive;
1428
rib inet6.0;
rib-groups {
blue_group {
import-rib [ inet6.0 blue.inet6.0 ];
}
}
Vericaon
IN THIS SECTION
Verifying Roung Informaon | 1429
Verifying Encapsulaon on PE1 | 1431
Verifying De-Encapsulaon on PE2 | 1432
Conrm that the conguraons are working properly.
Verifying Roung Informaon
Purpose
Verify that the direct routes include the alternate roung table informaon.
Acon
To perform the vericaon:
1. (Oponal) To verify the roung instance blue on PE2, use the show route instance operaonal mode
command to display the primary table and number of routes for that roung instance.
user@PE2> show route instance blue summary
Instance Type
Primary RIB Active/holddown/hidden
blue forwarding
blue.inet6.0 2/0/0
1429
2. (Oponal) To view the roung table associated with the roung instance blue on PE2, use the show
route table operaonal mode command
user@PE2> show route table blue.inet6.0
blue.inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::192:168:239:17/128
*[Direct/0] 00:02:26
> via lo0.0
fe80::2a0:a50f:fc64:e032/128
*[Direct/0] 00:02:26
> via lo0.0
3. (Oponal) To verify that the alternate routes from roung instance blue have been imported to the
PE2 forwarding table, use the show route forwarding-table operaonal mode command to display
the contents of the router forwarding table and the roung instance forwarding table.
user@PE2> show route forwarding-table blue
Routing table: blue.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 689 1
0.0.0.0/32 perm 0 dscd 687 1
172.16.233.0/4 perm 0 mdsc 688 1
172.16.233.1/32 perm 0 172.16.233.1 mcst 684 1
255.255.255.255/32 perm 0 bcst 685 1
Routing table: blue.iso
ISO:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 695 1
Routing table: blue.inet6
Internet6:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 701 1
::/128 perm 0 dscd 699 1
2001:db8::192:168:239:17/128
user 0 rtbl 2 3
1430
fe80::2a0:a50f:fc64:e032/128
user 0 rtbl 2 3
ff00::/8 perm 0 mdsc 700 1
ff02::1/128 perm 0 ff02::1 mcst 697 1
Verifying Encapsulaon on PE1
Purpose
Verify the encapsulang interface on PE1.
Acon
To perform the vericaon:
1. Use the show interfaces lters operaonal mode command to verify that the encapsulang rewall
lter is aached to the ingress of the encapsulang interface.
user@PE1> show interfaces filters xe-0/0/0.0
Interface Admin Link Proto Input Filter Output Filter
xe-0/0/0.0 up down inet6 gre_encap_1
2. Use the show interfaces operaonal mode command to verify that the encapsulang interface is
receiving packets.
user@PE1> show interfaces xe-0/0/0.0 detail | filter ”Ingress traffic”
...
Physical interface: xe-0/0/0, Enabled, Physical link is Up
...
Ingress traffic statistics at Packet Forwarding Engine:
Input bytes : 6970299398 0 bps
Input packets: 81049992 0 pps
Drop bytes : 0 0 bps
Drop packets: 0 0 pps
...
1431
3. Use the show rewall lter operaonal mode command to verify that ingress passenger protocol
trac triggers the encapsulang lter.
user@PE1> show firewall filter gre_encap_1
Filter: gre_encap_1
Counters:
Name Bytes Packets
c_gre_encap_1 6970299398 81049992
Meaning
If the encapsulang lter is aached to the encapsulang interface, and the encapsulang interface
receives passenger protocol trac, and the rewall lter stascs show that ingress passenger protocol
trac is being encapsulated, then GRE packets are being forwarded through the tunnel.
Verifying De-Encapsulaon on PE2
Purpose
Verify the de-encapsulang interfaces on PE2.
Acon
To perform the vericaon:
1. On PE1, use the ping operaonal mode command to verify that PE2 is reachable.
user@PE1> ping 10.255.2.2
PING 10.255.2.2 (10.255.2.2): 56 data bytes
64 bytes from 10.255.2.2: icmp_seq=0 ttl=64 time=0.576 ms
64 bytes from 10.255.2.2: icmp_seq=1 ttl=64 time=0.269 ms
^C [abort]
2. On PE2, use the show interfaces lter operaonal mode command to verify that the de-
encapsulang rewall lter is aached to the ingress of the de-encapsulang interfaces.
user@PE2> show interfaces filter | match xe-
Interface Admin Link Proto Input Filter Output Filter
xe-0/0/0.0 up down inet gre_decap_1
1432
xe-0/0/1.0 up down inet gre_decap_1
xe-0/0/2.0 up down inet gre_decap_1
3. On PE2, use the show interfaces operaonal mode command to verify that the de-encapsulang
interfaces are receiving packets.
user@PE2> show interfaces xe-0/0/0.0 detail | filter ”Ingress traffic”
Physical interface: xe-0/0/0, Enabled, Physical link is Up
...
Ingress traffic statistics at Packet Forwarding Engine:
Input bytes : 6970299398 0 bps
Input packets: 81049992 0 pps
Drop bytes : 0 0 bps
Drop packets: 0 0 pps
...
user@PE2> show interfaces xe-0/0/1.0 detail | filter ”Ingress traffic”
Physical interface: xe-0/0/2, Enabled, Physical link is Up
...
user@PE2> show interfaces xe-0/0/2.0 detail | filter ”Ingress traffic”
Physical interface: xe-0/0/2, Enabled, Physical link is Up
...
Depending on how roung is congured and which links are up and which links are down, some of
the de-encapsulang interfaces might not be receiving packets although the tunnel is operang
properly.
4. On PE2, use the show rewall lter operaonal mode command to verify that ingress GRE trac
triggers the de-encapsulang lter.
user@PE2> show firewall filter gre_decap_1
Filter: gre_decap_1
Counters:
Name Bytes Packets
c_gre_decap_1 6970299398 81049992
1433
Meaning
The vericaon conrms the following operaonal states and acvies of the encapsulator:
• PE2 is reachable from the PE1.
• The de-encapsulang lter is aached to the input of all de-encapsulang interfaces.
• The de-encapsulator is receiving trac at de-encapsulang interfaces as expected.
• GRE packets received at the de-encapsulang interfaces trigger the de-encapsulang rewall lter
acon.
RELATED DOCUMENTATION
Understanding Filter-Based Tunneling Across IPv4 Networks | 1398
Interfaces That Support Filter-Based Tunneling Across IPv4 Networks | 1405
Components of Filter-Based Tunneling Across IPv4 Networks | 1407
Firewall Filter Terminang Acons | 886
tunnel-end-point
clear rewall
show chassis fpc
show rewall
show rewall log
show interfaces (Aggregated Ethernet)
show interfaces
show route forwarding-table
Junos OS Support for IPv4, IPv6, and MPLS Roung Protocols
1434
CHAPTER 22
Conguring Service Filters
IN THIS CHAPTER
Service Filter Overview | 1435
How Service Filters Evaluate Packets | 1437
Guidelines for Conguring Service Filters | 1439
Guidelines for Applying Service Filters | 1442
Example: Conguring and Applying Service Filters | 1445
Service Filter Match Condions for IPv4 or IPv6 Trac | 1453
Service Filter Nonterminang Acons | 1464
Service Filter Terminang Acons | 1465
Service Filter Overview
IN THIS SECTION
Services | 1435
Service Rules | 1436
Service Rule Renement | 1436
Service Filter Counters | 1436
Services
The Adapve Services Physical Interface Cards (PICs), Mulservices PICs, and Mulservices Dense Port
Concentrators (DPCs) provide
adapve services interfaces
. Adapve services interfaces enable you to
coordinate a special range of services on a single PIC or DPC by conguring a set of services and
applicaons.
1435
NOTE: Service lters are not supported on T4000 routers.
Service Rules
A
service set
is an oponal denion you can apply to the trac at an adapve services interface. A
service set enables you to congure combinaons of direconal rules and default sengs that control
the behavior of each service in the service set.
Service Rule Renement
When you apply a service set to the trac at an adapve services interface, you can oponally use
service lters
to rene the target of the set of services and also to process trac. Service lters enable
you to manipulate trac by performing packet ltering to a dened set of services on an adapve
services interface before the trac is delivered to its desnaon. You can apply a service lter to trac
before packets are accepted for input or output service processing or aer packets return from input
service processing.
Service Filter Counters
Like standard rewall lters, service lters support counng of matched packets. When you display
counters for a service lter, however, the syntax for specifying the lter name includes the name of the
service set
to which the service lter is applied.
• To enable counng of the packets matched by a service lter term, specify the count
counter-name
nonterminang acon in that term.
• To display counters for service lters, use the show firewall filter
filter-name
<counter
counter-name
>
operaonal mode command
, and specify the
filter-name
as follows:
__service-
service-set-name
:
service-filter-name
For example, suppose you congure a service lter named out_filter with a counter named out_counter
and apply that service lter to a
logical interface
to direct certain packets for processing by the output
1436
services associated with the service set nat_set. In this scenario, the syntax for using the show firewall
operaonal mode command to display the counter is as follows:
[edit]
user@host> show firewall filter __service-nat_set:out_filter counter out_counter
RELATED DOCUMENTATION
Stateless Firewall Filter Types
How Service Filters Evaluate Packets | 1437
Guidelines for Conguring Service Filters | 1439
Guidelines for Applying Service Filters | 1442
Example: Conguring and Applying Service Filters | 1445
Adapve Services and Mulservices Interfaces Overview
Conguring Service Sets to be Applied to Services Interfaces
Conguring Service Rules
How Service Filters Evaluate Packets
IN THIS SECTION
Service Filters That Contain a Single Term | 1437
Service Filters That Contain Mulple Terms | 1438
Service Filter Terms That Do Not Contain Any Match Condions | 1438
Service Filter Terms That Do Not Contain Any Acons | 1438
Service Filter Default Acon | 1438
Service Filters That Contain a Single Term
For a service lter that consists of a single term, the policy framework soware evaluates a packet as
follows:
1437
• If the packet matches all the condions, the acons are taken.
• If the packet matches all the condions and no acons are specied, the packet is accepted.
• If the packet does not match all the condions, it is discarded.
Service Filters That Contain Mulple Terms
For a service lter that consists of mulple terms, the policy framework soware evaluates a packet
against the terms in the lter sequenally, beginning with the rst term in the lter, unl either the
packet matches all the condions in one of the terms or there are no more terms in the lter.
• If the packet matches all the condions in a term, the acons in that term are performed and
evaluaon of the packet ends at that term. Any subsequent terms in the lter are not used.
• If the packet does not match all the condions in the term, evaluaon of the packet proceeds to the
next term in the lter.
Service Filter Terms That Do Not Contain Any Match Condions
For service lters with a single term and for lters with mulple terms, if a term does not contain any
match condions, the acons are taken on any packet evaluated.
Service Filter Terms That Do Not Contain Any Acons
If a term does not contain any acons, and if the packet matches the condions in the term, the packet
is accepted.
Service Filter Default Acon
Each service lter has an
implicit
skip acon at the end of the lter, which is equivalent to including the
following example term explicit_skip as the nal term in the service lter:
term explicit_skip {
then skip;
}
By default, if a packet matches none of the terms in a service lter, the packet bypasses service
processing.
1438
RELATED DOCUMENTATION
Service Filter Overview | 1435
Guidelines for Conguring Service Filters | 1439
Guidelines for Applying Service Filters | 1442
Example: Conguring and Applying Service Filters | 1445
Guidelines for Conguring Service Filters
IN THIS SECTION
Statement Hierarchy for Conguring Service Filters | 1439
Service Filter Protocol Families | 1440
Service Filter Names | 1440
Service Filter Terms | 1440
Service Filter Match Condions | 1440
Service Filter Terminang Acons | 1441
Statement Hierarchy for Conguring Service Filters
To congure a service lter, include the service-filter
service-filter-name
statement at the [edit firewall
family (inet | inet6)] hierarchy level:
[edit]
firewall {
family (inet | inet6) {
service-filter
service-filter-name
{
term
term-name
{
from {
match-conditions
;
}
then {
actions
;
}
}
1439
}
}
}
Individual statements supported under the service-filter
service-filter-name
statement are described
separately in this topic and are illustrated in the example of conguring and applying a service lter.
Service Filter Protocol Families
You can congure service lters to lter IPv4 trac (family inet) and IPv6 trac (family inet6) only. No
other protocol families are supported for service lters.
Service Filter Names
Under the family inet or family inet6 statement, you can include service-filter
service-filter-name
statements to create and name service lters. The lter name can contain leers, numbers, and hyphens
(-) and be up to 64 characters long. To include spaces in the name, enclose the enre name in quotaon
marks (“ ”).
Service Filter Terms
Under the service-filter
service-filter-name
statement, you can include term
term-name
statements to create
and name lter terms.
• You must congure at least one term in a
rewall lter
.
• You must specify a unique name for each term within a rewall lter. The term name can contain
leers, numbers, and hyphens (-) and can be up to 64 characters long. To include spaces in the name,
enclose the enre name in quotaon marks (“ ”).
• The order in which you specify terms within a rewall lter conguraon is important. Firewall lter
terms are evaluated in the order in which they are congured. By default, new terms are always
added to the end of the exisng lter. You can use the insert conguraon mode command to
reorder the terms of a rewall lter.
Service Filter Match Condions
Service lter terms support only a subset of the IPv4 and IPv6 match condions that are supported for
standard stateless rewall lters.
If you specify an IPv6 address in a match condion (the address, destination-address, or source-address match
condions), use the syntax for text representaons described in RFC 4291,
IP Version 6 Addressing
1440
Architecture
. For more informaon about IPv6 addresses, see “IPv6 Overview” in the Junos OS Roung
Protocols Library for Roung Devices.
Service Filter Terminang Acons
When conguring a service lter term, you must specify one of the following lter-terminang acons:
• service
• skip
NOTE: These acons are unique to service lters.
Service lter terms support only a subset of the IPv4 and IPv6 nonterminang acons that are
supported for standard stateless rewall lters:
•
count
counter-name
• log
• port-mirror
• sample
Service lters do not support the next acon.
RELATED DOCUMENTATION
Service Filter Overview | 1435
How Service Filters Evaluate Packets | 1437
Guidelines for Applying Service Filters | 1442
Service Filter Match Condions for IPv4 or IPv6 Trac | 1453
Service Filter Terminang Acons | 1465
Service Filter Nonterminang Acons | 1464
Example: Conguring and Applying Service Filters | 1445
1441
Guidelines for Applying Service Filters
IN THIS SECTION
Restricons for Adapve Services Interfaces | 1442
Statement Hierarchy for Applying Service Filters | 1443
Associang Service Rules with Adapve Services Interfaces | 1443
Filtering Trac Before Accepng Packets for Service Processing | 1444
Postservice Filtering of Returning Service Trac | 1445
Restricons for Adapve Services Interfaces
The following restricons apply to adapve services interfaces and service lters.
Adapve Services Interfaces
You can apply a service lter to IPv4 or IPv6 trac associated with a service set at an
adapve services
interface
only. Adapve services interfaces are supported for the following hardware only:
• Adapve Services (AS) PICs on M Series and T Series routers
• Mulservices (MS) PICs on M Series and T Series routers
• MS DPCs on MX Series routers and EX Series switches
• MS MPCs and MICs on MX Series routers
System Logging to a Remote Host from M Series Routers
Logging of adapve services interfaces messages to an external server by means of the fxp0 or em0 port is
not supported on M Series routers. The architecture does not support system logging trac out of a
management interface. Instead, access to an external server is supported on a Packet Forwarding Engine
interface.
1442
Statement Hierarchy for Applying Service Filters
You can enable packet ltering of IPv4 or IPv6 trac before a packet is accepted for input or output
service processing. To do this, apply a service lter to the adapve services interface input or output in
conjuncon with an interface service set.
You can also enable packet ltering of IPv4 or IPv6 trac that is returning to the Packet Forwarding
Engine aer input service processing completes. To do this, apply a post-service lter to the adapve
services interface input.
The following conguraon shows the hierarchy levels at which you can apply the service lters to
adapve services interfaces:
[edit]
interfaces {
interface-name
{
unit
unit-number
{
family (inet | inet6) {
service {
input {
service-set
service-set-name
service-filter
service-filter-name
;
post-service-filter
service-filter-name
;
}
output {
service-set
service-set-name
service-filter
service-filter-name
;
}
}
}
}
}
}
Associang Service Rules with Adapve Services Interfaces
To dene and group the service rules be applied to an adapve services interface, you dene an
interface service set
by including the service-set
service-set-name
statement at the [edit services] hierarchy
level.
To apply an interface service set to the input and output of an adapve services interface, you include
the service-set
service-set-name
at the following hierarchy levels:
• [edit interfaces
interface-name
unit
unit-number
input]
1443
• [edit interfaces
interface-name
unit
unit-number
output]
If you apply a service set to one direcon of an adapve services interface but do not apply a service set
to the other direcon, an error occurs when you commit the conguraon.
The adapve services PIC performs dierent acons depending on whether the packet is sent to the PIC
for input service or for output service. For example, you can congure a single service set to perform
Network Address Translaon (NAT) in one direcon and desnaon NAT (dNAT) in the other direcon.
Filtering Trac Before Accepng Packets for Service Processing
To lter IPv4 or IPv6 trac before accepng packets for input or output service processing, include the
service-set
service-set-name
service-filter
service-filter-name
at one of the following interfaces:
• [edit interfaces
interface-name
unit
unit-number
family (inet | inet6) service input]
• [edit interfaces
interface-name
unit
unit-number
family (inet | inet6) service output]
For the
service-set-name
, specify a service set congured at the [edit services service-set] hierarchy level.
The service set retains the input interface informaon even aer services are applied, so that funcons
such as lter-class forwarding and desnaon class usage (DCU) that depend on input interface
informaon connue to work.
The following requirements apply to ltering inbound or outbound trac before accepng packets for
service processing:
• You congure the same service set on the input and output sides of the interface.
• If you include the service-set statement without an oponal service-filter denion, the Junos OS
assumes the match condion is true and selects the service set for processing automacally.
• The service lter is applied only if a service set is congured and selected.
You can include more than one service set denion on each side of an interface. The following
guidelines apply:
• If you include mulple service sets, the router (or switch) soware evaluates them in the order in
which they appear in the conguraon. The system executes the rst service set for which it nds a
match in the service lter and ignores the subsequent denions.
• A maximum of six service sets can be applied to an interface.
• When you apply mulple service sets to an interface, you must also congure and apply a service
lter to the interface.
1444
Postservice Filtering of Returning Service Trac
As an opon to ltering of IPv4 or IPv6 input service trac, you can apply a service lter to IPv4 or IPv6
trac that is returning to the services interface aer the service set is executed. To apply a service lter
in this manner, include the post-service-filter
service-filter-name
statement at the [edit interfaces
interface-name
unit
unit-number
family (inet | inet6) service input] hierarchy level.
RELATED DOCUMENTATION
Service Filter Overview | 1435
How Service Filters Evaluate Packets | 1437
Guidelines for Conguring Service Filters | 1439
Example: Conguring and Applying Service Filters | 1445
Adapve Services and Mulservices Interfaces Overview
Conguring Service Sets to be Applied to Services Interfaces
Conguring Service Rules
Example: Conguring and Applying Service Filters
IN THIS SECTION
Requirements | 1445
Overview | 1446
Conguraon | 1447
Vericaon | 1451
This example shows how to congure and apply service lters.
Requirements
This example use the logical interface xe-0/1/0.0 on any of the following hardware components:
• Adapve Services (AS) PIC on an M Series or T Series router
1445
• Mulservices (MS) PIC on an M Series or T Series router
• Mulservices (MS) DPC on an MX Series router
• EX Series switch
Before you begin, make sure that you have:
• Installed your supported router (or switch) and PICs or DPCs and performed the inial router (or
switch) conguraon.
• Congured basic Ethernet in the topology, and veried that trac is owing in the topology and that
IPv4 trac is owing through logical interface xe-0/1/0.0.
• Congured the service set vrf_svcs with service input and output rules and default sengs for
services at a service interface.
For guidelines for conguring service sets, see
Conguring Service Sets to be Applied to Services
Interfaces
.
Overview
IN THIS SECTION
Topology | 1446
In this example, you create three types of service lters for IPv4 trac: one input service lter, one
postservice input lter, and one output service lter. Dierent service-lters can be applied to the same
service-set. See also:
Conguring Service Sets to be Applied to Services Interfaces
Topology
You apply the input service lter and postservice input lter to input trac at logical interface xe-0/1/0.0,
and you apply the output service lter to the output trac at the same logical interface.
• Filtering IPv4 trac before it is accepted for input service processing—At logical interface xe-0/1/0.0,
you use the service lter in_filter_presvc to lter IPv4 input trac before the trac can be accepted
for processing by services associated with service set vrf_svcs. The in_filter_presvc service lter
counts packets sent from ICMP port 179, directs these packets to the input services associated with
the service set vrf_svcs, and discards all other packets.
• Filtering IPv4 trac aer it has completed input service processing—At logical interface xe-0/1/0.0,
you use the service lter
in_filter_postsvc
to lter trac that is returning to the services interface
1446
aer the input service set in_filter_presvc is executed. The in_filter_postsvc service lter counts
packets sent from ICMP port 179 and then discards them.
• Filtering IPv4 trac before it is accepted for output service processing—At logical interface xe-0/1/0.0,
you use the service-lter out_filter_presvc to lter IPv4 output trac before the trac can be
accepted for processing by the services associated with service set vrf_svcs. The out_filter_presvc
service lter counts packets desned for TCP port 179 and then directs the packets to the output
services associated with the service set vrf_svcs.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1447
Conguring the Three Service Filters | 1448
Applying the Three Service Filters | 1450
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet service-filter in_filter_presvc term t1 from protocol tcp
set firewall family inet service-filter in_filter_presvc term t1 from source-port bgp
set firewall family inet service-filter in_filter_presvc term t1 then count svc_in_pkts
set firewall family inet service-filter in_filter_presvc term t1 then service
set firewall family inet service-filter in_filter_postsvc term t2 from protocol tcp
set firewall family inet service-filter in_filter_postsvc term t2 from source-port bgp
set firewall family inet service-filter in_filter_postsvc term t2 then count svc_in_pkts_rtn
set firewall family inet service-filter in_filter_postsvc term t2 then skip
set firewall family inet service-filter out_filter_presvc term t3 from protocol icmp
set firewall family inet service-filter out_filter_presvc term t3 from destination-port bgp
set firewall family inet service-filter out_filter_presvc term t3 then count svc_out_pkts
set firewall family inet service-filter out_filter_presvc term t3 then service
1447
set interfaces xe-0/1/0 unit 0 family inet service input service-set vrf_svcs service-filter
in_filter_presvc
set interfaces xe-0/1/0 unit 0 family inet service input post-service-filter in_filter_postsvc
set interfaces xe-0/1/0 unit 0 family inet service output service-set vrf_svcs service-filter
out_filter_presvc
Conguring the Three Service Filters
Step-by-Step Procedure
To congure the three service lters:
1. Congure the input service lter.
[edit]
user@host# edit firewall family inet service-filter in_filter_presvc
[edit firewall family inet service-filter in_filter_presvc]
user@host# set term t1 from protocol tcp
user@host# set term t1 from source-port bgp
user@host# set term t1 then count svc_in_pkts
user@host# set term t1 then service
2. Congure the postservice input lter.
[edit]
user@host# edit firewall family inet service-filter in_filter_postsvc
[edit firewall family inet service-filter in_filter_postsvc]
user@host# set term t2 from protocol tcp
user@host# set term t2 from source-port bgp
user@host# set term t2 then count svc_in_pkts_rtn
user@host# set term t2 then skip
3. Congure the output service lter.
[edit]
user@host# edit firewall family inet service-filter out_filter_presvc
1448
[edit firewall family inet service-filter out_filter_presvc]
user@host# set term t3 from protocol icmp
user@host# set term t3 from destination-port bgp
user@host# set term t3 then count svc_out_pkts
user@host# set term t3 then service
Results
Conrm the conguraon of the input and output service lters and the postservice input lter by
entering the show firewall conguraon mode command. If the command output does not display the
intended conguraon, repeat the instrucons in this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
service-filter in_filter_presvc {
term t1 {
from {
protocol tcp;
source-port bgp;
}
then {
count svc_in_pkts;
service;
}
}
}
service-filter in_filter_postsvc {
term t2 {
from {
protocol tcp;
source-port bgp;
}
then {
count svc_in_pkts_rtn;
skip;
}
}
}
service-filter out_filter_presvc {
term t3 {
1449
from {
protocol icmp;
destination-port bgp;
}
then {
count svc_out_pkts;
service;
}
}
}
}
Applying the Three Service Filters
Step-by-Step Procedure
To apply the three service lters:
1. Access the IPv4 protocol on the input interface xe-0/1/0.0.
[edit]
user@host# edit interfaces xe-0/1/0 unit 0 family inet
2. Apply the input service lter and the postservice input lter.
[edit interfaces xe-0/1/0 unit 0 family inet]
user@host# set service input service-set vrf_svcs service-filter in_filter_presvc
user@host# set service input post-service-filter in_filter_postsvc
user@host# set service output service-set vrf_svcs service-filter out_filter_presvc
Results
Conrm the conguraon of the interfaces by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
example to correct the conguraon.
[edit]
user@host# show interfaces
xe-0/1/0 {
1450
unit 0 {
family inet {
service {
input {
service-set vrf_svcs service-filter in_filter_presvc;
post-service-filter in_filter_postsvc;
}
output {
service-set vrf_svcs service-filter out_filter_presvc;
}
}
}
}
}
When you are done conguring the device, commit your candidate conguraon.
Vericaon
IN THIS SECTION
Verifying That Inbound Trac Is Filtered Before Input Service | 1451
Verifying That Inbound Trac Is Filtered Aer Input Service Processing | 1452
Verifying That Outbound Trac Is Filtered Before Output Service Processing | 1452
Conrm that the conguraon is working properly.
Verifying That Inbound Trac Is Filtered Before Input Service
Purpose
Verify that inbound packets sent from TCP port 179 are sent for processing by the
input
services
associated with the service set vrf_svcs.
1451
Acon
Display the count of packets sent for processing by the
input
services associated with the service set
vrf_svcs.
[edit]
user@host> show firewall filter in_filter_presvc-vrf_svcs counter svc_in_pkts
Verifying That Inbound Trac Is Filtered Aer Input Service Processing
Purpose
Verify that inbound packets sent from TCP port 179 are returned from processing by the
input
services
associated with the service set vrf_svcs.
Acon
Display the count of packets returned from processing by the
input
services associated with the service
set vrf_svcs.
[edit]
user@host> show firewall filter in_filter_postsvc-vrf_svcs counter svc_in_pkts_rtn
Verifying That Outbound Trac Is Filtered Before Output Service Processing
Purpose
Verify that outbound packets sent to ICMP port 179 are sent for processing by the
output
services
associated with the service set vrf_svcs.
Acon
Display the count of packets sent for processing by the
output
services associated with the service set
vrf_svcs.
[edit]
user@host> show firewall filter out_filter_presvc-vrf_svcs counter svc_out_pkts
1452
RELATED DOCUMENTATION
Service Filter Overview | 1435
How Service Filters Evaluate Packets | 1437
Guidelines for Conguring Service Filters | 1439
Guidelines for Applying Service Filters | 1442
Service Filter Match Condions for IPv4 or IPv6 Trac
Service lters support only a subset of the stateless rewall lter match condions for IPv4 and IPv6
trac. Table 70 on page 1453 describes the service lter match condions.
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
Match Condion Descripon Protocol
Families
address
address
Match the IP source or desnaon address eld.
• family
inet
• family
inet6
address
address
except
Do not match the IP source or desnaon address eld.
• family
inet
• family
inet6
ah-spi
spi-value
(M Series routers, except M120 and M320) Match on the IPsec
authencaon header (AH) security parameter index (SPI) value.
• family
inet
ah-spi-except
spi-
value
(M Series routers, except M120 and M320) Do not match on the IPsec
AH SPI value.
• family
inet
1453
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
destination-address
address
Match the IP desnaon address eld.
You cannot specify both the address and destination-address match
condions in the same term.
• family
inet
• family
inet6
destination-address
address
except
Do not match the IP desnaon address eld.
You cannot specify both the address and destination-address match
condions in the same term.
• family
inet
• family
inet6
destination-port
number
Match the UDP or TCP desnaon port eld.
You cannot specify both the port and destination-port match condions in
the same term.
If you congure this match condion for IPv4 trac, we recommend that
you also congure the protocol udp or protocol tcp match statement in
the same term to specify which protocol is being used on the port.
If you congure this match condion for IPv6 trac, we recommend that
you also congure the next-header udp or next-header tcp match condion
in the same term to specify which protocol is being used on the port.
In place of the numeric value, you can specify one of the following text
synonyms (the port numbers are also listed): afs (1483), bgp (179),
biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67),
domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21),
ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-
sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760),
kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-
ssn (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110),
pptp (1723), printer (515), radacct (1813), radius (1812), rip (520),
rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080),
ssh (22), sunrpc (111), syslog (514), tacacs (49), tacacs-ds (65), talk (517),
telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
• family
inet
• family
inet6
1454
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
destination-port-
except
number
Do not match the UDP or TCP desnaon port eld. For details, see the
destination-port match descripon.
• family
inet
• family
inet6
destination-prefix-
list
name
Match the list of desnaon prexes. The prex list is dened at the [edit
policy-options prefix-list
prefix-list-name
] hierarchy level.
• family
inet
• family
inet6
esp-spi
value
Match the IPsec encapsulang security payload (ESP) SPI value. Specify a
single value or a range of values. You can specify a
value
in hexadecimal,
binary, or decimal form. To specify the value in hexadecimal form, include
0x as a prex. To specify the value in binary form, include b as a prex.
• family
inet
• family
inet6
esp-spi-except
value
Do not match the IPsec ESP SPI value or range of values. For details, see
the esp-spi match condion.
• family
inet
• family
inet6
first-fragment
Match if the packet is the rst fragment of a fragmented packet. Do not
match if the packet is a trailing fragment of a fragmented packet. The rst
fragment of a fragmented packet has a fragment oset value of 0.
This match condion is an alias for the bit-eld match condion fragment-
offset 0 match condion.
To match both rst and trailing fragments, you can use two terms that
specify dierent match condions: first-fragment and is-fragment.
• family
inet
1455
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
forwarding-class
Match one or more of the following specied packet forwarding classes:
• assured-forwarding
• best-effort
• expedited-forwarding
• network-control
•
user-defined-name
For informaon about forwarding classes and router-internal output
queues, see
Understanding How Forwarding Classes Assign Classes to
Output Queues
.
• family
inet
• family
inet6
forwarding-class-
except
Do not match one or more of the following specied packet forwarding
classes:
• assured-forwarding
• best-effort
• expedited-forwarding
• network-control
•
user-defined-name
• family
inet
• family
inet6
fragment-flags
number
(Ingress only) Match the three-bit IP fragmentaon ags eld in the IP
header.
In place of the numeric eld value, you can specify one of the following
keywords (the eld values are also listed): dont-fragment (0x4), more-
fragments (0x2), or reserved (0x8).
• family
inet
1456
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
fragment-offset
number
Match the 13-bit fragment oset eld in the IP header. The value is the
oset, in 8-byte units, in the overall datagram message to the data
fragment. Specify a numeric value, a range of values, or a set of values. An
oset value of 0 indicates the rst fragment of a fragmented packet.
The first-fragment match condion is an alias for the fragment-offset 0
match condion.
To match both rst and trailing fragments, you can use two terms that
specify dierent match condions (first-fragment and is-fragment).
• family
inet
fragment-offset-except
number
Do not match the 13-bit fragment oset eld.
• family
inet
interface-group
group-
number
Match the interface group (set of one or more logical interfaces) on which
the packet was received. For
group-number
, specify a value from 0 through
255.
For informaon about conguring interface groups, see "Filtering Packets
Received on a Set of Interface Groups Overview" on page 1377.
• family
inet
• family
inet6
interface-group-except
group-number
Do not match the interface group on which the packet was received. for
details, see the interface-group match condion.
• family
inet
• family
inet6
1457
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
ip-options
values
Match the 8-bit IP opon eld, if present, to the specied value or list of
values.
In place of a numeric value, you can specify one of the following text
synonyms (the opon values are also listed): loose-source-route (131),
record-route (7), router-alert (148), security (130), stream-id (136), strict-
source-route (137), or timestamp (68).
To match
any
value for the IP opon, use the text synonym any. To match
on
mulple
values, specify the list of values within square brackets ('[’ and
']’). To match a
range
of values, use the value specicaon [
value1
-
value2
].
For example, the match condion ip-options [ 0-147 ] matches on an
IP opons eld that contains the loose-source-route, record-route, or
security values, or any other value from 0 through 147. However, this
match condion does not match on an IP opons eld that contains only
the router-alert value (148).
For most interfaces, a lter term that species an ip-option match on one
or more
specic
IP opon values (a value other than any) causes packets
to be sent to the Roung Engine so that the kernel can parse the
IP opon eld in the packet header.
• For a rewall lter term that species an ip-option match on one or
more specic IP opon values, you cannot specify the count, log, or
syslog nonterminang acons
unless
you also specify the discard
terminang acon in the same term. This behavior prevents double-
counng of packets for a lter applied to a transit interface on the
router (or switch).
• Packets processed on the kernel might be dropped in case of a system
boleneck. To ensure that matched packets are instead sent to the
Packet Forwarding Engine (where packet processing is implemented in
hardware), use the ip-options any match condion.
The 10-Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit
Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, 60-Gigabit Ethernet
Enhanced Queuing MPC on MX Series routers and EX Series switches are
capable of parsing the IP opon eld of the IPv4 packet header. This
capability is supported on EX Series switches also. For interfaces
family inet
1458
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
congured on those MPCs,
all
packets that are matched using the ip-
options match condion are sent to the Packet Forwarding Engine for
processing.
ip-options-except
values
Do not match the IP opon eld to the specied value or list of values.
For details about specifying the
values
, see the ip-options match
condion.
• family
inet
is-fragment
Match if the packet is a trailing fragment of a fragmented packet. Do not
match the rst fragment of a fragmented packet.
This match condion is an alias for the bit-eld match condion fragment-
offset 0 except bits.
NOTE: To match both rst and trailing fragments, you can use two terms
that specify dierent match condions (first-fragment and is-fragment).
• family
inet
loss-priority
Match one or more of the following specied packet loss priority (PLP)
levels:
• low
• medium-low
• medium-high
• high
The PLP is used by schedulers in conjuncon with the random early
discard (RED) algorithm to control packet discard during periods of
congeson. For informaon about PLP, see
Managing Congeson by
Seng Packet Loss Priority for Dierent Trac Flows
and
Overview of
Assigning Service Levels to Packets Based on Mulple Packet Header
Fields
.
• family
inet
• family
inet6
1459
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
loss-priority-except
Do not match one or more of the following specied packet loss priority
(PLP) levels:
• low
• medium-low
• medium-high
• high
• family
inet
• family
inet6
port
number
Match the UDP or TCP source or desnaon port eld.
If you congure this match condion, you cannot congure the
destination-port match condion or the source-port match condion in
the same term.
If you congure this match condion for IPv4 trac, we recommend that
you also congure the protocol udp or protoco tcp match statement in the
same term to specify which protocol is being used on the port.
If you congure this match condion for IPv6 trac, we recommend that
you also congure the next-header udp or next-header tcp match condion
in the same term to specify which protocol is being used on the port.
In place of the numeric value, you can specify one of the text synonyms
listed under destination-port.
• family
inet
• family
inet6
port-except
number
Do not match the UDP or TCP source or desnaon port eld. For details,
see the port match condion.
• family
inet
• family
inet6
prefix-list
prefix-
list-name
Match the prexes of the source or desnaon address elds to the
prexes in the specied list. The prex list is dened at the [edit policy-
options prefix-list
prefix-list-name
] hierarchy level.
• family
inet
• family
inet6
1460
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
protocol
number
Match the IP protocol type eld.
In place of the numeric value, you can specify one of the following text
synonyms (the eld values are also listed): ah (51), dstopts (60), egp (8),
esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58),
icmpv6 (58), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46),
sctp (132), tcp (6), udp (17), or vrrp (112).
• family
inet
protocol-except
number
Do not match the IP protocol type eld. For details, see the protocol
match condion.
• family
inet
source-address
address
Match the IP source address.
You cannot specify both the address and source-address match condions
in the same term.
• family
inet
• family
inet6
source-address
address
except
Do not match the IP source address.
You cannot specify both the address and source-address match condions
in the same term.
• family
inet
• family
inet6
1461
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
source-port
number
Match the UDP or TCP source port eld.
You cannot specify the port and source-port match condions in the same
term.
If you congure this match condion for IPv4 trac, we recommend that
you also congure the protocol udp or protocol tcp match statement in
the same term to specify which protocol is being used on the port.
If you congure this match condion for IPv6 trac, we recommend that
you also congure the next-header udp or next-header tcp match condion
in the same term to specify which protocol is being used on the port.
In place of the numeric value, you can specify one of the text synonyms
listed with the destination-port
number
match condion.
• family
inet
• family
inet6
source-port-except
number
Do not match the UDP or TCP source port eld. For details, see the
source-port match condion.
• family
inet
• family
inet6
source-prefix-list
name
Match source prexes in the specied list. Specify the name of a prex list
dened at the [edit policy-options prefix-list
prefix-list-name
]
hierarchy level.
• family
inet
• family
inet6
1462
Table 70: Service Filter Match Condions for IPv4 or IPv6 Trac
(Connued)
Match Condion Descripon Protocol
Families
tcp-flags
value
Match one or more of the low-order 6 bits in the 8-bit TCP ags eld in
the TCP header.
To specify individual bit elds, you can specify the following text
synonyms or hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in the inial packet sent, while
the ACK ag is set in all packets sent aer the inial packet.
You can string together mulple ags using the bit-eld logical operators.
For combined bit-eld match condions, see the tcp-established and tcp-
initial match condions.
If you congure this match condion for IPv4 trac, we recommend that
you also congure the protocol tcp match statement in the same term to
specify that the TCP protocol is being used on the port.
If you congure this match condion for IPv6 trac, we recommend that
you also congure the next-header tcp match condion in the same term
to specify that the TCP protocol is being used on the port.
• family
inet
• family
inet6
NOTE: If you specify an IPv6 address in a match condion (the address, destination-address, or
source-address match condions), use the syntax for text representaons described in RFC 4291,
IP Version 6 Addressing Architecture
. For more informaon about IPv6 addresses, see “IPv6
Overview” in the Junos OS Roung Protocols Library for Roung Devices.
1463
RELATED DOCUMENTATION
Service Filter Overview | 1435
Guidelines for Conguring Service Filters | 1439
Example: Conguring and Applying Service Filters | 1445
Service Filter Terminang Acons | 1465
Service Filter Nonterminang Acons | 1464
Service Filter Nonterminang Acons
Service lters support dierent sets of terminang acons for each protocol family.
NOTE: Service lters do not support the next term acon.
Table 71 on page 1464 describes the nonterminang acons you can congure in a service lter term.
Table 71:
Nonterminang Acons for Service Filters
Nonterminang
Acon Descripon
Protocol
Families
count
counter-
name
Count the packet in the named counter.
• inet
• inet6
log
Log the packet header informaon in a buer within the Packet Forwarding
Engine. You can access this informaon by issuing the show firewall log
command at the command-line interface (CLI).
• inet
• inet6
port-mirror
Port-mirror the packet based on the specied family. Supported on M120
routers, M320 routers congured with Enhanced III FPCs, MX Series routers,
and EX Series switches only.
• inet
• inet6
sample
Sample the packet.
• inet
• inet6
1464
RELATED DOCUMENTATION
Service Filter Overview | 1435
Guidelines for Conguring Service Filters | 1439
Example: Conguring and Applying Service Filters | 1445
Service Filter Match Condions for IPv4 or IPv6 Trac | 1453
Service Filter Terminang Acons | 1465
Service Filter Terminang Acons
Service lters support dierent sets of terminang acons than standard stateless rewall lters or
simple lters.
NOTE: Service lters do not support the next term acon.
Table 72 on page 1465 describes the terminang acons you can congure in a service lter term.
Table 72:
Terminang Acons for Service Filters
Terminang
Acon Descripon
Protocol
Families
service
Direct the packet to service processing.
• inet
• inet6
skip
Let the packet bypass service processing.
• inet
• inet6
RELATED DOCUMENTATION
Service Filter Overview | 1435
Guidelines for Conguring Service Filters | 1439
Example: Conguring and Applying Service Filters | 1445
1465
Service Filter Match Condions for IPv4 or IPv6 Trac | 1453
Service Filter Nonterminang Acons | 1464
1466
CHAPTER 23
Conguring Simple Filters
IN THIS CHAPTER
Simple Filter Overview | 1467
How Simple Filters Evaluate Packets | 1468
Guidelines for Conguring Simple Filters | 1469
Guidelines for Applying Simple Filters | 1474
Example: Conguring and Applying a Simple Filter | 1475
Simple Filter Overview
Simple lters are supported on Gigabit Ethernet intelligent queuing 2 (IQ2) and Enhanced Queuing
Dense Port Concentrator (DPC) interfaces only.
Simple lters are recommended for metropolitan Ethernet applicaons.
RELATED DOCUMENTATION
How Simple Filters Evaluate Packets | 1468
Guidelines for Conguring Simple Filters | 1469
Guidelines for Applying Simple Filters | 1474
Example: Conguring and Applying a Simple Filter | 1475
1467
How Simple Filters Evaluate Packets
IN THIS SECTION
Simple Filters That Contain a Single Term | 1468
Simple Filters That Contain Mulple Terms | 1468
Simple Filter Terms That Do Not Contain Any Match Condions | 1468
Simple Filter Terms That Do Not Contain Any Acons | 1469
Simple Filter Default Acon | 1469
Simple Filters That Contain a Single Term
For a simple lter that consists of a single term, the policy framework soware evaluates a packet as
follows:
• If the packet matches all the condions, the acons are taken.
• If the packet matches all the condions and no acons are specied, the packet is accepted.
• If the packet does not match all the condions, it is discarded.
Simple Filters That Contain Mulple Terms
For a simple lter that consists of mulple terms, the policy framework soware evaluates a packet
against the terms in the lter sequenally, beginning with the rst term in the lter, unl either the
packet matches all the condions in one of the terms or there are no more terms in the lter.
• If the packet matches all the condions in a term, the acons in that term are performed and
evaluaon of the packet ends at that term. Any subsequent terms in the lter are not used.
• If the packet does not match all the condions in the term, evaluaon of the packet proceeds to the
next term in the lter.
Simple Filter Terms That Do Not Contain Any Match Condions
For simple lters with a single term and for lters with mulple terms, if a term does not contain any
match condions, the acons are taken on any packet evaluated.
1468
Simple Filter Terms That Do Not Contain Any Acons
If a simple lter term does not contain any acons, and if the packet matches the condions in the term,
the packet is accepted.
Simple Filter Default Acon
Each simple lter has an
implicit
discard acon at the end of the lter, which is equivalent to including
the following example term explicit_discard as the nal term in the simple lter:
term explicit_discard {
then discard;
}
By default, if a packet matches none of the terms in a simple lter, the packet is discarded.
RELATED DOCUMENTATION
Simple Filter Overview | 1467
Guidelines for Conguring Simple Filters | 1469
Guidelines for Applying Simple Filters | 1474
Example: Conguring and Applying a Simple Filter | 1475
Guidelines for Conguring Simple Filters
IN THIS SECTION
Statement Hierarchy for Conguring Simple Filters | 1470
Simple Filter Protocol Families | 1470
Simple Filter Names | 1470
Simple Filter Terms | 1470
Simple Filter Match Condions | 1471
Simple Filter Terminang Acons | 1473
Simple Filter Nonterminang Acons | 1473
1469
Statement Hierarchy for Conguring Simple Filters
To congure a simple lter, include the simple-filter
simple-filter-name
statement at the [edit firewall
family inet] hierarchy level.
[edit]
firewall {
family inet {
simple-filter
simple-filter-name
{
term
term-name
{
from {
match-conditions
;
}
then {
actions
;
}
}
}
}
}
Individual statements supported under the simple-filter
simple-filter-name
statement are described
separately in this topic and are illustrated in the example of conguring and applying a simple lter.
Simple Filter Protocol Families
You can congure simple lters to lter IPv4 trac (family inet) only. No other protocol family is
supported for simple lters.
Simple Filter Names
Under the family inet statement, you can include simple-filter
simple-filter-name
statements to create and
name simple lters. The lter name can contain leers, numbers, and hyphens (-) and be up to 64
characters long. To include spaces in the name, enclose the enre name in quotaon marks (“ ”).
Simple Filter Terms
Under the simple-filter
simple-filter-name
statement, you can include term
term-name
statements to create
and name lter terms.
• You must congure at least one term in a
rewall lter
.
1470
• You must specify a unique name for each term within a rewall lter. The term name can contain
leers, numbers, and hyphens (-) and can be up to 64 characters long. To include spaces in the name,
enclose the enre name in quotaon marks (“ ”).
• The order in which you specify terms within a rewall lter conguraon is important. Firewall lter
terms are evaluated in the order in which they are congured. By default, new terms are always
added to the end of the exisng lter. You can use the insert conguraon mode command to
reorder the terms of a rewall lter.
Simple lters do
not
support the next term acon.
Simple Filter Match Condions
Simple lter terms support only a subset of the IPv4 match condions that are supported for standard
stateless rewall lters.
Unlike standard stateless rewall lters, the following restricons apply to simple lters:
• On MX Series routers with the Enhanced Queuing DPC and on EX Series switches, simple lters
do
not
support the forwarding- class match condion.
• Simple lters support only one source-address and one destination-address prex for each lter term. If
you congure mulple prexes, only the last one is used.
• Simple lters do
not
support mulple source addresses and desnaon addresses in a single term. If
you congure mulple addresses, only the last one is used.
• Simple lters do
not
support negated match condions, such as the protocol-except match condion or
the exception keyword.
• Simple lters support a range of values for source-port and destination-port match condions only. For
example, you can congure source-port 400-500 or destination-port 600-700.
• Simple lters do
not
support nonconguous mask values.
Table 73 on page 1471 lists the simple lter match condions.
Table 73: Simple Filter Match
Condions
Match Condion Descripon
destination-address
destination-
address
Match IP desnaon address.
1471
Table 73: Simple Filter Match Condions
(Connued)
Match Condion Descripon
destination-port
number
TCP or UDP desnaon port eld.
If you congure this match condion, we recommend that you also
congure the protocol match statement to determine which protocol is
being used on the port.
In place of the numeric value, you can specify one of the following text
aliases (the port numbers are also listed): afs (1483), bgp (179), biff (512),
bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53),
eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20),
http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543),
kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389),
login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-
dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119),
ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813),
radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162),
snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs-ds (65),
talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
forwarding-class
class
Match the forwarding class of the packet.
Specify assured-forwarding, best-effort, expedited-forwarding, or network-
control.
For informaon about forwarding classes and router-internal output
queues, see
Understanding How Forwarding Classes Assign Classes to
Output Queues
.
protocol
number
IP protocol eld. In place of the numeric value, you can specify one of the
following text aliases (the eld values are also listed): ah (51), dstopts (60),
egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58),
icmpv6 (58), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46),
sctp (132), tcp (6), udp (17), or vrrp (112).
source-address
ip-source-address
Match the IP source address.
1472
Table 73: Simple Filter Match Condions
(Connued)
Match Condion Descripon
source-port
number
Match the UDP or TCP source port eld.
If you congure this match condion, we recommend that you also
congure the protocol match statement to determine which protocol is
being used on the port.
In place of the numeric eld, you can specify one of the text aliases listed
for destination-port.
Simple Filter Terminang Acons
Simple lters do
not
support explicitly congurable terminang acons, such as accept, reject, and discard.
Terms congured in a simple lter always accept packets.
Simple lters do
not
support the next acon.
Simple Filter Nonterminang Acons
Simple lters support only the following nonterminang acons:
• forwarding-class (
forwarding-class
| assured-forwarding |best-effort | expedited-forwarding | network-control)
NOTE: On the MX Series routers and EX Series switches with the Enhanced Queuing DPC,
the forwarding class is not supported as a from match condion.
• loss-priority (high | low | medium-high | medium-low)
Simple lters do not support acons that perform other funcons on a packet (such as incremenng a
counter, logging informaon about the packet header, sampling the packet data, or sending informaon
to a remote host using the system log funconality).
RELATED DOCUMENTATION
Simple Filter Overview | 1467
How Simple Filters Evaluate Packets | 1468
Guidelines for Applying Simple Filters | 1474
1473
Example: Conguring and Applying a Simple Filter | 1475
Guidelines for Applying Simple Filters
IN THIS SECTION
Statement Hierarchy for Applying Simple Filters | 1474
Restricons for Applying Simple Filters | 1474
Statement Hierarchy for Applying Simple Filters
You can apply a simple lter to the IPv4 ingress trac at a
logical interface
by including the simple-filter
input
simple-filter-name
statement at the [edit interfaces
interface-name
unit
unit-number
family inet]
hierarchy level.
[edit]
interfaces {
interface-name
{
unit
logical-unit-number
{
family inet {
simple-filter {
input
filter-name
;
}
}
}
}
}
Restricons for Applying Simple Filters
You can apply a simple lter to the ingress IPv4 trac at a logical interface congured on the following
hardware only:
• Gigabit Ethernet intelligent queuing (IQ2) PICs installed on M120, M320, or T Series routers.
1474
• Enhanced Queuing Dense Port Concentrators (EQ DPCs) installed on MX Series routers and EX
Series switches.
The following addional restricons pertain to applying simple lters:
• Simple lters are not supported on Modular Port Concentrator (MPC) interfaces, including Enhanced
Queuing MPC interfaces.
• Simple lters are not supported for interfaces in an aggregated-Ethernet bundle.
• You can apply simple lters to family inet trac only. No other protocol family is supported.
• You can apply simple lters to ingress trac only. Egress trac is not supported.
• You can apply only a single simple lter to a supported logical interface. Input lists are not supported.
RELATED DOCUMENTATION
Simple Filter Overview | 1467
How Simple Filters Evaluate Packets | 1468
Guidelines for Conguring Simple Filters | 1469
Example: Conguring and Applying a Simple Filter | 1475
Example: Conguring and Applying a Simple Filter
IN THIS SECTION
Requirements | 1475
Overview | 1476
Conguraon | 1476
Vericaon | 1480
This example shows how to congure a simple lter.
Requirements
This example uses one of the following hardware components:
1475
• One Gigabit Ethernet intelligent queuing (IQ2) PIC installed on an M120, M320, or T Series router
• One Enhanced Queuing Dense Port Concentrator (EQ DPC) installed on an MX Series router or an
EX Series switch
Before you begin, make sure that you have:
• Installed your supported router (or switch) and PIC or DPC and performed the inial router (or
switch) conguraon.
• Congured basic Ethernet in the topology, and veried that trac is owing in the topology and that
ingress IPv4 trac is owing into logical interface ge-0/0/1.0.
Overview
IN THIS SECTION
Topology | 1476
This simple lter sets the loss priority to low for TCP trac with source address 172.16.1.1, sets the loss
priority to high for HTTP (Web) trac with source addresses in the 172.16.4.0/8 range, and sets the loss
priority to low for all trac with desnaon address 172.16.6.6.
Topology
The simple lter is applied as an input lter (arriving packets are checking for desnaon address 6.6.6.6,
not queued output packets) on interface ge-0/0/1.0.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1477
Conguring the Simple Firewall Filter | 1477
Applying the Simple Filter to the Logical Interface Input | 1479
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
1476
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following commands into a text le, remove any line breaks,
and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet simple-filter sf_classify_1 term 1 from source-address 172.16.1.1/32
set firewall family inet simple-filter sf_classify_1 term 1 from protocol tcp
set firewall family inet simple-filter sf_classify_1 term 1 then loss-priority low
set firewall family inet simple-filter sf_classify_1 term 2 from source-address 172.16.4.0/8
set firewall family inet simple-filter sf_classify_1 term 2 from protocol tcp
set firewall family inet simple-filter sf_classify_1 term 2 from source-port http
set firewall family inet simple-filter sf_classify_1 term 2 then loss-priority high
set firewall family inet simple-filter sf_classify_1 term 3 from destination-address 6.6.6.6/32
set firewall family inet simple-filter sf_classify_1 term 3 then loss-priority low
set firewall family inet simple-filter sf_classify_1 term 3 then forwarding-class best-effort
set interfaces ge-0/0/1 unit 0 family inet simple-filter input sf_classify_1
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
Conguring the Simple Firewall Filter
Step-by-Step Procedure
To congure the simple lter:
1. Create the simple lter sf_classify_1.
[edit]
user@host# edit firewall family inet simple-filter sf_classify_1
2. Congure classicaon of TCP trac based on the source IP address.
[edit firewall family inet simple-filter sf_classify_1]
user@host# set term 1 from source-address 172.16.1.1/32
user@host# set term 1 from protocol tcp
user@host# set term 1 then loss-priority low
1477
3. Congure classicaon of HTTP trac based on the source IP address.
[edit firewall family inet simple-filter sf_classify_1]
user@host# set term 2 from source-address 172.16.4.0/8
user@host# set term 2 from protocol tcp
user@host# set term 2 from source-port http
user@host# set term 2 then loss-priority high
4. Congure classicaon of other trac based on the desnaon IP address.
[edit firewall family inet simple-filter sf_classify_1]
user@host# set term 3 from destination-address 6.6.6.6/32
user@host# set term 3 then loss-priority low
user@host# set term 3 then forwarding-class best-effort
Results
Conrm the conguraon of the simple lter by entering the show firewall conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
simple-filter sf_classify_1 {
term 1 {
from {
source-address {
172.16.1.1/32;
}
protocol {
tcp;
}
}
then loss-priority low;
}
term 2 {
from {
source-address {
172.16.4.0/8;
1478
}
source-port {
http;
}
protocol {
tcp;
}
}
then loss-priority high;
}
term 3 {
from {
destination-address {
6.6.6.6/32;
}
}
then {
loss-priority low;
forwarding-class best-effort;
}
}
}
}
Applying the Simple Filter to the Logical Interface Input
Step-by-Step Procedure
To apply the simple lter to the logical interface input:
1. Congure the logical interface to which you will apply the simple lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
1479
3. Apply the simple lter to the logical interface input.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set simple-filter input sf_classify_1
Results
Conrm the conguraon of the interface by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
unit 0 {
family inet {
simple-filter {
input sf_classify_1;
}
address 10.1.2.3/30;
}
}
}
When you are done conguring the device, commit your candidate conguraon.
Vericaon
IN THIS SECTION
Displaying the Mapping of Forwarding Class Maps and Names to Queue Numbers | 1481
Displaying CoS Queue Counters for the Interface | 1481
Displaying CoS Queue Counter Details for the Physical Interface | 1482
Conrm that the conguraon is working properly.
1480
Displaying the Mapping of Forwarding Class Maps and Names to Queue Numbers
Purpose
Display the mapping of forwarding class names to queue numbers.
Acon
Enter the show class-of-service forwarding-class operaonal mode command.
[edit]
user@host> show class-of-service forwarding-class
For informaon about the command output, see “show class-of-service forwarding-class” in the CLI
Explorer.
Displaying CoS Queue Counters for the Interface
Purpose
Verify that the class-of-service (CoS) queue counters for the interface reect the simple lter applied to
the logical interface.
Acon
Enter the show interfaces command for the physical interface on which the simple lter is applied, and
specify detail or extensive output level.
[edit]
user@host> show interfaces ge-0/0/1 detail
In the Physical interface secon, under Ingress queues, the Queue counters secon displays ingress queue
counters for each forwarding class.
For more detailed informaon about the command output, see “show interfaces ” in the CLI Explorer.
1481
Displaying CoS Queue Counter Details for the Physical Interface
Purpose
Verify that the CoS queue counter details for the physical interface reect the simple lter applied to the
logical interface.
Acon
Enter the show interfaces queue command for the physical interface on which the simple lter is applied,
and specify the ingress opon.
[edit]
user@host> show interfaces queue ge-0/0/1 ingress
For informaon about the command output, see “show interfaces queue” in the CLI Explorer.
RELATED DOCUMENTATION
Simple Filter Overview | 1467
How Simple Filters Evaluate Packets | 1468
Guidelines for Conguring Simple Filters | 1469
Guidelines for Applying Simple Filters | 1474
1482
CHAPTER 24
Conguring Layer 2 Firewall Filters
IN THIS CHAPTER
Understanding Firewall Filters Used to Control Trac Within Bridge Domains and VPLS Instances | 1483
Example: Conguring Filtering of Frames by MAC Address | 1484
Example: Conguring Filtering of Frames by IEEE 802.1p Bits | 1486
Example: Conguring Filtering of Frames by Packet Loss Priority | 1487
Example: Conguring Policing and Marking of Trac Entering a VPLS Core | 1489
Understanding Firewall Filters on OVSDB-Managed Interfaces | 1492
Example: Applying a Firewall Filter to OVSDB-Managed Interfaces | 1493
Understanding Firewall Filters Used to Control Trac Within Bridge
Domains and VPLS Instances
Juniper Networks MX Series 5G Universal Roung Plaorms support rewall lters for the bridge and
vpls protocol families. You congure these rewall lters to control trac within bridge domains and
VPLS instances. This topic explores some of the ways that lters can be used in a Layer 2 environment
to control trac.
MX Series router rewall lters can be applied to:
• Input interfaces
• Output interfaces
• Input to the Layer 2 forwarding table
You use a
rewall lter
aer taking the following two steps:
1.
You congure any policers and the rewall lter at the [edit firewall] hierarchy level.
2. You apply the properly congured rewall lter to an interface or bridge domain.
1483
NOTE: If the chassis is running in Enhanced IP mode, a single shared lter instance is created for
a lter applied across bridge domains. Otherwise, separate lter instances are created for each
bridge domain that the lter is applied to.
RELATED DOCUMENTATION
Example: Conguring Policing and Marking of Trac Entering a VPLS Core | 1489
Example: Conguring Filtering of Frames by MAC Address | 1484
Example: Conguring Filtering of Frames by IEEE 802.1p Bits | 1486
Example: Conguring Filtering of Frames by Packet Loss Priority | 1487
Example: Conguring Filtering of Frames by MAC Address
This example rewall lter nds frames with a certain source MAC address (88:05:00:29:3c:de/48), then
counts and silently discards them. For more informaon about conguring rewall lter match
condions, see the Roung Policies, Firewall Filters, and Trac Policers User Guide. The lter is applied
to the VLAN congured as vlan100200 as an input lter on Router 1.
NOTE: This example does not present exhausve conguraon lisngs for all routers in the
gures. However, you can use this example with a broader conguraon strategy to complete
the MX Series router network Ethernet Operaons, Administraon, and Maintenance (OAM)
conguraons.
To congure ltering of frames by MAC address:
1. Congure evil-mac-address, the rewall lter:
[edit firewall]
family bridge {
filter evil-mac-address {
term one {
from {
source-mac-address 88:05:00:29:3c:de/48;
}
1484
then {
count evil-mac-address; # Counts frame with the bad source MAC address
discard;
}
term two {
then accept; # Make sure to accept other traffic
}
}
}
}
2. Apply evil-mac-address as an input lter to vlan100200 on Router 1:
[edit routing-instances]
virtual-switch-R1-1 {
bridge-domains {
vlan100200 {
domain-type bridge;
forwarding-options {
filter {
input evil-mac-address;
}
}
}
}
}
RELATED DOCUMENTATION
Understanding Firewall Filters Used to Control Trac Within Bridge Domains and VPLS Instances |
1483
Example: Conguring Policing and Marking of Trac Entering a VPLS Core | 1489
Example: Conguring Filtering of Frames by IEEE 802.1p Bits | 1486
Example: Conguring Filtering of Frames by Packet Loss Priority | 1487
1485
Example: Conguring Filtering of Frames by IEEE 802.1p Bits
For the bridge and vpls protocol families only, MX Series router rewall lters can be congured to
provide matching on IEEE 802.1p priority bits in packets with VLAN tagging:
• To congure a rewall lter term that includes matching on IEEE 802.1p learned VLAN priority (in
the outer VLAN tag), use the learn-vlan-1p-priority or learn-vlan-1p-priority-except match condion.
• To congure a rewall lter term that includes matching on IEEE 802.1p user priority (in the inner
VLAN tag), use the user-vlan-1p-priority or user-vlan-1p-priority-except match condion.
For more detailed informaon about conguring rewall lters and conguring lter match condions
for Layer 2 bridging trac on the MX Series routers, see the Roung Policies, Firewall Filters, and Trac
Policers User Guide.
NOTE: Layer 2 bridging is supported only on the MX Series routers. For more informaon about
how to congure Layer 2 bridging, see the Roung Policies, Firewall Filters, and Trac Policers
User Guide.
This example Layer 2 bridging rewall lter nds any incoming frames with an IEEE 802.1p learned
VLAN priority level of either 1 or 2, and then classies the packet in the best-eort default forwarding
class.
NOTE: This example does not present exhausve conguraon lisngs for all routers in the
gures. However, you can use this example with a broader conguraon strategy to complete
the MX Series router network Ethernet Operaons, Administraon, and Maintenance (OAM)
conguraons.
To congure ltering of frames by IEEE 802.1p bits:
1. Congure the rewall lter lter-learn-vlan-congure-forwarding:
[edit firewall]
family bridge {
filter filter-learn-vlan-configure-forwarding {
term 0 {
from {
learn-vlan-1p-priority [1 2];
}
then forwarding-class best-effort;
1486
}
}
}
2. Apply the rewall lter lter-learn-vlan-congure-forwarding as an input lter to ge-0/0/0:
[edit interfaces]
ge-0/0/0 {
unit 0 {
family bridge {
filter {
input filter-learn-vlan-configure-forwarding;
}
}
}
}
RELATED DOCUMENTATION
Understanding Firewall Filters Used to Control Trac Within Bridge Domains and VPLS Instances |
1483
Example: Conguring Policing and Marking of Trac Entering a VPLS Core | 1489
Example: Conguring Filtering of Frames by MAC Address | 1484
Example: Conguring Filtering of Frames by Packet Loss Priority | 1487
Example: Conguring Filtering of Frames by Packet Loss Priority
To congure an MX Series router rewall lter to provide matching on the packet loss priority (PLP) level
carried in the frame, use the loss-priority or loss-priority-except match condion. Packet loss priority
matching is available for all protocols. For more detailed informaon about conguring rewall lters
and conguring lter match condions for Layer 2 bridging trac on the MX Series routers, see the
Roung Policies, Firewall Filters, and Trac Policers User Guide.
1487
NOTE: Layer 2 bridging is supported only on the MX Series routers. For more informaon about
how to congure Layer 2 bridging, see the Junos OS Roung Protocols Library for Roung
Devices.
This example Layer 2 bridging rewall lter nds any incoming frames with a packet loss priority (PLP)
level of medium-high, and then classies the packet in the expedited-forwarding default forwarding
class.
NOTE: This example does not present exhausve conguraon lisngs for all routers in the
gures. However, you can use this example with a broader conguraon strategy to complete
the MX Series router network Ethernet Operaons, Administraon, and Maintenance (OAM)
conguraons.
To congure ltering of frames by packet loss priority:
1. Congure the rewall lter lter-plp-congure-forwarding:
[edit firewall]
family bridge {
filter filter-plp-configure-forwarding {
term 0 {
from {
loss-priority medium-high;
}
then forwarding-class expedited-forwarding;
}
}
}
2. Congure a Layer 2 bridging domain bd for the ge-0/0/0 interface (that has already been congured
at the [edit interfaces] hierarchy level):
[edit bridge-domains]
bd {
domain-type bridge {
interface ge-0/0/0;
1488
}
}
3. Apply the lter lter-plp-congure-forwarding as an input lter to the ge-0/0/0 interface:
[edit interfaces]
ge-0/0/0 {
unit 0 {
family bridge {
filter {
input filter-plp-configure-forwarding;
}
}
}
}
RELATED DOCUMENTATION
Roung Policies, Firewall Filters, and Trac Policers User Guide
Understanding Firewall Filters Used to Control Trac Within Bridge Domains and VPLS Instances |
1483
Example: Conguring Policing and Marking of Trac Entering a VPLS Core | 1489
Example: Conguring Filtering of Frames by MAC Address | 1484
Example: Conguring Filtering of Frames by IEEE 802.1p Bits | 1486
Example: Conguring Policing and Marking of Trac Entering a VPLS
Core
This example rewall lter allows a service provider to limit the aggregate broadcast trac entering the
virtual private LAN service (VPLS) core. The broadcast, unknown unicast, and non-IP mulcast trac
received from one of the service provider’s customers on a logical interface has a policer applied. The
service provider has also congured a two-rate, three-color policer to limit the customer’s IP mulcast
trac. For more informaon on the conguraon of policers, see the Junos OS Class of Service User
Guide for Roung Devices.
The posion of the router is shown in Figure 65 on page 1490.
1489
Figure 65: Policing and Marking Trac Entering a VPLS Core
There are four major parts to the conguraon:
• The policer for broadcast, unknown unicast, and non-IP mulcast trac. This example marks the loss
priority as high if this type of trac exceeds 50 Kbps.
• The two-rate, three-color policer for IP mulcast trac. This example congures a commied
informaon rate (CIR) of 4 Mbps, a commied burst size of 256 Kbytes, a peak informaon rate of
4.1 Mbps, and a peak burst size of 256 Kbytes (the same as the CIR).
• The lter that applies the two policers to VPLS.
• The applicaon of the lter to the customer interface conguraon as an input lter.
NOTE: This example does not present exhausve conguraon lisngs for all routers in the
gures. However, you can use this example with a broader conguraon strategy to complete
the MX Series router network Ethernet Operaons, Administraon, and Maintenance (OAM)
conguraons.
To congure policing and marking of trac entering a VPLS core:
1. Congure policer bcast-unknown-unicast-non-ip-mcast-policer, a rewall policer to limit the
aggregate broadcast, unknown unicast, and non-IP mulcast to 50 kbps:
[edit firewall]
policer bcast-unknown-unicast-non-ip-mcast-policer {
if-exceeding {
bandwidth-limit 50k;
burst-size-limit 150k;
}
then loss-priority high;
}
1490
2. Congure three-color-policer ip-mulcast-trac-policer, a three-color policer to limit the IP mulcast
trac:
[edit firewall]
three-color-policer ip-multicast-traffic-policer {
two-rate {
color-blind;
committed-information-rate 4m;
committed-burst-size 256k;
peak-information-rate 4100000;
peak-burst-size 256k;
}
}
3. Congure customer-1, a rewall lter that uses the two policers to limit and mark customer trac.
The rst term marks the IP mulcast trac based on the desnaon MAC address, and the second
term polices the broadcast, unknown unicast, and non-IP mulcast trac:
[edit firewall]
family vpls {
filter customer-1 {
term t0 {
from {
destination-mac-address {
01:00:5e:00:00:00/24;
}
}
then {
three-color-policer {
two-rate ip-multicast-traffic-policer;
}
forwarding-class expedited-forwarding;
}
}
term t1 {
from {
traffic-type [ broadcast unknown-unicast multicast ];
}
then policer bcast-unknown-unicast-non-ip-mcast-policer;
}
1491
}
}
4. Apply the rewall lter as an input lter to the customer interface at ge-2/1/0:
[edit interfaces]
ge-2/1/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 5 {
encapsulation vlan-vpls;
vlan-id 9;
family vpls {
filter {
input customer-1;
}
}
}
}
RELATED DOCUMENTATION
Understanding Firewall Filters Used to Control Trac Within Bridge Domains and VPLS Instances |
1483
Example: Conguring Filtering of Frames by MAC Address | 1484
Example: Conguring Filtering of Frames by IEEE 802.1p Bits | 1486
Example: Conguring Filtering of Frames by Packet Loss Priority | 1487
Understanding Firewall Filters on OVSDB-Managed Interfaces
When you use a Contrail controller to manage VXLANs on a QFX switch (through the Open vSwitch
Database—OVSDB—management protocol), the VXLAN interfaces are automacally congured with the
flexible-vlan-tagging and encapsulation extended-vlan-bridge statements. Starng with Junos OS Release
14.1X53-D30, you can create family ethernet-switching logical units (subinterfaces) on these interfaces.
This enables you to apply Layer 2 (family ethernet-switching) rewall lters to these subinterfaces, which
means that you apply rewall lters to OVSDB-managed interfaces. These lters support all the same
match condions and acons as any other Layer 2 lter.
1492
WARNING: Firewall lters are the only supported conguraon items on family
ethernet-switching subinterfaces of OVSDB-managed interfaces. Layer 2 (port) lters are
the only allowed lters.
Because a Contrail controller can create subinterfaces dynamically, you need to apply rewall lters in
such a way that the lters will apply to subinterfaces whenever the controller creates them. You
accomplish this by using conguraon groups to congure and apply the rewall lters. See "Example:
Applying a Firewall Filter to OVSDB-Managed Interfaces" on page 1493 for more informaon.
RELATED DOCUMENTATION
Example: Applying a Firewall Filter to OVSDB-Managed Interfaces | 1493
Overview of Firewall Filters (QFX Series) | 1720
Understanding VXLANs
Understanding the OVSDB Protocol Running on Juniper Networks Devices
Understanding Policers on OVSDB-Managed Interfaces | 2032
Example: Applying a Firewall Filter to OVSDB-Managed Interfaces
IN THIS SECTION
Requirements | 1494
Overview | 1494
Conguraon | 1494
Starng with Junos OS Release 14.1X53-D30, you can create family ethernet-switching logical units
(subinterfaces) on VXLAN interfaces managed by a Contrail controller. (The controller and switch
communicate through the Open vSwitch Database—OVSDB—management protocol). This support
enables you to apply Layer 2 (family ethernet-switching) rewall lters to these subinterfaces, which means
that you apply rewall lters to OVSDB-managed interfaces. Because a Contrail controller can create
subinterfaces dynamically, you need to apply rewall lters in such a way that the lters will apply to
subinterfaces whenever the controller creates them. You accomplish this by using conguraon groups
1493
to congure and apply the rewall lters. (You must use conguraon groups for this purpose—that is,
you cannot apply a rewall lter directly to these subinterfaces.)
NOTE: Firewall lters are the only supported conguraon items on family ethernet-switching
subinterfaces of OVSDB-managed interfaces. Layer 2 (port) lters are the only allowed lters.
Requirements
This example uses the following hardware and soware components:
• A QFX5100 switch
• Junos OS Release 14.1X53-D30 or later
Overview
This example assumes that interfaces xe-0/0/0 and xe-0/0/1 on the switch are VXLAN interfaces
managed by a Contrail controller, which means that the controller has applied the flexible-vlan-tagging
and encapsulation extended-vlan-bridge statements to these interfaces. You want to apply a rewall lter
that accepts trac from the Web to any subinterfaces that the controller creates dynamically. To apply a
rewall lter Layer 2 (port) rewall lter to any dynamically created subinterfaces, you must create and
apply the lter as shown in this example.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1494
Procedure | 1495
To congure a rewall lter to be automacally applied to subinterfaces created dynamically by a
Contrail controller, perform these tasks:
CLI Quick Conguraon
[edit]
set groups vxlan-filter-group interfaces xe-0/0/0 unit <*> family ethernet-switching filter
input vxlan-filter
set groups vxlan-filter-group interfaces xe-0/0/1 unit <*> family ethernet-switching filter
1494
input vxlan-filter
set groups vxlan-filter-group firewall family ethernet-switching filter vxlan-filter term t1
from destination-port 80
set groups vxlan-filter-group firewall family ethernet-switching filter vxlan-filter term t1
then accept
set apply-groups vxlan-filter-group
Procedure
Step-by-Step Procedure
1. Create conguraon group vxlan-filter-group to apply rewall lter vxlan-filter to any subinterface of
interface xe-0/0/0. The lter applies to any subinterface because you specify unit <*>:
[edit]
user@switch# set groups vxlan-filter-group interfaces xe-0/0/0 unit <*> family ethernet-
switching filter input vxlan-filter
2. Create the same conguraon for interface xe-0/0/1:
[edit]
user@switch# set groups vxlan-filter-group interfaces xe-0/0/1 unit <*> family ethernet-
switching filter input vxlan-filter
3. Congure the group to include a family ethernet-switching lter that matches on outgoing trac to the
web:
[edit]
user@switch# set groups vxlan-filter-group firewall family ethernet-switching filter vxlan-
filter term t1 from destination-port 80
4. Congure the group to accept the trac that matches the lter:
[edit]
user@switch# set groups vxlan-filter-group firewall family ethernet-switching filter vxlan-
filter term t1 then accept
1495
5. Apply the group to enable its conguraon:
[edit]
user@switch# set apply-groups vxlan-filter-group
RELATED DOCUMENTATION
Understanding Junos OS Conguraon Groups
Overview of Firewall Filters (QFX Series) | 1720
Understanding VXLANs
Understanding the OVSDB Protocol Running on Juniper Networks Devices
Example: Applying a Policer to OVSDB-Managed Interfaces | 2033
1496
CHAPTER 25
Conguring Firewall Filters for Forwarding,
Fragments, and Policing
IN THIS CHAPTER
Filter-Based Forwarding Overview | 1497
Firewall Filters That Handle Fragmented Packets Overview | 1500
Stateless Firewall Filters That Reference Policers Overview | 1500
Example: Conguring Filter-Based Forwarding on the Source Address | 1501
Example: Conguring Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP
Address | 1515
Filter-Based Forwarding Overview
IN THIS SECTION
Filters That Classify Packets or Direct Them to Roung Instances | 1498
Input Filtering to Classify and Forward Packets Within the Router or Switch | 1499
Output Filtering to Forward Packets to Another Roung Table | 1499
Restricons for Applying Filter-Based Forwarding | 1499
Firewall lters can be used to block specic packets. They can also be used to aect how specic
packets are forwarded.
1497
Filters That Classify Packets or Direct Them to Roung Instances
For IPv4 or IPv6 trac only, you can use stateless rewall lters in conjuncon with forwarding classes
and roung instances to control how packets travel in a network. This is called
lter-based forwarding
(FBF).
You can dene a ltering term that matches incoming packets based on source address and then
classies matching packets to a specied forwarding class. This type of ltering can be congured to
grant certain types of trac preferenal treatment or to improve load balancing. To congure a stateless
rewall lter
to classify packets to a forwarding class, congure a term with the
nonterminang acon
forwarding-class
class-name
.
You can also dene a ltering term that directs matching packets to a specied roung instance. This
type of ltering can be congured to route specic types of trac through a rewall or other security
device before the trac connues on its path. To congure a stateless rewall lter to direct trac to a
roung instance, congure a term with the
terminang acon
routing-instance
routing-instance-name
<topology
topology-name
> to specify the roung instance to which matching packets will be forwarded.
NOTE: Unicast Reverse Path Forwarding (uRPF) check is compable with FBF acons. uRPF
check is processed for source address checking before any FBF acons are enabled for stac and
dynamic interfaces. This applies to both IPv4 and IPv6 families.
NOTE: Services Ooad (SOF) and Power Mode Ipsec (PMI) path will not be followed by the
packets which are forwarded with FBF.
• SOF - Even if SOF is enabled , the packets will not go through SOF if they are forwarded with
FBF.
• PMI - If PMI is congured, the direcon to which the lter is congured, the packets in that
direcon will not go through the PMI. The returning packets will go through the PMI,
provided the returning packets are not forwarded with FBF.
To forward trac to the master roung instance, reference routing-instance default in the rewall
conguraon, as shown here:
[edit firewall]
family inet {
filter test {
term 1 {
then {
1498
routing-instance default;
}
}
}
}
NOTE: Do not reference routing-instance master. This does not work.
Input Filtering to Classify and Forward Packets Within the Router or Switch
You can congure lters to classify packets based on source address and specify the forwarding path the
packets take within the router or switch by conguring a lter on the ingress interface.
For example, you can use this lter for applicaons to dierenate trac from two clients that have a
common access layer (for example, a Layer 2 switch) but are connected to dierent Internet service
providers (ISPs). When the lter is applied, the router or switch can dierenate the two trac streams
and direct each to the appropriate network. Depending on the media type the client is using, the lter
can use the source IP address to forward the trac to the corresponding network through a tunnel. You
can also congure lters to classify packets based on IP protocol type or IP precedence bits.
Output Filtering to Forward Packets to Another Roung Table
You can also forward packets based on output lters by conguring a lter on the egress interfaces. In
the case of
port mirroring
, it is useful for port-mirrored packets to be distributed to mulple monitoring
PICs and collecon PICs based on paerns in packet headers. FBF on the port-mirroring egress interface
must be congured.
Packets forwarded to the output lter have been through at least one route lookup when an FBF lter is
congured on the egress interface. Aer the packet is classied at the egress interface by the FBF lter,
it is redirected to another roung table for further route lookup.
Restricons for Applying Filter-Based Forwarding
An interface congured with lter-based forwarding does not support source-class usage (SCU) lter
matching or source-class and desnaon-class usage (SCU/DCU) accounng.
If lter-based forwarding is directly aached to an interface or through forwarding table lter, then the
DCU on that interface will not work.
1499
RELATED DOCUMENTATION
Example: Conguring Filter-Based Forwarding on the Source Address | 1501
Example: Conguring Filter-Based Forwarding on Logical Systems | 1240
Firewall Filters That Handle Fragmented Packets Overview
You can create stateless rewall lters that handle fragmented packets desned for the Roung Engine.
By applying these policies to the Roung Engine, you protect against the use of IP fragmentaon as a
means to disguise TCP packets from a
rewall lter
.
For example, consider an IP packet that is fragmented into the smallest allowable fragment size of
8 bytes (a 20-byte IP header plus an 8-byte payload). If this IP packet carries a TCP packet, the rst
fragment (fragment oset of 0) that arrives at the device contains only the TCP source and desnaon
ports (rst 4 bytes), and the sequence number (next 4 bytes). The TCP ags, which are contained in the
next 8 bytes of the TCP header, arrive in the second fragment (fragment oset of 1).
See RFC 1858,
Security Consideraons for IP Fragment Filtering
.
RELATED DOCUMENTATION
Understanding How to Use Standard Firewall Filters | 780
Example: Conguring a Stateless Firewall Filter to Handle Fragments | 1197
Stateless Firewall Filters That Reference Policers Overview
Policing, or rate liming, is an important component of rewall lters that lets you limit the amount of
trac that passes into or out of an interface.
A
rewall lter
that references a policer can provide protecon from denial-of-service (DOS) aacks.
Trac that exceeds the rate limits congured for the policer is either discarded or marked as lower
priority than trac that conforms to the congured rate limits. Packets can be marked for a lower
priority by being set to a specic output queue, set to a specic packet loss priority (PLP) level, or both.
When necessary, low-priority trac can be discarded to prevent congeson.
A policer species two types of rate limits on trac:
• Bandwidth limit—The average trac rate permied, specied as a number of bits per second.
• Maximum burst size—The packet size permied for bursts of data that exceed the bandwidth limit.
1500
Policing uses an algorithm to enforce a limit on average bandwidth while allowing bursts up to a
specied maximum value. You can use policing to dene specic classes of trac on an interface and
apply a set of rate limits to each class. Aer you name and congure a policer, it is stored as a template.
You can then apply the policer in an interface conguraon or, to rate-limit packet-ltered trac only, in
a rewall lter conguraon.
For an IPv4 rewall lter term only, you can also specify a
prex-specic acon
as a nonterminang
acon that applies a policer to the matched packets. A prex-specic acon applies addional matching
criteria on the lter-matched packets based on specied address prex bits and then associates the
matched packets with a counter and policer instance for that lter term or for all terms in the rewall
lter.
To apply a policer or a prex acon to packet-ltered trac, you can use the following rewall lter
nonterminang acons:
• policer
policer-name
• three-color-policer (single-rate | two-rate)
policer-name
• prefix-action
action-name
NOTE: The packet lengths that a policer considers depends on the address family of the rewall
lter. See "Understanding the Frame Length for Policing Packets" on page 1930.
RELATED DOCUMENTATION
Firewall Filter Nonterminang Acons | 873
Controlling Network Access Using Trac Policing Overview | 1920
Prex-Specic Counng and Policing Acons | 2087
Example: Conguring Filter-Based Forwarding on the Source Address
IN THIS SECTION
Requirements | 1502
Overview | 1502
1501
Conguraon | 1505
Vericaon | 1513
This example shows how to congure lter-based forwarding (FBF), which is somemes also called
Policy Based Roung (PBR). The lter classies packets to determine their forwarding path within the
ingress roung device.
Filter-based forwarding is supported for IP version 4 (IPv4) and IP version 6 (IPv6).
NOTE: QFX5110, QFX5120, QFX5130, QFX5200, QFX5210, QFX5220, QFX5230, QFX5240,
and QFX5700 do not support instance-type forwarding; only instance-type virtual-router is
supported.
Requirements
No special conguraon beyond device inializaon is required for this example.
Overview
IN THIS SECTION
Topology | 1504
In this example, we use FBF for service provider selecon when customers have Internet connecvity
provided by dierent ISPs yet share a common access layer. When a shared media (such as a cable
modem) is used, a mechanism on the common access layer looks at Layer 2 or Layer 3 addresses and
disnguishes between customers. You can use lter-based forwarding when the common access layer is
implemented using a combinaon of Layer 2 switches and a single router.
With FBF, all packets received on an interface are considered. Each packet passes through a lter that
has match condions. If the match condions are met for a lter and you have created a roung
instance, FBF is applied to the packet. The packet is forwarded based on the next hop specied in the
roung instance. For stac routes, the next hop can be a specic LSP.
1502
NOTE: Source-class usage lter matching and unicast reverse-path forwarding checks are not
supported on an interface congured for FBF.
To congure FBF, perform the following tasks:
• Create a match lter on the ingress device. To specify a match lter, include the filter
filter-name
statement at the [edit firewall] hierarchy level. A packet that passes through the lter is compared
against a set of rules to classify it and to determine its membership in a set. Once classied, the
packet is forwarded to a roung table specied in the accept acon in the lter descripon language.
The roung table then forwards the packet to the next hop that corresponds to the desnaon
address entry in the table.
• Create roung instances that specify the roung table(s) to which a packet is forwarded, and the
desnaon to which the packet is forwarded at the [edit routing-instances] hierarchy level. For
example:
[edit]
routing-instances {
routing-table-name1
{
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.0.14;
}
}
}
routing-table-name2
{
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.0.18;
}
}
}
}
• Create a RIB group to share interface routes with the forwarding roung instances used in lter-
based forwarding (FBF). This part of the conguraon resolves the routes installed in the roung
1503
instances to directly connected next hops on that interface. Create the roung table group at the
[edit routing-options] hierarchy level.
[edit]
routing-options {
interface-routes {
rib-group;
inet {
int-routes
;
}
}
}
}
routing-options {
rib-groups {
int-routes {
import-rib {
inet.0
;
webtraffic.inet.0
;
}
}
}
}
This example shows a packet lter that directs customer trac to a next-hop router in the domains, SP1
or SP2, based on the packet’s source address.
If the packet has a source address assigned to an SP1 customer, desnaon-based forwarding occurs
using the sp1-route-table.inet.0 roung table. If the packet has a source address assigned to an SP2
customer, desnaon-based forwarding occurs using the sp2-route-table.inet.0 roung table. If a packet
does not match either of these condions, the lter accepts the packet, and desnaon-based
forwarding occurs using the standard inet.0 roung table.
Topology
Figure 66 on page 1505 shows the topology used in this example.
On Device P1, an input lter classies packets received from Device PE3 and Device PE4. The packets
are routed based on the source addresses. Packets with source addresses in the 10.1.1.0/24 and
10.1.2.0/24 networks are routed to Device PE1. Packets with source addresses in the 10.2.1.0/24 and
10.2.2.0/24 networks are routed to Device PE2.
1504
Figure 66: Filter-Based Forwarding
To establish connecvity, OSPF is congured on all of the interfaces. For demonstraon purposes,
loopback interface addresses are congured on the roung devices to represent networks in the clouds.
The "CLI Quick Conguraon" on page 1505 secon shows the enre conguraon for all of the
devices in the topology. The "Conguring Filter-Based Forwarding on Device P1" on page 1509 secon
shows the step-by-step conguraon of the ingress roung device, Device P1.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1505
Conguring the Firewall Filter on P1 | 1507
Conguring Filter-Based Forwarding on Device P1 | 1509
Results | 1510
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
1505
Device P1
set firewall filter classify-customers term sp1-customers from source-address 10.1.1.0/24
set firewall filter classify-customers term sp1-customers from source-address 10.1.2.0/24
set firewall filter classify-customers term sp1-customers then log
set firewall filter classify-customers term sp1-customers then routing-instance sp1-route-table
set firewall filter classify-customers term sp2-customers from source-address 10.2.1.0/24
set firewall filter classify-customers term sp2-customers from source-address 10.2.2.0/24
set firewall filter classify-customers term sp2-customers then log
set firewall filter classify-customers term sp2-customers then routing-instance sp2-route-table
set firewall filter classify-customers term default then accept
set interfaces fe-1/2/0 unit 0 family inet filter input classify-customers
set interfaces fe-1/2/0 unit 0 family inet address 172.16.0.10/30
set interfaces fe-1/2/1 unit 0 family inet address 172.16.0.13/30
set interfaces fe-1/2/2 unit 0 family inet address 172.16.0.17/30
set protocols ospf rib-group fbf-group
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
set routing-instances sp1-route-table instance-type forwarding
set routing-instances sp1-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.14
set routing-instances sp2-route-table instance-type forwarding
set routing-instances sp2-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.18
set routing-options interface-routes rib-group fbf-group
set routing-options rib-groups fbf-group import-rib inet.0
set routing-options rib-groups fbf-group import-rib sp1-route-table.inet.0
set routing-options rib-groups fbf-group import-rib sp2-route-table.inet.0
Device P2
set interfaces fe-1/2/0 unit 0 family inet address 172.16.0.2/30
set interfaces fe-1/2/1 unit 0 family inet address 172.16.0.6/30
set interfaces fe-1/2/2 unit 0 family inet address 172.16.0.9/30
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Device PE1
set interfaces fe-1/2/0 unit 0 family inet address 172.16.0.14/30
set interfaces lo0 unit 0 family inet address 172.16.1.1/32
1506
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Device PE2
set interfaces fe-1/2/0 unit 0 family inet address 172.16.0.18/30
set interfaces lo0 unit 0 family inet address 172.16.2.2/32
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Device PE3
set interfaces fe-1/2/0 unit 0 family inet address 172.16.0.1/30
set interfaces lo0 unit 0 family inet address 10.1.1.1/32
set interfaces lo0 unit 0 family inet address 10.1.2.1/32
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Device PE4
set interfaces fe-1/2/0 unit 0 family inet address 172.16.0.5/30
set interfaces lo0 unit 0 family inet address 10.2.1.1/32
set interfaces lo0 unit 0 family inet address 10.2.2.1/32
set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
Conguring the Firewall Filter on P1
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure the rewall lter on the main router or switch:
1507
1. Congure the source addresses for SP1 customers.
[edit firewall filter classify-customers term sp1-customers]
user@host# set from source-address 10.1.1.0/24
user@host# set from source-address 10.1.2.0/24
2. Congure the acons that are taken when packets are received with the specied source addresses;
they are logged, and they are passed to the sp1-route-table roung instance for roung via the sp1-
route-table.inet.0 roung table.
[edit firewall filter classify-customers term sp1-customers]
user@host# set then log
user@host# set then routing-instance sp1-route-table
3. Congure the source addresses for SP2 customers.
[edit firewall filter classify-customers term sp2-customers]
user@host# set from source-address 10.2.1.0/24
user@host# set from source-address 10.2.2.0/24
4. Congure the acons that are taken when packets are received with the specied source addresses;
they are logged, and they are passed to the sp2-route-table roung instance for roung via the sp2-
route-table.inet.0 roung table.
[edit firewall filter classify-customers term sp2-customers]
user@host# set then log
user@host# set then routing-instance sp2-route-table
5. Congure the acon to take when packets are received from any other source address; they are
accepted and routed using the default IPv4 unicast roung table, inet.0.
[edit firewall filter classify-customers term default]
user@host# set then accept
1508
Conguring Filter-Based Forwarding on Device P1
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure the roung instances:
1. Congure the interfaces.
[edit interfaces fe-1/2/0]
user@host# set unit 0 family inet address 172.16.0.10/30
[edit interfaces fe-1/2/1]
user@host# set unit 0 family inet address 172.16.0.13/30
[edit interfaces fe-1/2/2]
user@host# set unit 0 family inet address 172.16.0.17/30
2. Assign the classify-customers rewall lter to router interface fe-1/2/0.0 as an input packet lter.
[edit interfaces fe-1/2/0]
user@host# set unit 0 family inet filter input classify-customers
3. Congure connecvity, using either a roung protocol or stac roung.
As a best pracce, disable roung on the management interface.
[edit protocols ospf area 0.0.0.0]
user@host# set interface all
user@host# set interface fxp0.0 disable
4. Create the roung instances that are referenced in the classify-customers rewall lter. The forwarding
instance type provides support for lter-based forwarding, where interfaces are not associated with
instances.
[edit routing-instances]
user@host# set sp1-route-table instance-type forwarding
user@host# set sp2-route-table instance-type forwarding
1509
5. For each roung instance, dene a default route to forward trac to the specied next hop (PE1 and
PE2 in this example).
[edit routing-instances ]
user@host# set sp1-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.14
user@host# set sp2-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.18
6. Associate the roung tables to form a roung table group. The rst roung table, inet.0, is the
primary roung table, and the others are secondary roung tables. The primary roung table
determines the address family of the roung table group, in this case IPv4.
[edit routing-options]
user@host# set rib-groups fbf-group import-rib inet.0
user@host# set rib-groups fbf-group import-rib sp1-route-table.inet.0
user@host# set rib-groups fbf-group import-rib sp2-route-table.inet.0
7. Specify the f-group roung table group within the OSPF conguraon to install OSPF routes into
the three roung tables.
[edit protocols ospf]
user@host# set rib-group fbf-group
8. Commit the conguraon when you are done.
[edit]
user@host# commit
Results
Conrm your conguraon by issuing the show interfaces, show firewall, show protocols, show routing-instances,
and show routing-options commands.
user@host# show interfaces
fe-1/2/0 {
unit 0 {
family inet {
filter {
input classify-customers;
1510
}
address 172.16.0.10/30;
}
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 172.16.0.13/30;
}
}
}
fe-1/2/2 {
unit 0 {
family inet {
address 172.16.0.17/30;
}
}
}
user@host# show firewall
filter classify-customers {
term sp1-customers {
from {
source-address {
10.1.1.0/24;
10.1.2.0/24;
}
}
then {
log;
routing-instance sp1-route-table;
}
}
term sp2-customers {
from {
source-address {
10.2.1.0/24;
10.2.2.0/24;
}
}
1511
then {
log;
routing-instance sp2-route-table;
}
}
term default {
then accept;
}
}
user@host# show protocols
ospf {
rib-group fbf-group;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
user@host# show routing-instances
sp1-route-table {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.0.14;
}
}
}
sp2-route-table {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.0.18;
}
1512
}
}
user@host# show routing-options
rib-groups {
fbf-group {
import-rib [ inet.0 sp1-route-table.inet.0 sp2-route-table.inet.0 ];
}
}
Vericaon
IN THIS SECTION
Pinging with Specied Source Addresses | 1513
Verifying the Firewall Filter | 1514
Conrm that the conguraon is working properly.
Pinging with Specied Source Addresses
Purpose
Send some ICMP packets across the network to test the rewall lter.
Acon
1. Run the ping command, pinging the lo0.0 interface on Device PE1.
The address congured on this interface is 172.16.1.1.
Specify the source address 10.1.2.1, which is the address congured on the lo0.0 interface on Device
PE3.
user@PE3> ping 172.16.1.1 source 10.1.2.1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=62 time=1.444 ms
1513
64 bytes from 172.16.1.1: icmp_seq=1 ttl=62 time=2.094 ms
^C
--- 172.16.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.444/1.769/2.094/0.325 ms
2. Run the ping command, pinging the lo0.0 interface on Device PE2.
The address congured on this interface is 172.16.2.2.
Specify the source address 10.2.1.1, which is the address congured on the lo0.0 interface on Device
PE4.
user@PE4> ping 172.16.2.2 source 10.2.1.1
PING 172.16.2.2 (172.16.2.2): 56 data bytes
64 bytes from 172.16.2.2: icmp_seq=0 ttl=62 time=1.473 ms
64 bytes from 172.16.2.2: icmp_seq=1 ttl=62 time=1.407 ms
^C
--- 172.16.2.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.407/1.440/1.473/0.033 ms
Meaning
Sending these pings acvates the rewall lter acons.
Verifying the Firewall Filter
Purpose
Make sure the rewall lter acons take eect.
Acon
1.
Run the show firewall log command on Device P1.
user@P1> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr Dest Addr
13:52:20 pfe A fe-1/2/0.0 ICMP 10.2.1.1 172.16.2.2
1514
13:52:19 pfe A fe-1/2/0.0 ICMP 10.2.1.1 172.16.2.2
13:51:53 pfe A fe-1/2/0.0 ICMP 10.1.2.1 172.16.1.1
13:51:52 pfe A fe-1/2/0.0 ICMP 10.1.2.1 172.16.1.1
RELATED DOCUMENTATION
Conguring Filter-Based Forwarding
Copying and Redirecng Trac with Port Mirroring and Filter-Based Forwarding
Using Filter-Based Forwarding to Export Monitored Trac to Mulple Desnaons
Filter-Based Forwarding Overview | 1497
Example: Conguring Filter-Based Forwarding to a Specic Outgoing
Interface or Desnaon IP Address
IN THIS SECTION
Understanding Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP Address | 1515
Example: Conguring Filter-Based Forwarding to a Specic Outgoing Interface | 1517
Example: Conguring Filter-Based Forwarding to a Specic Desnaon IP Address | 1524
Understanding Filter-Based Forwarding to a Specic Outgoing Interface or
Desnaon IP Address
Policy-based roung (also known as lter-based forwarding) refers to the use of rewall lters that are
applied to an interface to match certain IP header characteriscs and to route only those matching
packets dierently than the packets would normally be routed.
Starng in Junos OS Release 12.2, you can use then next-interface, then next-ip, or then next-ip6 as an
acon in a
rewall lter
. From specic match condions, IPv4 and IPv6 addresses or an interface name
can be specied as the response acon to a match.
The set of match condions can be as follows:
• Layer-3 properes (for example, the source or desnaon IP address or the TOS byte)
1515
• Layer-4 properes (for example, the source or desnaon port)
The route for the given IPv4 or IPv6 address has to be present in the roung table for policy-based
roung to take eect. Similarly, the route through the given interface has to be present in the
forwarding table for next-interface acon to take eect. This can be achieved by conguring an interior
gateway protocol (IGP), such as OSPF or IS-IS, to adverse Layer 3 routes.
The rewall lter matches the condions and forwards the packet to one of the following:
• An IPv4 address (using the next-ip rewall lter acon)
• An IPv6 address (using the next-ip6 rewall lter acon)
• An interface (using the next-interface rewall lter acon)
Suppose, for example, that you want to oer services to your customers, and the services reside on
dierent servers. An example of a service might be hosted DNS or hosted FTP. As customer trac
arrives at the Juniper Networks roung device, you can use lter-based forwarding to send trac to the
servers by applying a match condion on a MAC address or an IP address or simply an incoming
interface and send the packets to a certain outgoing interface that is associated with the appropriate
server. Some of your desnaons might be IPv4 or IPv6 addresses, in which case the next-ip or next-ip6
acon is useful.
Oponally, you can associate the outgoing interfaces or IP addresses with roung instances.
For example:
firewall {
filter filter1 {
term t1 {
from {
source-address {
10.1.1.3/32;
}
}
then {
next-interface {
xe-0/1/0.1;
routing-instance rins1;
}
}
}
term t2 {
from {
1516
source-address {
10.1.1.4/32;
}
}
then {
next-interface {
xe-0/1/0.2;
routing-instance rins2;
}
}
}
}
}
routing-instances {
rins1 {
instance-type virtual-router;
interface xe-0/1/0.1;
}
rins2 {
instance-type virtual-router;
interface xe-0/1/0.2;
}
}
SEE ALSO
Example: Conguring Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP
Address | 1515
Firewall Filter Nonterminang Acons | 873
Example: Conguring Filter-Based Forwarding to a Specic Outgoing Interface
IN THIS SECTION
Requirements | 1518
Overview | 1518
Conguraon | 1519
Vericaon | 1523
1517
This example shows how to use then next-interface as an acon in a rewall lter.
Requirements
This example has the following hardware and soware requirements:
• MX Series 5G Universal Roung Plaorm as the roung device with the rewall lter congured.
• Junos OS Release 12.2 running on the roung device with the rewall lter congured.
• The lter with the next-interface (or next-ip) acon can only be applied to an interface that is hosted
on a Trio MPC. If you apply the lter to an I-chip based DPC, the commit operaon fails.
• The outgoing interface referred to in the next-interface
interface-name
acon can be hosted on a Trio
MPC or an I-chip based DPC.
Overview
IN THIS SECTION
Topology | 1519
In this example, Device R1 has two loopback interface addresses congured: 172.16.1.1 and 172.16.2.2.
On Device R2, a rewall lter has mulple terms congured. Each term matches one of the source
addresses in incoming trac, and routes the trac to specied outgoing interfaces. The outgoing
interfaces are congured as VLAN-tagged interfaces between Device R2 and Device R3.
IS-IS is used for connecvity among the devices.
Figure 67 on page 1518 shows the topology used in this example.
Figure 67: Filter-Based Forwarding to Specied Outgoing Interfaces
This example shows the conguraon on Device R2.
1518
Topology
Conguraon
IN THIS SECTION
Procedure | 1519
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R2
set interfaces ge-2/1/0 unit 0 family inet filter input filter1
set interfaces ge-2/1/0 unit 0 family inet address 10.0.0.10/30
set interfaces ge-2/1/0 unit 0 description to-R1
set interfaces ge-2/1/0 unit 0 family iso
set interfaces ge-2/1/1 vlan-tagging
set interfaces ge-2/1/1 description to-R3
set interfaces ge-2/1/1 unit 0 vlan-id 1001
set interfaces ge-2/1/1 unit 0 family inet address 10.0.0.13/30
set interfaces ge-2/1/1 unit 0 family iso
set interfaces ge-2/1/1 unit 1 vlan-id 1002
set interfaces ge-2/1/1 unit 1 family inet address 10.0.0.25/30
set interfaces ge-2/1/1 unit 1 family iso
set interfaces lo0 unit 0 family inet address 10.255.4.4/32
set interfaces lo0 unit 0 family iso address 49.0001.0010.0000.0404.00
set firewall family inet filter filter1 term t1 from source-address 172.16.1.1/32
set firewall family inet filter filter1 term t1 then next-interface ge-2/1/1.0
set firewall family inet filter filter1 term t2 from source-address 172.16.2.2/32
set firewall family inet filter filter1 term t2 then next-interface ge-2/1/1.1
set protocols isis interface all level 1 disable
1519
set protocols isis interface fxp0.0 disable
set protocols isis interface lo0.0
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in
the Junos OS CLI User Guide.
To congure Device R2:
1. Congure the interfaces.
[edit interfaces]
user@R2# set ge-2/1/0 unit 0 family inet filter input filter1
user@R2# set ge-2/1/0 unit 0 family inet address 10.0.0.10/30
user@R2# set ge-2/1/0 unit 0 description to-R1
user@R2# set ge-2/1/0 unit 0 family iso
user@R2# set ge-2/1/1 vlan-tagging
user@R2# set ge-2/1/1 description to-R3
user@R2# set ge-2/1/1 unit 0 vlan-id 1001
user@R2# set ge-2/1/1 unit 0 family inet address 10.0.0.13/30
user@R2# set ge-2/1/1 unit 0 family iso
user@R2# set ge-2/1/1 unit 1 vlan-id 1002
user@R2# set ge-2/1/1 unit 1 family inet address 10.0.0.25/30
user@R2# set ge-2/1/1 unit 1 family iso
user@R2# set lo0 unit 0 family inet address 10.255.4.4/32
user@R2# set lo0 unit 0 family iso address 49.0001.0010.0000.0404.00
2. Congure the rewall lter.
[edit firewall family inet filter filter1]
user@R2# set term t1 from source-address 172.16.1.1/32
user@R2# set term t1 then next-interface ge-2/1/1.0
user@R2# set term t2 from source-address 172.16.2.2/32
user@R2# set term t2 then next-interface ge-2/1/1.1
1520
3. Enable IS-IS on the interfaces.
[edit protocols is-is]
user@R2# set interface all level 1 disable
user@R2# set interface fxp0.0 disable
user@R2# set interface lo0.0
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show firewall, and
show protocols commands. If the output does not display the intended conguraon, repeat the
conguraon instrucons in this example to correct it.
user@R2# show interfaces
ge-2/1/0 {
unit 0 {
description to-R1;
family inet {
filter {
input filter1;
}
address 10.0.0.10/30;
}
family iso;
}
}
ge-2/1/1 {
description to-R3;
vlan-tagging;
unit 0 {
vlan-id 1001;
family inet {
address 10.0.0.13/30;
}
family iso;
}
unit 1 {
vlan-id 1002;
family inet {
address 10.0.0.25/30;
1521
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.4.4/32;
}
family iso {
address 49.0001.0010.0000.0404.00;
}
}
}
user@R2# show firewall
family inet {
filter filter1 {
term t1 {
from {
source-address {
172.16.1.1/32;
}
}
then {
next-interface {
ge-2/1/1.0;
}
}
term t2 {
from {
source-address {
172.16.2.2/32;
}
}
then {
next-interface {
ge-2/1/1.1;
}
}
}
1522
}
}
user@R2# show protocols
isis {
interface all {
level 1 disable;
}
interface fxp0.0 {
disable;
}
interface lo0.0;
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Checking the Paths Used | 1523
Conrm that the conguraon is working properly.
Checking the Paths Used
Purpose
Make sure that the expected paths are used when sending trac from Device R1 to Device R4.
Acon
On Device R1, enter the traceroute command.
user@R1> traceroute 10.255.6.6 source 172.16.1.1
traceroute to 10.255.6.6 (10.255.6.6) from 172.16.1.1, 30 hops max, 40 byte packets
1 10.0.0.10 (10.0.0.10) 0.976 ms 0.895 ms 0.815 ms
1523
2 10.0.0.14 (10.0.0.14) 0.868 ms 0.888 ms 0.813 ms
3 10.255.6.6 (10.255.6.6) 1.715 ms 1.442 ms 1.382 ms
user@R1> traceroute 10.255.6.6 source 172.16.2.2
traceroute to 10.255.6.6 (10.255.6.6) from 172.16.2.2, 30 hops max, 40 byte packets
1 10.0.0.10 (10.0.0.10) 0.973 ms 0.907 ms 0.782 ms
2 10.0.0.26 (10.0.0.26) 0.844 ms 0.890 ms 0.852 ms
3 10.255.6.6 (10.255.6.6) 1.384 ms 1.516 ms 1.462 ms
Meaning
The output shows that the second hop changes, depending on the source address used in the traceroute
command.
To verify this feature, a traceroute operaon is performed on Device R1 to Device R4. When the source
IP address is 172.16.1.1, packets are forwarded out the ge-2/1/1.0 interface on Device R2. When the
source IP address is 172.16.2.2, packets are forwarded out the ge-2/1/1.1 interface on Device R2.
SEE ALSO
Understanding Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP Address
Example: Conguring Filter-Based Forwarding to a Specic Desnaon IP Address
Firewall Filter Nonterminang Acons | 873
Example: Conguring Filter-Based Forwarding to a Specic Desnaon IP Address
IN THIS SECTION
Requirements | 1525
Overview | 1525
Conguraon | 1526
Vericaon | 1535
This example shows how to use then next-ip as an acon in a rewall lter.
1524
Requirements
This example has the following hardware and soware requirements:
• MX Series 5G Universal Roung Plaorm as the roung device with the rewall lter congured.
• Junos OS Release 12.2 running on the roung device with the rewall lter congured.
• The lter with the next-interface (or next-ip) acon can only be applied to an interface that is hosted
on a Trio MPC. If you apply the lter to an I-chip based DPC, the commit operaon fails.
• The outgoing interface referred to in the next-interface interface-name acon can be hosted on a
Trio MPC or an I-chip based DPC.
Overview
IN THIS SECTION
Topology | 1526
In this example, Device R2 has two roung instances that are interconnected with physical links. Trac
from certain sources is required to be directed across the upper link for inspecon by a trac opmizer,
which acts transparently on the IP layer. When the trac opmizer fails, the trac moves to the lower
link. Flows in direcon R1>R3 and R3>R1 follow idencal paths.
Figure 68 on page 1525 shows the topology used in this example.
Figure 68: Filter-Based Forwarding to Specied Outgoing Interfaces
On Device R2, a rewall lter is applied to interface ge-1/0/8 in the input direcon. The second term
matches the specic source addresses 10.0.0.0/24, and routes the trac to address 192.168.0.3. This
1525
address resolves to next-hop 192.168.20.2. If the link connected to interface ge-1/1/0 goes down, the
address 192.168.0.3 will resolve to next-hop 192.168.30.2.
On Device R2, a rewall lter is applied to interface ge-1/0/0 in the input direcon. The second term
matches the specic desnaon addresses 10.0.0.0/24, and routes the trac to address 192.168.0.2.
This address resolves to next-hop 192.168.20.1. If the link connected to interface ge-1/3/8 goes down,
the address 192.168.0.2 will resolve to next-hop 192.168.30.1.
NOTE: The address congured using the next-ip acon is not automacally resolved. On Ethernet
interfaces, it is assumed that the congured address is resolved using a roung protocol or stac
routes.
Internal BGP (IBGP) is used between Device R2-VR1 and Device R2-VR2. External BGP (EBGP) is used
between Device R1 and Device R2-VR1, as well as between Device R2-VR2 and Device R3.
BGP operaons proceed as follows:
• R2-VR1 learns 10/8 from R1, and 0/0 from R2-VR2.
• R2-VR2 learns 0/0 from R3, and 10/8 from R2-VR1.
• R1 adverses 10/8, and receives 0/0 from R2-VR1.
• R3 adverses 0/0, and receives 10/8 from R2-VR2.
The rewall lter applied to Device R2 needs to allow control-plane trac for the directly connected
interfaces, in this case the EBGP sessions.
This example shows the conguraon on Device R2.
Topology
Conguraon
IN THIS SECTION
Procedure | 1527
1526
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces lo0 unit 0 family inet address 10.0.0.1/32
set interfaces lo0 unit 0 family inet address 10.1.0.1/32
set interfaces ge-1/0/8 unit 0 family inet address 192.168.10.1/24
set routing-options autonomous-system 64501
set protocols bgp group eBGP neighbor 192.168.10.2 peer-as 64502
set protocols bgp group eBGP export Announce10
set policy-options policy-statement Announce10 term 1 from route-filter 10.0.0.0/8 exact
set policy-options policy-statement Announce10 term 1 then accept
set policy-options policy-statement Announce10 term 2 then reject
Device R2
set interfaces ge-1/0/8 unit 0 family inet address 192.168.10.2/24
set interfaces ge-1/0/8 unit 0 family inet filter input SteerSrcTrafficOptimizer
set interfaces ge-1/1/0 unit 0 family inet address 192.168.20.1/24
set interfaces ge-1/1/1 unit 0 family inet address 192.168.30.1/24
set routing-instances VR1 instance-type virtual-router
set routing-instances VR1 interface ge-1/0/8.0
set routing-instances VR1 interface ge-1/1/0.0
set routing-instances VR1 interface ge-1/1/1.0
set routing-instances VR1 routing-options static route 192.168.0.3 next-hop 192.168.20.2
set routing-instances VR1 routing-options static route 192.168.0.3 qualified-next-hop
192.168.30.2 metric 100
set routing-instances VR1 routing-options autonomous-system 64502
set routing-instances VR1 protocols bgp group eBGP neighbor 192.168.10.1 peer-as 64501
set routing-instances VR1 protocols bgp group iBGP neighbor 192.168.30.2 peer-as 64502
set routing-instances VR1 protocols bgp group iBGP neighbor 192.168.30.2 export AcceptExternal
set firewall family inet filter SteerSrcTrafficOptimizer term 0 from source-address
192.168.10.0/24
set firewall family inet filter SteerSrcTrafficOptimizer term 0 then accept
set firewall family inet filter SteerSrcTrafficOptimizer term 1 from source-address 10.0.0.0/24
set firewall family inet filter SteerSrcTrafficOptimizer term 1 then next-ip 192.168.0.3 routing-
1527
instance VR1
set firewall family inet filter SteerSrcTrafficOptimizer term 2 from source-address 10.0.0.0/8
set firewall family inet filter SteerSrcTrafficOptimizer term 2 then accept
set interfaces ge-1/0/0 unit 0 family inet address 192.168.40.1/24
set interfaces ge-1/0/0 unit 0 family inet filter input SteerDstTrafficOptimizer
set interfaces ge-1/3/8 unit 0 family inet address 192.168.20.2/24
set interfaces ge-1/3/9 unit 0 family inet address 192.168.30.2/24
set routing-instances VR2 instance-type virtual-router
set routing-instances VR2 interface ge-1/0/0.0
set routing-instances VR2 interface ge-1/3/8.0
set routing-instances VR2 interface ge-1/3/9.0
set routing-instances VR2 routing-options static route 192.168.0.2/32 next-hop 192.168.20.1
set routing-instances VR2 routing-options static route 192.168.0.2/32 qualified-next-hop
192.168.30.1 metric 100
set routing-instances VR2 routing-options autonomous-system 64502
set routing-instances VR2 protocols bgp group eBGP neighbor 192.168.40.2 peer-as 64503
set routing-instances VR2 protocols bgp group iBGP neighbor 192.168.30.1 peer-as 64502
set routing-instances VR2 protocols bgp group iBGP neighbor 192.168.30.1 export AcceptExternal
set firewall family inet filter SteerDstTrafficOptimizer term 0 from source-address
192.168.40.0/24
set firewall family inet filter SteerDstTrafficOptimizer term 0 then accept
set firewall family inet filter SteerDstTrafficOptimizer term 1 from destination-address
10.0.0.0/24
set firewall family inet filter SteerDstTrafficOptimizer term 1 then next-ip 192.168.0.2 routing-
instance VR2
set firewall family inet filter SteerDstTrafficOptimizer term 2 from destination-address
10.0.0.0/8
set firewall family inet filter SteerDstTrafficOptimizer term 2 then accept
set policy-options policy-statement AcceptExternal term 1 from route-type external
set policy-options policy-statement AcceptExternal term 1 then accept
Device R3
set interfaces lo0 unit 0 family inet address 10.11.0.1/32
set interfaces ge-1/0/0 unit 0 family inet address 192.168.40.2/24
set routing-options autonomous-system 64503
set protocols bgp group eBGP neighbor 192.168.40.1 peer-as 64502
set protocols bgp group eBGP export Announce0
set policy-options policy-statement Announce0 term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement Announce0 term 1 then accept
set policy-options policy-statement Announce0 term 2 then reject
1528
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892 in
the Junos OS CLI User Guide.
To congure Device R2:
1. Congure the interfaces.
[edit interfaces]
user@R2# set ge-1/0/8 unit 0 family inet address 192.168.10.2/24
user@R2# set ge-1/0/8 unit 0 family inet filter input SteerSrcTrafficOptimizer
user@R2# set ge-1/1/0 unit 0 family inet address 192.168.20.1/24
user@R2# set ge-1/1/1 unit 0 family inet address 192.168.30.1/24
user@R2# set ge-1/0/0 unit 0 family inet address 192.168.40.1/24
user@R2# set ge-1/0/0 unit 0 family inet filter input SteerDstTrafficOptimizer
user@R2# set ge-1/3/8 unit 0 family inet address 192.168.20.2/24
user@R2# set ge-1/3/9 unit 0 family inet address 192.168.30.2/24
2. Congure the roung instance.
[edit routing-instances]
user@R2# set VR1 instance-type virtual-router
user@R2# set VR1 interface ge-1/0/8.0
user@R2# set VR1 interface ge-1/1/0.0
user@R2# set VR1 interface ge-1/1/1.0
user@R2# set VR2 instance-type virtual-router
user@R2# set VR2 interface ge-1/0/0.0
user@R2# set VR2 interface ge-1/3/8.0
user@R2# set VR2 interface ge-1/3/9.0
3. Congure the stac and BGP roung.
[edit routing-instances]
user@R2# set VR1 routing-options static route 192.168.0.3 next-hop 192.168.20.2
user@R2# set VR1 routing-options static route 192.168.0.3 qualified-next-hop 192.168.30.2
metric 100
user@R2# set VR1 routing-options autonomous-system 64502
user@R2# set VR1 protocols bgp group eBGP neighbor 192.168.10.1 peer-as 64501
user@R2# set VR1 protocols bgp group iBGP neighbor 192.168.30.2 peer-as 64502
1529
user@R2# set VR1 protocols bgp group iBGP neighbor 192.168.30.2 export AcceptExternal
user@R2# set VR2 routing-options static route 192.168.0.2/32 next-hop 192.168.20.1
user@R2# set VR2 routing-options static route 192.168.0.2/32 qualified-next-hop 192.168.30.1
metric 100
user@R2# set VR2 routing-options autonomous-system 64502
user@R2# set VR2 protocols bgp group eBGP neighbor 192.168.40.2 peer-as 64503
user@R2# set VR2 protocols bgp group iBGP neighbor 192.168.30.1 peer-as 64502
user@R2# set VR2 protocols bgp group iBGP neighbor 192.168.30.1 export AcceptExternal
4. Congure the rewall lters.
[edit firewall family inet]
user@R2# set filter SteerSrcTrafficOptimizer term 0 from source-address 192.168.10.0/24
user@R2# set filter SteerSrcTrafficOptimizer term 0 then accept
user@R2# set filter SteerSrcTrafficOptimizer term 1 from source-address 10.0.0.0/24
user@R2# set filter SteerSrcTrafficOptimizer term 1 then next-ip 192.168.0.3 routing-instance
VR1
user@R2# set filter SteerSrcTrafficOptimizer term 2 from source-address 10.0.0.0/8
user@R2# set filter SteerSrcTrafficOptimizer term 2 then accept
user@R2# set filter SteerDstTrafficOptimizer term 0 from source-address 192.168.40.0/24
user@R2# set filter SteerDstTrafficOptimizer term 0 then accept
user@R2# set filter SteerDstTrafficOptimizer term 1 from destination-address 10.0.0.0/24
user@R2# set filter SteerDstTrafficOptimizer term 1 then next-ip 192.168.0.2 routing-instance
VR2
user@R2# set filter SteerDstTrafficOptimizer term 2 from destination-address 10.0.0.0/8
user@R2# set filter SteerDstTrafficOptimizer term 2 then accept
5. Congure the roung policy.
[edit policy-options policy-statement AcceptExternal term 1]
user@R2# set from route-type external
user@R2# set term 1 then accept
1530
Results
From conguraon mode, conrm your conguraon by entering the show interfaces, show firewall, and
show protocols commands. If the output does not display the intended conguraon, repeat the
conguraon instrucons in this example to correct it.
user@R2# show interfaces
ge-1/0/0 {
unit 0 {
family inet {
filter {
input SteerDstTrafficOptimizer;
}
address 192.168.40.1/24;
}
}
}
ge-1/0/8 {
unit 0 {
family inet {
filter {
input SteerSrcTrafficOptimizer;
}
address 192.168.10.2/24;
}
}
}
ge-1/1/0 {
unit 0 {
family inet {
address 192.168.20.1/24;
}
}
}
ge-1/1/1 {
unit 0 {
family inet {
address 192.168.30.1/24;
}
}
}
ge-1/3/8 {
1531
unit 0 {
family inet {
address 192.168.20.2/24;
}
}
}
ge-1/3/9 {
unit 0 {
family inet {
address 192.168.30.2/24;
}
}
}
user@R2# show firewall
family inet {
filter SteerSrcTrafficOptimizer {
term 0 {
from {
source-address {
192.168.10.0/24;
}
}
then accept;
}
term 1 {
from {
source-address {
10.0.0.0/24;
}
}
then {
next-ip 192.168.0.3/32 routing-instance VR1;
}
}
term 2 {
from {
source-address {
10.0.0.0/8;
}
}
1532
then accept;
}
}
filter SteerDstTrafficOptimizer {
term 0 {
from {
source-address {
192.168.40.0/24;
}
}
then accept;
}
term 1 {
from {
destination-address {
10.0.0.0/24;
}
}
then {
next-ip 192.168.0.2/32 routing-instance VR2;
}
}
term 2 {
from {
destination-address {
10.0.0.0/8;
}
}
then accept;
}
}
}
user@R2# show policy-options
policy-statement AcceptExternal {
term 1 {
from route-type external;
then accept;
1533
}
}
user@R2# show routing-instances
VR1 {
instance-type virtual-router;
interface ge-1/0/8.0;
interface ge-1/1/0.0;
interface ge-1/1/1.0;
routing-options {
static {
route 192.168.0.3/32 {
next-hop 192.168.20.2;
qualified-next-hop 192.168.30.2 {
metric 100;
}
}
}
autonomous-system 64502;
}
protocols {
bgp {
group eBGP {
neighbor 192.168.10.1 {
peer-as 64501;
}
}
group iBGP {
neighbor 192.168.30.2 {
export NextHopSelf;
peer-as 64502;
}
}
}
}
}
VR2 {
instance-type virtual-router;
interface ge-1/0/0.0;
interface ge-1/3/8.0;
interface ge-1/3/9.0;
1534
routing-options {
static {
route 192.168.0.2/32 {
next-hop 192.168.20.1;
qualified-next-hop 192.168.30.1 {
metric 100;
}
}
}
autonomous-system 64502;
}
protocols {
bgp {
group eBGP {
neighbor 192.168.40.2 {
peer-as 64503;
}
}
group iBGP {
neighbor 192.168.30.1 {
export NextHopSelf;
peer-as 64502;
}
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Checking the Paths Used | 1536
Conrm that the conguraon is working properly.
1535
Checking the Paths Used
Purpose
Make sure that the expected paths are used when sending trac from Device R1 to Device R3.
Acon
On Device R1, enter the traceroute command before and aer the link failure
Before Failure of the Trac Opmizer
user@R1> traceroute 10.11.0.1 source 10.0.0.1
traceroute to 10.11.0.1 (10.11.0.1) from 10.0.0.1, 30 hops max, 40 byte packets
1 192.168.10.2 (192.168.10.2) 0.519 ms 0.403 ms 0.380 ms
2 192.168.20.2 (192.168.20.2) 0.404 ms 0.933 ms 0.402 m0
3 10.11.0.1 (10.11.0.1) 0.709 ms 0.656 ms 0.644 ms
user@R1> traceroute 10.11.0.1 source 10.1.0.1
traceroute to 10.11.0.1 (10.11.0.1) from 10.1.0.1, 30 hops max, 40 byte packets
1 192.168.10.2 (192.168.10.2) 0.524 ms 0.396 ms 0.380 ms
2 192.168.30.2 (192.168.30.2) 0.412 ms 0.410 ms 0.911 ms
3 10.11.0.1 (10.11.0.1) 0.721 ms 0.639 ms 0.659 ms
Aer Failure of the Trac Opmizer
user@R1> traceroute 10.11.0.1 source 10.0.0.1
traceroute to 10.11.0.1 (10.11.0.1) from 10.0.0.1, 30 hops max, 40 byte packets
1 192.168.10.2 (192.168.10.2) 0.506 ms 0.400 ms 0.378 ms
2 192.168.30.2 (192.168.30.2) 0.433 ms 0.550 ms 0.415 ms
3 10.11.0.1 (10.11.0.1) 0.723 ms 0.638 ms 0.638 ms
user@R1> traceroute 10.11.0.1 source 10.1.0.1
traceroute to 10.11.0.1 (10.11.0.1) from 10.1.0.1, 30 hops max, 40 byte packets
1 192.168.10.2 (192.168.10.2) 0.539 ms 0.411 ms 0.769 ms
2 192.168.30.2 (192.168.30.2) 0.426 ms 0.413 ms 2.429 ms
1536
3 10.11.0.1 (10.11.0.1) 10.868 ms 0.662 ms 0.647 ms
Meaning
The output shows that the second hop changes, depending on the source address used in the traceroute
command.
To verify this feature, a traceroute operaon is performed on Device R1 to Device R3. When the source
IP address is 10.0.0.1, packets are forwarded out the ge-1/1/0.0 interface on Device R2. When the
source IP address is 10.1.0.1, packets are forwarded out the ge-1/1/1.0 interface on Device R2.
When the link between ge-1/1/0 and ge-1/3/8 fails, packets with source IP address 10.0.0.1 are
forwarded out the ge-1/1/1.0 interface on Device R2.
SEE ALSO
Understanding Filter-Based Forwarding to a Specic Outgoing Interface or Desnaon IP Address
Example: Conguring Filter-Based Forwarding to a Specic Outgoing Interface
Firewall Filter Nonterminang Acons | 873
RELATED DOCUMENTATION
Example: Conguring Filter-Based Forwarding on Logical Systems | 1240
Example: Conguring Filter-Based Forwarding on the Source Address | 1501
Firewall Filter Nonterminang Acons | 873
1537
CHAPTER 26
Conguring Firewall Filters (EX Series Switches)
IN THIS CHAPTER
Firewall Filters for EX Series Switches Overview | 1539
Understanding Planning of Firewall Filters | 1543
Understanding Firewall Filter Match Condions | 1547
Understanding How Firewall Filters Control Packet Flows | 1553
Understanding How Firewall Filters Are Evaluated | 1554
Understanding Firewall Filter Processing Points for Bridged and Routed Packets on EX Series
Switches | 1556
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
Plaorm Support for Firewall Filter Match Condions, Acons, and Acon Modiers on EX Series
Switches | 1574
Support for Match Condions and Acons for Loopback Firewall Filters on Switches | 1637
Conguring Firewall Filters (CLI Procedure) | 1642
Understanding How Firewall Filters Test a Packet's Protocol | 1653
Understanding Filter-Based Forwarding for EX Series Switches | 1654
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches | 1654
Example: Conguring a Firewall Filter on a Management Interface on an EX Series Switch | 1684
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Example: Applying Firewall Filters to Mulple Supplicants on Interfaces Enabled for 802.1X or MAC RADIUS
Authencaon | 1696
Verifying That Policers Are Operaonal | 1703
Troubleshoong Firewall Filters | 1704
1538
Firewall Filters for EX Series Switches Overview
IN THIS SECTION
Firewall Filter Types | 1539
Firewall Filter Components | 1540
Firewall Filter Processing | 1543
Firewall lters provide rules that dene whether to permit, deny, or forward packets that are transing
an interface on a Juniper Networks EX Series Ethernet Switch from a source address to a desnaon
address. You congure rewall lters to determine whether to permit, deny, or forward trac before it
enters or exits a port, VLAN, or Layer 3 (routed) interface to which the
rewall lter
is applied. To apply
a rewall lter, you must rst congure the lter and then apply it to an port, VLAN, or Layer 3
interface.
You can apply rewall lters to network interfaces, aggregated Ethernet interfaces (also known as link
aggregaon groups (LAGs)), loopback interfaces, management interfaces, virtual management Ethernet
interfaces (VMEs), and routed VLAN interfaces (RVIs). For informaon on EX Series switches that
support a rewall lter on these interfaces, see EX Series Switch Soware Features Overview.
An
ingress
rewall lter is a lter that is applied to packets that are entering a network. An
egress
rewall lter is a lter that is applied to packets that are exing a network. You can congure rewall
lters to subject packets to ltering, class-of-service (CoS) marking (grouping similar types of trac
together, and treang each type of trac as a class with its own level of service priority), and trac
policing (controlling the maximum rate of trac sent or received on an interface).
NOTE: Policers on network port, layer 2 and layer 3, or IRB interfaces do not police host-bound
trac. But if you want to prevent DDoS aacks, then you can create a rewall lter on the lo0
that protects the roung engine.
Firewall Filter Types
The following rewall lter types are supported for EX Series switches:
• Port (Layer 2) rewall lter—Port rewall lters apply to Layer 2 switch ports. You can apply port
rewall lters in both ingress and egress direcons on a physical port.
1539
• VLAN rewall lter—VLAN rewall lters provide access control for packets that enter a VLAN, are
bridged within a VLAN, or leave a VLAN. You can apply VLAN rewall lters in both ingress and
egress direcons on a VLAN. VLAN rewall lters are applied to all packets that are forwarded to or
forwarded from the VLAN.
• Router (Layer 3) rewall lter—You can apply a router rewall lter in both ingress and egress
direcons on Layer 3 (routed) interfaces and routed VLAN interfaces (RVIs). You can apply a router
rewall lter in the ingress direcon on the loopback interface (lo0) also. Firewall lters congured on
loopback interfaces are applied only to packets that are sent to the Roung Engine CPU for further
processing.
You can apply port, VLAN, or router rewall lters to
both
IPv4 and IPv6 trac on these switches:
• EX2200 switch
• EX3300 switch
• EX3200 switch
• EX4200 switch
• EX4300 switch
• EX4400 switch
• EX4500 switch
• EX4550 switch
• EX6200 switch
• EX8200 switch
For informaon on rewall lters supported on dierent switches, see "Plaorm Support for Firewall
Filter Match Condions, Acons, and Acon Modiers on EX Series Switches" on page 1574.
Firewall Filter Components
In a rewall lter, you rst dene the family address type (ethernet-switching, inet, or inet6), and then
you dene one or more terms that specify the ltering criteria (specied as terms with match condions)
and the acon (specied as acons or acon modiers) to take if a match occurs.
The maximum number of terms allowed per rewall lter for EX Series switches is:
• 512 for EX2200 switches
• 1436 for EX3300 switches
1540
NOTE: On EX3300 switches, if you add and delete lters with a large number of terms (on
the order of 1000 or more) in the same commit operaon, not all the lters are installed. You
must add lters in one commit operaon, and delete lters in a separate commit operaon.
• 7,042 for EX3200 and EX4200 switches—as allocated by the dynamic allocaon of ternary content
addressable memory (TCAM) for rewall lters.
• On EX4300 switches, the following maximum number of terms are supported for ingress and egress
trac, for rewall lers congured on a port, VLAN and Layer 3 interface:
• For ingress trac:
• 3500 terms for rewall lters congured on a port
• 3500 terms for rewall lters congured on a VLAN
• 7000 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 3500 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
• For EX4300-MP devices, ingress support is the same as the above with the following excepon:
• 3072 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• For egress trac:
• 512 terms for rewall lters congured on a port
• 256 terms for rewall lters congured on a VLAN
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
NOTE: You can congure the maximum number of terms only when you congure one type
of rewall lter (port, VLAN, or router (Layer 3) rewall lter) on the switch, and when storm
control is not enabled on any interface in the switch.
• For EX4400 switches, the following maximum number of terms are supported for ingress and egress
trac, for rewall lters congured on a port, VLAN and layer 3 interfaces.
• For ingress trac:
• 2048 terms for rewall lters congured on a port.
1541
• 2048 terms for rewall lters congured on a VLAN.
• 2048 terms for rewall lters congured on layer 3 interfaces.
• For egress trac:
• 1024 terms for rewall lters congured on a port.
• 512 terms for rewall lters congured on a VLAN.
• 1024 terms for rewall lters congured on layer 3 interfaces.
• 1200 for EX4500 and EX4550 switches
• 1400 for EX6200 switches
• 32,768 for EX8200 switches
NOTE: The on-demand dynamic allocaon of the shared space TCAM in EX8200 switches is
achieved by assigning free space blocks to rewall lters. Firewall lters are categorized into two
dierent pools. Port and VLAN lters are pooled together (the memory threshold for this pool is
22K) while router rewall lters are pooled separately (the threshold for this pool is 32K). The
assignment happens based on the lter pool type. Free space blocks can be shared only among
the rewall lters belonging to the same lter pool type. An error message is generated when
you try to congure a rewall lter beyond the TCAM threshold.
Each term consists of the following components:
• Match condions—Specify the values or elds that the packet must contain. You can dene various
match condions, including the IP source address eld, IP desnaon address eld, Transmission
Control Protocol (TCP) or User Datagram Protocol (UDP) source port eld, IP protocol eld, Internet
Control Message Protocol (ICMP) packet type, TCP ags, and interfaces.
• Acon—Species what to do if a packet matches the match condions. Possible acons are to accept
or discard the packet or to send the packet to a specic virtual roung interface. In addion, packets
can be counted to collect stascal informaon. If no acon is specied for a term, the default acon
is to accept the packet.
• Acon modier—Species one or more acons for the switch if a packet matches the match
condions. You can specify acon modiers such as count, mirror, rate limit, and classify packets.
1542
Firewall Filter Processing
The order of the terms within a rewall lter conguraon is important. Packets are tested against each
term in the order in which the terms are listed in the rewall lter conguraon. For informaon on how
rewall lters process packets, see "Understanding How Firewall Filters Are Evaluated" on page 1554.
RELATED DOCUMENTATION
Understanding Planning of Firewall Filters | 1543
Understanding Firewall Filter Processing Points for Bridged and Routed Packets on EX Series
Switches | 1556
Understanding How Firewall Filters Are Evaluated | 1554
Understanding Firewall Filter Match Condions | 1547
Understanding the Use of Policers in Firewall Filters | 2214
Understanding Filter-Based Forwarding for EX Series Switches | 1654
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Understanding Planning of Firewall Filters
Before you create a
rewall lter
and apply it to an interface, determine what you want the rewall lter
to accomplish and how to use its match condions and acons to achieve your goals. You must
understand how packets are matched to match condions, the default and congured acons of the
rewall lter, and proper placement of the rewall lter.
You can congure and apply no more than one rewall lter per port, VLAN, or router interface, per
direcon. The following limits apply for the number of rewall lter terms allowed per lter on various
switch models:
• On EX3300 switches, the number of terms per lter cannot exceed 1436.
• On EX3200 and EX4200 switches, the number of terms per lter cannot exceed 7042.
• On EX2300 switches, the following maximum number of terms are supported for ingress and egress
trac, for rewall lters congured on a port, VLAN and Layer 3 interface:
• For ingress trac:
• 256 terms for rewall lters congured on a port
1543
• 256 terms for rewall lters congured on a VLAN
• 256 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 256 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
• For egress trac:
• 512 terms for rewall lters congured on a port
• 128 terms for rewall lters congured on a VLAN
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
On EX3400 switches, the following maximum number of terms are supported for ingress and egress
trac, for rewall lters congured on a port, VLAN and Layer 3 interface:
• For ingress trac:
• 512 terms for rewall lters congured on a port
• 512 terms for rewall lters congured on a VLAN
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
• For egress trac:
• 512 terms for rewall lters congured on a port
• 256 terms for rewall lters congured on a VLAN
• 1024 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 1024 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
On EX4300 switches, the following maximum number of terms are supported for ingress and egress
trac, for rewall lers congured on a port, VLAN and Layer 3 interface:
• For ingress trac:
• 3500 terms for rewall lters congured on a port
• 3500 terms for rewall lters congured on a VLAN
• 7000 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 3500 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
1544
NOTE: The ternary content addressable memory (TCAM) limit for ingress trac on the
EX4300 switch is 256 entries.
• For egress trac:
• 512 terms for rewall lters congured on a port
• 256 terms for rewall lters congured on a VLAN
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv6 trac
NOTE: You can congure the maximum number of terms only when you congure one
type of rewall lter (port, VLAN, or router (Layer 3) rewall lter) on the switch, and
when storm control is not enabled on any interface in the switch.
• On EX4500 and EX4550 switches, the number of terms per lter cannot exceed 1200.
• On EX6200 switches, the number of terms per lter cannot exceed 1400.
• On EX8200 switches, the number of terms per lter cannot exceed 32,768.
In addion, try to be conservave in the number of terms (rules) that you include in each rewall lter
because a large number of terms requires longer processing me during a commit and also can make
rewall lter tesng and troubleshoong more dicult. Similarly, applying rewall lters across many
switch and router interfaces can make tesng and troubleshoong the rules of those lters dicult.
Before you congure and apply rewall lters, answer the following quesons for each of those rewall
lters:
1. What is the purpose of the rewall lter?
For example, you can use a rewall lter to limit trac to source and desnaon MAC addresses,
specic protocols, or certain data rates or to prevent denial of service (DoS) aacks.
2. What are the appropriate match condions?
a. Determine the packet header elds that the packet must contain for a match. Possible elds
include:
• Layer 2 header elds—Source and desnaon MAC addresses, dot1q tag, Ethernet type, and
VLAN
1545
• Layer 3 header elds—Source and desnaon IP addresses, protocols, and IP opons (IP
precedence, IP fragmentaon ags, TTL type)
• TCP header elds—Source and desnaon ports and ags
• ICMP header elds—Packet type and code
b. Determine the port, VLAN, or router interface on which the packet was received.
3. What are the appropriate acons to take if a match occurs?
Possible acons to take if a match occurs are accept, discard, and forward to a roung instance.
4. What addional acon modiers might be required?
Determine whether addional acons are required if a packet matches a match condion; for
example, you can specify an acon modier to count, analyze, or police packets.
5. On what interface should the rewall lter be applied?
Start with the following basic guidelines:
• If all the packets entering a port need to be exposed to ltering, then use port rewall lters.
• If all the packets that are bridged need ltering, then use VLAN rewall lters.
• If all the packets that are routed need ltering, then use router rewall lters.
Before you choose the interface on which to apply a rewall lter, understand how that placement
can impact trac ow to other interfaces. In general, apply a rewall lter that lters on source and
desnaon IP addresses, IP protocols, or protocol informaon—such as ICMP message types, and
TCP and UDP port numbers—nearest to the source devices. However, typically apply a rewall lter
that lters only on a source IP address nearest to the desnaon devices. When applied too close to
the source device, a rewall lter that lters only on a source IP address could potenally prevent
that source device from accessing other services that are available on the network.
NOTE: Egress rewall lters do not aect the ow of locally generated control packets from
the Roung Engine.
6. In which direcon should the rewall lter be applied?
You can apply rewall lters to ports on the switch to lter packets that are entering a port. You can
apply rewall lters to VLANs, and Layer 3 (routed) interfaces to lter packets that are entering or
exing a VLAN or routed interface. Typically, you congure dierent sets of acons for trac
entering an interface than you congure for trac exing an interface.
1546
RELATED DOCUMENTATION
Firewall Filters for EX Series Switches Overview | 1539
Understanding the Use of Policers in Firewall Filters | 2214
Understanding How Firewall Filters Are Evaluated | 1554
Understanding Filter-Based Forwarding for EX Series Switches | 1654
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Understanding Firewall Filter Match Condions
IN THIS SECTION
Filter Match Condions | 1547
Numeric Filter Match Condions | 1548
Interface Filter Match Condions | 1549
IP Address Filter Match Condions | 1549
MAC Address Filter Match Condions | 1550
Bit-Field Filter Match Condions | 1551
Before you dene terms for rewall lters, you must understand how the match condions that you
specify in a term are handled and how to specify various types of match condions to achieve the
desired ltering results. A match condion consists of a string (called a match statement) that denes
the match condion. Match condions are the values or elds that a packet must contain.
Filter Match Condions
In the from statement of a
rewall lter
term, you specify the packet condions that trigger the acon in
one of the then statements: then with various opons, then interface or then vlan. All condions in the
from statement must match for the acon to be taken. The order in which you specify match condions
is not important, because a packet must match all the condions in a term for a match to occur.
If you specify no match condions in a term, that term matches all packets.
1547
An individual condion in a from statement cannot contain a list of values. For example, you cannot
specify numeric ranges or mulple source or desnaon addresses.
Individual condions in a from statement cannot be negated. A negated condion is an explicit mismatch.
Numeric Filter Match Condions
Numeric lter condions match packet elds that are idened by a numeric value, such as port and
protocol numbers. For numeric lter match condions, you specify a keyword that idenes the
condion and a single value that a eld in a packet must match.
You can specify the numeric value in one of the following ways:
• Single number—A match occurs if the value of the eld matches the number. For example:
source-port 25;
• Text synonym for a single number— A match occurs if the value of the eld matches the number that
corresponds to the synonym. For example:
source-port http;
To specify more than one value in a lter term, you enter each value in its own match statement, which
is a string that denes a match condion. For example, a match occurs in the following term if the value
of vlan is 10 or 30.
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
vlan 10;
vlan 30;
The following restricons apply to numeric lter match condions:
• You cannot specify a range of values.
• You cannot specify a list of comma-separated values.
• You cannot exclude a specic value in a numeric lter match condion. For example, you cannot
specify a condion that would match only if the match condion was not equal to a given value.
1548
Interface Filter Match Condions
Interface lter match condions can match interface name values in a packet. For interface lter match
condions, you specify the name of the interface, for example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set interface ge-0/0/1
Port and VLAN interfaces do not use logical unit numbers. However, a rewall lter that is applied to a
router interface can specify the logical unit number in the interface lter match condion, for example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set interface ge-0/1/0.0
You can include the * wildcard as part of the interface name, for example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set interface ge-0/*/1
user@switch# set interface ge-0/1/*
user@switch# set interface ge-*
IP Address Filter Match Condions
Address lter match condions can match prex values in a packet, such as IP source and desnaon
prexes. For address lter match condions, you specify a keyword that idenes the eld and one
prex of that type that a packet must match.
You specify the address as a single prex. A match occurs if the value of the eld matches the prex. For
example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-address 10.2.1.0/28;
Each prex contains an implicit 0/0 except statement, which means that any prex that does not match
the prex that is specied is explicitly considered not to match.
1549
To specify the address prex, use the notaon prex/prex-length. If you omit prex-length, it defaults
to /32. For example:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-address 10
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# show destination-address
10.0.0.0/32;
To specify more than one IP address in a lter term, you enter each address in its own match statement.
For example, a match occurs in the following term if the value of the source-address eld matches either
of the following source-address prexes:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-address 10.0.0.0/8
user@switch# set source-address 10.1.0.0/16
MAC Address Filter Match Condions
MAC address lter match condions can match source and desnaon MAC address values in a packet.
For MAC address lter match condions, you specify a keyword that idenes the eld and one value of
that type that a packet must match.
You can specify the MAC address as six hexadecimal bytes in the following formats:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-mac-address 0011.2233.4455
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-mac-address 00:11:22:33:44:55
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set destination-mac-address 001122334455
1550
To specify more than one MAC address in a lter term, you enter each MAC address in its own match
statement. For example, a match occurs in the following term if the value of the source-mac-address
eld matches either of the following addresses.
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set source-mac-address 00:11:22:33:44:55
user@switch# set source-mac-address 00:11:22:33:20:15
Bit-Field Filter Match Condions
Bit-eld lter condions match packet elds if parcular bits in those elds are or are not set. You can
match the IP opons, TCP ags, and IP fragmentaon elds. For bit-eld lter match condions, you
specify a keyword that idenes the eld and tests to determine that the opon is present in the eld.
To specify the bit-eld value to match, enclose the value in double quotaon marks. For example, a
match occurs if the RST bit in the TCP ags eld is set:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "rst"
Typically, you specify the bits to be tested by using keywords. Bit-eld match keywords always map to a
single bit value. You also can specify bit elds as hexadecimal or decimal numbers.
To match mulple bit-eld values, use the logical operators, which are described in Table 74 on page
1551. The operators are listed in order from highest precedence to lowest precedence. Operaons are
le-associave.
Table 74: Logical Operators for Matching
Mulple Bit-Field Operators
Logical Operators Descripon
! Negaon.
& Logical AND.
| Logical OR.
1551
To negate a match, precede the value with an exclamaon point. For example, a match occurs only if the
RST bit in the TCP ags eld is not set:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "!rst"
In the following example of a logical AND operaon, a match occurs if the packet is the inial packet on
a TCP session:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "syn&!ack"
In the following example of a logical OR operaon, a match occurs if the packet is part of TCP session
establishment or tear down:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags "syn|fin"
For a logical OR operaon, you can specify a maximum of two match condions in a single term. If you
need to match more than two bit-eld values in a logical OR operaon, congure the same match
condion in consecuve terms with addional bit-eld values. In the following example, the two terms
congured match the SYN, ACK, FIN, or RST bit in the TCP ags eld:
[edit firewall family
family-name
filter
filter-name
term
term-name1
from]
user@switch# set tcp-flags "syn|ack"
[edit firewall family
family-name
filter
filter-name
term
term-name2
from]
user@switch# set tcp-flags "fin|rst"
You can use text synonyms to specify some common bit-eld matches. You specify these matches as a
single keyword. In the following example of a text synonym, a match occurs if the packet is the inial
packet on a TCP session:
[edit firewall family
family-name
filter
filter-name
term
term-name
from]
user@switch# set tcp-flags tcp-initial
1552
RELATED DOCUMENTATION
Firewall Filters for EX Series Switches Overview | 1539
Understanding How Firewall Filters Test a Packet's Protocol | 1653
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
Understanding How Firewall Filters Control Packet Flows
Juniper Networks EX Series Ethernet Switches support rewall lters that allow you to control ows of
data packets and local packets.
Data packets
are chunks of data that transit the switch as they are
forwarded from a source to a desnaon.
Local packets
are chunks of data that are desned for or sent
by the switch. Local packets usually contain roung protocol data, data for IP services such as Telnet or
SSH, and data for administrave protocols such as the Internet Control Message Protocol (ICMP).
You create rewall lters to protect your switch from excessive trac transing the switch to a network
desnaon or desned for the Roung Engine on the switch. Firewall lters that control local packets
can also protect your switch from external incidents such as denial-of-service (DoS) aacks.
Firewall lters aect packet ows entering in to or exing from the switch's interfaces:
• Ingress rewall lters aect the ow of data packets that are received by the switch's interfaces. The
Packet Forwarding Engine handles this ow. When a switch receives a data packet on an interface,
the switch determines where to forward the packet by looking in the forwarding table for the best
route (Layer 2 switching, Layer 3 roung) to a desnaon. Data packets are forwarded to their
desnaon through an outgoing interface. Locally desned packets are forwarded to the Roung
Engine.
• Egress rewall lters aect the ow of data packets that are transmied from the switch's interfaces
but do not aect the ow of locally generated control packets from the Roung Engine. The Packet
Forwarding Engine handles the ow of data packets that are transmied from the switch, and egress
rewall lters are applied here. The Packet Forwarding Engine also handles the ow of control
packets from the Roung Engine.
Figure 69 on page 1554 illustrates the applicaon of ingress and egress rewall lters to control the
ow of packets through the switch.
1553
Figure 69: Applicaon of Firewall Filters to Control Packet Flow
1. Ingress
rewall lter
applied to control locally desned packets that are received on the switch's
interfaces and are desned for the Roung Engine.
2. Ingress rewall lter applied to control incoming packets on the switch's interfaces.
3. Egress rewall lter applied to control packets that are transing the switch's interfaces.
RELATED DOCUMENTATION
Understanding Firewall Filter Processing Points for Bridged and Routed Packets on EX Series
Switches | 1556
Understanding How Firewall Filters Are Evaluated | 1554
Understanding How Firewall Filters Are Evaluated
A
rewall lter
consists of one or more terms, and the order of the terms within a rewall lter is
important. Before you congure rewall lters, you should understand how Juniper Networks EX Series
Ethernet Switches evaluate the terms within a rewall lter and how packets are evaluated against the
terms.
When a rewall lter consists of a single term, the lter is evaluated as follows:
1554
• If the packet matches all the condions, the acon in the then statement is taken.
• If the packet matches all the condions, and no acon is specied in the then statement, the default
acon accept is taken.
When a rewall lter consists of more than one term, the rewall lter is evaluated sequenally:
1. The packet is evaluated against the condions in the from statement in the rst term.
2. If the packet matches all the condions in the term, the acon in the then statement is taken and the
evaluaon ends. Subsequent terms in the lter are not evaluated.
3. If the packet does not match all the condions in the term, the packet is evaluated against the
condions in the from statement in the second term.
This process connues unl either the packet matches the condions in the from statement in one of
the subsequent terms or there are no more terms in the lter.
4. If a packet passes through all the terms in the lter without a match, the packet is discarded.
Figure 70 on page 1555 shows how an EX Series switch evaluates the terms within a rewall lter.
Figure 70: Evaluaon of Terms Within a Firewall Filter
1555
If a term does not contain a from statement, the packet is considered to match and the acon in the then
statement of the term is taken.
If a term does not contain a then statement, or if an acon has not been congured in the then statement,
and the packet matches the condions in the from statement of the term, the packet is accepted.
Every rewall lter contains an implicit deny statement at the end of the lter, which is equivalent to the
following explicit lter term:
term implicit-rule {
then discard;
}
Consequently, if a packet passes through all the terms in a lter without matching any condions, the
packet is discarded. If you congure a rewall lter that has no terms, all packets that pass through the
lter are discarded.
RELATED DOCUMENTATION
Firewall Filters for EX Series Switches Overview | 1539
Understanding Firewall Filter Match Condions | 1547
Understanding the Use of Policers in Firewall Filters | 2214
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Understanding Firewall Filter Processing Points for Bridged and Routed
Packets on EX Series Switches
Juniper Networks EX Series Ethernet Switches are mullayered switches that provide Layer 2 switching
and Layer 3 roung. You apply rewall lters at mulple processing points in the packet forwarding path
on EX Series switches. At each processing point, the acon to be taken on a packet is determined based
on the results of the lookup in the switch's forwarding table. A table lookup determines which exit port
on the switch to use to forward the packet.
For both bridged unicast packets and routed unicast packets, rewall lters are evaluated and applied
hierarchically. First, a packet is checked against the port
rewall lter
, if present. If the packet is
permied, it is then checked against the VLAN rewall lter, if present. If the packet is permied, it is
then checked against the router rewall lter, if present. The packet must be permied by the router
rewall lter before it is processed.
1556
Figure 71 on page 1557 shows the various rewall lter processing points in the packet forwarding path
in a mullayered switching plaorm.
Figure 71: Firewall Filter Processing Points in the Packet Forwarding Path
For a mulcast packet that results in replicaons, an egress rewall lter is applied to each copy of the
packet based on its corresponding egress VLAN.
For Layer 2 (bridged) unicast packets, the following rewall lter processing points apply:
• Ingress port rewall lter
• Ingress VLAN rewall lter
• Egress port rewall lter
• Egress VLAN rewall lter
1557
For Layer 3 (routed and mullayer-switched) unicast packets, the following rewall lter processing
points apply:
• Ingress port rewall lter
• Ingress VLAN rewall lter (Layer 2 CoS)
• Ingress router rewall lter (Layer 3 CoS)
• Egress router rewall lter
• Egress VLAN rewall lter
RELATED DOCUMENTATION
Firewall Filters for EX Series Switches Overview | 1539
Understanding How Firewall Filters Control Packet Flows | 1553
Understanding Bridging and VLANs on Switches
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Firewall Filter Match Condions, Acons, and Acon Modiers for EX
Series Switches
IN THIS SECTION
Firewall Filter Elements | 1559
Match Condions Supported on Switches | 1559
Acons for Firewall Filters | 1570
Acon Modiers for Firewall Filters | 1571
When you dene a rewall lter for an EX Series switch, you dene ltering criteria (
terms
, with
match
condions
) for the packets and an
acon
(and, oponally, an
acon modier
) for the switch to take if the
packets match the ltering criteria. You can dene a rewall lter to monitor IPv4, IPv6, or non-IP trac.
This topic describes in detail the various match condions, acons, and acon modiers that you can
dene in a rewall lter. For informaon about support for match condions on various EX Series
1558
switches, see "Plaorm Support for Firewall Filter Match Condions, Acons, and Acon Modiers on
EX Series Switches" on page 1574.
Firewall Filter Elements
A rewall lter conguraon contains a term, a match condion, an acon, and, oponally, an acon
modier. Table 75 on page 1559 describes each element in a rewall lter conguraon.
Table 75: Elements of a Firewall Filter Conguraon
Element Name Descripon
Term Denes the ltering criteria for the packets. Each term in the rewall lter consists of match
condions and an acon. You can dene a single term or mulple terms in the rewall lter. If
you dene mulple terms, each term must have a unique name.
Match
condion
Consists of a string (called a
match statement
) that denes the match condion. Match
condions are the values or elds that a packet must contain. You can dene a single match
condion or mulple match condions for a term. You can also opt not to dene a match
condion. If no match condions are specied for a term, all packets are matched by default.
Acon Species the acon that the switch takes if a packet matches all the criteria specied in the
match condions.
Acon modier Species one or more acons that the switch takes if a packet matches the match condions
for the specic term.
Match Condions Supported on Switches
Based on the type of trac that you want to monitor, you can congure a rewall lter to monitor IPv4,
IPv6, or non-IP trac. When you congure a rewall lter to monitor a parcular type of trac, ensure
that you specify match condions that are supported for that type of trac. For informaon about
match condions supported for a specic type of trac and switches on which they are supported, see
"Plaorm Support for Firewall Filter Match Condions, Acons, and Acon Modiers on EX Series
Switches" on page 1574.
Table 76 on page 1560 describes all the match condions that are supported for rewall lters on EX
Series Switches.
1559
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
Match Condion Descripon
destination-address
ip-address
IP desnaon address eld, which is the address of the nal desnaon
node.
ip-destination-address
ip-address
IP desnaon address eld, which is the address of the nal desnaon
node.
ip6-destination-address
ip-address
IP desnaon address eld, which is the address of the nal desnaon
node.
desnaon-mac-address
mac-address
Desnaon media access control (MAC) address of the packet.
You can dene a desnaon MAC address with a prex, such as
desnaon-mac-address 00:01:02:03:04:05/24. If no prex is
specied, the default value 48 is used.
desnaon-port
number
TCP or UDP desnaon port eld. Typically, you specify this match
condion in conjuncon with the protocol or ip-protocol match
condion to determine which protocol is used on the port. For
number
,
you can specify one of the following text synonyms (the port numbers
are also listed):
afs (1483), bgp (179), bi (512), bootpc (68), bootps (67), cmd (514),
cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106),
exec (512), nger (79), p (21), p-data (20), hp (80), hps (443), ident
(113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-
prop (754), krbupdate (760), kshell (544), ldap (389), login (513),
mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138),
netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518),
ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813),radius
(1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162),
snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs-ds
(65), talk (517), telnet (23), tp (69), med (525), who (513), xdmcp
(177), zephyr-clt (2103), zephyr-hm (2104)
1560
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
desnaon-prex-list
prex-list
IP desnaon prex list eld.
You can dene a list of IP address prexes under a prex-list alias for
frequent use. You dene this match condion at the [edit policy-
options] hierarchy level.
dot1q-tag
number
The tag eld in the Ethernet header. The tag values range from 1
through 4095. The dot1q-tag match condion and the vlan match
condion are mutually exclusive.
user-vlan-id
number
The tag eld in the Ethernet header. The tag values range from 1
through 4095. The user-vlan-id match condion and the learn-vlan-id
match condion are mutually exclusive.
dot1q-user-priority
number
User-priority eld of the tagged Ethernet packet. User-priority values
can range from 0 through 7.
For
number
, you can specify one of the following text synonyms (the
eld values are also listed):
• background (1)—Background
• best-eort (0)—Best eort
•
controlled-load (4)—Controlled load
•
excellent-load (3)—Excellent load
•
network-control (7)—Network control reserved trac
•
standard (2)—Standard or spare
•
video (5)—Video
• voice (6)—Voice
1561
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
user-vlan-1p-priority
number
User-priority eld of the tagged Ethernet packet. User-priority values
can range from 0 through 7.
For
number
, you can specify one of the following text synonyms (the
eld values are also listed):
• background (1)—Background
• best-eort (0)—Best eort
•
controlled-load (4)—Controlled load
•
excellent-load (3)—Excellent load
•
network-control (7)—Network control reserved trac
•
standard (2)—Standard or spare
•
video (5)—Video
• voice (6)—Voice
dscp
number
Species the Dierenated Services code point (DSCP). The DiServ
protocol uses the type-of-service (ToS) byte in the IP header. The most
signicant six bits of this byte form the DSCP.
You can specify DSCP in hexadecimal, binary, or decimal form.
For
number
, you can specify one of the following text synonyms (the
eld values are also listed):
• ef (46)—as dened in RFC 2598,
An Expedited Forwarding PHB
.
•
af11 (10), af12 (12), af13 (14), af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30), af41 (34), af42 (36), af43 (38)
These four classes, with three drop precedences in each class, are
dened for 12 code points in RFC 2597,
Assured Forwarding PHB
Group
.
1562
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
ether-type
value
Ethernet type eld of a packet. The
value
species what protocol is
being transported in the Ethernet frame. For
value
, you can specify one
of the following text synonyms:
• aarp—EtherType value AARP (0x80F3)
• appletalk—EtherType value AppleTalk (0x809B)
• arp—EtherType value ARP (0x0806)
•
ipv4—EtherType value IPv4 (0x0800)
•
ipv6—EtherType value IPv6 (0x08DD)
•
mpls mulcast—EtherType value MPLS mulcast (0x8848)
•
mpls unicast—EtherType value MPLS unicast (0x8847)
•
oam—EtherType value OAM (0x88A8)
• ppp—EtherType value PPP (0x880B)
• pppoe-discovery—EtherType value PPPoE Discovery Stage (0x8863)
• pppoe-session—EtherType value PPPoE Session Stage (0x8864)
• sna—EtherType value SNA (0x80D5)
NOTE: The following match condions are not supported when ether-
type is set to ipv6:
• dscp
• fragment-ags
• is-fragment
• precedence or ip-precedence
• protocol or ip-protocol
1563
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
fragment-ags
fragment-ags
IP fragmentaon ags, specied in symbolic or hexadecimal formats.
You can specify one of the following opons:
• dont-fragment (0x4000)
• more-fragments (0x2000)
• reserved (0x8000)
gbp-dst-tag Match the desnaon tag, for use with micro-segmentaon on a
VXLAN, as described here: Example: Micro and Macro Segmentaon
using Group Based Policy in a VXLAN
gbp-src-tag Match the source tag, for use with micro-segmentaon on a VXLAN, as
described here: Example: Micro and Macro Segmentaon using Group
Based Policy in a VXLAN
icmp-code
number
ICMP code eld. This value or opon provides more specic informaon
than icmp-type. Because the value’s meaning depends upon the
associated icmp-type, you must specify icmp-type along with icmp-
code. For
number
, you can specify one of the following text synonyms
(the eld values are also listed). The opons are grouped by the ICMP
type with which they are associated:
• parameter-problem—ip-header-bad (0), required-opon-missing (1)
• redirect—redirect-for-host (1), redirect-for-network (0), redirect-for-
tos-and-host (3), redirect-for-tos-and-net (2)
•
me-exceeded—l-eq-zero- during-reassembly (1), l-eq-zero-
during-transit (0)
•
unreachable—communicaon-prohibited-by-ltering (13),
desnaon-host-prohibited (10), desnaon-host-unknown (7),
desnaon-network-prohibited (9), desnaon-network-unknown
(6), fragmentaon-needed (4), host-precedence-violaon (14), host-
unreachable (1), host-unreachable-for-TOS (12), network-
unreachable (0), network-unreachable-for-TOS (11), port-
unreachable (3), precedence-cuto-in-eect (15), protocol-
unreachable (2), source-host-isolated (8), source-route-failed (5)
1564
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
icmp-type
number
ICMP packet type eld. Typically, you specify this match condion in
conjuncon with the protocol or ip-protocol match condion to
determine which protocol is being used on the port. For
number
, you
can specify one of the following text synonyms (the eld values are also
listed):
echo-reply (0), echo-request (8), info-reply (16), info-request (15),
mask-request (17), mask-reply (18), parameter-problem (12),
redirect (5), router-adversement (9), router-solicit (10), source-quench
(4),
me-exceeded (11), mestamp (13), mestamp-reply (14), unreachable
(3)
interface
interface-name
Interface on which the packet is received. You can specify the wildcard
character (*) as part of an interface name.
NOTE: The interface match condion is not supported for egress trac
on an EX8200 Virtual Chassis.
ip-opons Presence of the opons eld in the IP header.
1565
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
ip-version
version
match_condion(s)
Version of the IP protocol for port and VLAN rewall lters. The value
for
version
can be ipv4 or ipv6.
For
match_condion(s)
, you can specify one or more of the following
match condions:
• destination-address, ip-destination-address, or ip6-destination-
address
• desnaon-port
• desnaon-prex-list
• dscp
• fragment-ags
• icmp-code
• icmp-type
• is-fragment
• precedence or ip-precedence
• protocol or ip-protocol
• source-address or ip-source-address
• source-port
• source-prex-list
• tcp-established
• tcp-ags
• tcp-inial
1566
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
is-fragment If the packet is a trailing fragment, this match condion does not match
the rst fragment of a fragmented packet. Use two terms to match both
rst and trailing fragments.
NOTE: Due to a limitaon on the EX2300, EX3400, and EX4300
switches, this match condion does not match the last fragment of a
fragmented packet when applied to "family ethernet-switching.”
l2-encap-type llc-non-snap Match on logical link control (LLC) layer packets for non-Subnet Access
Protocol (SNAP) Ethernet Encapsulaon type.
next-header
bytes
8-bit protocol eld that idenes the type of header immediately
following the IPv6 header. In place of the numeric value, you can specify
one of the following text synonyms (the eld values are also listed):
ah (51), dstops (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop
(0), icmp (1), icmp6 (1), igmp (2), ipip (4), ipv6 (41), no-next-header (59),
ospf (89), pim (103), roung (43), rsvp (46), sctp (132), tcp (6), udp (17),
vrrp (112)
packet-length
bytes
Length of the received packet, in bytes.
The length refers only to the IP packet, including the packet header, and
does not include any Layer 2 encapsulaon overhead.
precedence
precedence
IP precedence. For
precedence
, you can specify one of the following
text synonyms (the eld values are also listed):
crical-ecp (5), ash (3), ash-override (4), immediate (2), internet-
control (6), net-control (7), priority (1), roune (0)
ip-precedence
precedence
IP precedence. For
precedence
, you can specify one of the following
text synonyms (the eld values are also listed):
crical-ecp (5), ash (3), ash-override (4), immediate (2), internet-
control (6), net-control (7), priority (1), roune (0)
1567
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
protocol
list of protocol
IPv4 protocol value. For
protocols
, you can specify one of the following
text synonyms:
egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4),
ospf (89), pim (103), rsvp (46), tcp (6), udp (17)
ip-protocol
list of protocol
IPv4 protocol value. For
protocols
, you can specify one of the following
text synonyms:
egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4),
ospf (89), pim (103), rsvp (46), tcp (6), udp (17)
source-address
ip-address
IP source address eld, which is the address of the source node sending
the packet. For IPv6, the source-address eld is 128 bits in length. The
lter descripon syntax supports the text representaons for IPv6
addresses that are described in RFC 2373,
IP Version 6 Addressing
Architecture
.
ip-source-address (
ip-address | ip6-
address
)
IP source address eld, which is the address of the source node sending
the packet. You can specify either an IPv4 address (ip-address) or an
IPv6 address (ip6-address). For IPv6, the ip-source-address eld is 128
bits in length. The lter descripon syntax supports the text
representaons for IPv6 addresses that are described in RFC 2373,
IP
Version 6 Addressing Architecture
.
source-mac-address
mac-address
Source MAC address.
You can dene a source MAC address with a prex, such as source-mac-
address 00:01:02:03:04:05/24. If no prex is specied, the default
value 48 is used.
source-port
number
TCP or UDP source-port eld. Typically, you specify this match in
conjuncon with the protocol or ip-protocol match condion to
determine which protocol is being used on the port. For
number
, you
can specify one of the text synonyms listed under desnaon-port.
1568
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
source-prex-list
prex-list
IP source prex list eld.
You can dene a list of IP address prexes under a prex-list alias for
frequent use. You dene this match condion at the [edit policy-
options] hierarchy level.
tcp-established TCP packets of an established TCP connecon. This condion matches
packets other than the rst packet of a connecon. tcp-established is a
synonym for the bit names "(ack | rst)".
tcp-established does not implicitly check whether the protocol is TCP.
To do so, specify the next-header tcp match condion.
tcp-ags (
ags
tcp-inial) One or more TCP ags:
• bit-name—n, syn, rst, push, ack, urgent
• logical operators—& (logical AND), | (logical OR), ! (negaon)
• numerical value—0x01 through 0x20
• text synonym—tcp-inial
To specify mulple ags, use logical operators.
tcp-inial Matches the rst TCP packet of a connecon. tcp-inial is a synonym
for the bit names "(syn&!ack)".
tcp-inial does not implicitly check whether the protocol is TCP. To do
so, specify the protocol tcp or ip-protocol tcp match condion.
trac-class
number
Species the DSCP code point for a packet.
l
value
TTL type to match. The value ranges from 1 through 255.
vlan (
vlan-name
|
vlan-id
)
The VLAN that is associated with the packet. For
vlan-id
, you can
specify either the VLAN ID or a VLAN range. The vlan match condion
and the dot1q-tag match condion are mutually exclusive.
1569
Table 76: Firewall Filter Match Condions Supported on EX Series Switches
(Connued)
Match Condion Descripon
learn-vlan-id (
vlan-name
|
vlan-id
)
The VLAN that is associated with the packet. For
vlan-id
, you can
specify either the VLAN ID or a VLAN range. The vlan match condion
and the user-vlan-id match condion are mutually exclusive.
Acons for Firewall Filters
You can dene an acon for the switch to take if a packet matches the ltering criteria dened in a
match condion. Table 77 on page 1570 describes the acons supported in a rewall lter
conguraon.
Table 77: Acons for Firewall Filters
Acon Descripon
accept Accept a packet.
discard Discard a packet silently without sending an Internet Control Message
Protocol (ICMP) message.
reject
message-type
Discard a packet, and send the ICMPv4 message (type 3) desnaon
unreachable. You can log the rejected packets if you congure the syslog
acon modier.
You can specify one of the following message codes: administravely-
prohibited (default), bad-host-tos, bad-network-tos, host-prohibited, host-
unknown, host-unreachable, network-prohibited, network-unknown,
network-unreachable, port-unreachable, precedence-cuto, precedence-
violaon, protocol-unreachable, source-host-isolated, source-route-failed,
tcp-reset.
If you specify tcp-reset, a TCP reset is returned if the packet is a TCP
packet. Otherwise nothing is returned.
If you do not specify a message type, the ICMP nocaon desnaon
unreachable is sent with the default message communicaon
administravely ltered.
1570
Table 77: Acons for Firewall Filters
(Connued)
Acon Descripon
roung-instance
roung-instance-
name
Forward matched packets to a virtual roung instance.
NOTE: EX4200 switches do not support rewall-lter-based redirecon
to the default roung instance.
vlan
vlan-name
Forward matched packets to a specic VLAN. Ensure that you specify the
VLAN name or VLAN ID and not a VLAN range, because the vlan acon
does not support the
vlan-range
opon.
NOTE: If you have dened a VLAN that is enabled for dot1q tunneling,
then that parcular VLAN is not supported as an acon (using the vlan
vlan-name
acon) for an ingress VLAN rewall lter.
Acon Modiers for Firewall Filters
In addion to the acons described in Table 77 on page 1570, you can dene acon modiers in a
rewall lter conguraon for a switch if packets match the ltering criteria dened in the match
condion. Table 78 on page 1571 describes the acon modiers supported in a rewall lter
conguraon.
Table 78:
Acon Modiers for Firewall Filters
Acon Modier Descripon
analyzer
analyzer-name
Mirror port trac to a specied desnaon port or VLAN that is
connected to a protocol analyzer applicaon. Mirroring copies all packets
seen on one switch port to a network monitoring connecon on another
switch port. The analyzer name must be congured under [edit ethernet-
switching-options analyzer].
NOTE: analyzer is not a supported acon modier for a management
interface.
NOTE: On EX4500 switches, you can congure only one analyzer and
include it in a rewall lter. If you congure mulple analyzers, you cannot
include any one of those analyzers in a rewall lter.
1571
Table 78: Acon Modiers for Firewall Filters
(Connued)
Acon Modier Descripon
dscp
number
Change the DSCP value for matched packets to the DSCP value specied
with this acon modier.
number
species the Dierenated Services
code point (DSCP). The DiServ protocol uses the type-of-service (ToS)
byte in the IP header. The most signicant six bits of this byte form the
DSCP.
You can specify DSCP in hexadecimal, binary, or decimal form.
For
number
, you can specify one of the following text synonyms (the eld
values are also listed):
•
ef (46)—as dened in RFC 2598,
An Expedited Forwarding PHB
.
•
af11 (10), af12 (12), af13 (14), af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30), af41 (34), af42 (36), af43 (38)
These four classes, with three drop precedences in each class, are
dened for 12 code points in RFC 2597,
Assured Forwarding PHB
Group
.
count
counter-name
Count the number of packets that pass this lter, term, or policer. A
policer enables you to specify rate limits on trac that enters an interface
on a switch.
NOTE: On EX4300 switches, you can congure the same number of
counters and policers as the number of terms in the ternary content
addressable memory (TCAM).
forwarding-class
class
Classify the packet in one of the following forwarding classes:
• assured-forwarding
• best-eort
• expedited-forwarding
• network-control
gbp-src-tag (EX4400 and EX4650
only)
Set the group based policy source tag (0..65535) for use with micro-
segmentaon on VXLAN, as described here: Example: Micro and Macro
Segmentaon using Group Based Policy in a VXLAN
1572
Table 78: Acon Modiers for Firewall Filters
(Connued)
Acon Modier Descripon
interface
interface-name
Forward the trac to the specied interface bypassing the switching
lookup.
log Log the packet's header informaon in the Roung Engine. To view this
informaon, issue the show firewall log command in the CLI.
NOTE: If the log or the syslog acon modier is congured along with a
vlan acon or an interface acon modier, the events might not be
logged. However, the redirect interface funconality works as expected.
loss-priority (high | low) Set the packet loss priority (PLP).
policer
policer-name
Apply rate limits to the trac.
You can specify a policer in a rewall lter only for ingress trac on a
port, VLAN, and router.
NOTE: A counter for a policer is not supported on EX8200 switches.
NOTE: On EX4300 switches, you can congure the same number of
counters and policers as the number of terms in the TCAM.
port-mirror Mirror packets to the interface dened in the [edit forwarding-options
analyzer] hierarchy.
port-mirror-instance
instance-name
Mirror packets to the instance dened in the [edit forwarding-options
analyzer] hierarchy.
syslog Log an alert for this packet. You can specify that the log be sent to a
server for storage and analysis.
NOTE: If the log or the syslog acon modier is congured along with a
vlan acon or an interface acon modier, the events might not be
logged. However, the redirect interface funconality works as expected.
three-color-policer Apply a three-color policer.
1573
RELATED DOCUMENTATION
Plaorm Support for Firewall Filter Match Condions, Acons, and Acon Modiers on EX Series
Switches | 1574
Understanding Firewall Filter Match Condions | 1547
Firewall Filter Conguraon Statements Supported by Junos OS for EX Series Switches | 2258
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Plaorm Support for Firewall Filter Match Condions, Acons, and
Acon Modiers on EX Series Switches
IN THIS SECTION
Firewall Filter Types and Their Bind Points | 1575
Support for IPv4 and IPv6 Firewall Filters on Switches | 1575
Plaorm Support for Match Condions for IPv4 Trac | 1576
Plaorm Support for Match Condions for IPv6 Trac | 1596
Plaorm Support for Match Condions for Non-IP Trac | 1610
Plaorm Support for Acons for IPv4 Trac | 1611
Plaorm Support for Acons for IPv6 Trac | 1615
Plaorm Support for Acon Modiers for IPv4 Trac | 1619
Plaorm Support for Acon Modiers for IPv6 Trac | 1628
Aer you dene a rewall lter on an EX Series switch, you must associate the lter to a bind point so
that the lter can lter the packets that enter or exit the bind point. Port rewall lters, VLAN rewall
lters, and Layer 3 (or router) rewall lters are the dierent types of rewall lters you can apply on a
switch, depending on the bind points the lters are associated with. While a port rewall lter applies to
Layer 2 interfaces, a VLAN rewall lter applies to packets that enter or leave a VLAN and also to
packets that are bridged within a VLAN. A Layer 3 rewall lter applies to Layer 3 (routed) interfaces
and routed VLAN interfaces (RVIs).
1574
NOTE: If you want to control the trac that enters the Roung Engine of the switch, you must
congure a rewall lter on the loopback interface (lo0) of the switch. For informaon about
match condions, acons, and acon modiers supported on the loopback interface of a switch,
see "Support for Match Condions and Acons for Loopback Firewall Filters on Switches" on
page 1637.
This topic describes the supported switches and bind points for match condions, acons, and acon
modiers for rewall lters supported on EX Series switches. For descripons of the match condions,
acons, and acon modiers, see "Firewall Filter Match Condions, Acons, and Acon Modiers for EX
Series Switches" on page 1558. For informaon about the EX4600 switch, see Firewall Filter Match
Condions and Acons.
Firewall Filter Types and Their Bind Points
You can apply a rewall lter at specic bind points to lter IPv4, IPv6, or non-IP trac. See the
remaining secons in this topic for informaon about support on individual switches for dierent trac
types.
Table 79 on page 1575 lists the rewall lter types and their associated bind points that are supported
on the switches.
Table 79: Bind Points Associated with Firewall Filter Types
Bind Points Firewall Filter Type
Ports (Layer 2 interfaces) Port rewall lter
VLANs VLAN rewall lter
Layer 3 interfaces (Layer 3 (routed) interfaces or routed
VLAN interfaces (RVIs)
Router rewall lter
Support for IPv4 and IPv6 Firewall Filters on Switches
On EX2200, EX2300/EX3400, EX3200/EX4200, EX3300, EX4500, and EX6200 switches port and
VLAN lters on IPv6 trac can match only layer 2 header elds. On an EX8200 switch, port and VLAN
1575
trac can match on layer 3 and layer 4 header elds, in addion to layer 2 header elds, of IPv6 trac.
On an EX4300 switch, port and VLAN lters on IPv6 trac can match layer 3 and layer 4 header elds.
Table 80 on page 1576 briey summarizes the support for IPv4 and IPv6 rewall lters on dierent
switches. The support for port, VLAN, and router rewall lters on dierent switches is further
discussed in the subsequent secons in this topic.
Table 80: Support for IPv4 and IPv6 Firewall Filters on Switches
Switch Support for IPv4 Firewall Filter Support for IPv6 Firewall Filter
EX2200 Yes Yes
EX2300 and EX3400 Yes Yes
EX3200 and EX4200 Yes Yes
EX3300 Yes Yes
EX4300 Yes Yes
EX4500 Yes Yes
EX6200 Yes Yes
EX8200 Yes Yes
Plaorm Support for Match Condions for IPv4 Trac
You can dene port, VLAN, and router rewall lters for ingress and egress IPv4 trac on all EX Series
switches. Table 81 on page 1577 summarizes the support for match condions on dierent bind points
for ingress and egress IPv4 trac on dierent switches.
1576
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
Match Condion Switch
Supported Bind Points
Ingress Egress
destination-address
ip-
address
EX2200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Layer 3 interfaces Layer 3 interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Layer 3 interfaces Layer 3 interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
ip-destination-address
EX4300 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Not supported (EX2300)
Ports and VLANs (EX3400)
destination-mac-address
mac-address
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
1577
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX3200 and EX4200
Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Ports and VLANs Ports and VLANs
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
destination-port
number
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces (EX4300)
Not supported (EX2300)
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1578
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX4500
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
destination-prefix-list
prefix-list
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1579
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX8200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
dot1q-tag
number
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Not supported Not supported
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Not supported
user-vlan-id number
EX4300 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
dot1q-user-priority
number
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports and VLANs Ports and VLANs
1580
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX3300
Ports and VLANs Ports and VLANs
EX4300 Not supported Not supported
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
user-vlan-1p-priority
number
EX4300 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
dscp
number
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1581
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX4500
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
ether-type
value
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Ports and VLANs Ports and VLANs
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Not supported
fragment-flags
fragment-
flags
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
1582
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX3200 and EX4200
Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
icmp-code
number
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 Interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1583
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX4300
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
icmp-type
number
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 Interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1584
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX6200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
interface
interface-name
NOTE: This match
condion is not
supported by rewall
lters congured on
ingress L3 interfaces
and ingress VLAN
interfaces when the
interface to be matched
is aggregate Ethernet
(ae) interface.
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
ip-options
EX2200 Layer 3 interfaces Not supported
1585
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX2300 and EX3400
Layer 3 interfaces Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports and VLANs
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports and VLANs
EX4300 Layer 3 interfaces Layer 3 interfaces
EX4500 Layer 3 interfaces Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Layer 3 interfaces Not supported
ip-version
versionmatch_condio
n(s)
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Not supported (EX2300)
Ports and VLANs (EX3400)
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Ports and VLANs Ports and VLANs
EX4500 Ports and VLANs Ports and VLANs
1586
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX6200
Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
is-fragment
NOTE: Due to a
limitaon on the
EX2300, EX3400, and
EX4300 switches, this
match condion does
not match the last
fragment of a
fragmented packet
when applied to a port
or a VLAN.
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
precedence
precedence
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1587
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX2300 and EX3400
Layer 3 interfaces Layer 3 interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Layer 3 interfaces Layer 3 interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
ip-precedence precedence
EX4300 Ports and VLANs Not supported
EX2300 and EX3400 Ports and VLANs Not supported
protocol
list of
protocols
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Layer 3 interfaces Layer 3 interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1588
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX3300
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Layer 3 interfaces Layer 3 interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
ip-protocol list of
protocols
EX4300 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
source-address
ip-
address
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Layer 3 interfaces Layer 3 interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Layer 3 interfaces Layer 3 interfaces
1589
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX4500
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
ip-source-address ip-
address
EX4300 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Not supported (EX2300)
Ports and VLANs (EX3400)
source-mac-address
mac-
address
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Ports and VLANs Ports and VLANs
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
1590
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
source-port
number
EX2200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
source-prefix-list
prefix-list
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
1591
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX3200 and EX4200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
tcp-established
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1592
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX4300
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
tcp-flags (
flags
tcp-
initial)
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1593
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX6200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
tcp-initial
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1594
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
ttl
value
EX2200
Layer 3 interfaces Not supported
EX2300 and EX3400 Layer 3 interfaces Layer 3 interfaces (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Layer 3 interfaces Not supported
EX3300 Layer 3 interfaces Not supported
EX4300 Layer 3 interfaces Ports, VLANs, and Layer 3
interfaces
EX4500 Layer 3 interfaces Not supported
EX6200 Layer 3 interfaces Not supported
EX8200 Layer 3 interfaces Not supported
vlan (
vlan-name
|
vlan-
id
)
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Not supported Not supported
1595
Table 81: Firewall Filter Match Condions Supported for IPv4 Trac on Switches
(Connued)
Match Condion Switch
Supported Bind Points
Ingress Egress
EX4500
Ports and VLANs Ports
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
learn-vlan-id vlan-id
EX4300 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
Plaorm Support for Match Condions for IPv6 Trac
Table 82 on page 1596 summarizes support for match condions on dierent bind points for ingress and
egress IPv6 trac on dierent switches.
Table 82: Firewall Filter Match
Condions Supported for IPv6 Trac on Switches
Match Condion Switch Supported Bind Points
Ingress Egress
destination-address
ip-address
EX2200
Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Layer 3 interfaces Layer 3 interfaces
EX3200 and EX4200 Layer 3 interfaces Layer 3 (routed)
interfaces only
EX3300 Layer 3 interfaces Layer 3 interfaces
1596
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX4300
Layer 3 interfaces Layer 3 (routed)
interfaces only
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Layer 3 interfaces
destination-mac-
address
mac-address
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Ports and VLANs Ports and VLANs
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
destination-port
number
EX2200 Layer 3 interfaces Layer 3 interfaces
1597
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Ports, VLANs, and Layer
3 interfaces
Not supported (EX2300)
Ports and VLANs
(EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Ports, VLANs, and Layer
3 interfaces
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
destination-prefix-
list
prefix-list
EX2200 Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer
3 interfaces
Layer 3 interfaces
(EX2300)
Ports, VLANs, and Layer
3 interfaces (EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 (routed)
interfaces only
EX3300 Layer 3 interfaces Layer 3 interfaces
1598
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX4300
Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
dot1q-tag
number
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Not supported Not supported
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Not supported
user-vlan-id number
EX4300 Ports and VLANs Ports and VLANs
1599
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
dot1q-user-priority
number
EX2200
Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Not supported Not supported
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
user-vlan-1p-
priority number
EX4300 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Not supported
ether-type
(ipv6)
value
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
1600
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX4300
Ports and VLANs Ports and VLANs
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
icmp-code
number
EX2200 Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer
3 interfaces
Not supported (EX2300)
Ports and VLANs
(EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Ports, VLANs, and Layer
3 interfaces
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
icmp-type
number
EX2200 Layer 3 interfaces Layer 3 interfaces
1601
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Ports, VLANs, and Layer
3 interfaces
Not supported (EX2300)
Ports and VLANs
(EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Ports, VLANs, and Layer
3 interfaces
Not supported
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
interface
interface-name
NOTE: This match
condion is not
supported by
rewall lters
congured on
ingress L3
interfaces and
ingress VLAN
interfaces when
the interface to be
matched is
EX2200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer
3 interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
EX3300 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
1602
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
aggregate Ethernet
(ae) interface.
EX4300
Ports, VLANs, and Layer
3 interfaces
Not supported
EX4500 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
ip-version
version
match_condion(s)
EX2200 Not supported Not supported
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Not supported Not supported
EX4500 Not supported Not supported
EX6200 Not supported Not supported
EX8200 Ports and VLANs Ports and VLANs
next-header
bytes
EX2200 Layer 3 interfaces Layer 3 interfaces
1603
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Layer 3 interfaces Layer 3 interfaces
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Layer 3 interfaces Layer 3 interfaces
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
packet-length
bytes
EX2200 Not supported Not supported
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Not supported Not supported
EX4500 Not supported Not supported
EX6200 Not supported Not supported
1604
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX8200
Layer 3 interfaces Not supported
source-address
ip-
address
EX2200 Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Layer 3 interfaces Not supported
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4500 Layer 3 interfaces Layer 3 interfaces
EX4300 Layer 3 interfaces Not supported
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
source-mac-address
mac-address
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Ports and VLANs Ports and VLANs
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Ports and VLANs Ports and VLANs
1605
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX4500
Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
source-port
number
EX2200 Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, Layer 3
interfaces
Ports and VLANs
(EX3400)
Not supported (EX2300)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Ports, VLANs, Layer 3
interfaces
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
source-prefix-list
prefix-list
EX2200 Layer 3 interfaces Layer 3 interfaces
1606
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Ports, VLANs, and Layer
3 interfaces
Not supported (EX2300)
Ports and VLANs
(EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Ports, VLANs, and Layer
3 interfaces
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
tcp-established
EX2200 Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer
3 interfaces
Not supported (EX2300)
Ports and VLANs
(EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
1607
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX4300
Ports, VLANs, and Layer
3 interfaces
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
tcp-flags (
flags
tcp-initial)
EX2200 Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer
3 interfaces
Not supported (EX2300)
Ports and VLANs
(EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Ports, VLANs, and Layer
3 interfaces
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
1608
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
tcp-initial
EX2200
Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer
3 interfaces
Not supported (EX2300)
Ports and VLANs
(EX3400)
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
EX4300 Ports, VLANs, and Layer
3 interfaces
Ports and VLANs
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Ports, VLANs, and Layer
3 interfaces
Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
traffic-class
number
EX2200 Layer 3 interfaces Layer 3 interfaces
EX2300 and EX3400 Layer 3 interfaces Layer 3 interfaces
EX3200 and EX4200 Layer 3 interfaces Layer 3 interfaces
EX3300 Layer 3 interfaces Layer 3 interfaces
1609
Table 82: Firewall Filter Match Condions Supported for IPv6 Trac on Switches
(Connued)
Match Condion Switch Supported Bind Points
Ingress Egress
EX4300
Layer 3 interfaces Layer 3 interfaces
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Layer 3 interfaces Layer 3 interfaces
EX8200 Ports, VLANs, and Layer
3 interfaces
Ports, VLANs, and Layer
3 interfaces
vlan (
vlan-id
|
vlan-name
)
EX2200 Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Not supported Not supported
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Not supported
Plaorm Support for Match Condions for Non-IP Trac
You can dene port, VLAN, and router rewall lters for ingress and egress non-IP trac on all EX Series
switches. Table 83 on page 1611 summarizes support for match condions on dierent bind points for
ingress and egress non-IP trac on dierent switches.
1610
Table 83: Firewall Filter Match Condion Supported for Non-IP Trac on Switches
Match Condion Switch Supported Bind Points
Ingress Egress
l2-encap-type llc-non-
snap
EX2200
Ports and VLANs Ports and VLANs
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports and VLANs Ports and VLANs
EX3300 Ports and VLANs Ports and VLANs
EX4300 Not supported Not supported
EX4500 Ports and VLANs Ports and VLANs
EX6200 Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs Ports and VLANs
Plaorm Support for Acons for IPv4 Trac
Table 84 on page 1611 summarizes the support for acons on dierent bind points for ingress and
egress IPv4 trac on dierent switches.
Table 84: Firewall Filter
Acons Supported for IPv4 Trac on Switches
Acon Switch Supported Bind Points
Ingress Egress
accept
EX2200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1611
Table 84: Firewall Filter Acons Supported for IPv4 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
discard
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1612
Table 84: Firewall Filter Acons Supported for IPv4 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
EX3300
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
reject
message-
type
EX2200 Layer 3 interfaces Not supported
EX2300 and EX3400 Layer 3 interfaces Not supported
EX3200 and EX4200 Layer 3 interfaces Not supported
EX3300 Layer 3 interfaces Not supported
EX4300 Layer 3 interfaces Not supported
EX4500 Layer 3 interfaces Not supported
EX6200 Layer 3 interfaces Not supported
EX8200 Layer 3 interfaces Not supported
1613
Table 84: Firewall Filter Acons Supported for IPv4 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
routing-instance
routing-instance-
name
EX2200
Not supported Not supported
EX2300 and EX3400 Not supported (EX2300)
Layer 3 interfaces (EX3400)
Not supported
EX3200 and EX4200 Layer 3 interfaces Not supported
EX3300 Layer 3 interfaces Not supported
EX4300 Layer 3 interfaces Not supported
EX4500 Layer 3 interfaces Not supported
EX6200 Layer 3 interfaces Not supported
EX8200 Layer 3 interfaces Not supported
vlan
vlan-name
EX2200 Ports and VLANs Not supported
EX2300 and EX3400 Ports and VLANs Not supported
EX3200 and EX4200 Ports and VLANs Not supported
EX3300 Ports and VLANs Not supported
EX4300 Ports and VLANs Not supported
EX4500 Ports and VLANs Ports
1614
Table 84: Firewall Filter Acons Supported for IPv4 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
EX6200
Ports and VLANs Ports and VLANs
EX8200 Ports and VLANs
NOTE: Supported only
when used in conjuncon
with the interface acon
modier. On EX8200 Virtual
Chassis, the vlan acon is
supported only for VLANs.
Not supported
Plaorm Support for Acons for IPv6 Trac
Table 85 on page 1615 summarizes the support for acons on dierent bind points for ingress and
egress IPv6 trac.
Table 85: Firewall Filter
Acons Supported for IPv6 Trac on Switches
Acon Switch Supported Bind Points
Ingress Egress
accept
EX2200
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1615
Table 85: Firewall Filter Acons Supported for IPv6 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
EX3300
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
discard
EX2200 Ports and VLANs, and Layer
3 interfaces
Ports and VLANs, and Layer
3 interfaces
EX2300 and EX3400 Ports and VLANs, and Layer
3 interfaces
Ports and VLANs, and Layer
3 interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
1616
Table 85: Firewall Filter Acons Supported for IPv6 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
EX4500
Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
reject
message-
type
EX2200 Layer 3 interfaces Not supported
EX2300 and EX3400 Layer 3 interfaces Not supported
EX3200 and EX4200 Layer 3 interfaces Not supported
EX3300 Layer 3 interfaces Not supported
EX4300 Layer 3 interfaces Not supported
EX4500 Layer 3 interfaces Not supported
EX6200 Layer 3 interfaces Not supported
EX8200 Layer 3 interfaces Not supported
routing-instance
routing-instance-
name
EX2200 Not supported Not supported
EX2300 and EX3400 Not supported (EX2300)
Layer 3 interfaces (EX3400)
Not supported
1617
Table 85: Firewall Filter Acons Supported for IPv6 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
EX3200 and EX4200
Layer 3 interfaces Not supported
EX3300 Layer 3 interfaces Not supported
EX4300 Not supported Not supported
EX4500 Layer 3 interfaces Not supported
EX6200 Layer 3 interfaces Not supported
EX8200 Layer 3 interfaces Not supported
vlan
vlan-name
EX2200 Ports and VLANs Not supported
EX2300 and EX3400 Ports and VLANs Not supported
EX3200 and EX4200 Ports and VLANs Not supported
EX3300 Ports and VLANs Not supported
EX4300 Ports and VLANs Not supported
EX4500 Ports and VLANs Not supported
EX6200 Ports and VLANs Not supported
1618
Table 85: Firewall Filter Acons Supported for IPv6 Trac on Switches
(Connued)
Acon Switch Supported Bind Points
Ingress Egress
EX8200
Ports and VLANs
NOTE: Supported only
when used in conjuncon
with the interface acon
modier. On EX8200 Virtual
Chassis, the vlan acon is
supported only for VLANs.
Not supported
Plaorm Support for Acon Modiers for IPv4 Trac
Table 86 on page 1619 summarizes support for acon modiers on dierent bind points for ingress and
egress IPv4 trac on dierent switches.
Table 86: Firewall Filter
Acon Modiers Supported for IPv4 Trac on Switches
Acon Modier Switch Supported Bind Points
Ingress Egress
analyzer
EX2200
Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Not supported Not supported
1619
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX4500
Ports, VLANs, and Layer 3
interfaces
Layer 3 interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
dscp
EX2200 Not supported Not supported
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Not supported Not supported
EX4500 Not supported Not supported
EX6200 Not supported Not supported
EX8200 Layer 3 interfaces Not supported
count
EX2200 VLANs and Layer 3
interfaces (me0 interfaces
only)
Layer 3 interfaces (me0
interfaces only)
1620
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Ports, VLANs, and Layer 3
Interfaces
Ports, VLANs, and Layer 3
interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300 VLANs and Layer 3
interfaces (me0 and vme0
interfaces only)
Layer 3 interfaces (me0 and
vme0 interfaces only)
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
forwarding-class
class
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
1621
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX3300
Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
interface
interface-name
EX2200 Ports and VLANs Not supported
EX2300 and EX3400 Ports and VLANs Ports and VLANs
EX3200 and EX4200 Ports and VLANs Not supported
EX3300 Ports and VLANs Not supported
EX4300 Ports and VLANs Not supported
EX4500 Ports and VLANs Not supported
EX6200 Ports and VLANs Not supported
1622
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX8200
Ports and VLANs
NOTE: On EX8200 Virtual
Chassis, the interface acon
modier is supported only
for VLANs.
Not supported
log
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
1623
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
loss-priority
(high | low)
EX2200
Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
policer
policer-
name
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
1624
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX3200 and EX4200
Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
port-mirror
EX2200 Not supported Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
1625
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX4500
Not supported Not supported
EX6200 Not supported Not supported
EX8200 Not supported Not supported
port-mirror-
instance instance-
name
EX2200 Not supported Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Not supported Not supported
EX6200 Not supported Not supported
EX8200 Not supported Not supported
syslog
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
1626
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
three-color-
policer
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interface
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Not supported
1627
Table 86: Firewall Filter Acon Modiers Supported for IPv4 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX3300
Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Not supported Not supported
Plaorm Support for Acon Modiers for IPv6 Trac
Table 87 on page 1628 summarizes support for acon modiers on dierent bind points for ingress and
egress IPv6 trac.
Table 87: Firewall Filter
Acon Modiers Supported for IPv6 Trac on Switches
Acon Modier Switch Supported Bind Points
Ingress Egress
analyzer
EX2200
Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Not supported Not supported
1628
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX3200 and EX4200
Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and layer 3
interfaces
Not supported
EX4500 Layer 3 interfaces Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
dscp
EX2200 Not supported Not supported
EX2300 and EX3400 Not supported Not supported
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Not supported Not supported
EX4500 Not supported Not supported
EX6200 Not supported Not supported
1629
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX8200
Layer 3 interfaces Not supported
count
EX2200 VLANs and Layer 3
interfaces (me0 and vme0
interfaces only)
Layer 3 interfaces (me0 and
vme0 interfaces only)
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX3300
Layer 3 interfaces (me0 and
vme0 interfaces only)
Layer 3 interfaces (me0 and
vme0 interfaces only)
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
forwarding-class
class
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
1630
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX2300 and EX3400
Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX3300 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
interface
interface-name
EX2200 Ports and VLANs Not supported
EX2300 and EX3400 Ports and VLANs Not supported
EX3200 and EX4200 Ports and VLANs Not supported
EX3300 Ports and VLANs Not supported
EX4300 Ports and VLANs Not supported
1631
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX4500
Ports and VLANs Not supported
EX6200 Ports and VLANs Not supported
EX8200 Ports and VLANs
NOTE: On EX8200 Virtual
Chassis, the interface acon
modier is supported only
for VLANs.
Not supported
log
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
1632
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX8200
Ports, VLANs, and Layer 3
interfaces
Not supported
loss-priority
(high | low)
EX2200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX3300 Ports, VLANS, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
EX8200 Ports, VLANs, and Layer 3
interfaces
Ports and Layer 3 interfaces
policer
policer-
name
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
1633
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX3200 and EX4200
Ports, VLANs, and Layer 3
interfaces
Not supported
EX3300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Ports, VLANs, and Layer 3
interfaces
EX4500 Layer 3 interfaces Layer 3 interfaces
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
port-mirror
EX2200 Not supported Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
1634
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX6200
Not supported Not supported
EX8200 Not supported Not supported
port-mirror-
instance instance-
name
EX2200 Not supported Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported (EX2300)
Ports, VLANs, and Layer 3
interfaces (EX3400)
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Not supported Not supported
EX8200 Not supported Not supported
syslog
EX2200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Ports, VLANs, and Layer 3
interfaces
Not supported
1635
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX3300
Ports, VLAN, and Layer 3
interfaces
Not supported
EX4300 Ports, VLANs, and Layer 3
interfaces
Not supported
EX4500 Ports, VLANs, and Layer 3
interfaces
Not supported
EX6200 Ports, VLANs, and Layer 3
interfaces
Not supported
EX8200 Ports, VLANs, and Layer 3
interfaces
Not supported
three-color-
policer
EX2200 Not supported Not supported
EX2300 and EX3400 Ports, VLANs, and Layer 3
interfaces
Not supported
EX3200 and EX4200 Not supported Not supported
EX3300 Not supported Not supported
EX4300 Not Supported Not Supported
EX4500 Not supported Not supported
EX6200 Not supported Not supported
1636
Table 87: Firewall Filter Acon Modiers Supported for IPv6 Trac on Switches
(Connued)
Acon Modier Switch Supported Bind Points
Ingress Egress
EX8200
Not Supported Not Supported
RELATED DOCUMENTATION
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
Support for Match Condions and Acons for Loopback Firewall Filters on Switches | 1637
Understanding Firewall Filter Match Condions | 1547
Firewall Filter Conguraon Statements Supported by Junos OS for EX Series Switches | 2258
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Support for Match Condions and Acons for Loopback Firewall Filters
on Switches
On EX Series Ethernet switches, a loopback interface is a gateway for all the control trac that enters
the Roung Engine of the switch. If you want to monitor this control trac, you must congure a
rewall lter on the loopback interface (lo0). Loopback rewall lters are applied only to packets that are
sent to the Roung Engine CPU for further processing. Therefore, you can apply a rewall lter only in
the ingress direcon on the loopback interface.
Each term in a rewall lter consists of
match condions
and an
acon
. Match condions are the values
or elds that a packet must contain. You can dene mulple, single, or no match condions. If no match
condions are specied for the term, all packets are matched by default. The string that denes a match
condion is called a
match statement
. The acon is the acon that the switch takes if a packet matches
the match condions for the specic term. Acon modiers are oponal and specify one or more
acons that the switch takes if a packet matches the match condions for the specic term.
The following tables list match condions, acons, and acon modiers that are supported for a rewall
lter congured on a loopback interface on a switch:
1637
• Table 88 on page 1638
• Table 89 on page 1640
• Table 90 on page 1641
For informaon on match condions, acons, and acon modiers supported for a rewall lter
congured on a network interface, see "Plaorm Support for Firewall Filter Match Condions, Acons,
and Acon Modiers on EX Series Switches" on page 1574.
Table 88: Match Condions for Firewall Filters on Loopback Interfaces for IPv4 and IPv6 Trac—
Support per Switch
Match Condion EX2200 EX3200,
EX4200
EX3300 EX4500 EX6200 EX8200
Match condions for IPv4 trac:
desnaon-
address
✓ ✓ ✓ ✓ ✓ ✓
desnaon-port ✓ ✓ ✓ ✓ ✓ ✓
desnaon-prex-
list
✓ ✓ ✓ ✓ ✓ ✓
dscp ✓ ✓ ✓ ✓ ✓ ✓
icmp-code ✓ ✓ ✓ ✓ ✓ ✓
icmp-type ✓ ✓ ✓ ✓ ✓ ✓
interface ✓ ✓ ✓ ✓ ✓ ✓
is-fragment ✓ ✓ ✓ ✓ – –
packet-length – – – – – ✓
precedence ✓ ✓ ✓ ✓ ✓ ✓
1638
Table 88: Match Condions for Firewall Filters on Loopback Interfaces for IPv4 and IPv6 Trac—
Support per Switch
(Connued)
Match Condion EX2200 EX3200,
EX4200
EX3300 EX4500 EX6200 EX8200
protocol ✓ ✓ ✓ ✓ ✓ ✓
source-address ✓ ✓ ✓ ✓ ✓ ✓
source-port ✓ ✓ ✓ ✓ ✓ ✓
source-prex-list ✓ ✓ ✓ ✓ ✓ ✓
Match condions for IPv6 trac:
ip6-desnaon-
address
✓ ✓ ✓ ✓ ✓ ✓
desnaon-port ✓ ✓ ✓ ✓ ✓ ✓
desnaon-prex-
list
✓ ✓ ✓ ✓ ✓ ✓
icmp-code ✓ ✓ ✓ ✓ ✓ ✓
icmp-type ✓ ✓ ✓ ✓ ✓ ✓
interface ✓ ✓ ✓ ✓ ✓ ✓
next-header ✓ ✓ ✓ ✓ ✓ ✓
packet-length – – – – – ✓
source-address ✓ ✓ ✓ ✓ ✓ ✓
1639
Table 88: Match Condions for Firewall Filters on Loopback Interfaces for IPv4 and IPv6 Trac—
Support per Switch
(Connued)
Match Condion EX2200 EX3200,
EX4200
EX3300 EX4500 EX6200 EX8200
source-port ✓ ✓ ✓ ✓ ✓ ✓
source-prex-list ✓ ✓ ✓ ✓ ✓ ✓
tcp-established ✓ ✓ ✓ ✓ ✓ –
tcp-ags ✓ ✓ ✓ ✓ ✓ –
tcp-inial ✓ ✓ ✓ ✓ ✓ –
trac-class ✓ ✓ ✓ ✓ ✓ ✓
Table 89: Acons for Firewall Filters on Loopback Interfaces for IPv4 and IPv6 Trac—Support per
Switch
Acon EX2200 EX3200,
EX4200
EX3300 EX4500 EX6200 EX8200
Acons for IPv4 trac:
accept ✓ ✓ ✓ ✓ ✓ ✓
discard ✓ ✓ ✓ ✓ ✓ ✓
Acons for IPv6 trac:
accept ✓ ✓ ✓ ✓ ✓ ✓
discard ✓ ✓ ✓ ✓ ✓ ✓
1640
Table 90: Acon Modiers for Firewall Filters on Loopback Interfaces for IPv4 and IPv6 Trac—
Support per Switch
Acon EX2200 EX3200,
EX4200
EX3300 EX4500 EX6200 EX8200
Acon modiers for IPv4 trac:
count – ✓ – ✓ ✓ –
forwarding-
class
✓ ✓ ✓ ✓ – ✓
loss-priority ✓ ✓ ✓ ✓ – ✓
Acon modiers for IPv6 trac:
count – ✓ – ✓ – –
forwarding-
class
✓ ✓ ✓ ✓ – ✓
loss-priority ✓ ✓ ✓ ✓ – ✓
NOTE: On EX8200 switches, if an implicit or explicit discard acon is congured on a loopback
interface for IPv4 trac, next hop resolve packets are accepted and allowed to pass through the
switch. However, for IPv6 trac, you must explicitly congure a rule to allow the neighbor
discovery IPv6 resolve packets to pass through the switch.
RELATED DOCUMENTATION
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
Plaorm Support for Firewall Filter Match Condions, Acons, and Acon Modiers on EX Series
Switches | 1574
Understanding Firewall Filter Match Condions | 1547
1641
Understanding How Firewall Filters Are Evaluated | 1554
Understanding How Firewall Filters Test a Packet's Protocol | 1653
Understanding the Use of Policers in Firewall Filters | 2214
Conguring Firewall Filters (CLI Procedure)
IN THIS SECTION
Conguring a Firewall Filter | 1642
Conguring a Term Specically for IPv4 or IPv6 Trac | 1647
Applying a Firewall Filter to a Port on a Switch | 1648
Applying a Firewall Filter to a Management Interface on a Switch | 1649
Applying a Firewall Filter to a VLAN on a Network | 1650
Applying a Firewall Filter to a Layer 3 (Routed) Interface | 1652
You congure rewall lters on EX Series switches to control trac that enters ports on the switch or
enters and exits VLANs on the network and Layer 3 (routed) interfaces. To congure a rewall lter you
must congure the lter and then apply it to a port, VLAN, or Layer 3 interface.
Conguring a Firewall Filter
Before you can apply a rewall lter to a port, VLAN, or Layer 3 interface, you must congure a rewall
lter with the required details, such as type of family for the rewall lter, rewall lter name, and match
condions. A match condion in the rewall lter conguraon can contain mulple terms that dene
the criteria for the match condion. For each term, you must specify an acon to be performed if a
packet matches the condions in the term. For informaon on dierent match condions and acons,
see "Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches" on page
1558.
To congure a rewall lter:
1. Congure the family address type for the rewall lter:
1642
• For a rewall lter that is applied to a port or VLAN, specify the family address type ethernet-
switching to lter Layer 2 (Ethernet) packets and Layer 3 (IP) packets, for example:
[edit firewall]
user@switch# set family ethernet-switching
• For a rewall lter that is applied to a Layer 3 (routed) interface:
• To lter IPv4 packets, specify the family address type inet, for example:
[edit firewall]
user@switch# set family inet
• To lter IPv6 packets, specify the family address type inet6, for example:
[edit firewall]
user@switch# set family inet6
NOTE: You can congure rewall lters for both IPv4 and IPv6 trac on the same Layer 3
interface.
2. Specify the lter name:
[edit firewall family ethernet-switching]
user@switch# set filter ingress-port-filter
The lter name can contain leers, numbers, and hyphens (-) and can have a maximum of 64
characters. Each lter name must be unique.
3. If you want to apply a rewall lter to mulple interfaces and name individual rewall counters
specic to each interface, congure the interface-specic opon:
[edit firewall family ethernet-switching filter ingress-port-filter]
user@switch# set interface-specific
1643
4. Specify a term name:
[edit firewall family ethernet-switching filter ingress-port-filter]
user@switch# set term term-one
The term name can contain leers, numbers, and hyphens (-) and can have a maximum of 64
characters.
A rewall lter can contain one or more terms. Each term name must be unique within a lter.
NOTE: The maximum number of terms allowed per rewall lter for EX Series switches is:
• 512 for EX2200 switches
• 1,436 for EX3300 switches
NOTE: On EX3300 switches, if you add and delete lters with a large number of
terms (on the order of 1000 or more) in the same commit operaon, not all the
lters are installed. You must add lters in one commit operaon, and delete lters
in a separate commit operaon.
• 7,168 for EX3200 and EX4200 switches
• On EX4300 switches, following are the number of terms supported for ingress and egress
trac, for rewall lers congured on a port, VLAN and Layer 3 interface:
• For ingress trac:
• 3,500 terms for rewall lters congured on a port
• 3,500 terms for rewall lters congured on a VLAN
• 7,000 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 3,500 terms for rewall lers congured on Layer 3 interfaces for IPv6 trac
• For egress trac:
• 512 terms for rewall lters congured on a port
1644
• 256 terms for rewall lters congured on a VLAN
• 512 terms for rewall lters congured on Layer 3 interfaces for IPv4 trac
• 512 terms for rewall lers congured on Layer 3 interfaces for IPv6 trac
NOTE: You can congure these maximum number of terms only when you
congure one type of rewall lter (Port, VLAN, or Router (Layer 3) rewall lter)
on the switch, and when storm control is not enabled on all interfaces in the
switch.
• 1,200 for EX4500 and EX4550 switches
• 1,400 for EX6200 switches
• 32,768 for EX8200 switches
If you aempt to congure a rewall lter that exceeds these limits, the switch returns an
error message when you commit the conguraon.
5. For each rewall lter term, specify the match condion(s) that you want to include. The example
below shows how to match packets from a given IP address and port:
[edit firewall family ethernet-switching filter ingress-port-filter term term-one]
user@switch# set from source-address 192.0.2.0
user@switch# set from source-port 80
You can specify one or more match condions in a single from statement. For a match to occur, the
packet must match all the condions in the term.
The from statement is oponal, but if included in a term, the from statement cannot be empty. If you
omit the from statement, all packets are considered to match.
6. For each rewall lter term, specify the acon to take if the packet matches all the condions in that
term.
You can specify an acon and/or acon modiers:
• To specify a lter acon, for example, to discard packets that match the condions of the lter
term:
[edit firewall family ethernet-switching filter ingress-port-filter term term-one]
user@switch# set then discard
1645
You can specify no more than one acon per lter term.
•
To specify an acon modier, for example, to count and classify packets in a forwarding class:
[edit firewall family ethernet-switching filter ingress-port-filter term term-one]
user@switch# set then count counter-one
user@switch# set then forwarding-class expedited-forwarding
In a then statement, you can specify the following acon modiers:
• analyzer
analyzer-name
—Mirror port trac to a specied desnaon port or VLAN that is
connected to a protocol analyzer applicaon. An analyzer must be congured under the
ethernet-switching family address type. See
Conguring Port Mirroring to Analyze Trac (CLI
Procedure)
.
• count
counter-name
—Count the number of packets that pass this lter term.
NOTE: We recommend that you congure a counter for each term in a rewall lter, so
that you can monitor the number of packets that match the condions specied in
each lter term.
• forwarding-class
class
—Classify packets in a forwarding class.
• loss-priority
priority
—Set the priority for dropping a packet.
• policer
policer-name
—Apply rate liming to the trac.
• interface
interface-name
—Forward the trac to the specied interface, bypassing the
switching lookup.
• log—Log the packet's header informaon in the Roung Engine.
If you omit the then statement or do not specify an acon, packets that match all the condions in the
from statement are accepted. However, you must always explicitly congure an acon and/or acon
modier in the then statement. You can include no more than one acon, but you can use any
combinaon of acon modiers. For an acon or acon modier to take eect, all condions in the
from statement must match.
NOTE: Implicit discard is also applicable to a rewall lter applied to the loopback interface,
lo0.
1646
On Juniper Networks EX8200 Ethernet Switches, if an implicit or explicit discard acon is
congured on a loopback interface for IPv4 trac, next hop resolve packets are accepted and
allowed to pass through the switch. However, for IPv6 trac, you must explicitly congure a
rule to allow the next hop IPv6 resolve packets to pass through the switch.
Conguring a Term Specically for IPv4 or IPv6 Trac
To congure a term in a rewall lter conguraon specically for IPv4 trac:
1. Verify that neither ether-type ipv6 nor ip-version ipv6 is specied in the term in the conguraon. By
default, a conguraon that does not contain either ether-type ipv6 or ip-version ipv6 in a term applies
to IPv4 trac.
2. (Oponal) Perform one of these tasks:
• Dene ether-type ipv4 in a term in the conguraon.
• Dene ip-version ipv4 in a term in the conguraon.
• Dene both ether-type ipv4 and ip-version ipv4 in a term in the conguraon.
• Verify that neither ether-type ipv6 nor ip-version ipv6 is specied in a term in the conguraon—by
default, a conguraon that does not contain either ether-type ipv6 or ip-version ipv6 in a term
applies to IPv4 trac if it does not contain ether-type ipv6 or ip-version ipv6.
3. Ensure that other match condions in the term are valid for IPv4 trac.
To congure a term in a rewall lter conguraon specically for IPv6 trac:
1. Perform one of these tasks:
• Dene ether-type ipv6 in a term in the conguraon.
• Dene ip-version ipv6 in a term in the conguraon.
• Dene both ether-type ipv6 and ip-version ipv4 in a term in the conguraon.
NOTE: By default, a conguraon that does not contain either ether-type ipv6 or ip-version
ipv6 in a term applies to IPv4 trac.
2. Ensure that other match condions in the term are valid for IPv6 trac.
1647
NOTE: If the term contains either of the match condions ether-type ipv6 or ip-version ipv6, with
no other IPv6 match condion specied, all IPv6 trac is matched.
NOTE: To congure a rewall lter for both IPv4 and IPv6 trac, you must include two separate
terms, one for IPv4 trac and the other for IPv6 trac.
Applying a Firewall Filter to a Port on a Switch
You can apply a rewall lter to a port on a switch to lter ingress or egress trac on the switch. When
you congure the rewall lter, you can specify any match condion, acon, and acon modiers
specied in "Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches" on
page 1558. The acon specied in the match condion indicates the acon for the matched packets in
the ingress or egress trac.
To apply a rewall lter to a port to lter ingress or egress trac:
NOTE: For applying a rewall lter to a management interface, see "Applying a Firewall Filter to a
Management Interface on a Switch" on page 1649
1. Specify the interface name and provide a meaningful descripon of the rewall lter and the
interface to which the lter is applied:
[edit interfaces]
user@switch# set ge-0/0/1 description "filter to limit tcp traffic filter at trunk port for
employee-vlan and voice-vlan applied on the interface"
NOTE: Providing the descripon is oponal.
2. Specify the unit number and family address type for the interface:
[edit interfaces]
user@switch# set ge-0/0/1 unit 0 family ethernet-switching
For rewall lters that are applied to ports, the family address type must be ethernet-switching.
1648
3. To apply a rewall lter to lter packets that are entering a port:
[edit interfaces]
user@switch# set ge-0/0/1 unit 0 family ethernet-switching filter input ingress-port-filter
To apply a rewall lter to lter packets that are exing a port:
[edit interfaces]
user@switch# set ge-0/0/1 unit 0 family ethernet-switching filter output egress-port-filter
NOTE: You can apply no more than one rewall lter per port, per direcon.
Applying a Firewall Filter to a Management Interface on a Switch
You can congure and apply a rewall lter to a management interface to control trac that is entering
or exing the interface on a switch. You can use ulies such as SSH or Telnet to connect to the
management interface over the network and then use management protocols such as SNMP to gather
stascal data from the switch. Similar to conguring a rewall lter on other types of interfaces, you
can congure a rewall lter on a management interface using any match condion, acon, and acon
modier specied in "Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series
Switches" on page 1558 except for the following acon modiers:
• loss-priority
• forwarding-class
You can apply a rewall lter to the management Ethernet interface on any EX Series switch. You can
also apply a rewall lter to the virtual management Ethernet (VME) interface on the EX4200 switch.
For more informaon on the management Ethernet interface and the VME interface, see
Interfaces
Overview for Switches
.
To apply a rewall lter on the management interface to lter ingress or egress trac:
1. Specify the interface name and provide a meaningful descripon of the rewall lter and the
interface to which the lter is applied:
[edit interfaces]
user@switch# set me0 description "filter to limit tcp traffic filter at management interface"
1649
NOTE: Providing the descripon is oponal.
2. Specify the unit number and family address type for the management interface:
[edit interfaces]
user@switch# set me0 unit 0 family inet
NOTE: For rewall lters that are applied to management interfaces, the family address type
can be either inet or inet6.
3. To apply a rewall lter to lter packets that are entering a management interface:
[edit interfaces]
user@switch# set me0 unit 0 family inet filter input ingress-port-filter
To apply a rewall lter to lter packets that are exing a management interface:
[edit interfaces]
user@switch# set me0 unit 0 family inet filter output egress-port-filter
NOTE: You can apply no more than one rewall lter per management interface, per
direcon.
Applying a Firewall Filter to a VLAN on a Network
You can apply a rewall lter to a VLAN on a network to lter ingress or egress trac on the network.
To apply a rewall lter to a VLAN, specify the VLAN name and ID, and then apply the rewall lter to
the VLAN. When you congure the rewall lter, you can specify any match condion, acon, and
acon modiers specied in "Firewall Filter Match Condions, Acons, and Acon Modiers for EX
Series Switches" on page 1558. The acon specied in the match condion indicates the acon for the
matched packets in the ingress or egress trac.
To apply a rewall lter to a VLAN:
1650
1. Specify the VLAN name and VLAN ID and provide a meaningful descripon of the rewall lter and
the VLAN to which the lter is applied:
[edit vlans]
user@switch# set employee-vlan vlan-id 20 vlan-description "filter to rate limit traffic
applied on employee-vlan"
NOTE: Providing the descripon is oponal.
2. Apply rewall lters to lter packets that are entering or exing the VLAN:
• To apply a rewall lter to lter packets that are entering the VLAN:
[edit vlans]
user@switch# set employee-vlan vlan-id 20 filter input ingress-vlan-filter
(On EX4300 switches) To apply a rewall lter to lter packets that are entering the VLAN:
[edit vlans]
user@switch# set employee-vlan vlan-id 20 forwarding-options input ingress-vlan-filter
• To apply a rewall lter to lter packets that are exing the VLAN:
[edit vlans]
user@switch# set employee-vlan vlan-id 20 filter output egress-vlan-filter
(On EX4300 switches) To apply a rewall lter to lter packets that are exing the VLAN:
[edit vlans]
user@switch# set employee-vlan vlan-id 20 forwarding-options output egress-vlan-filter
NOTE: You can apply no more than one rewall lter per VLAN, per direcon.
1651
Applying a Firewall Filter to a Layer 3 (Routed) Interface
You can apply a rewall lter to a Layer 3 (routed) interface to lter ingress or egress trac on the
switch. When you congure the rewall lter, you can specify any match condion, acon, and acon
modiers specied in "Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series
Switches" on page 1558. The acon specied in the match condion indicates the acon for the
matched packets in the ingress or egress trac.
To apply a rewall lter to a Layer 3 interface on a switch:
1. Specify the interface name and provide a meaningful descripon of the rewall lter and the
interface to which the lter is applied:
[edit interfaces]
user@switch# set ge-0/1/0 description "filter to count and monitor employee-vlan traffic
applied on layer 3 interface"
NOTE: Providing the descripon is oponal.
2. Specify the unit number, family address type, and address for the interface:
[edit interfaces]
user@switch# set ge-0/1/0 unit 0 family inet address 10.10.10.1/24
For rewall lters applied to Layer 3 interfaces, the family address type must be inet (for IPv4 trac)
or inet6 (for IPv6 trac).
3. You can apply rewall lters to lter packets that are entering or exing a Layer 3 (routed) interface:
• To apply a rewall lter to lter packets that are entering a Layer 3 interface:
[edit interfaces]
user@switch# set ge-0/1/0 unit 0 family inet address 10.10.10.1/24 filter input ingress-
router-filter
• To apply a rewall lter to lter packets that are exing a Layer 3 interface:
[edit interfaces]
user@switch# set ge-0/1/0 unit 0 family inet address 10.10.10.1/24 filter output egress-
router-filter
1652
NOTE: When you apply a lter to an IRB interface associated with a given VLAN, the lter is
executed on any Layer 3 interface with a matching VLAN ID. This is because the lter
matches on all Layer 3 interfaces with the corresponding VLAN tag.
NOTE: You can apply no more than one rewall lter per Layer 3 interface, per direcon.
RELATED DOCUMENTATION
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Example: Conguring a Firewall Filter on a Management Interface on an EX Series Switch | 1684
Verifying That Firewall Filters Are Operaonal | 1869
Monitoring Firewall Filter Trac | 1870
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Understanding How Firewall Filters Test a Packet's Protocol
When examining match condions, Juniper Networks Junos operang system (Junos OS) for Juniper
Networks EX Series Ethernet Switches tests only the eld that is specied. The soware does not
implicitly test the IP header to determine whether a packet is an IP packet. Therefore, in some cases, you
must specify protocol eld match condions in conjuncon with other match condions to ensure that
the lters are performing the expected matches.
If you specify a protocol match condion or a match of the ICMP type or TCP ags eld, there is no
implied protocol match. For the following match condions, you must explicitly specify the protocol
match condion in the same term:
• desnaon-port—Specify the match protocol tcp or protocol udp.
• source-port—Specify the match protocol tcp or protocol udp.
If you do not specify the protocol when using the preceding elds, design your lters carefully to ensure
that they perform the expected matches. For example, if you specify a match of desnaon-port ssh,
the switch determiniscally matches any packets that have a value of 22 in the two-byte eld that is
two bytes beyond the end of the IP header without ever checking the IP protocol eld.
1653
RELATED DOCUMENTATION
Firewall Filters for EX Series Switches Overview | 1539
Understanding Firewall Filter Match Condions | 1547
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Understanding Filter-Based Forwarding for EX Series Switches
Administrators of Juniper Networks EX Series Ethernet Switches can use rewall lters in conjuncon
with virtual roung instances to specify dierent routes for packets to travel in their networks. To set up
this feature, which is called lter-based forwarding, you specify a lter and match criteria and then
specify the virtual roung instance to send packets to.
You might want to use lter-based forwarding to route specic types of trac through a rewall or
security device before the trac connues on its path. You can also use lter-based forwarding to give
certain types of trac preferenal treatment or to improve load balancing of switch trac.
RELATED DOCUMENTATION
Understanding Virtual Roung Instances on EX Series Switches
Firewall Filters for EX Series Switches Overview | 1539
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac
on EX Series Switches
IN THIS SECTION
Requirements | 1655
Overview | 1655
Conguring an Ingress Port Firewall Filter to Priorize Voice Trac and Rate-Limit TCP and ICMP
Trac | 1660
Conguring a VLAN Ingress Firewall Filter to Prevent Rogue Devices from Disrupng VoIP Trac | 1668
1654
Conguring a VLAN Firewall Filter to Count, Monitor, and Analyze Egress Trac on the Employee
VLAN | 1672
Conguring a VLAN Firewall Filter to Restrict Guest-to-Employee Trac and Peer-to-Peer Applicaons on
the Guest VLAN | 1675
Conguring a Router Firewall Filter to Give Priority to Egress Trac Desned for the Corporate
Subnet | 1678
Vericaon | 1680
This example shows how to congure and apply rewall lters to control trac that is entering or
exing a port on the switch, a VLAN on the network, and a Layer 3 interface on the switch. Firewall
lters dene the rules that determine whether to forward or deny packets at specic processing points
in the packet ow.
Requirements
This example uses the following soware and hardware components:
• Junos OS Release 9.0 or later for EX Series switches.
• Two Juniper Networks EX3200-48T switches: one to be used as an access switch, the other to be
used as a distribuon switch
• One Juniper Networks EX-UM-4SFP uplink module
• One Juniper Networks J-series router
Before you congure and apply the rewall lters in this example, be sure you have:
• An understanding of rewall lter concepts, policers, and CoS
• Installed the uplink module in the distribuon switch. See Installing an Uplink Module in an EX3200
Switch.
Overview
IN THIS SECTION
Network Topology | 1658
1655
This conguraon example show how to congure and apply rewall lters to provide rules to evaluate
the contents of packets and determine when to discard, forward, classify, count, and analyze packets
that are desned for or originang from the EX Series switches that handle all voice-vlan, employee-vlan,
and guest-vlan trac. Table 91 on page 1656 shows the rewall lters that are congured for the EX
Series switches in this example.
Table 91: Conguraon Components: Firewall Filters
Component Purpose/Descripon
Port rewall lter,
ingress-port-voip-
class-limit-tcp-icmp
This rewall lter performs two funcons:
• Assigns priority queueing to packets with a source MAC address that matches the
phone MAC addresses. The forwarding class expedited-forwarding provides low loss,
low delay, low jier, assured bandwidth, and end-to-end service for all voice-vlan
trac.
• Performs rate liming on packets that enter the ports for employee-vlan. The trac
rate for TCP and ICMP packets is limited to 1 Mbps with a burst size up to 30,000
bytes.
This rewall lter is applied to port interfaces on the access switch.
VLAN rewall lter,
ingress-vlan-rogue-
block
Prevents rogue devices from using HTTP sessions to mimic the gatekeeper device that
manages call registraon, admission, and call status for VoIP calls. Only TCP or UDP
ports should be used; and only the gatekeeper uses HTTP. That is, all voice-vlan trac
on TCP ports should be desned for the gatekeeper device. This rewall lter applies to
all phones on voice-vlan, including communicaon between any two phones on the
VLAN and all communicaon between the gatekeeper device and VLAN phones.
This rewall lter is applied to VLAN interfaces on the access switch.
VLAN rewall lter,
egress-vlan-watch-
employee
Accepts employee-vlan trac desned for the corporate subnet, but does not monitor
this trac. Employee trac desned for the Web is counted and analyzed.
This rewall lter is applied to vlan interfaces on the access switch.
VLAN rewall lter,
ingress-vlan-limit-
guest
Prevents guests (non-employees) from talking with employees or employee hosts on
employee-vlan. Also prevents guests from using peer-to-peer applicaons on guest-vlan,
but allows guests to access the Web.
This rewall lter is applied to VLAN interfaces on the access switch.
1656
Table 91: Conguraon Components: Firewall Filters
(Connued)
Component Purpose/Descripon
Router rewall lter,
egress-router-corp-
class
Priorizes employee-vlan trac, giving highest forwarding-class priority to employee
trac desned for the corporate subnet.
This rewall lter is applied to a routed port (Layer 3 uplink module) on the distribuon
switch.
Figure 72 on page 1657 shows the applicaon of port, VLAN, and Layer 3 routed rewall lters on the
switch.
Figure 72: Applicaon of Port, VLAN, and Layer 3 Routed Firewall Filters
1657
Network Topology
The topology for this conguraon example consists of one EX-3200-48T switch at the access layer,
and one EX-3200-48T switch at the distribuon layer. The distribuon switch's uplink module is
congured to support a Layer 3 connecon to a J-series router.
The EX Series switches are congured to support VLAN membership. Table 92 on page 1658 shows the
VLAN conguraon components for the VLANs.
Table 92: Conguraon Components: VLANs
VLAN Name VLAN ID VLAN Subnet and
Available IP Addresses
VLAN Descripon
voice-vlan 10 192.0.2.0/28
192.0.2.1through
192.0.2.14
192.0.2.15 is the subnet’s
broadcast address
Voice VLAN used for
employee VoIP trac
employee-vlan 20 192.0.2.16/28 192.0.2.17
through 192.0.2.30
192.0.2.31 is the subnet’s
broadcast address
VLAN standalone PCs,
PCs connected to the
network through the hub
in VoIP telephones,
wireless access points,
and printers. This VLAN
completely includes the
voice VLAN. Two VLANs
(voice-vlan and employee-
vlan) must be congured
on the ports that connect
to the telephones.
1658
Table 92: Conguraon Components: VLANs
(Connued)
VLAN Name VLAN ID VLAN Subnet and
Available IP Addresses
VLAN Descripon
guest-vlan 30 192.0.2.32/28 192.0.2.33
through 192.0.2.46
192.0.2.47 is the subnet’s
broadcast address
VLAN for guests’ data
devices (PCs). The
scenario assumes that the
corporaon has an area
open to visitors, either in
the lobby or in a
conference room, that has
a hub to which visitors
can plug in their PCs to
connect to the Web and
to their company’s VPN.
camera-vlan 40 192.0.2.48/28 192.0.2.49
through 192.0.2.62
192.0.2.63 is the subnet’s
broadcast address
VLAN for the corporate
security cameras.
Ports on the EX Series switches support Power over Ethernet (PoE) to provide both network
connecvity and power for VoIP telephones connecng to the ports. Table 93 on page 1659 shows the
switch ports that are assigned to the VLANs and the IP and MAC addresses for devices connected to
the switch ports:
Table 93:
Conguraon Components: Switch Ports on a 48-Port All-PoE Switch
Switch and Port Number VLAN Membership IP and MAC Addresses Port Devices
ge-0/0/0, ge-0/0/1
voice-vlan, employee-vlan IP addresses: 192.0.2.1
through 192.0.2.2
MAC addresses:
00.00.5E.00.53.01,
00.00.5E.00.53.02
Two VoIP telephones,
each connected to one
PC.
ge-0/0/2, ge-0/0/3
employee-vlan 192.0.2.17 through
192.0.2.18
Printer, wireless access
points
1659
Table 93: Conguraon Components: Switch Ports on a 48-Port All-PoE Switch
(Connued)
Switch and Port Number VLAN Membership IP and MAC Addresses Port Devices
ge-0/0/4, ge-0/0/5
guest-vlan 192.0.2.34 through
192.0.2.35
Two hubs into which
visitors can plug in their
PCs. Hubs are located in
an area open to visitors,
such as a lobby or
conference room
ge-0/0/6, ge-0/0/7
camera-vlan 192.0.2.49 through
192.0.2.50
Two security cameras
ge-0/0/9
voice-vlan IP address: 192.0.2.14
MAC
address:00.05.5E.00.53.0E
Gatekeeper device. The
gatekeeper manages call
registraon, admission,
and call status for VoIP
phones.
ge-0/1/0
IP address: 192.0.2.65
Layer 3 connecon to a
router; note that this is a
port on the switch’s
uplink module
Conguring an Ingress Port Firewall Filter to Priorize Voice Trac and Rate-Limit
TCP and ICMP Trac
IN THIS SECTION
Procedure | 1661
To congure and apply rewall lters for port, VLAN, and router interfaces, perform these tasks:
1660
Procedure
CLI Quick Conguraon
To quickly congure and apply a port rewall lter to priorize voice trac and rate-limit packets that
are desned for the employee-vlan subnet, copy the following commands and paste them into the switch
terminal window:
[edit]
set firewall policer tcp-connection-policer if-exceeding burst-size-
limit 30k bandwidth-limit 1m
set firewall policer tcp-connection-policer then
discard
set firewall policer icmp-connection-policer if-exceeding burst-size-
limit 30k bandwidth-limit 1m
set firewall policer icmp-connection-policer then
discard
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term voip-high from source-mac-address 00.00.5E.00.53.01
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term voip-high from source-mac-address 00.00.5E.00.53.02
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term voip-high from protocol udp
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term voip-high then forwarding-class expedited-forwarding
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term voip-high then loss-priority low
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term network-control from precedence net-control
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term network-control then forwarding-class network-control
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term network-control then loss-priority low
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term tcp-connection from destination-address 192.0.2.16/28
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term tcp-connection from protocol tcp
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term tcp-connection then policer tcp-connection-policer
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term tcp-connection then count tcp-counter
set firewall family ethernet-switching filter ingress-port-voip-class-
1661
limit-tcp-icmp term tcp-connection then forwarding-class best-effort
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term tcp-connection then loss-priority high
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term icmp-connection from destination-address 192.0.2.16/28
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term icmp-connection from protocol icmp
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term icmp-connection then policer icmp-connection-policer
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term icmp-connection then count icmp-counter
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term icmp-connection then forwarding-class best-effort
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term icmp-connection then loss-priority high
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term best-effort then forwarding-class best-effort
set firewall family ethernet-switching filter ingress-port-voip-class-
limit-tcp-icmp term best-effort then loss-priority high
set interfaces ge-0/0/0 description "voice priority and tcp and icmp
traffic rate-limiting filter at ingress port"
set interfaces ge-0/0/0 unit 0 family ethernet-switching filter input
ingress-port-voip-class-limit-tcp-icmp
set interfaces ge-0/0/1 description "voice priority and tcp and icmp
traffic rate-limiting filter at ingress port"
set interfaces ge-0/0/1 unit 0 family ethernet-switching filter input
ingress-port-voip-class-limit-tcp-icmp
set class-of-service schedulers voice-high buffer-size percent
15
set class-of-service schedulers voice-high priority
high
set class-of-service schedulers net-control buffer-size percent
10
set class-of-service schedulers net-control priority
high
set class-of-service schedulers best-effort buffer-size percent
75
set class-of-service schedulers best-effort priority
low
set class-of-service scheduler-maps ethernet-diffsrv-cos-map forwarding-
class expedited-forwarding scheduler voice-high
set class-of-service scheduler-maps ethernet-diffsrv-cos-map forwarding-
class network-control scheduler net-control
1662
set class-of-service scheduler-maps ethernet-diffsrv-cos-map forwarding-
class best-effort scheduler best-effort
Step-by-Step Procedure
To congure and apply a port rewall lter to priorize voice trac and rate-limit packets that are
desned for the employee-vlan subnet:
1. Dene the policers tcp-connection-policer and icmp-connection-policer:
[edit]
user@switch# set firewall policer tcp-connection-policer if-exceeding burst-size-limit 30k
bandwidth-limit 1m
user@switch# set firewall policer tcp-connection-policer then discard
user@switch# set firewall policer icmp-connection-policer if-exceeding burst-size-limit 30k
bandwidth-limit 1m
user@switch# set firewall policer icmp-connection-policer then
discard
2. Dene the rewall lter ingress-port-voip-class-limit-tcp-icmp:
[edit firewall]
user@switch# set family ethernet-switching filter ingress-port-voip-class-limit-tcp-
icmp
3. Dene the term voip-high:
[edit firewall family ethernet-switching filter ingress-port-voip-class-limit-tcp-icmp ]
user@switch# set term voip-high from source-mac-address 00.00.5E.00.53.01
user@switch# set term voip-high from source-mac-address 00.00.5E.00.53.02
user@switch# set term voip-high from protocol udp
user@switch# set term voip-high then forwarding-class expedited-forwarding
user@switch# set term voip-high then loss-priority low
4.
Dene the term network-control:
[edit firewall family ethernet-switching filter ingress-port-voip-class-limit-tcp-icmp ]
user@switch# set term network-control from precedence net-control
1663
user@switch# set term network-control then forwarding-class network-control
user@switch# set term network-control then loss-priority low
5. Dene the term tcp-connection to congure rate limits for TCP trac:
[edit firewall family ethernet-switching filter ingress-port-voip-class-limit-tcp-icmp]
user@switch# set term tcp-connection from destination-address 192.0.2.16/28
user@switch# set term tcp-connection from protocol tcp
user@switch# set term tcp-connection then policer tcp-connection-policer
user@switch# set term tcp-connection then count tcp-counter
user@switch# set term tcp-connection then forwarding-class best-effort
user@switch# set term tcp-connection then loss-priority high
6. Dene the term icmp-connection to congure rate limits for ICMP trac:
[edit firewall family ethernet-switching filter ingress-port-voip-class-limit-tcp-icmp]
user@switch# set term icmp-connection from destination-address 192.0.2.16/28
user@switch# set term icmp-connection from protocol icmp
user@switch# set term icmp-connection then policer icmp-policer
user@switch# set term icmp-connection then count icmp-counter
user@switch# set term icmp-connection then forwarding-class best-effort
user@switch# set term icmp-connection then loss-priority high
7. Dene the term best-effort with no match condions for an implicit match on all packets that did
not match any other term in the rewall lter:
[edit firewall family ethernet-switching filter ingress-port-voip-class-limit-tcp-icmp]
user@switch# set term best-effort then forwarding-class best-effort
user@switch# set term best-effort then loss-priority high
8. Apply the rewall lter ingress-port-voip-class-limit-tcp-icmp as an input lter to the port interfaces
for employee-vlan:
[edit interfaces]
user@switch# set ge-0/0/0 description "voice priority and tcp and icmp traffic rate-
limiting filter at ingress port"
user@switch# set ge-0/0/0 unit 0 family ethernet-switching filter input ingress-port-voip-
class-limit-tcp-icmp
user@switch# set ge-0/0/1 description "voice priority and tcp and icmp traffic rate-
1664
limiting filter at ingress port"
user@switch# set ge-0/0/1 unit 0 family ethernet-switching filter input ingress-port-voip-
class-limit-tcp-icmp
9. Congure the parameters that are desired for the dierent schedulers.
NOTE: When you congure parameters for the schedulers, dene the numbers to match
your network trac paerns.
[edit class-of-service]
user@switch# set schedulers voice-high buffer-size percent 15
user@switch# set schedulers voice-high priority high
user@switch# set schedulers network—control buffer-size percent 10
user@switch# set schedulers network—control priority high
user@switch# set schedulers best-effort buffer-size percent 75
user@switch# set schedulers best-effort priority low
10. Assign the forwarding classes to schedulers with a scheduler map:
[edit class-of-service]
user@switch# set scheduler-maps ethernet-diffsrv-cos-map
user@switch# set scheduler-maps ethernet-diffsrv-cos-map forwarding-class expedited-
forwarding scheduler voice-high
user@switch# set scheduler-maps ethernet-diffsrv-cos-map forwarding-class network-control
scheduler net-control
user@switch# set scheduler-maps ethernet-diffsrv-cos-map forwarding-class best-effort
scheduler best-effort
11. Associate the scheduler map with the outgoing interface:
[edit class-of-service]
user@switch# set interfaces ge–0/1/0 scheduler-map ethernet-diffsrv-cos-
map
1665
Results
Display the results of the conguraon:
user@switch# show
firewall {
policer tcp-connection-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 30k;
}
then {
discard;
}
}
policer icmp-connection-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 30k;
}
then {
discard;
}
}
family ethernet-switching {
filter ingress-port-voip-class-limit-tcp-icmp {
term voip-high {
from {
destination-mac-address 00.00.5E.00.53.01;
destination-mac-address 00.00.5E.00.53.02;
protocol udp;
}
then {
forwarding-class expedited-forwarding;
loss-priority low;
}
}
term network-control {
from {
precedence net-control ;
}
then {
1666
forwarding-class network-control;
loss-priority low;
}
}
term tcp-connection {
from {
destination-address 192.0.2.16/28;
protocol tcp;
}
then {
policer tcp-connection-policer;
count tcp-counter;
forwarding-class best-effort;
loss-priority high;
}
}
term icmp-connection
from {
protocol icmp;
}
then {
policer icmp-connection-policer;
count icmp-counter;
forwarding-class best-effort;
loss-priority high;
}
}
term best-effort {
then {
forwarding-class best-effort;
loss-priority high;
}
}
}
}
}
interfaces {
ge-0/0/0 {
description "voice priority and tcp and icmp traffic rate-limiting filter at ingress
port";
unit 0 {
family ethernet-switching {
filter {
1667
input ingress-port-voip-class-limit-tcp-icmp;
}
}
}
}
ge-0/0/1 {
description "voice priority and tcp and icmp traffic rate-limiting filter at ingress
port";
unit 0 {
family ethernet-switching {
filter {
input ingress-port-voip-class-limit-tcp-icmp;
}
}
}
}
}
scheduler-maps {
ethernet-diffsrv-cos-map {
forwarding-class expedited-forwarding scheduler voice-high;
forwarding-class network-control scheduler net-control;
forwarding-class best-effort scheduler best-effort;
}
}
interfaces {
ge/0/1/0 {
scheduler-map ethernet-diffsrv-cos-map;
}
}
Conguring a VLAN Ingress Firewall Filter to Prevent Rogue Devices from Disrupng
VoIP Trac
IN THIS SECTION
Procedure | 1669
To congure and apply rewall lters for port, VLAN, and router interfaces, perform these tasks:
1668
Procedure
CLI Quick Conguraon
To quickly congure a VLAN rewall lter on voice-vlan to prevent rogue devices from using HTTP
sessions to mimic the gatekeeper device that manages VoIP trac, copy the following commands and
paste them into the switch terminal window:
[edit]
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term to-gatekeeper from destination-address 192.0.2.14
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term to-gatekeeper from destination-port 80
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term to-gatekeeper then accept
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term from-gatekeeper from source-address 192.0.2.14
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term from-gatekeeper from source-port 80
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term from-gatekeeper then accept
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term not-gatekeeper from destination-port 80
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term not-gatekeeper then count rogue-counter
set firewall family ethernet-switching filter ingress-vlan-rogue-block
term not-gatekeeper then discard
set vlans voice-vlan description "block rogue devices on voice-
vlan"
set vlans voice-vlan filter input ingress-vlan-rogue-
block
Step-by-Step Procedure
To congure and apply a VLAN rewall lter on voice-vlan to prevent rogue devices from using HTTP to
mimic the gatekeeper device that manages VoIP trac:
1669
1. Dene the rewall lter ingress-vlan-rogue-block to specify lter matching on the trac you want to
permit and restrict:
[edit firewall]
user@switch# set family ethernet-switching filter ingress-vlan-rogue-
block
2.
Dene the term to-gatekeeper to accept packets that match the desnaon IP address of the
gatekeeper:
[edit firewall family ethernet-switching filter ingress-vlan-rogue-block]
user@switch# set term to-gatekeeper from destination-address 192.0.2.14
user@switch# set term to-gatekeeper from destination-port 80
user@switch# set term to-gatekeeper then accept
3. Dene the term from-gatekeeper to accept packets that match the source IP address of the gatekeeper:
[edit firewall family ethernet-switching filter ingress-vlan-rogue-block]
user@switch# set term from-gatekeeper from source-address 192.0.2.14
user@switch# set term from-gatekeeper from source-port 80
user@switch# set term from-gatekeeper then accept
4. Dene the term not-gatekeeper to ensure all voice-vlan trac on TCP ports is desned for the
gatekeeper device:
[edit firewall family ethernet-switching filter ingress-vlan-rogue-block]
user@switch# set term not-gatekeeper from destination-port 80
user@switch# set term not-gatekeeper then count rogue-counter
user@switch# set term not-gatekeeper then discard
5. Apply the rewall lter ingress-vlan-rogue-block as an input lter to the VLAN interface for the VoIP
telephones:
[edit]
user@switch# set vlans voice-vlan description "block rogue devices on voice-vlan"
user@switch# set vlans voice-vlan filter input ingress-vlan-rogue-block
1670
Results
Display the results of the conguraon:
user@switch# show
firewall {
family ethernet-switching {
filter ingress-vlan-rogue-block {
term to-gatekeeper {
from {
destination-address 192.0.2.14/32
destination-port 80;
}
then {
accept;
}
}
term from-gatekeeper {
from {
source-address 192.0.2.14/32
source-port 80;
}
then {
accept;
}
}
term not-gatekeeper {
from {
destination-port 80;
}
then {
count rogue-counter;
discard;
}
}
}
vlans {
voice-vlan {
description "block rogue devices on voice-vlan";
filter {
input ingress-vlan-rogue-block;
}
1671
}
}
Conguring a VLAN Firewall Filter to Count, Monitor, and Analyze Egress Trac on
the Employee VLAN
IN THIS SECTION
Procedure | 1672
To
congure and apply rewall lters for port, VLAN, and router interfaces, perform these tasks:
Procedure
CLI Quick Conguraon
A rewall lter is congured and applied to VLAN interfaces to lter employee-vlan egress trac.
Employee trac desned for the corporate subnet is accepted but not monitored. Employee trac
desned for the Web is counted and analyzed.
To quickly congure and apply a VLAN rewall lter, copy the following commands and paste them into
the switch terminal window:
[edit]
set firewall family ethernet-switching filter egress-vlan-watch-
employee term employee-to-corp from destination-address 192.0.2.16/28
set firewall family ethernet-switching filter egress-vlan-watch-
employee term employee-to-corp then accept
set firewall family ethernet-switching filter egress-vlan-watch-
employee term employee-to-web from destination-port 80
set firewall family ethernet-switching filter egress-vlan-watch-
employee term employee-to-web then count employee-web-counter
set firewall family ethernet-switching filter egress-vlan-watch-
employee term employee-to-web then analyzer employee-monitor
set vlans employee-vlan description "filter at egress VLAN to count and
analyze employee to Web traffic"
set vlans employee-vlan filter output egress-vlan-watch-
employee
1672
Step-by-Step Procedure
To congure and apply an egress port rewall lter to count and analyze employee-vlan trac that is
desned for the Web:
1. Dene the rewall lter egress-vlan-watch-employee:
[edit firewall]
user@switch# set family ethernet-switching filter egress-vlan-watch-
employee
2. Dene the term employee-to-corp to accept but not monitor all employee-vlan trac desned for the
corporate subnet:
[edit firewall family ethernet-switching filter egress-vlan-watch-employee]
user@switch# set term employee-to-corp from destination-address 192.0.2.16/28
user@switch# set term employee-to-corp then accept
3. Dene the term employee-to-web to count and monitor all employee-vlan trac desned for the Web:
[edit firewall family ethernet-switching filter egress-vlan-watch-employee]
user@switch# set term employee-to-web from destination-port 80
user@switch# set term employee-to-web then count employee-web-counter
user@switch# set term employee-to-web then analyzer employee-monitor
NOTE: See Example: Conguring Port Mirroring for Local Monitoring of Employee Resource
Use on EX Series Switches for informaon about conguring the employee-monitor analyzer.
4. Apply the rewall lter egress-vlan-watch-employee as an output lter to the port interfaces for the VoIP
telephones:
[edit]
user@switch# set vlans employee-vlan description "filter at egress VLAN to count and analyze
employee to Web traffic"
user@switch# set vlans employee-vlan filter output egress-vlan-watch-
employee
1673
Results
Display the results of the conguraon:
user@switch# show
firewall {
family ethernet-switching {
filter egress-vlan-watch-employee {
term employee-to-corp {
from {
destination-address 192.0.2.16/28
}
then {
accept;
}
}
term employee-to-web {
from {
destination-port 80;
}
then {
count employee-web-counter:
analyzer employee-monitor;
}
}
}
}
}
vlans {
employee-vlan {
description "filter at egress VLAN to count and analyze employee to Web traffic";
filter {
output egress-vlan-watch-employee;
}
}
}
1674
Conguring a VLAN Firewall Filter to Restrict Guest-to-Employee Trac and Peer-to-
Peer Applicaons on the Guest VLAN
IN THIS SECTION
Procedure | 1675
To congure and apply rewall lters for port, VLAN, and router interfaces, perform these tasks:
Procedure
CLI Quick Conguraon
In the following example, the rst lter term permits guests to talk with other guests but not employees
on employee-vlan. The second lter term allows guests Web access but prevents them from using peer-to-
peer applicaons on guest-vlan.
To quickly congure a VLAN rewall lter to restrict guest-to-employee trac, blocking guests from
talking with employees or employee hosts on employee-vlan or aempng to use peer-to-peer
applicaons on guest-vlan, copy the following commands and paste them into the switch terminal
window:
[edit]
set firewall family ethernet-switching filter ingress-vlan-limit-guest
term guest-to-guest from destination-address 192.0.2.33/28
set firewall family ethernet-switching filter ingress-vlan-limit-guest
term guest-to-guest then accept
set firewall family ethernet-switching filter ingress-vlan-limit-guest
term no-guest-employee-no-peer-to-peer from destination-mac-address
00.05.5E.00.00.DF
set firewall family ethernet-switching filter ingress-vlan-limit-guest
term no-guest-employee-no-peer-to-peer then accept
set vlans guest-vlan description "restrict guest-to-employee traffic
and peer-to-peer applications on guest VLAN"
set vlans guest-vlan forwarding-options filter input ingress-vlan-limit-
guest
1675
Step-by-Step Procedure
To congure and apply a VLAN rewall lter to restrict guest-to-employee trac and peer-to-peer
applicaons on guest-vlan:
1. Dene the rewall lter ingress-vlan-limit-guest:
[edit firewall]
set firewall family ethernet-switching filter ingress-vlan-limit-
guest
2. Dene the term guest-to-guest to permit guests on the guest-vlan to talk with other guests but not
employees on the employee-vlan:
[edit firewall family ethernet-switching filter ingress-vlan-limit-guest]
user@switch# set term guest-to-guest from destination-address 192.0.2.33/28
user@switch# set term guest-to-guest then accept
3. Dene the term no-guest-employee-no-peer-to-peer to allow guests on guest-vlan Web access but prevent
them from using peer-to-peer applicaons on the guest-vlan.
NOTE: The destination-mac-address is the default gateway, which for any host in a VLAN is the
next-hop router.
[edit firewall family ethernet-switching filter ingress-vlan-limit-guest]
user@switch# set term no-guest-employee-no-peer-to-peer from destination-mac-address
00.05.5E.00.00.DF
user@switch# set term no-guest-employee-no-peer-to-peer then accept
4. Apply the rewall lter ingress-vlan-limit-guest as an input lter to the interface for guest-vlan :
[edit]
user@switch# set vlans guest-vlan description "restrict guest-to-employee traffic and peer-to-
peer applications on guest VLAN"
user@switch# set vlans guest-vlan forwarding-options filter input ingress-vlan-limit-
guest
1676
Results
Display the results of the conguraon:
user@switch# show
firewall {
family ethernet-switching {
filter ingress-vlan-limit-guest {
term guest-to-guest {
from {
destination-address 192.0.2.33/28;
}
then {
accept;
}
}
term no-guest-employee-no-peer-to-peer {
from {
destination-mac-address 00.05.5E.00.00.DF;
}
then {
accept;
}
}
}
}
}
vlans {
guest-vlan {
description "restrict guest-to-employee traffic and peer-to-peer applications on
guest VLAN";
filter {
input ingress-vlan-limit-guest;
}
}
}
1677
Conguring a Router Firewall Filter to Give Priority to Egress Trac Desned for the
Corporate Subnet
IN THIS SECTION
Procedure | 1678
To congure and apply rewall lters for port, VLAN, and router interfaces, perform these tasks:
Procedure
CLI Quick Conguraon
To quickly congure a rewall lter for a routed port (Layer 3 uplink module) to lter employee-vlan trac,
giving highest forwarding-class priority to trac desned for the corporate subnet, copy the following
commands and paste them into the switch terminal window:
[edit]
set firewall family inet filter egress-router-corp-class term corp-
expedite from destination-address 192.0.2.16/28
set firewall family inet filter egress-router-corp-class term corp-
expedite then forwarding-class expedited-forwarding
set firewall family inet filter egress-router-corp-class term corp-
expedite then loss-priority low
set firewall family inet filter egress-router-corp-class term not-to-
corp then accept
set interfaces ge-0/1/0 description "filter at egress router to
expedite destined for corporate network"
set ge-0/1/0 unit 0 family inet address 203.0.113.0
set interfaces ge-0/1/0 unit 0 family inet filter output egress-router-
corp-class
Step-by-Step Procedure
To congure and apply a rewall lter to a routed port (Layer 3 uplink module) to give highest priority to
employee-vlan trac desned for the corporate subnet:
1678
1. Dene the rewall lter egress-router-corp-class:
[edit]
user@switch# set firewall family inet filter egress-router-corp-class
2. Dene the term corp-expedite:
[edit firewall]
user@switch# set family inet filter egress-router-corp-class term corp-expedite from
destination-address 192.0.2.16/28
user@switch# set family inet filter egress-router-corp-class term corp-expedite then
forwarding-class expedited-forwarding
user@switch# set family inet filter egress-router-corp-class term corp-expedite then loss-
priority low
3.
Dene the term not-to-corp:
[edit firewall]
user@switch# set family inet filter egress-router-corp-class term not-to-corp then
accept
4. Apply the rewall lter egress-router-corp-class as an output lter for the port on the switch's uplink
module, which provides a Layer 3 connecon to a router:
[edit interfaces]
user@switch# set ge-0/1/0 description "filter at egress router to expedite employee traffic
destined for corporate network"
user@switch# set ge-0/1/0 unit 0 family inet address 203.0.113.0
user@switch# set ge-0/1/0 unit 0 family inet filter output egress-router-corp-
class
Results
Display the results of the conguraon:
user@switch# show
firewall {
1679
family inet {
filter egress-router-corp-class {
term corp-expedite {
from {
destination-address 192.0.2.16/28;
}
then {
forwarding-class expedited-forwarding;
loss-priority low;
}
}
term not-to-corp {
then {
accept;
}
}
}
}
}
interfaces {
ge-0/1/0 {
unit 0 {
description "filter at egress router interface to expedite employee traffic
destined for corporate network";
family inet {
source-address 203.0.113.0
filter {
output egress-router-corp-class;
}
}
}
}
}
Vericaon
IN THIS SECTION
Verifying that Firewall Filters and Policers are Operaonal | 1681
Verifying that Schedulers and Scheduler-Maps are Operaonal | 1682
1680
To conrm that the rewall lters are working properly, perform the following tasks:
Verifying that Firewall Filters and Policers are Operaonal
Purpose
Verify the operaonal state of the rewall lters and policers that are congured on the switch.
Acon
Use the operaonal mode command:
user@switch> show
firewall
Filter: ingress-port-voip-class-limit-tcp-icmp
Counters:
Name Packets
icmp-counter 0
tcp-counter 0
Policers:
Name Packets
icmp-connection-policer 0
tcp-connection-policer 0
Filter: ingress-vlan-rogue-block
Filter: egress-vlan-watch-employee
Counters:
Name Packets
employee-web—counter 0
Meaning
The show firewall command displays the names of the rewall lters, policers, and counters that are
congured on the switch. The output elds show byte and packet counts for all congured counters and
the packet count for all policers.
1681
Verifying that Schedulers and Scheduler-Maps are Operaonal
Purpose
Verify that schedulers and scheduler-maps are operaonal on the switch.
Acon
Use the operaonal mode command:
user@switch> show class-of-service scheduler-
map
Scheduler map: default, Index: 2
Scheduler: default-be, Forwarding class: best-effort, Index: 20
Transmit rate: 95 percent, Rate Limit: none, Buffer size: 95 percent,
Priority: low
Drop profiles:
Loss priority Protocol Index Name
Low non-TCP 1 default-drop-profile
Low TCP 1 default-drop-profile
High non-TCP 1 default-drop-profile
High TCP 1 default-drop-profile
Scheduler: default-nc, Forwarding class: network-control, Index: 22
Transmit rate: 5 percent, Rate Limit: none, Buffer size: 5 percent,
Priority: low
Drop profiles:
Loss priority Protocol Index Name
Low non-TCP 1 default-drop-profile
Low TCP 1 default-drop-profile
High non-TCP 1 default-drop-profile
High TCP 1 default-drop-profileScheduler map: ethernet-diffsrv-
cos-map, Index: 21657
Scheduler: best-effort, Forwarding class: best-effort, Index: 61257
Transmit rate: remainder, Rate Limit: none, Buffer size: 75 percent,
Priority: low
Drop profiles:
Loss priority Protocol Index Name
Low non-TCP 1 <default-drop-profile>
1682
Low TCP 1 <default-drop-profile>
High non-TCP 1 <default-drop-profile>
High TCP 1 <default-drop-profile>
Scheduler: voice-high, Forwarding class: expedited-forwarding, Index: 3123
Transmit rate: remainder, Rate Limit: none, Buffer size: 15 percent,
Priority: high
Drop profiles:
Loss priority Protocol Index Name
Low non-TCP 1 <default-drop-profile>
Low TCP 1 <default-drop-profile>
High non-TCP 1 <default-drop-profile>
High TCP 1 <default-drop-profile>
Scheduler: net-control, Forwarding class: network-control, Index: 2451
Transmit rate: remainder, Rate Limit: none, Buffer size: 10 percent,
Priority: high
Drop profiles:
Loss priority Protocol Index Name
Low non-TCP 1 <default-drop-profile>
Low TCP 1 <default-drop-profile>
High non-TCP 1 <default-drop-profile>
High TCP 1 <default-drop-profile>
Meaning
Displays stascs about the congured schedulers and schedulers-maps.
RELATED DOCUMENTATION
Example: Conguring CoS on EX Series Switches
Conguring Firewall Filters (CLI Procedure) | 1642
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
1683
Example: Conguring a Firewall Filter on a Management Interface on an
EX Series Switch
IN THIS SECTION
Requirements | 1684
Overview and Topology | 1684
Conguraon | 1685
Vericaon | 1688
You can
congure a rewall lter on a management interface on an EX Series switch to lter ingress or
egress trac on the management interface on the switch. You can use ulies such as SSH or Telnet to
connect to the management interface over the network and then use management protocols such as
SNMP to gather stascal data from the switch.
This example discusses how to congure a rewall lter on a management interface to lter SSH packets
egressing from an EX Series switch:
Requirements
This example uses the following hardware and soware components:
• One EX Series switch and one management PC
• Junos OS Release 10.4 or later for EX Series switches
Overview and Topology
IN THIS SECTION
Topology | 1685
1684
Topology
In this example, a management PC establishes an SSH connecon with the management interface on a
switch to remotely manage the switch. The IP address congured for the management interface is
10.204.33.103/20. A rewall lter is congured on the management interface to count the number of
packets egressing from a source SSH port on the management interface. When the management PC
establishes the SSH session with the management interface, the management interface returns SSH
packets to the management PC to conrm that the session is established. These SSH packets are ltered
based on the match condion specied in the rewall lter before they are forwarded to the
management PC. As these packets are generated from the source SSH port on the management
interface, they fulll the match condion specied for the management interface. The number of
matched SSH packets provides a count of the number of packets that have traversed the management
interface. A system administrator can use this informaon to monitor the management trac and take
any acon if required.
Figure 73 on page 1685 shows the topology for this example in which a management PC establishes an
SSH connecon with the switch.
Figure 73: SSH Connecon From a Management PC to an EX Series Switch
Conguraon
IN THIS SECTION
| 1686
To congure a rewall lter on a management interface, perform these tasks:
1685
CLI Quick Conguraon
To quickly create and congure a rewall lter on the management interface to lter SSH packets
egressing from the management interface, copy the following commands and paste them into the switch
terminal window:
[edit]
set firewall family inet filter mgmt_fil1 term t1 from source-port ssh
set firewall family inet filter mgmt_fil1 term t1 then count c1
set firewall family inet filter mgmt_fil1 term t2 then accept
set interfaces me0 unit 0 family inet filter output mgmt_fil1
Step-by-Step Procedure
To congure a rewall lter on the management interface to lter SSH packets:
1. Congure the rewall lter that matches SSH packets from the source port:
[edit]
user@switch# set firewall family inet filter (Firewall Filters) mgmt_fil1 term t1 from source-
port ssh
user@switch# set firewall family inet filter mgmt_fil1 term t1 then count c1
user@switch# set firewall family inet filter mgmt_fil1 term t2 then accept
These statements set a counter c1 to count the number of SSH packets that egress from the source
SSH interface on the management interface.
2. Set the rewall lter for the management interface:
[edit]
user@switch# set interfaces me0 unit 0 family inet filter output mgmt_fil1
NOTE: You can also set the rewall lter for a VME interface.
1686
Results
Check the results of the conguraon:
[edit]
user@switch# show
interfaces {
me0 {
unit 0 {
family inet {
filter {
output mgmt_fil1;
}
address 10.93.54.6/24;
}
}
}
}
firewall {
family inet {
filter mgmt_fil1{
term t1 {
from {
source-port ssh;
then count c1;
}
}
term t2 {
then accept;
}
}
}
}
1687
Vericaon
IN THIS SECTION
Verifying That the Firewall Filter Is Congured on a Management Interface | 1688
To conrm that the conguraon is working properly, perform these tasks:
Verifying That the Firewall Filter Is Congured on a Management Interface
Purpose
Verify that the rewall lter has been enabled on the management interface on the switch.
Acon
1. Verify that the rewall lter is applied to the management interface:
[edit]
user@switch# show interfaces me0
unit 0 {
family inet {
filter {
output mgmt_fil1;
}
address 10.204.33.103/20;
}
}
2. Check the counter value that is associated with the rewall lter:
user@switch> show firewall
Filter: mgmt_fil1
Counters:
Name Bytes Packets
c1 0 0
1688
3. From the management PC, establish a secure shell session with the switch:
[user@management-pc ~]$ ssh [email protected]
4. Check counter values aer SSH packets are generated from the switch in response to the secure
shell session request by the management PC:
user@switch> show firewall
Filter: mgmt_fil1
Counters:
Name Bytes Packets
c1 3533 23
Meaning
The output indicates that the rewall lter has been applied to the management interface and the
counter value indicates that 23 SSH packets were generated from the switch.
RELATED DOCUMENTATION
Conguring Firewall Filters (CLI Procedure) | 1642
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a
Security Device
IN THIS SECTION
Requirements | 1690
Overview and Topology | 1690
Conguraon | 1690
Vericaon | 1694
1689
This example describes how to set up lter-based forwarding on EX Series switches or a QFX10000.
You can congure lter-based forwarding by using a rewall lter to forward matched trac to a specic
virtual roung instance.
Requirements
This example applies to both EX Series switches running Junos OS Release 9.4 or later, and QFX10000
switches running Junos OS Release 15.1X53-D10 or later.
Overview and Topology
In this example, we create a rewall lter to match trac being sent from one applicaon server to
another according to the desnaon address (192.168.0.1) of packets egressing the source applicaon
server. Matching packets are routed to a virtual roung instance which forwards the trac to a security
device, which then forwards the trac on to the desnaon applicaon server.
NOTE: Filter-based forwarding does not work with IPv6 interfaces on some Juniper switches.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1690
Procedure | 1691
Results | 1692
To congure lter-based forwarding:
CLI Quick Conguraon
To use this example on your own device, copy the following commands into a text le, remove the line
breaks, and change the necessary details to t your conguraon. Then copy and paste the commands
into your CLI at the [edit] hierarchy level.
[edit]
set interfaces xe-0/0/0 unit 0 family inet address
10.1.0.1/24
set interfaces xe-0/0/3 unit 0 family inet address
1690
10.1.3.1/24
set firewall family inet filter f1 term t1 from source-address
10.1.0.50/32
set firewall family inet filter f1 term t1 from protocol
tcp
set interfaces xe-0/0/0 unit 0 family inet filter input f1
set routing-instances vrf01 instance-type virtual-router
set routing-instances vrf01 interface xe-0/0/3.0
set routing-instances vrf01 routing-options static route 192.168.0.1/24
next-hop 10.1.3.254
set firewall family inet filter f1 term t1 then routing-instance
vrf01
Procedure
Step-by-Step Procedure
To congure lter-based forwarding:
1. Congure an interface to connect to the applicaon server:
[edit interfaces]
user@switch# set xe-0/0/0 unit 0 family inet address 10.1.0.1/24
2. Congure an interface to connect to the security device:
[edit interfaces]
user@switch# set xe-0/0/3 unit 0 family inet address 10.1.3.1/24
3. Create a rewall lter that matches packets based on the address of the applicaon server that the
trac will be sent from. Also congure the lter so that it matches only TCP packets:
[edit firewall]
user@switch# set family inet filter f1 term t1 from source-address 10.1.0.50/32
user@switch# set firewall family inet filter f1 term t1 from protocol
tcp
1691
4. Apply the lter to the interface that connects to the source applicaon server and congure it to
match incoming packets:
[edit interfaces]
user@switch# set xe-0/0/0 unit 0 family inet filter input f1
5. Create a virtual router:
[edit]
user@switch# set routing-instances vrf01 instance-type virtual-router
6. Associate the virtual router with the interface that connects to the security device:
[edit routing-instances]
user@switch# set vrf01 interface xe-0/0/3.0
7. Congure the roung informaon for the virtual roung instance:
[edit routing-instances]
user@switch# set vrf01 routing-options static route 192.168.0.1/24 next-hop 10.1.3.254
8. Set the lter to forward packets to the virtual router:
[edit firewall]
user@switch# set family inet filter f1 term t1 then routing-instance
vrf01
Results
Check the results of the conguraon:
user@switch> show configuration
interfaces {
xe-0/0/0 {
unit 0 {
family inet {
filter {
1692
input f1;
}
address 10.1.0.1/24;
}
}
}
xe-0/0/3 {
unit 0 {
family inet {
address 10.1.3.1/24;
}
}
}
}
firewall {
family inet {
filter f1 {
term t1 {
from {
source-address {
10.1.0.50/32;
}
protocol tcp;
}
then {
routing-instance vrf01;
}
}
}
}
}
routing-instances {
vrf01 {
instance-type virtual-router;
interface xe-0/0/3.0;
routing-options {
static {
route 192.168.0.1/24 next-hop 10.1.3.254;
}
}
}
}
1693
Vericaon
IN THIS SECTION
Verifying That Filter-Based Forwarding Was Congured | 1694
To conrm that the conguraon is working properly, perform these tasks:
Verifying That Filter-Based Forwarding Was Congured
Purpose
Verify that lter-based forwarding was properly enabled on the switch.
Acon
1. Use the show interfaces filters command:
user@switch> show interfaces filters
xe-0/0/0.0
Interface Admin Link Proto Input Filter Output Filter
xe-0/0/0.0 up down inet fil
2. Use the show route forwarding-table command:
user@switch> show route forwarding-table
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default user 1 0:12:f2:21:cf:0 ucst 331 4 me0.0
default perm 0 rjct 36 3
0.0.0.0/32 perm 0 dscd 34 1
10.1.0.0/24 ifdn 0 rslv 613 1 xe-0/0/0.0
10.1.0.0/32 iddn 0 10.1.0.0 recv 611 1 xe-0/0/0.0
10.1.0.1/32 user 0 rjct 36 3
10.1.0.1/32 intf 0 10.1.0.1 locl 612 2
1694
10.1.0.1/32 iddn 0 10.1.0.1 locl 612 2
10.1.0.255/32 iddn 0 10.1.0.255 bcst 610 1 xe-0/0/0.0
10.1.1.0/26 ifdn 0 rslv 583 1 vlan.0
10.1.1.0/32 iddn 0 10.1.1.0 recv 581 1 vlan.0
10.1.1.1/32 user 0 rjct 36 3
10.1.1.1/32 intf 0 10.1.1.1 locl 582 2
10.1.1.1/32 iddn 0 10.1.1.1 locl 582 2
10.1.1.63/32 iddn 0 10.1.1.63 bcst 580 1 vlan.0
255.255.255.255/32 perm 0 bcst 32 1
Routing table: vrf01.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 559 2
0.0.0.0/32 perm 0 dscd 545 1
10.1.3.0/24 ifdn 0 rslv 617 1 xe-0/0/3.0
10.1.3.0/32 iddn 0 10.1.3.0 recv 615 1 xe-0/0/3.0
10.1.3.1/32 user 0 rjct 559 2
192.168.0.1/24 user 0 10.1.3.254 ucst 616 2 xe-0/0/3.0
192.168.0.1/24 user 0 10.1.3.254 ucst 616 2 xe-0/0/3.0
10.1.3.255/32 iddn 0 10.1.3.255 bcst 614 1 xe-0/0/3.0
224.0.0.0/4 perm 0 mdsc 546 1
224.0.0.1/32 perm 0 224.0.0.1 mcst 529 1
255.255.255.255/32 perm 0 bcst 543 1
Routing table: default.iso
ISO:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 60 1
Routing table: vrf01.iso
ISO:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 600 1
Meaning
The output indicates that the lter was created on the interface and that the virtual roung instance is
forwarding matching trac to the correct IP address.
1695
RELATED DOCUMENTATION
Conguring Firewall Filters | 1829
Understanding Filter-Based Forwarding | 1857
Understanding Virtual Router Roung Instances
Example: Applying Firewall Filters to Mulple Supplicants on Interfaces
Enabled for 802.1X or MAC RADIUS Authencaon
IN THIS SECTION
Requirements | 1696
Overview and Topology | 1697
Conguraon | 1699
Vericaon | 1702
On EX Series switches, rewall lters that you apply to interfaces enabled for 802.1X or MAC RADIUS
authencaon are dynamically combined with the per-user policies sent to the switch from the RADIUS
server. The switch uses internal logic to dynamically combine the interface rewall lter with the user
policies from the RADIUS server and create an individualized policy for each of the mulple users or
nonresponsive hosts that are authencated on the interface.
This example describes how dynamic rewall lters are created for mulple supplicants on an 802.1X-
enabled interface (the same principles shown in this example apply to interfaces enabled for MAC
RADIUS authencaon):
Requirements
This example uses the following hardware and soware components:
• Junos OS Release 9.5 or later for EX Series switches
• One EX Series switch
• One RADIUS authencaon server. The authencaon server acts as the backend database and
contains credenal informaon for hosts (supplicants) that have permission to connect to the
network.
1696
Before you apply rewall lters to an interface for use with mulple supplicants, be sure you have:
• Set up a connecon between the switch and the RADIUS server. See Example: Connecng a RADIUS
Server for 802.1X to an EX Series Switch.
• Congured 802.1X authencaon on the switch, with the authencaon mode for interface
ge-0/0/2 set to mulple. See Conguring 802.1X Interface Sengs (CLI Procedure) and Example:
Seng Up 802.1X for Single-Supplicant or Mulple-Supplicant Conguraons on an EX Series
Switch.
• Congured users on the RADIUS authencaon server.
Overview and Topology
IN THIS SECTION
Topology | 1697
Topology
When the 802.1X conguraon on an interface is set to mulple supplicant mode, the system
dynamically combines interface rewall lter with the user policies sent to the switch from the RADIUS
server during authencaon and creates separate terms for each user. Because there are separate terms
for each user authencated on the interface, you can, as shown in this example, use counters to view
the acvies of individual users that are authencated on the same interface.
When a new user (or a nonresponsive host) is authencated on an interface, the system adds a term to
the rewall lter associated with the interface, and the term (policy) for each user is associated with the
MAC address of the user. The term for each user is based on the user-specic lters set on the RADIUS
server and the lters congured on the interface. For example, as shown in Figure 74 on page 1698,
when User1 is authencated by the EX Series switch, the system creates the rewall lter dynamic-
lter-example. When User2 is authencated, another term is added to the rewall lter, and so on.
1697
Figure 74: Conceptual Model: Dynamic Filter Updated for Each New User
This is a conceptual model of the internal process—you cannot access or view the dynamic lter.
NOTE: If the rewall lter on the interface is modied aer the user (or nonresponsive host) is
authencated, the modicaons are not reected in the dynamic lter unless the user is
reauthencated.
In this example, you congure a rewall lter to count the requests made by each endpoint
authencated on interface ge-0/0/2 to the le server, which is located on subnet 192.0.2.16/28, and
set policer denions to rate limit the trac. Figure 75 on page 1699 shows the network topology for
this example.
1698
Figure 75: Mulple Supplicants on an 802.1X-Enabled Interface Connecng to a File Server
Conguraon
IN THIS SECTION
Conguring Firewall Filters on Interfaces with Mulple Supplicants | 1700
To congure rewall lters for mulple supplicants on 802.1X-enabled interfaces:
1699
Conguring Firewall Filters on Interfaces with Mulple Supplicants
CLI Quick Conguraon
To quickly congure rewall lters for mulple supplicants on an 802.1X-enabled interface copy the
following commands and paste them into the switch terminal window:
[edit]
set protocols dot1x authenticator interface ge-0/0/2 supplicant
multiple
set firewall family ethernet-switching filter filter1 term term1 from
destination-address 192.0.2.16/28
set firewall policer p1 if-exceeding bandwidth-limit 1m
set firewall policer p1 if-exceeding burst-size-limit 1k
set firewall family ethernet-switching filter filter1 term term1 then
count counter1
set firewall family ethernet-switching filter filter1 term term2 then policer p1
Step-by-Step Procedure
To congure rewall lters on an interface enabled for mulple supplicants:
1. Congure interface ge-0/0/2 for mulple supplicant mode authencaon:
[edit protocols dot1x]
user@switch# set authenticator interface ge-0/0/2 supplicant multiple
2. Set policer denion:
user@switch# show policer p1 |display set
set firewall policer p1 if-exceeding bandwidth-limit 1m
set firewall policer p1 if-exceeding burst-size-limit 1k
set firewall policer p1 then discard
1700
3. Congure a rewall lter to count packets from each user and a policer that limits the trac rate. As
each new user is authencated on the mulple supplicant interface, this lter term will be included in
the dynamically created term for the user:
[edit firewall family ethernet-switching]
user@switch# set filter filter1 term term1 from destination-address 192.0.2.16/28
user@switch# set filter filter1 term term1 then count counter1
user@switch# set filter filter1 term term2 then policer p1
Results
Check the results of the conguraon:
user@switch> show configuration
firewall {
family ethernet-switching {
filter filter1 {
term term1 {
from {
destination-address {
192.0.2.16/28;
}
}
then count counter1;
term term2 {
from {
destination-address {
192.0.2.16/28;
}
}
then policer p1;
}
}
}
policer p1 {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 1k;
}
then discard;
1701
}
}
protocols {
dot1x {
authenticator
interface ge-0/0/2 {
supplicant multiple;
}
}
}
Vericaon
IN THIS SECTION
Verifying Firewall Filters on Interfaces with Mulple Supplicants | 1702
To conrm that the conguraon is working properly, perform these tasks:
Verifying Firewall Filters on Interfaces with Mulple Supplicants
Purpose
Verify that rewall lters are funconing on the interface with mulple supplicants.
Acon
1. Check the results with one user authencated on the interface. In this case, the user is authencated
on ge-0/0/2:
user@switch> show dot1x firewall
Filter: dot1x_ge-0/0/2
Counters
counter1_dot1x_ge-0/0/2_user1 100
1702
2. When a second user, User2, is authencated on the same interface, ge-0/0/2, you can verify that the
lter includes the results for both of the users authencated on the interface:
user@switch> show dot1x firewall
Filter: dot1x-filter-ge-0/0/0
Counters
counter1_dot1x_ge-0/0/2_user1 100
counter1_dot1x_ge-0/0/2_user2 400
Meaning
The results displayed by the show dot1x firewall command output reect the dynamic lter created with
the authencaon of each new user. User1 accessed the le server located at the specied desnaon
address 100 mes, while User2 accessed the same le server 400 mes.
RELATED DOCUMENTATION
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Filtering 802.1X Supplicants by Using RADIUS Server Aributes
Verifying That Policers Are Operaonal
IN THIS SECTION
Purpose | 1703
Acon | 1704
Meaning | 1704
Purpose
Aer you congure policers and include them in rewall lter conguraons, you can perform the
following tasks to verify that the policers congured on EX Series switches are working properly.
1703
Acon
Use the operaonal mode command to verify that the policers on the switch are working properly:
user@switch> show policer
Filter: egress-vlan-watch-employee
Filter: ingress-port-filter
Filter: ingress-port-voip-class-limit-tcp-icmp
Policers:
Name Packets
icmp-connection-policer 0
tcp-connection-policer 0
Filter: ingress-vlan-rogue-block
Filter: ingress-vlan-limit-guest
Meaning
The show policer command displays the names of all rewall lters and policers that are congured on the
switch. For each policer that is specied in a lter conguraon, the output eld shows the current
packet count for all packets that exceed the specied rate limits.
RELATED DOCUMENTATION
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Conguring Firewall Filters (CLI Procedure) | 1642
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Monitoring Firewall Filter Trac | 1870
Troubleshoong Firewall Filters
IN THIS SECTION
Troubleshoong QFX10000 Switches | 1705
Troubleshoong Other Switches | 1706
1704
Use the following informaon to troubleshoot your rewall lter conguraon.
Troubleshoong QFX10000 Switches
IN THIS SECTION
Do Not Combine Match Condions for Dierent Layers | 1705
Layer 2 Packets Cannot be Discarded with Firewall Filters | 1705
Protect-RE (loopback) Firewall Filter Does Not Filter Packets Applied to EM0 Interfaces | 1706
This secon describes issues specic to QFX10000 switches:
Do Not Combine Match Condions for Dierent Layers
On QFX10000 switches, do not combine match condions for Layer 2 and any other layer in a family
ethernet-switching lter. (For example, do not include condions that match MAC addresses and IP
addresses in the same lter.) If you do so, the lter will commit successfully but will not work. You will
also see the following log message: L2 filter
filter-name
doesn't support mixed L2 and L3/L4 match conditions.
Please re-config.
Layer 2 Packets Cannot be Discarded with Firewall Filters
IN THIS SECTION
Problem | 1705
Soluon | 1706
Problem
Descripon
Layer 2 (L2) control packets such as Link Layer Discovery Protocol (LLDP) and bridge protocol data unit
(BPDU) cannot be discarded with rewall lters.
1705
Soluon
Congure distributed denial-of-service (DDoS) protecon on the L2 control packet and set the
aggregate policer bandwidth and burst values to the minimum value of 1. For example,
[edit system ddos-protection protocols
protocol name
]
user@host# set aggregate bandwidth 1
[edit system ddos-protection protocols
protocol name
]
user@host# set aggregate burst 1
Protect-RE (loopback) Firewall Filter Does Not Filter Packets Applied to EM0 Interfaces
IN THIS SECTION
Problem | 1706
Soluon | 1706
Problem
Descripon
On QFX10000 switches, the Protect-RE (loopback) rewall lter does not lter packets applied to EM0
interfaces including SNMP, Telnet, and other services.
Soluon
This is expected behavior.
Troubleshoong Other Switches
IN THIS SECTION
Firewall Filter Conguraon Returns a No Space Available in TCAM Message | 1707
1706
Filter Counts Previously Dropped Packet | 1710
Matching Packets Not Counted | 1711
Counter Reset When Eding Filter | 1712
Cannot Include loss-priority and policer Acons in Same Term | 1712
Cannot Egress Filter Certain Trac Originang on QFX Switch | 1713
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling | 1714
Egress Firewall Filters with Private VLANs | 1714
Egress Filtering of L2PT Trac Not Supported | 1716
Cannot Drop BGP Packets in Certain Circumstances | 1716
Invalid Stascs for Policer | 1717
Policers can Limit Egress Filters | 1717
This secon describes issues specic to QFX switches other than QFX10000 switches. This informaon
also applies to OCX1100 switches and EX4600 switches.
Firewall Filter Conguraon Returns a No Space Available in TCAM Message
IN THIS SECTION
Problem | 1707
Soluon | 1708
Problem
Descripon
When a rewall lter conguraon exceeds the amount of available Ternary Content Addressable
Memory (TCAM) space, the system returns the following syslogd message:
No space available in tcam.
Rules for filter
filter-name
will not be installed.
1707
A switch returns this message during the commit operaon if the rewall lter that has been applied to
a port, VLAN, or Layer 3 interface exceeds the amount of space available in the TCAM table. The lter is
not applied, but the commit operaon for the rewall lter conguraon is completed in the CLI
module.
Soluon
When a rewall lter conguraon exceeds the amount of available TCAM table space, you must
congure a new rewall lter with fewer lter terms so that the space requirements for the lter do not
exceed the available space in the TCAM table.
You can perform either of the following procedures to correct the problem:
To delete the lter and its binding and apply the new smaller rewall lter to the same binding:
1. Delete the lter and its binding to ports, VLANs, or Layer 3 interfaces. For example:
[edit]
user@switch# delete firewall family ethernet-switching filter ingress-vlan-rogue-block
user@switch# delete vlans employee-vlan description "filter to block rogue devices on
employee-vlan"
user@switch# delete vlans employee-vlan filter input ingress-vlan-rogue-block
2. Commit the changes:
[edit]
user@switch# commit
3. Congure a smaller lter with fewer terms that does not exceed the amount of available TCAM
space. For example:
[edit]
user@switch# set firewall family ethernet-switching filter new-ingress-vlan-rogue-block ...
4. Apply (bind) the new rewall lter to a port, VLAN , or Layer 3 interface. For example:
[edit]
user@switch# set vlans employee-vlan description "filter to block rogue devices on employee-
vlan"
user@switch# set vlans employee-vlan filter input new-ingress-vlan-rogue-block
1708
5. Commit the changes:
[edit]
user@switch# commit
To apply a new rewall lter and overwrite the exisng binding but not delete the original lter:
1. Congure a rewall lter with fewer terms than the original lter:
[edit]
user@switch# set firewall family ethernet-switching filter new-ingress-vlan-rogue-block...
2. Apply the rewall lter to the port, VLAN, or Layer 3 interfaces to overwrite the binding of the
original lter—for example:
[edit]
user@switch# set vlans employee-vlan description "smaller filter to block rogue devices on
employee-vlan"
user@switch# set vlans employee-vlan filter input new-ingress-vlan-rogue-block
Because you can apply no more than one rewall lter per VLAN per direcon, the binding of the
original rewall lter to the VLAN is overwrien with the new rewall lter new-ingress-vlan-rogue-
block.
3. Commit the changes:
[edit]
user@switch# commit
NOTE: The original lter is not deleted and is sll available in the conguraon.
1709
Filter Counts Previously Dropped Packet
IN THIS SECTION
Problem | 1710
Soluon | 1711
Problem
Descripon
If you congure two or more lters in the same direcon for a physical interface and one of the lters
includes a counter, the counter will be incorrect if the following circumstances apply:
• You congure the lter that is applied to packets rst to discard certain packets. For example,
imagine that you have a VLAN lter that accepts packets sent to 10.10.1.0/24 addresses and
implicitly discards packets sent to any other addresses. You apply the lter to the admin VLAN in the
output direcon, and interface xe-0/0/1 is a member of that VLAN.
• You congure a subsequent lter to accept and count packets that are dropped by the rst lter. In
this example, you have a port lter that accepts and counts packets sent to 192.168.1.0/24
addresses that is also applied to xe-0/0/1 in the output direcon.
The egress VLAN lter is applied rst and correctly discards packets sent to 192.168.1.0/24 addresses.
The egress port lter is applied next and counts the discarded packets as matched packets. The packets
are not forwarded, but the counter displayed by the egress port lter is incorrect.
Remember that the order in which lters are applied depends on the direcon in which they are applied,
as indicated here:
Ingress lters:
1. Port (Layer 2) lter
2. VLAN lter
3. Router (Layer 3) lter
Egress lters:
1. Router (Layer 3) lter
2. VLAN lter
1710
3. Port (Layer 2) lter
Soluon
This is expected behavior.
Matching Packets Not Counted
IN THIS SECTION
Problem | 1711
Soluon | 1711
Problem
Descripon
If you congure two egress lters with counters for a physical interface and a packet matches both of
the lters, only one of the counters includes that packet.
For example:
• You congure an egress port lter with a counter for interface xe-0/0/1.
• You congure an egress VLAN lter with a counter for the adminVLAN, and interface xe-0/0/1 is a
member of that VLAN.
• A packet matches both lters.
In this case, the packet is counted by only one of the counters even though it matched both lters.
Soluon
This is expected behavior.
1711
Counter Reset When Eding Filter
IN THIS SECTION
Problem | 1712
Soluon | 1712
Problem
Descripon
If you edit a rewall lter term, the value of any counter associated with any term in the same lter is set
to 0, including the implicit counter for any policer referenced by the lter. Consider the following
examples:
• Assume that your lter has term1, term2, and term3, and each term has a counter that has already
counted matching packets. If you edit any of the terms in any way, the counters for all the terms are
reset to 0.
• Assume that your lter has term1 and term2. Also assume that term2 has a policer acon modier and
the implicit counter of the policer has already counted 1000 matching packets. If you edit term1 or
term2 in any way, the counter for the policer referenced by term2 is reset to 0.
Soluon
This is expected behavior.
Cannot Include loss-priority and policer Acons in Same Term
IN THIS SECTION
Problem | 1713
Soluon | 1713
1712
Problem
Descripon
You cannot include both of the following acons in the same rewall lter term in a QFX Series switch:
• loss-priority
• policer
If you do so, you see the following error message when you aempt to commit the conguraon:
“cannot support policer acon if loss-priority is congured.”
Soluon
This is expected behavior.
Cannot Egress Filter Certain Trac Originang on QFX Switch
IN THIS SECTION
Problem | 1713
Soluon | 1713
Problem
Descripon
On a QFX Series switch, you cannot lter certain trac with a rewall lter applied in the output
direcon if the trac originates on the QFX switch. This limitaon applies to control trac for protocols
such as ICMP (ping), STP, LACP, and so on.
Soluon
This is expected behavior.
1713
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling
IN THIS SECTION
Problem | 1714
Soluon | 1714
Problem
Descripon
If you create a rewall lter that includes a match condion of dot1q-tag or dot1q-user-priority and apply
the lter on input to a trunk port that parcipates in a service VLAN, the match condion does not work
if the Q-in-Q EtherType is not 0x8100. (When Q-in-Q tunneling is enabled, trunk interfaces are assumed
to be part of the service provider or data center network and therefore parcipate in service VLANs.)
Soluon
This is expected behavior. To set the Q-in-Q EtherType to 0x8100, enter the set dot1q-tunneling
ethertype 0x8100 statement at the [edit ethernet-switching-options] hierarchy level. You must also
congure the other end of the link to use the same Ethertype.
Egress Firewall Filters with Private VLANs
IN THIS SECTION
Problem | 1715
Soluon | 1715
1714
Problem
Descripon
If you apply a rewall lter in the output direcon to a primary VLAN, the lter also applies to the
secondary VLANs that are members of the primary VLAN when the trac egresses with the primary
VLAN tag or isolated VLAN tag, as listed below:
• Trac forwarded from a secondary VLAN trunk port to a promiscuous port (trunk or access)
• Trac forwarded from a secondary VLAN trunk port that carries an isolated VLAN to a PVLAN trunk
port.
• Trac forwarded from a promiscuous port (trunk or access) to a secondary VLAN trunk port
• Trac forwarded from a PVLAN trunk port. to a secondary VLAN trunk port
• Trac forwarded from a community port to a promiscuous port (trunk or access)
If you apply a rewall lter in the output direcon to a primary VLAN, the lter does
not
apply to trac
that egresses with a community VLAN tag, as listed below:
• Trac forwarded from a community trunk port to a PVLAN trunk port
• Trac forwarded from a secondary VLAN trunk port that carries a community VLAN to a PVLAN
trunk port
• Trac forwarded from a promiscuous port (trunk or access) to a community trunk port
• Trac forwarded from a PVLAN trunk port. to a community trunk port
If you apply a rewall lter in the output direcon to a community VLAN, the following behaviors apply:
• The lter is applied to trac forwarded from a promiscuous port (trunk or access) to a community
trunk port (because the trac egresses with the community VLAN tag).
• The lter is applied to trac forwarded from a community port to a PVLAN trunk port (because the
trac egresses with the community VLAN tag).
• The lter is
not
applied to trac forwarded from a community port to a promiscuous port (because
the trac egresses with the primary VLAN tag or untagged).
Soluon
These are expected behaviors. They occur only if you apply a rewall lter to a private VLAN in the
output direcon and do not occur if you apply a rewall lter to a private VLAN in the input direcon.
1715
Egress Filtering of L2PT Trac Not Supported
IN THIS SECTION
Problem | 1716
Soluon | 1716
Problem
Descripon
Egress ltering of L2PT trac is not supported on the QFX3500 switch. That is, if you congure L2PT to
tunnel a protocol on an interface, you cannot also use a rewall lter to lter trac for that protocol on
that interface in the output direcon. If you commit a conguraon for this purpose, the rewall lter is
not applied to the L2PT-tunneled trac.
Soluon
This is expected behavior.
Cannot Drop BGP Packets in Certain Circumstances
IN THIS SECTION
Problem | 1716
Soluon | 1717
Problem
Descripon
BGP packets with a me-to-live (TTL) value greater than 1 cannot be discarded using a rewall lter
applied to a loopback interface or applied on input to a Layer 3 interface. BGP packets with TTL value of
1 or 0 can be discarded using a rewall lter applied to a loopback interface or applied on input to a
Layer 3 interface.
1716
Soluon
This is expected behavior.
Invalid Stascs for Policer
IN THIS SECTION
Problem | 1717
Soluon | 1717
Problem
Descripon
If you apply a single-rate two-color policer in more than 128 terms in a rewall lter, the output of the
show firewall command displays incorrect data for the policer.
Soluon
This is expected behavior.
Policers can Limit Egress Filters
IN THIS SECTION
Problem | 1717
Soluon | 1718
Problem
Descripon
On some switches, the number of egress policers you congure can aect the total number of allowed
egress rewall lters. Every policer has two implicit counters that take up two entries in a 1024-entry
1717
TCAM. These are used for counters, including counters that are congured as acon modiers in rewall
lter terms. (Policers consume two entries because one is used for green packets and one is used for
nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any
more egress rewall lters that have terms with counters. For example, if you congure and commit 512
egress policers (two-color, three-color, or a combinaon of both policer types), all of the memory entries
for counters get used up. If later in your conguraon le you insert addional egress rewall lters with
terms that also include counters,
none
of the terms in those lters are commied because there is no
available memory space for the counters.
Here are some addional examples:
• Assume that you congure egress lters that include a total of 512 policers and no counters. Later in
your conguraon le you include another egress lter with 10 terms, 1 of which has a counter
acon modier. None of the terms in this lter are commied because there is not enough TCAM
space for the counter.
• Assume that you congure egress lters that include a total of 500 policers, so 1000 TCAM entries
are occupied. Later in your conguraon le you include the following two egress lters:
• Filter A with 20 terms and 20 counters. All the terms in this lter are commied because there is
enough TCAM space for all the counters.
• Filter B comes aer Filter A and has ve terms and ve counters.
None
of the terms in this lter
are commied because there is not enough memory space for
all
the counters. (Five TCAM
entries are required but only four are available.)
Soluon
You can prevent this problem by ensuring that egress rewall lter terms with counter acons are placed
earlier in your conguraon le than terms that include policers. In this circumstance, Junos OS commits
policers even if there is not enough TCAM space for the implicit counters. For example, assume the
following:
• You have 1024 egress rewall lter terms with counter acons.
• Later in your conguraon le you have an egress lter with 10 terms. None of the terms have
counters but one has a policer acon modier.
You can successfully commit the lter with 10 terms even though there is not enough TCAM space for
the implicit counters of the policer. The policer is commied without the counters.
1718
CHAPTER 27
Conguring Firewall Filters (QFX Series Switches,
EX4600 Switches, PTX Series Routers)
IN THIS CHAPTER
Overview of Firewall Filters (QFX Series) | 1720
Understanding Firewall Filter Planning | 1723
Planning the Number of Firewall Filters to Create | 1725
Firewall Filter Match Condions and Acons (QFX and EX Series Switches) | 1734
Firewall Filter Match Condions and Acons (QFX10000 Switches) | 1783
Firewall Filter Match Condions and Acons (PTX Series Routers) | 1801
Firewall and Policing Dierences Between PTX Series Packet Transport Routers and T Series Matrix
Routers | 1826
Conguring Firewall Filters | 1829
Applying Firewall Filters to Interfaces | 1838
Overview of MPLS Firewall Filters on Loopback Interface | 1838
Conguring MPLS Firewall Filters and Policers on Switches | 1840
Conguring MPLS Firewall Filters and Policers on Routers | 1843
Conguring MPLS Firewall Filters and Policers | 1852
Understanding How a Firewall Filter Tests a Protocol | 1855
Understanding Firewall Filter Processing Points for Bridged and Routed Packets | 1856
Understanding Filter-Based Forwarding | 1857
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1858
Conguring a Firewall Filter to De-Encapsulate GRE or IPIP Trac | 1865
Verifying That Firewall Filters Are Operaonal | 1869
Monitoring Firewall Filter Trac | 1870
Troubleshoong Firewall Filter Conguraon | 1874
1719
Overview of Firewall Filters (QFX Series)
IN THIS SECTION
Where You Can Apply Filters | 1720
What Makes up a Firewall Filter | 1721
How Firewall Filters are Processed | 1722
Firewall lters, somemes called
access control lists
(ACLs), provide rules that dene whether to accept
or discard packets that are transing an interface. If a packet is accepted, you can congure more
acons on the packet, such as class-of-service (CoS) marking (grouping similar types of trac together
and treang each type of trac as a class with its own level of service priority) and trac policing
(controlling the maximum rate of trac sent or received).
You can congure rewall lters to determine where to accept or discard a packet before it enters or
exits a port, VLAN, Layer 2 CCC, Layer 3 (routed) interface, Routed VLAN interface (RVI), or MPLS
interface.
An
ingress (input)
rewall lter
is applied to packets that are entering an interface or VLAN, and an
egress (output)
rewall lter is applied to packets that are exing an interface or VLAN.
NOTE: Policers on network port, layer 2 and layer 3, or IRB interfaces do not police host-bound
trac. But if you want to prevent DDoS aacks, then you can create a rewall lter on the lo0
that protects the roung engine.
Where You Can Apply Filters
Aer you congure the rewall lter, you can apply it to the following:
• Port—Filters Layer 2 trac transing system ports.
• VLAN—Filters and provides access control for Layer 2 packets that enter a VLAN, are bridged within
a VLAN, or leave a VLAN.
• Layer 3 (routed) interface—Filters trac on IPv4 and IPv6 interfaces, routed VLAN interfaces (RVI),
and the loopback interface. The loopback interface lters trac sent to the switch itself or generated
by the switch.
1720
• Layer 2 CCC interface—Filters Layer 2 circuit cross-connect (CCC) interfaces.
• MPLS—Filters MPLS interfaces.
You can also apply a rewall lter to a management interface (for example, me0) on a QFX and EX4600
standalone switch. You can’t apply a lter to a management interface on a QFX3000-G or QFX3000-M
system.
NOTE: You can apply only one rewall lter to a port, VLAN, or Layer 2 CCC interface for a given
direcon. For example, for interface ge-0/0/6.0, you can apply one lter for the ingress direcon
and one for the egress direcon.
• (QFX Series) Starng with Junos OS Release 13.2X51-D15, you can apply a lter to a loopback
interface in the egress direcon.
• (QFX10000) Starng with Junos OS Release 18.2R1, you can apply ingress and egress rewall lters
with count and discard as policer acons on Layer 2 circuit interfaces.
• (QFX10002-36Q, QFX10002-72Q, QFX10002-60C, QFX10008, QFX10016, PTX10008, PTX10016)
Starng with Junos OS Release 19.2R1, you can apply the interface, forwarding-class, and loss-priority
match condions in the egress direcon on IPv4 and IPv6 interfaces.
NOTE: The EX4600 , QFX5000 series and QFX5000 EVO series switches do not depend on the
VRF match for loopback lters congured at dierent roung instances. Loopback lters per
roung instance (such as lo0.100, lo0.103, lo0.105) are not supported and may cause
unpredictable behavior. We recommend that you only apply the loopback lter (lo0.0) to the
master roung instance.
What Makes up a Firewall Filter
When you congure a rewall lter, you dene the family address type (ethernet-switching, inet (for
IPv4), inet6 (for IPv6), circuit cross-connect (CCC), or MPLS), the ltering criteria (terms, with match
condions,) and the acon to take if a match occurs.
Each term consists of the following
• Match condion—Values that a packet must contain to be considered a match. You can specify values
for most elds in the IP, TCP, UDP, or ICMP headers. You can also match on interface names.
• Acon—Acon taken if a packet matches a match condion. You can congure a rewall lter to
accept, discard, or reject a matching packet and then perform more acons, such as counng,
classifying, and policing. The default acon is accept.
1721
How Firewall Filters are Processed
If there are mulple terms in a lter, the order of the terms is important. If a packet matches the rst
term, the switch takes the acon dened by that term, and no other terms are evaluated. If the switch
doesn’t nd a match between the packet and the rst term, it compares the packet to the next term. If
no match occurs between the packet and the second term, the system connues to compare the packet
to each successive term in the lter unl a match is found. If no terms are matched, the switch discards
the packet by default.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release Descripon
19.2R1 (QFX10002-36Q, QFX10002-72Q, QFX10002-60C, QFX10008, QFX10016, PTX10008,
PTX10016) Starng with Junos OS Release 19.2R1, you can apply the interface, forwarding-class,
and loss-priority match condions in the egress direcon on IPv4 and IPv6 interfaces.
18.2R1 (QFX10000) Starng with Junos OS Release 18.2R1, you can apply ingress and egress rewall
lters with count and discard as policer acons on Layer 2 circuit interfaces.
13.2X51-D15 (QFX Series) Starng with Junos OS Release 13.2X51-D15, you can apply a lter to a loopback
interface in the egress direcon.
RELATED DOCUMENTATION
Understanding How Firewall Filters Are Evaluated | 856
Understanding Firewall Filter Planning | 1723
Planning the Number of Firewall Filters to Create | 1725
Conguring Firewall Filters | 1829
Conguring MPLS Firewall Filters and Policers | 1852
Overview of Policers | 2202
Understanding Firewall Filter Match Condions | 858
Firewall Filter Match Condions and Acons (QFX and EX Series Switches) | 1734
Firewall Filter Match Condions and Acons (QFX10000 Switches) | 1783
1722
Understanding Firewall Filter Planning
Before you create a
rewall lter
and apply it, determine what you want the lter to accomplish and
how to use its match condions and acons to achieve your goals. It is important that you understand
how packets are matched, the default and congured acons of the rewall lter, and where to apply
the rewall lter.
You can apply no more than one rewall lter per port, VLAN, or router interface per direcon (input
and output). For example, for a given port you can apply at most one lter in the input direcon and one
lter in the output direcon. You should try to be conservave in the number of terms (rules) that you
include in each rewall lter, because a large number of terms requires longer processing me during a
commit operaon and can make tesng and troubleshoong more dicult.
Before you congure and apply rewall lters, answer the following quesons for each of them:
1. What is the purpose of the lter?
For example, the system can drop packets based on header informaon, rate-limit trac, classify
packets into forwarding classes, log and count packets, or prevent denial-of-service aacks.
2. What are the appropriate match condions? Determine the packet header elds that the packet must
contain for a match. Possible elds include:
• Layer 2 header elds—Source and desnaon MAC addresses, 802.1Q tag, Ethernet type, or
VLAN.
• Layer 3 header elds—Source and desnaon IP addresses, protocols, and IP opons (IP
precedence, IP fragmentaon ags, or TTL type).
• TCP header elds—Source and desnaon ports and ags.
• ICMP header elds—Packet type and code.
3. What are the appropriate acons to take if a match occurs?
The system can accept, discard, or reject packets.
4. What addional acon modiers might be required?
For example, you can congure the system to mirror (copy) packets to a specied port, count
matching packets, apply trac management, or police packets.
5. On what port, router interface, or VLAN should the rewall lter be applied?
Start with the following basic guidelines:
1723
• If packets entering or leaving a Layer 2 interface (port) need to be ltered, apply the lter at the
[edit family ethernet switching filter] hierarchy level. This is a port lter.
• If packets entering or leaving any port in a specic VLAN need to be ltered, use a VLAN lter.
• If packets entering or leaving a Layer 3 (routed) interface or
routed VLAN interface
(
RVI
) need to
be ltered, use a router rewall lter. Apply the lter to the interface at the [edit family inet]
hierarchy level. You can also apply a router rewall lter on a loopback interface.
Before you choose the interface or VLAN on which to apply a rewall lter, understand how that
placement can aect trac ow to other interfaces. In general, apply a lter close to the source
device if the lter matches on source or desnaon IP addresses, IP protocols, or protocol
informaon—such as ICMP message types, and TCP or UDP port numbers. However, you should
apply a lter close to the desnaon device if the lter matches
only
on a source IP address. When
you apply a lter too close to the source device, the lter could prevent that source device from
accessing other services that are available on the network.
NOTE: Egress rewall lters do not aect the ow of locally generated control packets from
the Roung Engine.
6. In which direcon should the rewall lter be applied?
You typically congure dierent acons for trac entering an interface than you congure for trac
exing an interface.
7. How many lters should I create?
See "Planning the Number of Firewall Filters to Create" on page 1725 for informaon about how
many rewall lters you can apply.
RELATED DOCUMENTATION
Overview of Policers | 2202
Understanding How Firewall Filters Are Evaluated | 856
Conguring Firewall Filters | 1829
1724
Planning the Number of Firewall Filters to Create
IN THIS SECTION
How to Increase the Number of Firewall Filters | 1725
TCAM | 1726
Avoid Conguring too Many Filters | 1727
Conguring TCAM Error Messages | 1727
How to Increase the Scale of Firewall Filters Using Proles | 1728
How Policers can Limit Egress Filters | 1732
Planning for Filter-Specic Policers | 1733
Planning for Filter-Based Forwarding | 1733
How to Increase the Number of Firewall Filters
You can increase the number of rewall lters on your device several ways:
• (QFX5220) To create more than 512 egress VLAN lters, specify the rst VLAN ID as 6, the second
VLAN ID as 7, the third VLAN ID as 8 and so forth. For each VLAN that you congure, the number
increases by 1 and connues through VLAN ID 1029. If you want to create fewer than 512 egress
VLAN lters, but want the total number of terms in those lters to be more than 512, make sure that
you number your VLAN IDs this same way. Otherwise, the total number of allowed terms or lters
will be less than 1024 and will remain at 512.
• Starng in Junos OS Release 19.1R1, you can increase the number of egress VLAN rewall lters on
the QFX5110 from 1024 to 2048 by using the egress-to-ingress opon. You include this opon under
the from statement at the [edit firewall] hierarchy.
Starng in Junos OS Evolved Release 19.4R2, you can congure up to 2000 egress rewall lters on
the QFX5220 by including the egress-scale opon under the eracl-profile statement at the [edit system
packet-forwarding-option firewall] hierarchy level. This feature is supported only in the egress direcon
(routed trac exing the device).
Consider this following when conguring this feature:
• You cannot apply lters with the same match condions to dierent egress VLANs or Layer 3
interfaces.
• You cannot apply egress scaling on GRE interfaces.
1725
• If a packet matches mulple lters with dierent qualiers and you apply on dierent egress
interfaces, this can lead to unpredictable behavior.
• You can only congure the egress-scale opon in global mode. The new cli conguraon will be
provided in global mode. Once a user congures ERACL group in egress-scale (egress to ingress)
mode, he will not be able to congure ERACL the older way i.e., without using IFP tcam space. In
other words, ERACL in mixed mode will not be supported.
TCAM
NOTE: For QFX5120-48Y and EX4650 switches running Junos OS Release 20.3R1 or later, you
can increase the number of loopback lter terms on the loopback interface from 384(default) to
768 for IPv6 and from 384(default) to 1152 terms for IPv4. Use the set loopback-rewall-
opmizaon CLI at the [edit chassis] hierarchy level] to enable opmizaon. This command
causes an FPC reboot and service outage. See hps://www.juniper.net/documentaon/us/en/
soware/junos/cli-reference/topics/ref/statement/chassis-loopback-rewall-opmizaon.html
for informaon on the CLI.
Ternary content addressable memory (TCAM) for rewall lters is divided into slices that accommodate
256 terms. When you congure a rewall lter, all terms in a memory slice must be in lters of the same
type and applied in the same direcon. A memory slice is reserved as soon as you commit a lter. For
example, if you create a port lter and apply it in the input direcon, a memory slice is reserved that
only stores ingress port lters. If you create and apply only one ingress port lter and that lter has only
one term, the rest of this slice is unused and is unavailable for other lter types.
NOTE: In an EVPN environment, QFX5200 Series switches support up to 512 TCAM entries.
For example, let’s say that you create and apply 256 ingress port lters with one term each so that one
memory slice is lled. This leaves two more memory slices available for ingress lters. (In this case, the
maximum number of ingress terms is 768.) If you then create and apply an ingress Layer 3 lter with one
term, another memory slice is reserved for ingress Layer 3 lters. As before, the rest of the slice is
unused and is unavailable for dierent lter types. Now there is one memory slice available for any
ingress lter type.
Now assume that you create and apply a VLAN ingress lter. The nal memory slice is reserved for
VLAN ingress lters. Memory allocaon for ingress lters (once again assuming one term per lter) is:
• Slice 1: Filled with 256 ingress port lters. You cannot commit any more ingress port lters.
• Slice 2: Contains one ingress Layer 3 lter with one term. You can commit 255 more terms in ingress
Layer 3 lters.
1726
• Slice 3: Contains one ingress VLAN lter with one term. You can commit 255 more terms in ingress
VLAN lters.
Here is another example. Assume that you create 257 ingress port lters with one term per lter–that is,
you create one more term than a single memory slice can accommodate. When you apply the lters and
commit the conguraon, the lter memory allocaon is:
• Slice 1: Filled with 256 ingress port lters. You cannot apply any more ingress port lters.
• Slice 2: Contains one ingress port lter. You can apply 255 more terms in ingress port lters.
• Slice 3: This slice is unassigned. You can create and apply 256 terms in ingress lters of any type
(port, Layer 3, or VLAN), but all the lters must be of the same type.
NOTE: All of the above examples also apply to egress lters. The dierence is that four memory
slices are used because IPv4 and IPv6 Layer 3 lters are stored in separate slices. The memory
slices for egress lters are the same size as those for ingress lters, so the maximum number of
lters will be the same (1024).
Avoid Conguring too Many Filters
If you violate any of these restricons and commit a conguraon that is not in compliance, Junos OS
rejects the excessive lters. For example, if you congure 300 ingress port lters and 300 ingress Layer
3 lters and try to commit the conguraon, Junos OS does the following (again assuming one term per
lter):
• Accepts the 300 ingress port lters (storing them in two memory slices).
• Accepts the rst 256 ingress Layer 3 lters it processes (storing them in the third memory slice).
• Rejects the remaining 44 ingress Layer 3 lters.
NOTE: Make sure that you delete the excessive lters (for example, the remaining 44 ingress
Layer 3 lters) from the conguraon before you reboot the device. If you reboot a device that
has a noncompliant conguraon, it’s hard to predict which lters were installed aer the reboot.
Using the example above, the 44 ingress Layer 3 lters that were originally rejected might be
installed, and 44 of the port lters that were originally accepted might be rejected.
Conguring TCAM Error Messages
If you lack TCAM space and are unable to install a rewall lter, you can congure your switch to send
error messages the following ways:
1727
• Enter set system syslog file
filename
pfe emergency to send error messages to a syslog le.
• Enter set system syslog console pfe emergency to send error messages to the console.
• Enter set system syslog user
user-login
pfe emergency to send error messages to an SSH terminal session.
How to Increase the Scale of Firewall Filters Using Proles
When you congure a rewall lter, the term statement in the rewall lter conguraon provides an
extensive set of match condions. Match condions are the elds and values that a packet must contain
to be considered a match. You can dene a single or mulple match condions based on your
requirement. When a packet matches a lter, the device takes the acon specied in the term. The
scalability of rewall lters generally depends on the number of match condions used.
In typical deployment scenarios, you will only need to use a subset of match condions. With the
introducon of proles, you can use one of the available rewall lter proles with pre-dened match
condions to increase the number of rewall lters used to achieve maximum scale.
You can congure rewall lters proles for family inet and Ethernet-based switching. Use the proles
conguraon statement at the [edit system packet-forwarding-opons rewall] hierarchy level to
congure rewall lter proles.
NOTE: When you make changes to the rewall lter proles, either by selecng a prole, or
moving from one prole to another, the packet forwarding engine is restarted, which causes
disrupon to the trac ow.
The following table describes the rewall lter proles and the pre-dened match condions for inet
and Ethernet-based switching.
1728
Table 94: Firewall Filter Prole and Match Condions
Family Type Firewall Filter Proles Match Condion (pre-
dened)
Conguraon Hierarchy
inet (IPv4/IPv6)
profile1 ip-source-address
ip-source-prex-list
protocol
next-header
source-port
desnaon-port
rst-fragment
is-fragment
icmp-code
icmp-type
tcp-established
tcp-inial
tcp-ags
[edit system packet-
forwarding-options
firewall profiles inet
profile1]
1729
Table 94: Firewall Filter Prole and Match Condions
(Connued)
Family Type Firewall Filter Proles Match Condion (pre-
dened)
Conguraon Hierarchy
prole2 ip-source-address
ip6-source-address
ip-source-prex-list
ip6-source-prex-list
protocol
next-header
source-port
desnaon-port
rst-fragment
is-fragment
icmp-code
icmp-type
tcp-established
tcp-inial
tcp-ags
dscp
precedence
trac-class
l
hop-limit
[edit system packet-
forwarding-options
firewall profiles inet
profile2]
Ethernet Switching prole1 source-mac-address
desnaon-mac-address
[edit system packet-
forwarding-options
firewall profiles
ethernet-switching
profile1]
1730
Table 94: Firewall Filter Prole and Match Condions
(Connued)
Family Type Firewall Filter Proles Match Condion (pre-
dened)
Conguraon Hierarchy
prole2 source-mac-address
desnaon-mac-address
ether-type
ip-source-address
ip-source-prex-list
ip-protocol
source-port
desnaon-port
next-header
[edit system packet-
forwarding-options
firewall profiles
ethernet-switching
profile2]
NOTE: When you select a rewall lter prole, you must apply a match condion that is part of
the pre-dened match condion subset. If you apply a match condion that is not part of the
pre-dened match condion subset of the rewall lter prole, then a commit error occurs. For
example, if you select profile1 for inet lter and apply the match condion as ip-destination-
address, which is not part of the pre-dened match condion, then you will see an error during
the commit operaon stang that the ip-destination-address match is not part of profile1 for inet
lter.
You can use the show pfe filter hw profile-info CLI command to view the details of the rewall lter
proles.
To achieve maximum rewall lter scale, it is recommended to apply interface level (Layer 2 or Layer 3)
lters and distribute the lters equally across the interfaces of dierent packet processing pipelines.
Each set of interfaces is mapped to a packet processing pipeline which handles the packets received on
those interfaces. In this case, the rewall lters are installed to the packet processing pipeline’s TCAM
memory space mapped to the respecve interface.
When a packet enters an interface, the rewall lter performs ltering acons on the packet in the
packet processing pipeline based on the match condions before exing an egress interface. In the case
of mulple packet processing pipelines, when packets enter a device through mulple interfaces, the
1731
rewall lter performs ltering acons on the packets passing through the respecve packet processing
pipelines. Having the interface level lters distributed equally across the interfaces of dierent packet
processing pipelines gives beer scale
You can use the show pfe filter hw port-pipe-info CLI command to view the details of the packet
processing pipeline that each physical interface is mapped to. The output of this CLI command also
provides informaon about the rewall lters installed on a packet processing pipeline. You can use this
informaon to plan and distribute rewall lters across pipelines to achieve maximum scale.
The following sample output of the show pfe filter hw port-pipe-info CLI command show the details of the
packet processing pipeline that each physical interface is mapped to:
user@host> show pfe filter hw port-pipe-info
IFD Pipe
et-0/0/0 1
et-0/0/1 1
...
et-0/0/10 0
How Policers can Limit Egress Filters
On some switches, the number of egress policers you congure can aect the total number of allowed
egress rewall lters. Every policer has two implicit counters that take up two entries in a 1024-entry
TCAM. These are used for counters, including counters that are congured as acon modiers in rewall
lter terms. (Policers consume two entries because one is used for green packets and one is used for
nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any
more egress rewall lters that have terms with counters. For example, if you congure and commit 512
egress policers (two-color, three-color, or a combinaon of both policer types), all of the memory entries
for counters get used up. If later in your conguraon le you insert addional egress rewall lters with
terms that also include counters,
none
of the terms in those lters are commied because there is no
available memory space for the counters.
Here are some more examples:
• Assume that you congure egress lters that include a total of 512 policers and no counters. Later in
your conguraon le you include another egress lter with 10 terms, 1 of which has a counter
acon modier. None of the terms in this lter are commied because there is not enough TCAM
space for the counter.
• Assume that you congure egress lters that include a total of 500 policers, so 1000 TCAM entries
are occupied. Later in your conguraon le you include the following two egress lters:
• Filter A with 20 terms and 20 counters. All the terms in this lter are commied because there is
enough TCAM space for all the counters.
1732
• Filter B comes aer Filter A and has ve terms and ve counters.
None
of the terms in this lter
are commied because there is not enough memory space for
all
the counters. (Five TCAM
entries are required but only four are available.)
You can stop this problem from happening by ensuring that egress rewall lter terms with counter
acons are placed earlier in your conguraon le than terms that include policers. In this circumstance,
Junos OS commits policers even if there is not enough TCAM space for the implicit counters. For
example, assume the following:
• You have 1024 egress rewall lter terms with counter acons.
• Later in your conguraon le you have an egress lter with 10 terms. None of the terms have
counters but one has a policer acon modier.
You can successfully commit the lter with 10 terms even though there is not enough TCAM space for
the implicit counters of the policer. The policer is commied without the counters.
Planning for Filter-Specic Policers
You can congure policers to be lter-specic. This means that Junos OS creates only one policer
instance no maer how many mes the policer is referenced. When you do this, rate liming is applied
in aggregate, so if you congure a policer to discard trac that exceeds 1 Gbps and reference that
policer in three dierent terms, the total bandwidth allowed by the lter is 1 Gbps. However, the
behavior of a lter-specic policer is aected by how the rewall lter terms that reference the policer
are stored in ternary content addressable memory (TCAM). If you create a lter-specic policer and
reference it in mulple rewall lter terms, the policer allows more trac than expected if the terms are
stored in dierent TCAM slices. For example, if you congure a policer to discard trac that exceeds
1 Gbps and reference that policer in three dierent terms that are stored in three separate memory
slices, the total bandwidth allowed by the lter is 3 Gbps, not 1 Gbps.
To prevent this unexpected behavior from happening, use the informaon about TCAM slices above to
organize your conguraon le so that all the rewall lter terms that reference a given lter-specic
policer are stored in the same TCAM slice.
Planning for Filter-Based Forwarding
You can use rewall lters along with virtual roung instances to specify dierent routes for packets to
travel in their networks. To set up this feature–called lter-based forwarding, you specify a lter and
match criteria and then specify the virtual roung instance to send packets to. Filters used in this way
also consume memory in an addional TCAM. See
Understanding FIP Snooping, FBF, and MVR Filter
Scalability
for more informaon. The secon
FBF Filter VFP TCAM Consumpon
in this topic specically
addresses the number of supported lters when using lter-based forwarding.
1733
NOTE: Filter-based forwarding does not work with IPv6 interfaces on some Juniper switches.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release Descripon
19.4R2-EVO Starng in Junos OS Evolved Release 19.4R2, you can congure up to 2000 egress rewall lters on
the QFX5220 by including the egress-scale opon under the eracl-profile statement at the [edit
system packet-forwarding-option firewall] hierarchy level.
19.1R1 Starng in Junos OS Release 19.1R1, you can increase the number of egress VLAN rewall lters on
the QFX5110 from 1024 to 2048 by using the egress-to-ingress opon.
RELATED DOCUMENTATION
Understanding How Firewall Filters Are Evaluated | 856
Understanding Firewall Filter Planning | 1723
Conguring Firewall Filters | 1829
Understanding Filter-Based Forwarding | 1857
Firewall Filter Match Condions and Acons (QFX and EX Series
Switches)
IN THIS SECTION
Firewall Filter Match Condions and Acons (EX4100, EX4100-F, EX4400, EX4600, EX4650, QFX5100,
QFX5110, QFX5120, QFX5200, QFX5210, QFX5700) | 1735
Firewall Filter Match Condions and Acons (QFX5220 and the QFX5130-32CD) | 1765
1734
Firewall Filter Match Condions and Acons (EX4100, EX4100-F, EX4400, EX4600,
EX4650, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, QFX5700)
Each term in a rewall lter consists of
match condions
and an
acon
. Match condions are the elds
and values that a packet must contain to be considered a match. You can dene single or mulple match
condions in
match statements
. You can also include no match statement, in which case the term
matches all packets.
When a packet matches a lter, a switch takes the acon specied in the term. In addion, you can
specify acon modiers to count, mirror, rate-limit, and classify packets. If no match condions are
specied for the term, the switch accepts the packet by default.
• Table 96 on page 1737 describes the match condions you can specify when conguring a rewall
lter. Some of the numeric range and bit-eld match condions allow you to specify a text synonym.
To see a list of all the synonyms for a match condion, type ? at the appropriate place in a statement.
• Table 97 on page 1761 shows the acons that you can specify in a term.
• Table 98 on page 1762 shows the acon modiers you can use to count, mirror, rate-limit, and
classify packets.
For match condions on specic switches, these limitaons apply:
Table 95:
Limitaons
(QFX5100, QFX5110, QFX5200) When using lter-based forwarding on IPv6 interfaces, only these match
condions are supported in the (ingress direcon): source-address, destination-address, source-prefix-list,
destination-prefix-list, source-port, destination-port, hop-limit, icmp-type, and next-header.
(QFX5110) When you enable the egress-to-ingress opon under the [edit firewall] hierarchy, only accept,
discard, and count acons are supported.
(QFX5100, QFX5110, QFX5120, QFX5130-32CD, QFX5220, QFX5700) In an EVPN-VXLAN environment, only
these match condions are supported: source-address, destination-address, source-port, destination-port, ttl, ip-
protocol, and user-vlan-id.
(QFX5100, QFX5110, QFX5200) You cannot apply a rewall lter in the egress direcon on a EVPN-VXLAN IRB
interface.
(QFX5700) You cannot apply a rewall lter in the egress direcon on a loopback interface.
1735
(QFX5100, QFX5110) If you are using rewall lters to implement MAC ltering in an EVPN-VXLAN
environment, see
MAC Filtering, Storm Control, and Port Mirroring Support in an EVPN-VXLAN Environment
for
the supported match condions.
(QFX5100, QFX5110) For each rewall lter that you apply to a VXLAN, you can specify family ethernet-
switching to lter Layer 2 (Ethernet) packets, or family inet to lter on IRB interfaces. You cannot apply a rewall
lter in the egress direcon on IRB interfaces.
(EX4100, EX4400, EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210) Use only available
interfaces when using the interface match condion with the egress rewall lter on standalone devices. Using
unavailable interfaces will result in unexpected behavior.
On switches that do not support Layer 2 features, use only those match condions that are valid for IPv4 and
IPv6 interfaces.
(QFX5120, EX4650) Starng with Junos Release 21.4R1, the following match condions are supported in an
EVPN-VXLAN environment on QFX5120, and EX4650: gbp-src-tag, and gbp-dst-tag.
Starng in Junos OS Release 21.4R1, the source-port-range-opmize and the desnaon-port-range-opmize
condions are supported under [edit firewall family ethernet-switching filter <filter-name> term <term-name>
from] hierarchy level. This considerably reduces the TCAM space usage. In QFX5100 switches with source-port-
range-opmize and desnaon-port-range-opmize match condions congured, upto 24 non-conguous
source-port range and desnaon-port range match condions are supported. If more than 24 non-conguous
match condions are congured, it might throw an error.
Starng with Junos Release 22.4R1, the following match condions are supported for GBP tagging in an EVPN-
VXLAN environment on supported EX4100, EX4400, EX4650, and QFX5120 Series switches: ip-version ipv4,
ip-version ipv6, mac-address, vlan-id, interface + vlan-id combinaon, and interface.
Starng with Junos Release 23.2R1, new IPV4 and IPv6 L4 matches are supported for policy enforcement on the
EX4100 series, EX4400 series, EX4650 series, QFX5120-32C and QFX5120-48Y switches.
Starng in Junos OS Release 23.4R1 and later, the vlan-id
vlan list
|
vlan-range
and interface
interface-list
match
condions are supported for GBP tagging in an EVPN-VXLAN environment on supported EX4100, EX4400,
EX4650, and QFX5120 Series switches. The EX4100 switches do not support VLAN and PORT+VLAN based
GBP.
1736
Table 96: Supported Match Condions for Firewall Filters
Match Condion Descripon Direcon and Interface
arp-type
ARP request packet or ARP reply
packet.
Egress and ingress interfaces.
destination-address
ip-address
IP desnaon address eld, which is
the address of the nal desnaon
node.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces, and
IPv6 (inet6) interfaces.
destination-mac-address
mac-address
Desnaon media access control
(MAC) address of the packet.
Ingress ports, VLANs and IPv4
(inet) interfaces.
Egress ports and VLANs.
1737
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
destination-port
value
TCP or UDP desnaon port eld.
Typically, you specify this match in
conjuncon with the protocol match
statement. For the following well-
known ports you can specify text
synonyms (the port numbers are
also listed):
afs (1483), bgp (179), biff (512),
bootpc (68), bootps (67),
cmd (514), cvspserver (2401),
dhcp (67), domain (53),
eklogin (2105), ekshell (2106), exec
(512),
finger (79), ftp (21), ftp-data (20),
http (80), https (443),
ident (113), imap (143),
kerberos-sec (88), klogin (543),
kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544),
ldap (389), login (513),
mobileip-agent (434), mobilip-mn
(435), msdp (639),
netbios-dgm (138), netbios-ns (137),
netbios-ssn (139), nfsd (2049), nntp
(119), ntalk (518), ntp (123),
pop3 (110), pptp (1723), printer
(515),
radacct (1813),radius (1812), rip
(520), rkinit (2108),
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
1738
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
smtp (25), snmp (161), snmptrap (162),
snpp (444), socks (1080), ssh (22),
sunrpc (111), syslog (514),
tacacs-ds (65), talk (517), telnet
(23), tftp (69), timed (525),
who (513),
xdmcp (177),
zephyr-clt (2103), zephyr-hm (2104)
destination-port range-optimize
range
Match a range of TCP or UDP port
ranges while using the available
memory more eciently. Using this
condion allows you to congure
more rewall lters than if you
congure individual desnaon
ports. (Not supported with lter-
based forwarding.)
Ingress ports, VLANs, IPv4 (inet)
interfaces.
destination-prefix-list
prefix-list
IP desnaon prex list eld. You
can dene a list of IP address
prexes under a prex-list alias for
frequent use. Dene this list at the
[edit policy-options] hierarchy
level.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces and
IPv6 (inet6) interfaces.
1739
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
dscp
value
Dierenated Services code point
(DSCP). The DiServ protocol uses
the type-of-service (ToS) byte in the
IP header. The most-signicant 6
bits of this byte form the DSCP.
You can specify DSCP in
hexadecimal, binary, or decimal
form.
In place of the numeric value, you
can specify one of the following text
synonyms (the eld values are also
listed):
• be—best eort (default)
• ef (46)—as dened in RFC 3246,
An Expedited Forwarding PHB
.
• af11 (10), af12 (12), af13 (14);
af21 (18), af22 (20), af23 (22);
af31 (26), af32 (28), af33 (30);
af41 (34), af42 (36), af43 (38)
These four classes, with three
drop precedences in each class,
for a total of 12 code points, are
dened in RFC 2597,
Assured
Forwarding PHB
.
• cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7,
cs5
Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
1740
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
ether-type
value
Ethernet type eld of a packet. The
EtherType value species what
protocol is being transported in the
Ethernet frame. In place of the
numeric value, you can specify one
of the following text synonyms (the
eld values are also listed):
• aarp (0x80F3)—EtherType value
AARP
• appletalk (0x809B)—EtherType
value AppleTalk
• arp (0x0806)—EtherType value
ARP
• fcoe (0x8906)—EtherType value
FCoE
• fip (0x8914)—EtherType value
FIP
• ipv4 (0x0800)—EtherType value
IPv4
• ipv6 (0x08DD)—EtherType value
IPv6
• mpls-multicast (0x8848)—
EtherType value MPLS mulcast
• mpls-unicast (0x8847)—
EtherType value MPLS unicast
• oam (0x88A8)—EtherType value
OAM
• ppp (0x880B)—EtherType value
PPP
Ingress ports and VLANs.
Egress ports and VLANs.
1741
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
• pppoe-discovery (0x8863)—
EtherType value PPPoE
Discovery Stage
• pppoe-session (0x8864)—
EtherType value PPPoE Session
Stage
• sna (0x80D5)—EtherType value
SNA
egress-to-ingress
Include this opon to increase the
number of egress VLAN rewall
lter terms from 1024 to 2048.
Egress VLAN IPv4 (inet) interfaces
and IPv6 (inet6) interfaces.
exp
Match on MPLS EXP bits. Ingress MPLS interfaces.
Egress MPLS interfaces.
fragment-flags
value
IP fragmentaon ags. In place of
the numeric value, you can specify
one of the following text synonyms
(the hexadecimal values are also
listed):
• is-fragment
• dont-fragment (0x4000)
• more-fragments (0x2000)
• reserved (0x8000)
Ingress ports and VLANs.
gbp-dst-tag
Match the desnaon tag, for use
with micro-segmentaon on a
VXLAN, as described here: Example:
Micro and Macro Segmentaon
using Group Based Policy in a
VXLAN.
Not applicable
1742
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
gbp-src-tag
Match the source tag, for use with
micro-segmentaon on a VXLAN, as
described here: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN.
Not applicable
1743
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
icmp-code
value
ICMP code eld. Because the
meaning of the value depends upon
the associated icmp-type, you must
specify a value for icmp-type along
with a value for icmp-code. In place
of the numeric value, you can
specify one of the following text
synonyms (the eld values are also
listed). The keywords are grouped
by the ICMP type with which they
are associated:
•
IPv4:
parameter-problem—ip-
header-bad (0), required-option-
missing (1)
•
IPv6:
parameter-problem—ip6-
header-bad (0), unrecognized-
next-header (1), unrecognized-
option (2)
• redirect—redirect-for-network
(0), redirect-for-host (1),
redirect-for-tos-and-net (2),
redirect-for-tos-and-host (3)
• time-exceeded—ttl-eq-zero-
during-reassembly (1), ttl-eq-
zero-during-transit (0)
•
IPv4:
unreachable—network-
unreachable (0), host-unreachable
(1), protocol-unreachable (2),
port-unreachable (3),
fragmentation-needed (4), source-
route-failed (5), destination-
network-unknown (6), destination-
host-unknown (7), source-host-
isolated (8)
,
destination-
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
1744
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
network-prohibited (9),
destination-host-prohibited (10),
network-unreachable-for-TOS (11),
host-unreachable-for-TOS (12),
communication-prohibited-by-
filtering (13), host-precedence-
violation (14), precedence-
cutoff-in-effect (15)
•
IPv6:
unreachable—address-
unreachable (3),
administratively-prohibited (1),
no-route-to-destination (0),
port-unreachable (4)
hop-limit
value
Match the specied hop limit or set
of hop limits. Specify a single value
or a range of values from 0 through
255.
Ingress and egress IPv6 (inet6)
interfaces.
NOTE: Not supported in the
egress direcon on the QFX3500,
QFX3600, QFX5100, QFX5120,
QFX5110, QFX5200, and
QFX5210 switches.
ip-version ipv4
<ip address>
|
<prefix-list>
ip-version ipv6
<ip address>
|
<prefix-list>
Match the IPv4 or IPv6 source or
desnaon address, for use with
micro-segmentaon on a VXLAN, as
described here: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress and egress (system wide).
ip-version ipv4 destination-port
DST_PORT
Match the TCP/UDP desnaon
port, for use with GBP policy lter
L4 matches, as described in:
Example: Micro and Macro
Segmentaon using Group Based
Policy in a VXLAN
Ingress only.
1745
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
ip-version ipv4 source-port
SRC_PORT
Match the TCP/UDP source port,
for use with for use with GBP policy
lter L4 matches, as described in:
Example: Micro and Macro
Segmentaon using Group Based
Policy in a VXLAN
Ingress only.
ip-version ipv4 ip-protocol
PROTOCOL
Match the IP protocol type, for use
with GBP policy lter L4 matches, as
described in: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress only.
ip-version ipv4 is-fragment
Match if the packet is a fragment,
for use with GBP policy lter L4
matches, as described in: Example:
Micro and Macro Segmentaon
using Group Based Policy in a
VXLAN
Ingress only.
ip-version ipv4 fragment-flag
FLAGS
Match the fragment ags (in
symbolic or hex formats), for use
with GBP policy lter L4 matches, as
described in: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress only.
ip-version ipv4 ttl
Value
IP Time-to-live (TTL) eld in decimal.
The value can be 1-255. For use
with GBP policy lter L4 matches, as
described in: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress only.
1746
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
ip-version ipv4 tcp-flags
FLAGS
Match one or more TCP ags (in
symbolic or hex formats), for use
with GBP policy L4 matches, as
described in: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress only.
ip-version ipv4 tcp-initial
Match the rst TCP packet of a
connecon. For use with GBP policy
L4 matches, as described in:
Example: Micro and Macro
Segmentaon using Group Based
Policy in a VXLAN
Ingress only.
ip-version ipv4 tcp-established
Match the packets of an established
TCP connecon, for use with GBP
policy L4 matches, as described in:
Example: Micro and Macro
Segmentaon using Group Based
Policy in a VXLAN
Ingress only.
ip-version ipv6 source-port
SRC_PORT
Match the TCP/UDP source port,
for use with GBP policy L4 matches,
as described in: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress only.
ip-version ipv6 destination-port
DST_PORT
Match the TCP/UDP desnaon
port, for use with for use with GBP
policy lter L4 matches, as
described in: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress only.
1747
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
ip-version ipv6 next-header
PROTOCOL
Match the next header protocol
type, for use with GBP policy L4
matches, as described in: Example:
Micro and Macro Segmentaon
using Group Based Policy in a
VXLAN
Ingress only.
ip-version ipv6 tcp-flags
FLAGS
Match the TCP ags, for use with
GBP policy L4 matches, as described
in: Example: Micro and Macro
Segmentaon using Group Based
Policy in a VXLAN
Ingress only.
ip-version ipv6 tcp-initial
Match the inial packets of an
established TCP connecon, as
described in: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN
Ingress only.
ip-version ipv6 tcp-established
Match the packets of an established
TCP connecon, as described in:
Example: Micro and Macro
Segmentaon using Group Based
Policy in a VXLAN
Ingress only.
1748
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
icmp-type
value
ICMP message type eld. Typically,
you specify this match in
conjuncon with the protocol match
statement to determine which
protocol is being used on the port.
In place of the numeric value, you
can specify one of the following text
synonyms (the eld values are also
listed):
IPv4:
echo-reply (0), destination
unreachable (3), source-quench (4),
redirect (5), echo-request (8), IPv4
(inet)-advertisement (9), IPv4
(inet)-solicit (10), time-exceeded
(11), parameter-problem (12),
timestamp (13), timestamp-reply (14),
info-request (15), info-reply (16),
mask-request (17), mask-reply (18)
IPv6:
destination-unreachable (1),
packet-too-big (2), time-exceeded
(3), parameter-problem (4), echo-
request (128), echo-reply (129),
membership-query (130), membership-
report (131), membership-termination
(132), router-solicit (133), router-
advertisement (134), neighbor-solicit
(135), neighbor-advertisement (136),
redirect (137), router-renumbering
(138), node-information-request
(139), node-information-reply (140)
See also icmp-code
variable
.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
1749
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
interface
interface-name |
<interface_list>
Interface on which the packet is
received, including the logical unit.
You can include the wildcard
character (*) as part of an interface
name or logical unit.
NOTE: An interface from which a
packet is sent cannot be used as a
match condion.
Match a list of interfaces under the
same term in a lter. For use with
micro-segmentaon on a VXLAN, as
described here: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces and
IPv6 (inet6) interfaces.
ip-destination-address
address
IPv4 address that is the nal
desnaon node address for the
packet.
Ingress ports and VLANs.
ip6-destination-address
address
IPv6 address that is the nal
desnaon node address for the
packet.
Ingress ports and VLANs. (You
cannot simultaneously apply a
lter with this match criterion to a
Layer 2 port and VLAN that
includes that port.)
ip-options Specify any to create a match if
anything is specied in the opons
eld in the IP header.
Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
1750
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
ip-precedence
ip-precedence-field
IP precedence eld. In place of the
numeric eld value, you can specify
one of the following text synonyms
(the eld values are also listed):
critical-ecp (0xa0), flash (0x60),
flash-override (0x80), immediate
(0x40), internet-control (0xc0), net-
control (0xe0), priority (0x20), or
routine (0x00).
Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
ip-protocol
number
IP protocol eld. Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
ip-source-address
address
IPv4 address of the source node
sending the packet.
Ingress ports and VLANs.
ip6-source-address
address
IPv6 address of the source node
sending the packet.
Ingress ports and VLANs. (You
cannot simultaneously apply a
lter with this match criterion to a
Layer 2 port and VLAN that
includes that port.)
ip-version
address
IP version of the packet. Use this
condion to match IPv4 or IPv6
header elds in trac that arrives
on a Layer 2 port or VLAN interface.
Ingress ports and VLANs.
is-fragment
Using this condion causes a match
if the More Fragments ag is
enabled in the IP header or if the
fragment oset is not zero.
Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
1751
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
l2-encap-type llc-non-snap
Match on logical link control (LLC)
layer packets for non-Subnet Access
Protocol (SNAP) Ethernet
Encapsulaon type.
Ingress ports and VLANs.
Egress ports and VLANs.
label
Match on MPLS label bits. Ingress MPLS interfaces.
Egress MPLS interfaces.
learn-vlan-id
number
Matches the ID of a normal VLAN
or the ID of the outer (service)
VLAN (for Q-in-Q VLANs). The
acceptable values are 1-4095.
NOTE: Not supported on QFX3600,
QFX5100, QFX5110, QFX5120,
QFX5200, QFX5210, QFX5220,
EX4600, EX4650, EX4400, EX4100
and EX4300-MP switches. Use the
user-vlan-id match condion to
match the outer VLAN ID.
Ingress ports and VLANs.
Egress ports and VLANs.
mac-address
mac-address
Match the source media access
control (MAC) address, for use with
micro-segmentaon on a VXLAN, as
described here: Example: Micro and
Macro Segmentaon using Group
Based Policy in a VXLAN.
Ingress and egress (system wide)
.
1752
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
next-header
IPv4 or IPv6 protocol value. In place
of the numeric value, you can
specify one of the following text
synonyms (the numeric values are
also listed):
hop-by-hop (0),icmp (1), icmp6 (58),
igmp (2), ipip (4), tcp (6), egp (8),
udp (17), ipv6 (41), routing (43),
fragment (44),rsvp (46), gre (47), esp
(50), ah (51), icmp6 (58), no-next-
header (59), dstopts (60), ospf (89),
pim (103), vrrp (112), sctp (132)
Ingress ports, VLANs, and IPv6
(inet6) interfaces.
Egress IPv6 (inet6) interfaces.
packet-length
Packet length in bytes. You must
enter a value between 0 and 65535.
Ingress ports, VLANs, IPv4 (inet),
and IPv6 (inet6) interfaces.
Egress IPv4 (inet) interfaces.
payload-protocol
IPv4 or IPv6 protocol value. In place
of the numeric value, you can
specify one of the following text
synonyms (the numeric values are
also listed):
hop-by-hop (0),icmp (1), icmp6 (58),
igmp (2), ipip (4), tcp (6), egp (8),
udp (17), ipv6 (41), routing (43),
fragment (44),rsvp (46), gre (47), esp
(50), ah (51), icmp6 (58), no-next-
header (59), dstopts (60), ospf (89),
pim (103), vrrp (112), sctp (132)
NOTE: Not supported on the
QFX3500, QFX3600, QFX5100,
QFX5110, QFX5200, QFX5210
switches.
Ingress ports, VLANs, and IPv6
(inet6) interfaces.
Egress IPv6 (inet6) interfaces.
1753
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
Port qualifier
The port qualier will install two
entries in the packet forwarding
engine. One with the source-port
and second one with the
desnaon-port.
NOTE: Port qualier is not
supported on EX4400, EX4300,
EX4100, EX4300 (Mulgigabit PoE),
EX2300, EX2300 (Mulgigabit PoE),
and EX3400 plaorms.
Ingress ports, VLANs, IPv4 (inet),
and IPv6 (inet6) interfaces.
Egress IPv4 (inet) interfaces.
precedence
value
IP precedence bits in the type-of-
service (ToS) byte in the IP header.
(This byte can also used for the
DiServ DSCP.) In place of the
numeric value, you can specify one
of the following text synonyms (the
numeric values are also listed):
• routine (0)
• priority (1)
• immediate (2)
• flash (3)
• flash-override (4)
• critical-ecp (5)
• internet-control (6)
• net-control (7)
Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
1754
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
protocol
type
IPv4 or IPv6 protocol value. In place
of the numeric value, you can
specify one of the following text
synonyms (the numeric values are
also listed):
hop-by-hop (0),icmp (1), icmp6, igmp
(2), ipip (4), tcp (6), egp (8), udp
(17), ipv6 (41), routing (43),
fragment (44),rsvp (46), gre (47), esp
(50), ah (51), icmp6 (58), no-next-
header (59), dstopts (60), ospf (89),
pim (103), vrrp (112), sctp (132)
Ingress ports, VLANs and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
1755
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
rat-type
tech-type-value
Match the radio-access technology
(RAT) type specied in the 8-bit
Tech-Type eld of Proxy Mobile
IPv4 (PMIPv4) access technology
type extension. The technology type
species the access technology
through which the mobile device is
connected to the access network.
Specify a single value, a range of
values, or a set of values. You can
specify a technology type as a
numeric value from 0 through 255
or as a system keyword.
•
Numeric value 1 matches IEEE
802.3.
•
Numeric value 2 matches IEEE
802.11a/b/g.
• Numeric value 3 matches IEEE
802.16e
• Numeric value 4 matches IEEE
802.16m.
• Text string eutran matches 4G.
• Text string geran matches 2G.
• Text string utran matches 3G.
Egress and ingress IPv4 (inet)
interfaces.
sample
Sample the packet trac. Apply this
opon only if you have enabled
trac sampling.
Egress and ingress IPv4 (inet)
interfaces.
source-address
ip-address
IP source address eld, which is the
address of the node that sent the
packet.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
1756
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
source-mac-address
mac-address
Source media access control (MAC)
address of the packet.
Ingress ports and VLANs.
Egress ports and VLANs.
source-port
value
TCP or UDP source port. Typically,
you specify this match in
conjuncon with the protocol match
statement. In place of the numeric
eld, you can specify one of the text
synonyms listed under destination-
port.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
source-port range-optimize
range
Match a range of TCP or UDP port
ranges while using the available
memory more eciently. Using this
condion allows you to congure
more rewall lters than if you
congure individual source ports.
(Not supported with lter-based
forwarding.)
Ingress ports, VLANs, IPv4 (inet)
interfaces.
source-prefix-list
prefix-list
IP source prex list. You can dene a
list of IP address prexes under a
prex-list alias for frequent use.
Dene this list at the [edit policy-
options] hierarchy level.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
1757
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
tcp-established
Matches packets of an established
TCP three-way handshake
connecon (SYN, SYN-ACK, ACK).
The only packet not matched is the
rst packet of the handshake since
only the SYN bit is set. For this
packet, you must specify tcp-initial
as the match condion.
When you specify tcp-established,
the switch does not implicitly verify
that the protocol is TCP. You must
also specify the protocol tcp match
condion.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
tcp-flags
value
One or more TCP ags:
• ack (0x10)
• fin (0x01)
• push (0x08)
• rst (0x04)
• syn (0x02)
• urgent (0x20)
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
tcp-initial
Match the rst TCP packet of a
connecon. A match occurs when
the TCP ag SYN is set and the TCP
ag ACK is not set.
When you specify tcp-initial, a
switch does not implicitly verify that
the protocol is TCP. You must also
specify the protocol tcp match
condion.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
1758
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
traffic-class
8-bit eld that species the class-of-
service (CoS) priority of the packet.
The trac-class eld is used to
specify a DiServ code point (DSCP)
value. This eld was previously used
as the type-of-service (ToS) eld in
IPv4, and, the semancs of this eld
(for example, DSCP) are idencal to
those of IPv4.
You can specify one of the following
text synonyms (the eld values are
also listed):
af11 (10), af12 (12), af13 (14), af21
(18), af22 (20), af23 (22), af31 (26),
af32 (28), af33 (30), af41 (34), af42
(36), af43 (38), cs0 (0), cs1 (8), cs2
(16), cs3 (24), cs4 (32), cs5 (40), cs6
(48), cs7 (56), ef (46)
Ingress ports, VLANs, and IPv6
(inet6) interfaces.
Egress IPv6 (inet6) interfaces.
ttl
value
IP Time-to-live (TTL) eld in decimal.
The value can be 1-255.
Ingress IPv4 (inet) interfaces.
Egress IPv4 (inet) interfaces.
user-vlan-1p-priority
value
Matches the specied 802.1p VLAN
priority in the range 0-7.
Ingress and egress ports and
VLANs.
1759
Table 96: Supported Match Condions for Firewall Filters
(Connued)
Match Condion Descripon Direcon and Interface
user-vlan-id
number
Matches the ID of the inner
(customer) VLAN for a Q-in-Q
VLAN. The acceptable values are
1-4095.
NOTE: For QFX3600, QFX5100,
QFX5110, QFX5120, QFX5200,
QFX5210, EX4600, EX4650,
EX4400, EX4100 and EX4300-MP
switches, use user-vlan-id to match
the ID of the outer VLAN.
For QFX5220 Series switches, and
MX and ACX Series routers, use
learn
-vlan-id to match the ID of the
outer VLAN, and user-vlan-id to
match the ID of the inner VLAN.
Previously, you could use user-vlan-
id to match the outer VLAN ID.
Ingress and egress ports and
VLANs.
vlan-id
<vlan id> | <vlan-range> |
<vlan list>
Match the VLAN idener,
vlan-
range
(the rst and last VLAN ID
number for the group of VLANs), or
vlan list
(list of numbers) for use
with micro-segmentaon on a
VXLAN, as described here: Example:
Micro and Macro Segmentaon
using Group Based Policy in a
VXLAN.
NOTE: Not supported on the
EX4100 switches.
Ingress and egress (system wide)
Use then statements to dene acons that should occur if a packet matches all condions in a from
statement. Table 97 on page 1761shows the acons that you can specify in a term. (If you do not
include a then statement, the system accepts packets that match the lter.)
1760
Table 97: Acons for Firewall Filters
Acon Descripon
accept
Accept a packet. This is the default acon for packets that
match a term.
discard
Discard a packet silently without sending an Internet Control
Message Protocol (ICMP) message.
reject
message-type
Discard a packet and send a “desnaon unreachable” ICMPv4
message (type 3). To log rejected packets, congure the syslog
acon modier.
You can specify one of the following message types:
administratively-prohibited (default), bad-host-tos, bad-
network-tos, host-prohibited, host-unknown, host-unreachable,
network-prohibited, network-unknown, network-unreachable, port-
unreachable, precedence-cutoff, precedence-violation, protocol-
unreachable, source-host-isolated, source-route-failed, or tcp-
reset.
If you specify tcp-reset, the system sends a TCP reset if the
packet is a TCP packet; otherwise nothing is sent.
If you do not specify a message type, the ICMP nocaon
“desnaon unreachable” is sent with the default message
“communicaon administravely ltered.”
NOTE: The reject acon is supported on ingress interfaces only.
routing-instance
instance-name
Forward matched packets to a virtual roung instance.
vlan
VLAN-name
Forward matched packets to a specic VLAN.
NOTE: The vlan acon is supported on ingress interfaces only.
NOTE: This acon is not supported on OCX series switches.
You can also specify the acon modiers listed in Table 98 on page 1762 to count, mirror, rate-limit, and
classify packets.
1761
Table 98: Acon Modiers for Firewall Filters
Acon Modier Descripon
analyzer
analyzer-name
(Non-ELS plaorms) Mirror trac (copy packets) to an analyzer
congured at the [edit ethernet-switching-options analyzer]
hierarchy level.
You can specify port mirroring for ingress port, VLAN, and IPv4
(inet) rewall lters only.
count
counter-name
Count the number of packets that match the term.
decapsulate [gre |
routing-instance
]
De-encapsulate GRE packets or forward de-encapsulated GRE
packets to the specied roung instance
dscp
value
Dierenated Services code point (DSCP). The DiServ protocol
uses the type-of-service (ToS) byte in the IP header. The most-
signicant 6 bits of this byte form the DSCP.
You can specify DSCP in hexadecimal, binary, or decimal form.
In place of the numeric value, you can specify one of the
following text synonyms (the eld values are also listed):
• be—best eort (default)
• ef (46)—as dened in RFC 3246,
An Expedited Forwarding
PHB
.
• af11 (10), af12 (12), af13 (14);
af21 (18), af22 (20), af23 (22);
af31 (26), af32 (28), af33 (30);
af41 (34), af42 (36), af43 (38)
These four classes, with three drop precedences in each
class, for a total of 12 code points, are dened in RFC 2597,
Assured Forwarding PHB
.
• cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, cs5
1762
Table 98: Acon Modiers for Firewall Filters
(Connued)
Acon Modier Descripon
forwarding-class
class
Classify the packet in one of the following default forwarding
classes, or in a user-dened forwarding class:
• best-effort
• fcoe
• mcast
• network-control
• no-loss
NOTE: To congure a forwarding class, you must also congure
loss priority.
gbp-src-tag
(QFX5120 and EX4650 only)
Set the group based policy source tag (0..65535) for use with
micro-segmentaon on VXLAN, as described here: Example:
Micro and Macro Segmentaon using Group Based Policy in a
VXLAN.
gbp-tag
(EX4100, EX4400, EX4650 and QFX5120)
Set the group based policy source tag (1..65535) for use with
micro-segmentaon on VXLAN, as described here: Example:
Micro and Macro Segmentaon using Group Based Policy in a
VXLAN.
NOTE: Applies to Junos OS releases 22.4R1 and later.
interface
Switch the trac to the specied interface without performing a
lookup on it. This acon is valid only when the lter is applied
on ingress.
log
Log the packet's header informaon in the Roung Engine. To
view this informaon, enter the show firewall log operaonal
mode command.
NOTE: The log acon modier is supported on ingress
interfaces only.
1763
Table 98: Acon Modiers for Firewall Filters
(Connued)
Acon Modier Descripon
loss-priority (low | medium-low | medium-high
| high)
Set the packet loss priority (PLP).
NOTE: The loss-priority acon modier is supported on ingress
interfaces only.
NOTE: The loss-priority acon modier is not supported in
combinaon with the policer acon.
policer
policer-name
Send packets to a policer (for the purpose of applying rate
liming).
You can specify a policer for ingress port, VLAN, IPv4 (inet), IPv6
(inet6), and MPLS lters.
NOTE: The policer acon modier is not supported in
combinaon with the loss-priority acon.
port-mirror
(ELS plaorms) Mirror trac (copy packets) to an output
interface congured in a port-mirroring instance at the [edit
forwarding-options port-mirroring] hierarchy level.
You can specify port mirroring for ingress port, VLAN, and IPv4
(inet) rewall lters only.
port-mirror-instance
port-mirror-instance-
name
(ELS plaorms) Mirror trac to a port-mirroring instance
congured at the [edit forwarding-options port-mirroring]
hierarchy level.
You can specify port mirroring for ingress port, VLAN, and IPv4
(inet) rewall lters only.
NOTE: This acon modier is not supported on OCX series
switches.
syslog
Log an alert for this packet.
NOTE: The syslog acon modier is supported on ingress
interfaces only.
1764
Table 98: Acon Modiers for Firewall Filters
(Connued)
Acon Modier Descripon
three-color-policer
three-color-policer-name
Send packets to a three-color policer (for the purpose of
applying rate liming).
You can specify a three-color policer for ingress and egress port,
VLAN, IPv4 (inet), IPv6 (inet6), and MPLS lters.
NOTE: The policer acon modier is not supported in
combinaon with the loss-priority acon.
SEE ALSO
Firewall Filter Flexible Match Condions | 864
Firewall Filter Match Condions and Acons (QFX5220 and the QFX5130-32CD)
This topic describes the supported rewall lter match condions, acons, and acon modiers for the
QFX5220-CD, QFX5220-128C, and QFX5130-32CD switches.
Each term in a rewall lter consists of
match condions
and an
acon
. Match condions are the elds
and values that a packet must contain to be considered a match. You can dene single or mulple match
condions in
match statements
. You can also include no match statement, in which case the term
matches all packets.
When a packet matches a lter, a switch takes the acon specied in the term. If you apply no match
condion, the switch accepts the packet by default.
• Table 99 on page 1766 shows the match condions for IPv4 (inet) and the IPv6 (inet6) interfaces. It
also contains the match condions for ports and VLANs (ethernet-switching).
• Table 100 on page 1780 shows the acons and the acon modiers that you can specify in a term.
NOTE: For match condions, some of the numeric range and the bit-eld match condions allow
you to specify a text synonym. To see a list of all the synonyms for a match condion, type ? at
the appropriate place in a statement.
1765
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
Match
Condit
ion
Descripon Direcon and Interface
arp-
type
ARP request packet or an ARP reply packet. Ingress and egress ports and VLANs
destin
ation-
addres
s
ip-
addres
s
IP desnaon address eld, which is the address of the
nal desnaon node.
Ingress and egress IPv4 and IPv6 interfaces
Ingress ports and VLANs
destin
ation-
mac-
addres
s
mac-
addres
s
Desnaon MAC address of the packet. Ingress and egress ports and VLANs
1766
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
destin
ation-
port
value
TCP or UDP desnaon port eld. You must specify this
match with the protocol match statement for IPv4 trac,
or the next-header match statement for IPv6 trac.
For the following well-known ports and port numbers you
can specify text synonyms.
afs (1483), bgp (179), biff (512), bootpc (68), bootps (67),
cmd (514), cvspserver (2401),
dhcp (67), domain (53),
eklogin (2105), ekshell (2106), exec (512),
finger (79), ftp (21), ftp-data (20),
http (80), https (443),
ident (113), imap (143),
kerberos-sec (88), klogin (543), kpasswd (761), krb-prop
(754), krbupdate (760), kshell (544),
ldap (389), login (513),
mobileip-agent (434), mobilip-mn (435), msdp (639),
netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123),
pop3 (110), pptp (1723), printer (515),
radacct (1813),radius (1812), rip (520), rkinit (2108),
smtp (25), snmp (161), snmptrap (162), snpp (444), socks
(1080), ssh (22), sunrpc (111), syslog (514),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed
(525),
who (513),
Ingress and egress IPv4 interfaces
Ingress IPv6 interfaces.
Ingress ports and VLANs
1767
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
xdmcp (177),
zephyr-clt (2103), zephyr-hm (2104)
destin
ation-
port
range-
optimi
ze
range
Match a range of the TCP or UDP port ranges while using
the available memory more eciently. Using this
condion allows you to congure more rewall lters
than if you congure individual desnaon ports. (Not
supported with lter-based forwarding.)
Ingress IPv4 interfaces
destin
ation-
prefix
-list
prefix
-list
IP desnaon prex list eld. You can dene a list of IP
address prexes under a prex-list alias for frequent use.
Dene this list at the [edit policy-options] hierarchy
level.
Ingress and egress IPv4 and IPv6 interfaces
Ingress ports and VLANs.
1768
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
dscp
value
Dierenated Services code point (DSCP). The DiServ
protocol uses the type-of-service (ToS) byte in the IP
header. The most-signicant 6 bits of this byte form the
DSCP.
You can specify DSCP in hexadecimal, binary, or decimal
form.
In place of the numeric value, you can specify one of the
following text synonyms and eld listed.
• be—best eort (default)
• ef (46)—as dened in RFC 3246,
An Expedited
Forwarding PHB
.
• af11 (10), af12 (12), af13 (14);
af21 (18), af22 (20), af23 (22);
af31 (26), af32 (28), af33 (30);
af41 (34), af42 (36), af43 (38)
These four classes, with three drop precedences in
each class, for a total of 12 code points, are dened in
RFC 2597,
Assured Forwarding PHB
.
• cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, cs5
Ingress and egress IPv4 interfaces
Ingress ports and VLANs
1769
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
ether-
type
value
Ethernet type eld of a packet. The EtherType value
species what protocol is being transported in the
Ethernet frame. In place of the numeric value, you can
specify one of the following text synonyms. The eld
values are also listed.
• aarp (0x80F3)—EtherType value AARP
• appletalk (0x809B)—EtherType value AppleTalk
• arp (0x0806)—EtherType value ARP
• fcoe (0x8906)—EtherType value FCoE
• fip (0x8914)—EtherType value FIP
• ipv4 (0x0800)—EtherType value IPv4
• ipv6 (0x08DD)—EtherType value IPv6
• mpls-multicast (0x8848)—EtherType value MPLS
mulcast
• mpls-unicast (0x8847)—EtherType value MPLS unicast
• oam (0x88A8)—EtherType value OAM
• ppp (0x880B)—EtherType value PPP
• pppoe-discovery (0x8863)—EtherType value PPPoE
Discovery Stage
• pppoe-session (0x8864)—EtherType value PPPoE
Session Stage
• sna (0x80D5)—EtherType value SNA
Ingress and egress ports and VLANs
1770
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
rst-
fragm
ent
Match if the packet is the rst fragment of a fragmented
packet. Avoiding matching the packet if it is a trailing
fragment of a fragmented packet. The rst fragment of a
fragmented packet has a fragment oset value of 0.
This match condion is an alias for the bit-eld match
condion fragment-oset 0 match condion.
To match both rst and trailing fragments, you can use
two terms that specify dierent match condions: first-
fragment and is-fragment.
Ingress IPv4 interfaces
1771
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
icmp-
code
value
ICMP code eld. Because the meaning of the value
depends upon the associated icmp-type, you must specify
a value for icmp-type along with a value for icmp-code. In
place of the numeric value, you can specify one of the
following text synonyms (the eld values are also listed).
The keywords are grouped by the ICMP type with which
they are associated:
•
IPv4:
parameter-problem—ip-header-bad (0),
required-option-missing (1)
•
IPv6:
parameter-problem—ip6-header-bad (0),
unrecognized-next-header (1), unrecognized-option (2)
• redirect—redirect-for-network (0), redirect-for-host
(1), redirect-for-tos-and-net (2), redirect-for-tos-
and-host (3)
• time-exceeded—ttl-eq-zero- during-reassembly (1),
ttl-eq-zero-during-transit (0)
•
IPv4:
unreachable—network-unreachable (0), host-
unreachable (1), protocol-unreachable (2), port-
unreachable (3), fragmentation-needed (4), source-
route-failed (5), destination-network-unknown (6),
destination-host-unknown (7), source-host-isolated
(8), destination-network-prohibited (9), destination-
host-prohibited (10), network-unreachable-for-TOS
(11), host-unreachable-for-TOS (12), communication-
prohibited-by-filtering (13), host-precedence-
violation (14), precedence-cutoff-in-effect (15)
•
IPv6:
unreachable—address-unreachable (3),
administratively-prohibited (1), no-route-to-
destination (0), port-unreachable (4)
Ingress and egress IPv4 interfaces
Ingress IPv6 interfaces
Ingress ports and VLANs
1772
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
icmp-
type
value
ICMP message type eld. You must specify this match
along with the protocol match statement. This match
determines which protocol is being used on the port for
IPv4 trac, or the next-header match statement for IPv6
trac.
In place of the numeric value, you can specify one of the
following text synonyms (the eld values are also listed):
IPv4:
echo-reply (0), destination unreachable (3), source-
quench (4), redirect (5), echo-request (8), IPv4 (inet)-
advertisement (9), IPv4 (inet)-solicit (10), time-exceeded
(11), parameter-problem (12), timestamp (13), timestamp-
reply (14), info-request (15), info-reply (16), mask-
request (17), mask-reply (18)
IPv6:
destination-unreachable (1), packet-too-big (2),
time-exceeded (3), parameter-problem (4), echo-request
(128), echo-reply (129), membership-query (130),
membership-report (131), membership-termination (132),
router-solicit (133), router-advertisement (134),
neighbor-solicit (135), neighbor-advertisement (136),
redirect (137), router-renumbering (138), node-
information-request (139), node-information-reply (140)
See also icmp-code
variable
.
Ingress and egress IPv4 interfaces
Ingress IPv6 interfaces
Ingress ports and VLANs
interf
ace
interf
ace-
name
Interface on which the packet is received, including the
logical unit. You can include the wildcard character (*) as
part of an interface name or logical unit.
NOTE: An interface from which a packet is sent cannot
be used as a match condion.
Ingress ports and VLANs
1773
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
ip-
destin
ation-
addres
s
addres
s
IPv4 address that is the nal desnaon node address for
the packet.
Ingress ports and VLANs
ip-
option
s
Specify any to create a match if anything is specied in
the opons eld in the IP header.
Ingress IPv4 interfaces
ip-
protoc
ol
number
IP protocol eld. Ingress ports and VLANs
ip-
preced
ence
ip-
preced
ence-
field
IP precedence eld. In place of the numeric eld value,
you can specify one of the following text synonyms (the
eld values are also listed): critical-ecp (0xa0), flash
(0x60), flash-override (0x80), immediate (0x40), internet-
control (0xc0), net-control (0xe0), priority (0x20), or
routine (0x00).
Ingress ports and VLANs
ip-
source
-
addres
s
addres
s
IPv4 address of the source node sending the packet. Ingress ports and VLANs
1774
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
ip-
versio
n
addres
s
IP version of the packet. Use this condion to match IPv4
or IPv6 header elds in trac that arrives on a Layer 2
port or VLAN interface.
Ingress ports and VLANs
is-
fragme
nt
Using this condion causes a match if the More
Fragments ag is enabled in the IP header or if the
fragment oset is not zero.
Ingress and egress IPv4 interfaces
(QFX5220)
Ingress IPv4 interfaces (QFX5130)
learn-
vlan-
id
number
VLAN idener for MAC learning. Ingress and egress ports and VLANs
(QFX5220)
Ingress ports and VLANS (QFX5130)
learn-
vlan-1
p-
priori
ty
value
Match on the IEEE 802.1p learned VLAN priority bits in
the provider VLAN tag (the only tag in a single-tag frame
with 802.1Q VLAN tags or the outer tag in a dual-tag
frame with 802.1Q VLAN tags). Specify a single value or
mulple values from 0 through 7.
Ingress ports and VLANs
next-
header
IPv4 or IPv6 protocol value. In place of the numeric value,
you can specify one of the following text synonyms (the
numeric values are also listed):
hop-by-hop (0),icmp (1), icmp6 (58), igmp (2), ipip (4), tcp
(6), egp (8), udp (17), ipv6 (41), routing (43), fragment
(44),rsvp (46), gre (47), esp (50), ah (51), icmp6 (58), no-
next-header (59), dstopts (60), ospf (89), pim (103), vrrp
(112), sctp (132)
Ingress and egress IPv6 interfaces
1775
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
packet
-
length
Packet length in bytes. You must enter a value between 0
and 65535.
Ingress IPv4 and IPv6 interfaces
preced
ence
value
IP precedence bits in the type-of-service (ToS) byte in the
IP header. (This byte can also used for the DiServ DSCP.)
In place of the numeric value, you can specify one of the
following text synonyms (the numeric values are also
listed):
• routine (0)
• priority (1)
• immediate (2)
• flash (3)
• flash-override (4)
• critical-ecp (5)
• internet-control (6)
• net-control (7)
Ingress and egress IPv4 interfaces
protoc
ol
type
IP protocol value. In place of the numeric value, you can
specify one of the following text synonyms (the numeric
values are also listed):
hop-by-hop (0),icmp (1), icmp6, igmp (2), ipip (4), tcp (6),
egp (8), udp (17), ipv6 (41), routing (43), fragment
(44),rsvp (46), gre (47), esp (50), ah (51), icmp6 (58), no-
next-header (59), dstopts (60), ospf (89), pim (103), vrrp
(112), sctp (132)tcp (4)
Ingress and egress IPv4 interfaces.
Ingress IPv4 interfaces and VLANs
1776
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
source
-
addres
s
ip-
addres
s
IP source address eld, which is the address of the node
that sent the packet.
Ingress and egress IPv4 interfaces
Ingress IPv6 interfaces
Ingress ports and VLANs
source
-mac-
addres
s
mac-
addres
s
Source media access control (MAC) address of the packet. Ingress and egress IPv4 interfaces and
VLANs
source
-port
value
TCP or UDP source port. You must specify this match in
conjuncon with the protocol match statement for IPv4
trac, or the next-header match statement for IPv6 trac.
In place of the numeric eld, you can specify one of the
text synonyms listed under destination-port.
Ingress and egress IPv4 interfaces
Ingress IPv6 interfaces
Ingress ports and VLANs
source
-port
range-
optimi
ze
range
Match a range of TCP or UDP port ranges while using the
available memory more eciently. Using this condion
allows you to congure more rewall lters than if you
congure individual source ports. (Not supported with
lter-based forwarding.)
Ingress IPv4 interfaces
source
-
prefix
-list
prefix
-list
IP source prex list. You can dene a list of IP address
prexes under a prex-list alias for frequent use. Dene
this list at the [edit policy-options] hierarchy level.
Ingress and egress IPv4 interfaces
Ingress IPv6 interfaces
Ingress ports and VLANs
1777
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
tcp-
establ
ished
Match TCP packets of an established TCP session
(packets other than the rst packet of a connecon). This
is an alias for tcp-flags "(ack | rst)".
This match condion does not implicitly check that the
protocol is TCP. To check this, specify the protocol tcp
match condion.
Ingress and egress IPv4 interfaces
(QFX5220)
Ingress and egress IPv4 interfaces
(QFX5130)
Ingress IPv6 interfaces (QFX5130)
tcp-
flags
value
TCP ags (only one value is supported):
• ack (0x10)
• fin (0x01)
• push (0x08)
• rst (0x04)
• syn (0x02)
• urgent (0x20)
Ingress and egress IPv4 interfaces
Ingress IPv6 interfaces
Ingress ports and VLANs
tcp-
initia
l
Match the rst TCP packet of a connecon. A match
occurs when the TCP ag SYN is set and the TCP ag ACK is
not set.
When you specify tcp-initial, a switch does not
implicitly verify that the protocol is TCP. You must also
specify the protocol tcp match condion. See protocol
type
.
Ingress and egress IPv4 interfaces
(QFX5220)
Ingress and egress IPv4 interfaces, Ingress
IPv6 interfaces (QFX5130)
1778
Table 99: Supported Match Condions (QFX5220 and QFX5130-32CD Switches)
(Connued)
Match
Condit
ion
Descripon Direcon and Interface
traffi
c-
class
8-bit eld that species the class-of-service (CoS) priority
of the packet. The trac-class eld is used to specify a
DiServ code point (DSCP) value. This eld was
previously used as the type-of-service (ToS) eld in IPv4,
and, the semancs of this eld (for example, DSCP) are
idencal to those of IPv4.
You can specify one of the following text synonyms (the
eld values are also listed):
af11 (10), af12 (12), af13 (14), af21 (18), af22 (20), af23
(22), af31 (26), af32 (28), af33 (30), af41 (34), af42 (36),
af43 (38), cs0 (0), cs1 (8), cs2 (16), cs3 (24), cs4 (32), cs5
(40), cs6 (48), cs7 (56), ef (46)
Ingress and egress IPv6 interfaces
ttl
value
IP Time-to-live (TTL) eld in decimal. The value can be
1-255.
Ingress and egress IPv4 interfaces
user-
vlan-
id
number
Matches the ID of the inner (customer) VLAN for a Q-in-
Q VLAN. The acceptable values are 1-4095.
Ingress ports and VLANs (QFX5130)
user-
vlan-1
p-
priori
ty
value
Matches the specied 802.1p VLAN priority in the range
0-7.
Ingress ports and VLANs (QFX5130)
Use then statements to dene acons that should occur if a packet matches all condions in a from
statement. Table 100 on page 1780 shows the acons that you can specify in a term. (If you do not
include a then statement, the system accepts packets that match the lter.)
1779
NOTE: For egress IPv4 interfaces, IPv6 interfaces, and egress ports, you can only apply the
accept, discard, and count acons. For egress VLANs, you can only apply the accept acon.
Table 100: Acons and Acon Modiers
Acon Descripon
accept
Accept a packet. This is the default acon for packets that match
a term.
apply-groups-except
Specify which groups not to inherit conguraon data from. You
can specify more than one group name.
count
counter-name
Count the number of packets that match the term.
discard
Discard a packet silently without sending an Internet Control
Message Protocol (ICMP) message.
forwarding-class
class
Classify the packet in one of the following default forwarding
classes, or in a user-dened forwarding class:
• best-effort
• fcoe
• mcast
• network-control
• no-loss
NOTE: To congure a forwarding class, you must also congure
loss priority.
log
Log the packet's header informaon in the Roung Engine. To
view this informaon, enter the show firewall log operaonal
mode command.
1780
Table 100: Acons and Acon Modiers
(Connued)
Acon Descripon
loss-priority (low | medium-low | medium-
high | high)
Set the packet loss priority (PLP).
NOTE: The loss-priority acon modier is supported on ingress
IPv4 interfaces only.
NOTE: The loss-priority acon modier is not supported in
combinaon with the policer acon.
policer
policer-name
Send packets to a policer (for the purpose of applying rate
liming).
NOTE: The policer acon modier is not supported in
combinaon with the loss-priority acon.
port-mirror
Mirror trac (copy packets) to an output interface congured in
a port-mirroring instance at the [edit forwarding-options port-
mirroring] hierarchy level.
port-mirror-instance
port-mirror-instance-
name
Mirror trac to a port-mirroring instance congured at the [edit
forwarding-options port-mirroring] hierarchy level.
You can specify port mirroring for ingress port, VLAN, and IPv4
(inet) rewall lters only.
1781
Table 100: Acons and Acon Modiers
(Connued)
Acon Descripon
reject
message-type
Discard a packet and send a “desnaon unreachable” ICMPv4
message (type 3). To log rejected packets, congure the syslog
acon modier.
You can specify one of the following message types:
administratively-prohibited (default), bad-host-tos, bad-
network-tos, host-prohibited, host-unknown, host-unreachable,
network-prohibited, network-unknown, network-unreachable, port-
unreachable, precedence-cutoff, precedence-violation, protocol-
unreachable, source-host-isolated, source-route-failed.
If you do not specify a message type, the ICMP nocaon
“desnaon unreachable” is sent with the default message
“communicaon administravely ltered.”
NOTE: The reject acon is supported on ingress IPv4 interfaces
only.
three-color-policer
three-color-policer-name
Send packets to a three-color policer (for the purpose of
applying rate liming).
NOTE: The policer acon modier is not supported in
combinaon with the loss-priority acon.
NOTE: The color-aware and color-blind policers are not
supported. By default, trac is treated as color-blind.
vlan
VLAN-name
Forward matched packets to a specic VLAN.
NOTE: The vlan acon is only supported on ingress ports and
VLANs.
This acon is not supported on QFX5130 switches.
SEE ALSO
Overview of Firewall Filters (OCX Series) | 848
Understanding How Firewall Filters Are Evaluated | 856
Conguring Firewall Filters | 1829
1782
Overview of Policers | 2202
Firewall Filter Match Condions and Acons (QFX10000 Switches)
Each term in a rewall lter consists of
match condions
and an
acon
. Match condions are the elds
and values that a packet must contain to be considered a match. You can dene single or mulple match
condions in
match statements
. You can also include no match statement, in which case the term
matches all packets.
When a packet matches a lter, the switch takes the acon specied in the term. In addion, you can
specify acon modiers to count, mirror, rate-limit, and classify packets. If no match condions are
specied for the term, the switch accepts the packet by default.
This topic describes the various match condions, acons, and acon modiers that you can dene in
rewall lters on QFX10000 switches. For similar informaon about other QFX switches, see "Firewall
Filter Match Condions and Acons (QFX and EX Series Switches)" on page 1734.
• Table 101 on page 1783 describes the match condions you can specify when conguring a rewall
lter. Some of the numeric range and bit-eld match condions allow you to specify a text synonym.
To see a list of all the synonyms for a match condion, type ? at the appropriate place in a statement.
• Table 102 on page 1797 shows the acons that you can specify in a term.
• Table 103 on page 1798 shows the acon modiers you can use to count, mirror, rate-limit, and
classify packets.
Table 101: Supported Match
Condions (QFX10000 Switches)
Match Condion Descripon Direcon and Interface
destination-address
ip-
address
IP desnaon address eld, which is the
address of the nal desnaon node.
Ingress IPv4 (inet) interfaces and
IPv6 (inet6) interfaces.
Egress IPv4 (inet) interfaces, and
IPv6 (inet6) interfaces.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
destination-mac-address
mac-
address
Desnaon media access control (MAC)
address of the packet.
Ingress ports and VLANs.
Egress ports and VLANs.
1783
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
destination-port
value
TCP or UDP desnaon port eld.
Typically, you specify this match in
conjuncon with the protocol match
statement. For the following well-known
ports you can specify text synonyms (the
port numbers are also listed):
afs (1483), bgp (179), biff (512), bootpc
(68), bootps (67),
cmd (514), cvspserver (2401),
dhcp (67), domain (53),
eklogin (2105), ekshell (2106), exec (512),
finger (79), ftp (21), ftp-data (20),
http (80), https (443),
ident (113), imap (143),
kerberos-sec (88), klogin (543), kpasswd
(761), krb-prop (754), krbupdate (760),
kshell (544),
ldap (389), login (513),
mobileip-agent (434), mobilip-mn (435), msdp
(639),
netbios-dgm (138), netbios-ns (137),
netbios-ssn (139), nfsd (2049), nntp (119),
ntalk (518), ntp (123),
pop3 (110), pptp (1723), printer (515),
radacct (1813),radius (1812), rip (520),
rkinit (2108),
smtp (25), snmp (161), snmptrap (162), snpp
(444), socks (1080), ssh (22), sunrpc (111),
syslog (514),
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
ingress IRB interface for EVPN/
VXLAN fabric, where applicable
1784
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
tacacs-ds (65), talk (517), telnet (23), tftp
(69), timed (525),
who (513),
xdmcp (177),
zephyr-clt (2103), zephyr-hm (2104)
destination-prefix-list
prefix-list
IP desnaon prex list eld. You can
dene a list of IP address prexes under a
prex-list alias for frequent use. Dene this
list at the [edit policy-options] hierarchy
level.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
1785
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
dscp
value
Dierenated Services code point (DSCP).
The DiServ protocol uses the type-of-
service (ToS) byte in the IP header. The
most-signicant 6 bits of this byte form the
DSCP.
You can specify DSCP in hexadecimal,
binary, or decimal form.
In place of the numeric value, you can
specify one of the following text synonyms
(the eld values are also listed):
• be—best eort (default)
• ef (46)—as dened in RFC 3246,
An
Expedited Forwarding PHB
.
• af11 (10), af12 (12), af13 (14);
af21 (18), af22 (20), af23 (22);
af31 (26), af32 (28), af33 (30);
af41 (34), af42 (36), af43 (38)
These four classes, with three drop
precedences in each class, for a total of
12 code points, are dened in RFC
2597,
Assured Forwarding PHB
.
• cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, cs5
Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress ports, VLANs, and IPv4
(inet) interfaces.
1786
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
ether-type
value
Ethernet type eld of a packet. The
EtherType value species what protocol is
being transported in the Ethernet frame. In
place of the numeric value, you can specify
one of the following text synonyms (the
eld values are also listed):
• aarp (0x80F3)—EtherType value AARP
• appletalk (0x809B)—EtherType value
AppleTalk
• arp (0x0806)—EtherType value ARP
• fcoe (0x8906)—EtherType value FCoE
• fip (0x8914)—EtherType value FIP
• ipv4 (0x0800)—EtherType value IPv4
• ipv6 (0x08DD)—EtherType value IPv6
• mpls-multicast (0x8848)—EtherType
value MPLS mulcast
• mpls-unicast (0x8847)—EtherType value
MPLS unicast
• oam (0x88A8)—EtherType value OAM
• ppp (0x880B)—EtherType value PPP
• pppoe-discovery (0x8863)—EtherType
value PPPoE Discovery Stage
• pppoe-session (0x8864)—EtherType
value PPPoE Session Stage
• sna (0x80D5)—EtherType value SNA
Ingress ports and VLANs.
Egress ports and VLANs.
1787
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
forwarding-class
class
Classify the packet in one of the following
default forwarding classes, or in a user-
dened forwarding class:
• best-effort
• fcoe
• network-control
• no-loss
Egress IPv4 (inet) and IPv6 (inet6)
interfaces.
fragment-flags
value
IP fragmentaon ags. In place of the
numeric value, you can specify one of the
following text synonyms (the hexadecimal
values are also listed):
• is-fragment
• dont-fragment (0x4000)
• more-fragments (0x2000)
• reserved (0x8000)
Ingress ports, VLANs, and IPv4
(inet) interfaces.
hop-limit
value
Match the specied hop limit or set of hop
limits. Specify a single value or a range of
values from 0 through 255.
Ingress and egress IPv6 (inet6)
interfaces.
1788
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
icmp-code
value
ICMP code eld. Because the meaning of
the value depends upon the associated
icmp-type, you must specify a value for
icmp-type along with a value for icmp-code.
In place of the numeric value, you can
specify one of the following text synonyms
(the eld values are also listed). The
keywords are grouped by the ICMP type
with which they are associated:
•
IPv4:
parameter-problem—ip-header-
bad (0), required-option-missing (1)
•
IPv6:
parameter-problem—ip6-header-
bad (0), unrecognized-next-header (1),
unrecognized-option (2)
• redirect—redirect-for-network (0),
redirect-for-host (1), redirect-for-tos-
and-net (2), redirect-for-tos-and-host
(3)
• time-exceeded—ttl-eq-zero- during-
reassembly (1), ttl-eq-zero-during-
transit (0)
•
IPv4:
unreachable—network-unreachable
(0), host-unreachable (1), protocol-
unreachable (2), port-unreachable (3),
fragmentation-needed (4), source-route-
failed (5), destination-network-unknown
(6), destination-host-unknown (7),
source-host-isolated (8), destination-
network-prohibited (9), destination-
host-prohibited (10), network-
unreachable-for-TOS (11), host-
unreachable-for-TOS (12), communication-
prohibited-by-filtering (13), host-
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces
1789
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
precedence-violation (14), precedence-
cutoff-in-effect (15)
•
IPv6:
unreachable—address-unreachable
(3), administratively-prohibited (1), no-
route-to-destination (0), port-
unreachable (4)
icmp-type
value
ICMP message type eld. Typically, you
specify this match in conjuncon with the
protocol match statement to determine
which protocol is being used on the port. In
place of the numeric value, you can specify
one of the following text synonyms (the
eld values are also listed):
IPv4:
echo-reply (0), destination
unreachable (3), source-quench (4), redirect
(5), echo-request (8), IPv4 (inet)-
advertisement (9), IPv4 (inet)-solicit (10),
time-exceeded (11), parameter-problem (12),
timestamp (13), timestamp-reply (14), info-
request (15), info-reply (16), mask-request
(17), mask-reply (18)
IPv6:
destination-unreachable (1), packet-
too-big (2), time-exceeded (3), parameter-
problem (4), echo-request (128), echo-reply
(129), membership-query (130), membership-
report (131), membership-termination (132),
router-solicit (133), router-advertisement
(134), neighbor-solicit (135), neighbor-
advertisement (136), redirect (137), router-
renumbering (138), node-information-request
(139), node-information-reply (140)
See also icmp-code
variable
.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
1790
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
interface
interface-name
Interface on which the packet is received,
including the logical unit. You can include
the wildcard character (*) as part of an
interface name or logical unit.
NOTE: An interface from which a packet is
sent cannot be used as a match condion.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces and
IPv6 (inet6) interfaces.
ip-destination-address
address
IPv4 address that is the nal desnaon
node address for the packet.
Ingress ports, egress ports, and
VLANs.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
ip-options Specify any to create a match if anything is
specied in the opons eld in the IP
header.
Ingress ports, VLANs, and IPv4
(inet) interfaces.
ip-precedence
ip-precedence-
field
IP precedence eld. In place of the numeric
eld value, you can specify one of the
following text synonyms (the eld values
are also listed): critical-ecp (0xa0), flash
(0x60), flash-override (0x80), immediate
(0x40), internet-control (0xc0), net-control
(0xe0), priority (0x20), or routine (0x00).
Ingress ports and VLANs.
Egress ports and VLANs.
ip-protocol
number
IP protocol eld. Ingress ports and VLANs.
Egress ports and VLANs.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
ip-source-address
address
IPv4 address of the source node sending
the packet.
Ingress ports and VLANs.
Egress ports and VLANs.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
1791
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
ip-version
address
IP version of the packet. Use this condion
to match IPv4 or IPv6 header elds in
trac that arrives on a Layer 2 port or
VLAN interface.
Ingress ports and VLANs.
Egress ports and VLANs.
is-fragment
Using this condion causes a match if the
More Fragments ag is enabled in the IP
header or if the fragment oset is not zero.
Ingress ports, VLANs, and IPv4
(inet) interfaces.
Egress IPv4 (inet) interfaces.
learn-1p-priority
number
Matches the specied IEEE 802.1p VLAN
priority bits in the range 0-7.
Ingress ports and VLANs.
Egress ports and VLANs.
learn-vlan-id
number
Matches the ID of a normal VLAN or the
ID of the outer (service) VLAN (for Q-in-Q
VLANs). To use lter memory most
eciently and maximize the number of
possible lters, use this condion in
addion to user-id when you want to
match on the inner (customer) VLAN ID.
The acceptable values are 1-4095.
Ingress ports and VLANs.
Egress ports and VLANs.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
loss-priority (low | medium-
low | medium-high | high)
Set the packet loss priority (PLP).
NOTE: The loss-priority acon modier is
not supported in combinaon with the
policer acon.
Egress IPv4 (inet) and IPv6 (inet6)
interfaces.
1792
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
next-header
value
IPv4 or IPv6 protocol value. In place of the
numeric value, you can specify one of the
following text synonyms (the numeric
values are also listed):
hop-by-hop (0),icmp (1), icmp6 (58), igmp
(2), ipip (4), tcp (6), egp (8), udp (17), ipv6
(41), routing (43), fragment (44),rsvp (46),
gre (47), esp (50), ah (51), icmp6 (58), no-
next-header (59), dstopts (60), ospf (89),
pim (103), vrrp (112), sctp (132)
Ingress IPv6 (inet6) interfaces.
Egress IPv6 (inet6) interfaces.
packet-length
number
Packet length in bytes. You must enter a
number between 0 and 65535.
Ingress ports, VLANs, IPv4 (inet),
and IPv6 (inet6) interfaces.
Egress IPv4 (inet) interfaces.
precedence
value
IP precedence bits in the type-of-service
(ToS) byte in the IP header. (This byte can
also used for the DiServ DSCP.) In place
of the numeric value, you can specify one
of the following text synonyms (the
numeric values are also listed):
• routine (0)
• priority (1)
• immediate (2)
• flash (3)
• flash-override (4)
• critical-ecp (5)
• internet-control (6)
• net-control (7)
Ingress IPv4 (inet) interfaces.
Egress IPv4 (inet) interfaces.
1793
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
protocol
type
IPv4 or IPv6 protocol value. In place of the
numeric value, you can specify one of the
following text synonyms (the numeric
values are also listed):
hop-by-hop (0),icmp (1), icmp6, igmp (2),
ipip (4), tcp (6), egp (8), udp (17), ipv6
(41), routing (43), fragment (44),rsvp (46),
gre (47), esp (50), ah (51), icmp6 (58), no-
next-header (59), dstopts (60), ospf (89),
pim (103), vrrp (112), sctp (132)
Ingress IPv4 (inet) interfaces.
Egress IPv4 (inet) interfaces.
source-address
ip-address
IP source address eld, which is the
address of the node that sent the packet.
Ingress IPv4 (inet) interfaces and
IPv6 (inet6) interfaces.
Egress IPv4 (inet) interfaces and
IPv6 (inet6) interfaces.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
source-mac-address
mac-
address
Source media access control (MAC)
address of the packet.
Ingress ports and VLANs.
Egress ports and VLANs.
source-port
value
TCP or UDP source port. Typically, you
specify this match in conjuncon with the
protocol match statement. In place of the
numeric eld, you can specify one of the
text synonyms listed under destination-
port.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
1794
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
source-prefix-list
prefix-
list
IP source prex list. You can dene a list of
IP address prexes under a prex-list alias
for frequent use. Dene this list at the
[edit policy-options] hierarchy level.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
tcp-established
Match packets of an established TCP
connecon. This condion matches
packets other than those used to set up a
TCP connecon—that is, three-way
handshake packets are not matched.
When you specify tcp-established, a switch
does not implicitly verify that the protocol
is TCP. You must also specify the protocol
tcp match condion.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
tcp-flags
value
One or more TCP ags:
• ack (0x10)
• fin (0x01)
• push (0x08)
• rst (0x04)
• syn (0x02)
• urgent (0x20)
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
1795
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
tcp-initial
Match the rst TCP packet of a
connecon. A match occurs when the TCP
ag SYN is set and the TCP ag ACK is not
set.
When you specify tcp-initial, a switch
does not implicitly verify that the protocol
is TCP. You must also specify the protocol
tcp match condion.
Ingress ports, VLANs, IPv4 (inet)
interfaces, and IPv6 (inet6)
interfaces.
Egress IPv4 (inet) interfaces.
traffic-class
value
8-bit eld that species the class-of-
service (CoS) priority of the packet. The
trac-class eld is used to specify a
DiServ code point (DSCP) value. This eld
was previously used as the type-of-service
(ToS) eld in IPv4, and, the semancs of
this eld (for example, DSCP) are idencal
to those of IPv4.
You can specify one of the following text
synonyms (the eld values are also listed):
af11 (10), af12 (12), af13 (14), af21 (18),
af22 (20), af23 (22), af31 (26), af32 (28),
af33 (30), af41 (34), af42 (36), af43 (38),
cs0 (0), cs1 (8), cs2 (16), cs3 (24), cs4
(32), cs5 (40), cs6 (48), cs7 (56), ef (46)
Ingress IPv6 (inet6) interfaces.
Egress IPv6 (inet6) interfaces.
ttl
value
IP Time-to-live (TTL) eld in decimal. The
value can be 1-255.
Ingress IPv4 (inet) interfaces.
Egress IPv4 (inet) interfaces.
Ingress IRB interface for EVPN/
VXLAN fabric, where applicable
1796
Table 101: Supported Match Condions (QFX10000 Switches)
(Connued)
Match Condion Descripon Direcon and Interface
user-vlan-id
number
Matches the ID of the inner (customer)
VLAN in a Q-in-Q VLAN. To use lter
memory most eciently and maximize the
number of possible lters, use in
combinaon with learn-vlan-id to match
the outer (service) VLAN ID. The
acceptable values are 1-4095.
Ingress ports and VLANs.
Egress ports and VLANs.
Use then statements to dene acons that should occur if a packet matches all condions in a from
statement. Table 102 on page 1797 shows the acons that you can specify in a term. (If you do not
include a then statement, the system accepts packets that match the lter.)
Table 102: Acons
Acon Descripon
accept
Accept a packet. This is the default acon for packets that
match a term.
discard
Discard a packet silently without sending an Internet Control
Message Protocol (ICMP) message.
1797
Table 102: Acons
(Connued)
Acon Descripon
reject
message-type
Discard a packet and send a “desnaon unreachable” ICMPv4
message (type 3). To log rejected packets, congure the syslog
acon modier.
You can specify one of the following message types:
administratively-prohibited (default), bad-host-tos, bad-
network-tos, host-prohibited, host-unknown, host-unreachable,
network-prohibited, network-unknown, network-unreachable, port-
unreachable, precedence-cutoff, precedence-violation, protocol-
unreachable, source-host-isolated, source-route-failed, or tcp-
reset.
If you specify tcp-reset, the system sends a TCP reset if the
packet is a TCP packet; otherwise nothing is sent.
If you do not specify a message type, the ICMP nocaon
“desnaon unreachable” is sent with the default message
“communicaon administravely ltered.”
NOTE: The reject acon is supported on ingress interfaces only.
routing-instance
instance-name
Forward matched packets to a virtual roung instance. (The only
supported instance type is virtual-router.) Packets can be
forwarded to the default instance.
vlan
VLAN-name
Forward matched packets to a specic VLAN.
NOTE: The vlan acon is supported on ingress interfaces only.
NOTE: This acon is not supported on OCX series switches.
You can also specify the acon modiers listed in Table 103 on page 1798 to count, mirror, rate-limit,
and classify packets.
Table 103:
Acon Modiers
Acon Modier Descripon
count
counter-name
Count the number of packets that match the term.
1798
Table 103: Acon Modiers
(Connued)
Acon Modier Descripon
forwarding-class
class
Classify the packet in one of the following default forwarding
classes, or in a user-dened forwarding class:
• best-effort
• fcoe
• mcast
• network-control
• no-loss
NOTE: To congure a forwarding class, you must also congure
loss priority.
log
Log the packet's header informaon in the Roung Engine. To
view this informaon, enter the show firewall log operaonal
mode command.
NOTE: The log acon modier is supported on ingress
interfaces only.
loss-priority (low | medium-low | medium-high
| high)
Set the packet loss priority (PLP).
NOTE: The loss-priority acon modier is supported on ingress
interfaces only.
NOTE: The loss-priority acon modier is not supported in
combinaon with the policer acon.
policer
policer-name
Send packets to a policer (for the purpose of applying rate
liming).
You can specify a policer for ingress and egress port, VLAN, IPv4
(inet), and IPv6 (inet6) rewall lters.
NOTE: The policer acon modier is not supported in
combinaon with the loss-priority acon.
1799
Table 103: Acon Modiers
(Connued)
Acon Modier Descripon
port-mirror
(ELS plaorms) Mirror trac (copy packets) to an output
interface congured in a port-mirroring instance at the [edit
forwarding-options port-mirroring] hierarchy level.
You can specify port mirroring for ingress and egress port,
VLAN, IPv4 (inet), and IPv6 (inet6) rewall lters.
port-mirror-instance
port-mirror-instance-
name
(ELS plaorms) Mirror trac to a port-mirroring instance
congured at the [edit forwarding-options port-mirroring]
hierarchy level.
You can specify port mirroring for ingress and egress port,
VLAN, IPv4 (inet), and IPv6 (inet6) rewall lters.
NOTE:
syslog
Log an alert for this packet.
NOTE: The syslog acon modier is supported on ingress
interfaces only.
three-color-policer
three-color-policer-name
Send packets to a three-color policer (for the purpose of
applying rate liming).
You can specify a three-color policer for ingress and egress port,
VLAN, IPv4 (inet), and IPv6 (inet6) lters.
NOTE: The policer acon modier is not supported in
combinaon with the loss-priority acon.
RELATED DOCUMENTATION
Overview of Firewall Filters (OCX Series) | 848
Firewall Filter Match Condions and Acons (QFX and EX Series Switches) | 1734
Conguring Firewall Filters | 1829
Overview of Policers | 2202
1800
Firewall Filter Match Condions and Acons (PTX Series Routers)
IN THIS SECTION
Firewall Filter Match Condions and Acons (PTX Series Routers) | 1801
IPv6 Firewall Filter Match Condions and Acons (PTX10001-20C) | 1818
Firewall Filter Match Condions and Acons (PTX Series Routers)
Each term in a rewall lter consists of
match condions
and an
acon
. Match condions are the elds
and values that a packet must contain to be considered a match. You can dene single or mulple match
condions in
match statements
. You can also include no match statement, in which case the term
matches all packets.
When a packet matches a lter, the router takes the acon specied in the term. In addion, you can
specify acon modiers to count, mirror, rate-limit, and classify packets. If no match condions are
specied for the term, the router accepts the packet by default.
On the PTX10003, you can apply mulple rewall lters to a single interface as a single input list or
output list (filter input-list and output-list). In this way, you only manage the conguraon for a ltering
task in a single rewall lter. This gives you exibility in large environments when you have a device
congured with many interfaces. You can do the same on the PTX10008, but the router only supports
applying mulple rewall lters to a single input-list.
• Table 104 on page 1801 describes the match condions you can specify when conguring a rewall
lter. Some of the numeric range and bit-eld match condions allow you to specify a text synonym.
To see a list of all the synonyms for a match condion, type ? at the appropriate place in a statement.
• Table 105 on page 1816 shows the acons and acon modiers that you can specify in a term.
Table 104: Supported Match
Condions
Match Condion Descripon Supported Interfaces
address
address
[ except ]
Match the source or desnaon address
eld unless the except opon is included.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
1801
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
destination-address
address
[ except ]
Match the desnaon address eld unless
the except opon is included.
You cannot specify both address and
destination-address match condions in the
same term.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
1802
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
destination-port
number
Match the UDP or TCP desnaon port
eld. You must also congure the protocol
udp or protocol tcp match statement in the
same term to specify which protocol is
being used on the port.
You cannot specify both the port and
destination-port match condions in the
same term.
In place of the numeric value, you can
specify one of the following text synonyms
(the port numbers are also listed):
afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401),
dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79),
ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88),
klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389),
ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-
dgm (138), netbios-ns (137), netbios-
ssn (139), nfsd (2049), nntp (119),
ntalk (518), ntp (123), pop3 (110),
pptp (1723), printer (515), radacct (1813),
radius (1812), rip (520), rkinit (2108),
smtp (25), snmp (161), snmptrap (162),
snpp (444), socks (1080), ssh (22),
sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23),
tftp (69), timed (525), who (513), or
xdmcp (177).
IPv4 (inet) interfaces, and IPv6
(inet6) interfaces.
destination-port-except
number
Do not match the UDP or TCP desnaon
port eld. For details, see the destination-
port match condion.
IPv4 (inet) interfaces, and IPv6
(inet6) interfaces.
1803
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
destination-prefix-list
name
[ except ]
Match desnaon prexes in a list unless
the except opon is included. You can
dene a list of IP address prexes under a
prex-list alias for frequent use. Dene this
list at the [edit policy-options] hierarchy
level.
IPv4 (inet) interfaces, and IPv6
(inet6) interfaces.
dscp
number
Match the Dierenated Services code
point (DSCP). The DiServ protocol uses
the type-of-service (ToS) byte in the IP
header. The most-signicant 6 bits of this
byte form the DSCP.
You can specify DSCP in hexadecimal,
binary, or decimal form.
In place of the numeric value, you can
specify one of the following text synonyms
(the eld values are also listed):
• be—best eort (default)
• ef (46)—as dened in RFC 3246,
An
Expedited Forwarding PHB
.
• af11 (10), af12 (12), af13 (14);
af21 (18), af22 (20), af23 (22);
af31 (26), af32 (28), af33 (30);
af41 (34), af42 (36), af43 (38)
These four classes, with three drop
precedences in each class, for a total of
12 code points, are dened in RFC
2597,
Assured Forwarding PHB
.
• cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, cs5
IPv4 (inet) and IPv6 (inet6)
interfaces.
1804
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
dscp-except
number
Do not match on the DSCP number. For
more informaon, see the dscp match
condion.
IPv4 (inet) and IPv6 (inet6)
interfaces.
first-fragment
Match if the packet is the rst fragment of
a fragmented packet. Do not match if the
packet is a trailing fragment of a
fragmented packet. The rst fragment of a
fragmented packet has a fragment oset
value of 0.
This match condion is an alias for the bit-
eld match condion fragment-offset 0
match condion.
To match both rst and trailing fragments,
you can use two terms that specify
dierent match condions: first-fragment
and is-fragment.
IPv4 (inet) interfaces.
forwarding-class
class
Classify the packet in one of the following
default forwarding classes, or in a user-
dened forwarding class:
• best-effort
• fcoe
• network-control
• no-loss
IPv4 (inet), IPv6 (inet6), and MPLS
interfaces.
forwarding-class-except
class
Do not match the forwarding class of the
packet. For details, see the forwarding-class
match condion.
IPv4 (inet), IPv6 (inet6), and MPLS
interfaces.
1805
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
fragment-flags
number
Match the three-bit IP fragmentaon ags
eld in the IP header.
In place of the numeric eld value, you can
specify one of the following keywords (the
eld values are also listed): dont- (0x4),
more-s (0x2), or reserved (0x8).
IPv4 (inet) interfaces.
fragment-offset
value
Match the 13-bit fragment oset eld in
the IP header. The value is the oset, in 8-
byte units, in the overall datagram message
to the data fragment. Specify a numeric
value, a range of values, or a set of values.
An oset value of 0 indicates the rst
fragment of a fragmented packet.
The first-fragment match condion is an
alias for the fragment-offset 0 match
condion.
To match both rst and trailing fragments,
you can use two terms that specify
dierent match condions (first-fragment
and is-fragment).
IPv4 (inet) interfaces.
fragment-offset-except
number
Do not match the 13-bit fragment oset
eld.
IPv4 (inet) interfaces.
1806
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
icmp-code
message-code
Match the ICMP message code eld.
If you congure this match condion, we
recommend that you also congure the
next-header icmp or next-header icmp6
match condion in the same term.
If you congure this match condion, you
must also congure the icmp-type
message-
type
match condion in the same term. An
ICMP message code provides more specic
informaon than an ICMP message type,
but the meaning of an ICMP message code
is dependent on the associated ICMP
message type.
In place of the numeric value, you can
specify one of the following text synonyms
(the eld values are also listed). The
keywords are grouped by the ICMP type
with which they are associated:
• parameter-problem: ip-header-bad (0),
required-option-missing (1)
• redirect: redirect-for-host (1), redirect-
for-network (0), redirect-for-tos-and-
host (3), redirect-for-tos-and-net (2)
• me-exceeded: ttl-eq-zero-during-
reassembly (1), ttl-eq-zero-during-
transit (0)
• unreachable: communication-prohibited-
by-filtering (13), destination-host-
prohibited (10), destination-host-
unknown (7), destination-network-
prohibited (9), destination-network-
unknown (6), fragmentation-needed (4),
host-precedence-violation (14), host-
IPv4 (inet) and IPv6 (inet6)
interfaces.
1807
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
unreachable (1), host-unreachable-for-
TOS (12), network-unreachable (0),
network-unreachable-for-TOS (11), port-
unreachable (3), precedence-cutoff-in-
effect (15), protocol-unreachable (2),
source-host-isolated (8), source-route-
failed (5)
icmp-code-except
message-
code
Do not match the ICMP message code
eld. For details, see the icmp-code match
condion.
IPv4 (inet) and IPv6 (inet6)
interfaces.
icmp-type
number
Match the ICMP message type eld. You
must also congure icmp or icmpv6 as
protocol
next-header
match type in the
same term.
In place of the numeric value, you can
specify one of the following text synonyms
(the eld values are also listed): echo-
reply (0), echo-request (8), info-reply (16),
info-request (15), mask-request (17), mask-
reply (18), parameter-problem (12),
redirect (5), router-advertisement (9),
router-solicit (10), source-quench (4), time-
exceeded (11), timestamp (13), timestamp-
reply (14), or unreachable (3).
See also icmp-code
variable
.
IPv4 (inet) and IPv6 (inet6)
interfaces.
icmp-type-except
message-
type
Do not match the ICMP message type
eld. For details, see the icmp-type match
condion.
IPv4 (inet) and IPv6 (inet6)
interfaces.
1808
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
interface
interface-name
For ingress lters, match the interface on
which the packet was received.
For egress lters, match the interface on
which the packet was sent.
NOTE: PTX5000 series routers do not
support aaching the em0.0 interface (the
internal link between the roung and
packet forwarding engines) to lo0 (the
loopback interface), for example to lter
self-originang trac such as Telnet and
SSH by creang a rewall lter on lo0 to
match trac on em0.0. The following code
snippet provides context:
firewall
filter core-protect {
term Telnet {
from {
protocol tcp;
destination-port
telnet;
interface em0.0;
}
then accept;
}
}
}
IPv4 (inet) interfaces, and IPv6
(inet6) interfaces.
interface-except
number
Do not match the logical interface on
which the packet was received. For details,
see the interface match condion.
IPv4 (inet) interfaces, and IPv6
(inet6) interfaces.
1809
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
is-fragment
Match if the packet is a trailing fragment of
a fragmented packet. Do not match the
rst fragment of a fragmented packet.
NOTE: To match both rst and trailing
fragments, you can use two terms that
specify dierent match condions (first-
fragment and is-fragment).
For PTX10003 routers running Junos OS
Evolved, all fragmented packets including
the rst fragment of fragmented packets
will match on any rewall lter term
containing an "is-fragment" match.
IPv4 (inet) interfaces.
loss-priority
level
Match the packet loss priority (PLP).
Specify a single level or mulple levels: low,
medium-low, medium-high, or high.
NOTE: The loss-priority acon modier is
not supported in combinaon with the
policer acon.
IPv4 (inet), IPv6 (inet6), and MPLS
interfaces.
loss-priority-except
level
Do not match the PLP level. For details, see
the loss-priority match condion.
IPv4 (inet), IPv6 (inet6), and MPLS
interfaces.
next-header
header-type
Match the rst 8-bit next header eld in
the packet.
In place of the numeric value, you can
specify one of the following text synonyms
(the eld values are also listed): ah (51),
dstops (60), egp (8), esp (50), fragment (44),
gre (47), hop-by-hop (0), icmp (1), icmp6 (58),
icmpv6 (58), igmp (2), ipip (4), ipv6 (41),
mobility (135), no-next-header (59),
ospf (89), pim (103), routing (43), rsvp (46),
sctp (132), tcp (6), udp (17), or vrrp (112).
IPv6 (inet6) interfaces.
1810
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
next-header-except
header-
type
Do not match the 8-bit Next Header eld
that idenes the type of header between
the IPv6 header and payload. For details,
see the next-header match type.
IPv6 (inet6) interfaces
packet-length
bytes
Match the length of the received packet, in
bytes. The length refers only to the IP
packet, including the packet header, and
does not include any Layer 2 encapsulaon
overhead. You can also specify a range of
values to be matched.
IPv4 (inet), and IPv6 (inet6)
interfaces.
packet-length-except
bytes
Do not match the length of the received
packet, in bytes. For details, see the packet-
length match type.
IPv4 (inet), and IPv6 (inet6)
interfaces.
port
number
Match the UDP or TCP source or
desnaon port eld. You must also
congure the protocol udp or protocol tcp
match statement in the same term to
specify which protocol is being used on the
port.
You cannot congure the destination-port
match condion or the source-port match
condion in the same term.
In place of the numeric value, you can
specify one of the text synonyms listed
under destination-port.
IPv4 (inet), and IPv6 (inet6)
interfaces.
port-except
number
Do not match either the source or
desnaon UDP or TCP port eld. For
details, see the port match condion.
IPv4 (inet), and IPv6 (inet6)
interfaces.
1811
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
precedence
ip-precedence-
value
Match the IP precedence eld.
In place of the numeric eld value, you can
specify one of the following text synonyms
(the eld values are also listed): critical-
ecp (0xa0), flash (0x60), flash-
override (0x80), immediate (0x40), internet-
control (0xc0), net-control (0xe0),
priority (0x20), or routine (0x00). You can
specify precedence in hexadecimal, binary,
or decimal form.
IPv4 (inet) interfaces.
precedence-except
ip-
precedence-value
Do not match the IP precedence eld. IPv4 (inet) interfaces.
protocol
number
Match the IPv4 protocol type eld. In place
of the numeric value, you can specify one
of the following text synonyms (the
numeric values are also listed):
hop-by-hop (0),icmp (1), icmp6, igmp (2),
ipip (4), tcp (6), egp (8), udp (17), ipv6
(41), routing (43), fragment (44),rsvp (46),
gre (47), esp (50), ah (51), icmp6 (58), no-
next-header (59), dstopts (60), ospf (89),
pim (103), vrrp (112), sctp (132)
IPv4 (inet) interfaces.
protocol-except
number
Do not match the IP protocol type eld. In
place of the numeric value, you can specify
one of the following text synonyms (the
eld values are also listed): ah (51),
dstopts (60), egp (8), esp (50), fragment (44),
gre (47), hop-by-hop (0), icmp (1), icmp6 (58),
icmpv6 (58), igmp (2), ipip (4), ipv6 (41),
ospf (89), pim (103), rsvp (46), sctp (132),
tcp (6), udp (17), or vrrp (112).
IPv4 (inet) interfaces.
1812
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
source-address
ip-address
IP source address eld, which is the
address of the node that sent the packet.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
source-address
address
[ except ]
Match the IP address of the source node
sending the packet unless the except opon
is included. If the opon is included, do not
match the IP address of the source node
sending the packet.
You cannot specify both the address and
source-address match condions in the
same term.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
source-port
value
Match the TCP or UDP source port. You
must also congure the protocol udp or
protocol tcp match statement in the same
term.
In place of the numeric value, you can
specify one of the text synonyms listed
with the destination-port
number
match
condion.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
source-port-except
number
Do not match the UDP or TCP source port
eld. For details, see the source-port match
condion.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
source-prefix-list
prefix-
list
IP source prex list. You can dene a list of
IP address prexes under a prex-list alias
for frequent use. Dene this list at the
[edit policy-options] hierarchy level.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
1813
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
tcp-flags
value
Match one or more of the low-order 6 bits
in the 8-bit TCP ags eld in the TCP
header.
To specify individual bit elds, you can
specify the following text synonyms or
hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN ag is set only in
the inial packet sent, while the ACK ag is
set in all packets sent aer the inial
packet.
You can string together mulple ags using
the bit-eld logical operators.
If you congure this match condion, we
recommend that you also congure the
protocol tcp match statement in the same
term to specify that the TCP protocol is
being used on the port.
For IPv4 trac only, this match condion
does not implicitly check whether the
datagram contains the rst fragment of a
fragmented packet. To check for this
condion for IPv4 trac only, use the
first-fragment match condion.
IPv4 (inet) interfaces and IPv6
(inet6) interfaces.
1814
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
traffic-class
value
8-bit eld that species the class-of-
service (CoS) priority of the packet. The
trac-class eld is used to specify a
DiServ code point (DSCP) value. This eld
was previously used as the type-of-service
(ToS) eld in IPv4, and, the semancs of
this eld (for example, DSCP) are idencal
to those of IPv4.
You can specify one of the following text
synonyms (the eld values are also listed):
af11 (10), af12 (12), af13 (14), af21 (18),
af22 (20), af23 (22), af31 (26), af32 (28),
af33 (30), af41 (34), af42 (36), af43 (38),
cs0 (0), cs1 (8), cs2 (16), cs3 (24), cs4
(32), cs5 (40), cs6 (48), cs7 (56), ef (46)
IPv6 (inet6) interfaces.
traffic-class-except
number
Do not match the 8-bit eld that species
the CoS priority of the packet. For details,
see the traffic-class match descripon.
IPv6 (inet6) interfaces.
ttl
number
Match the IPv4 or IPv6 me-to-live
number. Specify a TTL value or a range of
TTL values. For
number
, you can specify one
or more values from 0 through 255.
IPv4 (inet) and IPv6 (inet6)
interfaces.
ttl-except
number
Do not match on the IPv4 or IPv6 TTL
number. For details, see the ttl match
condion.
IPv4 (inet) and IPv6 (inet6)
interfaces.
1815
Table 104: Supported Match Condions
(Connued)
Match Condion Descripon Supported Interfaces
vxlan
Specify a numeric value or range of
numeric values for the VNI. Apply the lter
on the ingress interface.
• vni
vni-value
—Match the VNI.
• vni-except
vni-value
—Do not match the
VNI.
NOTE: Starng with Junos OS Evolved
Release 23.4R2, you can lter vni and vni-
except numeric values on a vxlan match
condion on both ingress and egress
interfaces.
IPv4 (inet) interfaces.
Use then statements to dene acons that should occur if a packet matches all condions in a from
statement. Table 105 on page 1816 shows the acons that you can specify in a term. (If you do not
include a then statement, the system accepts packets that match the lter.)
Table 105:
Acons and Acon Modiers
Acon Descripon
accept
Accept a packet. This is the default acon for packets that
match a term.
discard
Discard a packet silently without sending an Internet Control
Message Protocol (ICMP) message.
count
counter-name
Count the number of packets that match the term.
1816
Table 105: Acons and Acon Modiers
(Connued)
Acon Descripon
forwarding-class
class
Classify the packet in one of the following default forwarding
classes, or in a user-dened forwarding class:
• best-effort
• fcoe
• mcast
• network-control
• no-loss
NOTE: The forwarding-class acon is supported on IPv4, IPv6,
and MPLS interfaces.
log
Log the packet's header informaon in the Roung Engine. To
view this informaon, enter the show firewall log operaonal
mode command.
NOTE: The log acon modier is only supported on IPv4 and
IPv6 ingress interfaces.
loss-priority
level
Set the packet loss priority (PLP).
policer
policer-name
Send packets to a policer (for the purpose of applying rate
liming). The PTX10003 supports two-color, single-rate three-
color (srTCM), and two-rate three-color marker (trTCM) policers.
NOTE: The policer acon modier is not supported in
combinaon with the loss-priority acon.
redirect
instance-name
(Supported on PTX10004, PTX10008, and PTX10016 devices
running Junos Evolved OS Release 22.1R1 only.)
Send packets to the P4 controller, as specied in the instance
dened at the [services inline-monitoring instance
instance-
name
controller
p4] level of the Junos hierarchy.
1817
Table 105: Acons and Acon Modiers
(Connued)
Acon Descripon
reject
message-type
Discard a packet and send a “desnaon unreachable” ICMPv4
or ICMPv6 message (type 3). To log rejected packets, congure
the syslog acon modier.
You can specify one of the following message types:
administratively-prohibited (default), bad-host-tos, bad-
network-tos, host-prohibited, host-unknown, host-unreachable,
network-prohibited, network-unknown, network-unreachable, port-
unreachable, precedence-cutoff, precedence-violation, protocol-
unreachable, source-host-isolated, source-route-failed, .
NOTE: The tcp-reset message type is not supported.
If you do not specify a message type, the ICMP nocaon
“desnaon unreachable” is sent with the default message
“communicaon administravely ltered.”
syslog
Log an alert for this packet.
routing-instance
instance-name
Forward matched packets to a virtual roung instance. Packets
can be forwarded to the default instance.
Supported on virtual-router and forwarding instance-types.
IPv6 Firewall Filter Match Condions and Acons (PTX10001-20C)
This topic describes the IPv6 rewall lter match condions, acons, and acon modiers for
PTX10001-20C routers.
Each term in a rewall lter consists of
match condions
and an
acon
. Match condions are the elds
and values that a packet must contain to be considered a match. You can dene single or mulple match
condions in
match statements
. You can also include the
no match statement
, in which case the term
matches all packets.
When a packet matches a lter, the router takes the acon specied in the term. You can also specify
acon modiers to count, mirror, and classify packets. If no match condions are specied for the term,
the router accepts the packet by default.
1818
NOTE: On PTX10001-20C routers, you can only apply a rewall lter on IPv6 interfaces in the
ingress direcon.
• Table 106 on page 1819 describes the supported match condions.
• Table 107 on page 1825 shows the acons that you can specify in a term. If you don’t include a then
statement, the system accepts packets that match the lter.
• Table 108 on page 1825 shows the acon modiers you can use to count, mirror, rate-limit, and
classify packets.
Table 106: IPv6 Supported Match Condions
Match Condion Descripon
address
address
[ except ]
Match the IPv6 source or desnaon address eld unless the except opon is
included. If the opon is included, do not match the IPv6 source or desnaon
address eld.
apply-groups
Specify which groups to inherit conguraon data from. You can specify more than
one group name. You must list them in order of inheritance priority. The
conguraon data in the rst group takes priority over the data in subsequent
groups.
apply-groups-except
Specify which groups not to inherit conguraon data from. You can specify more
than one group name.
destination-address
address
[ except ]
Match the IPv6 desnaon address eld unless the except opon is included. If the
opon is included, do not match the IPv6 desnaon address eld.
You cannot specify both the address and destination-address match condions in the
same term.
1819
Table 106: IPv6 Supported Match Condions
(Connued)
Match Condion Descripon
destination-port
number
Match the UDP or TCP desnaon port eld.
You cannot specify both the port and destination-port match condions in the same
term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
In place of the numeric value, you can specify one of the following text synonyms
(the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68),
bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105),
ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443),
ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754),
krbupdate (760), kshell (544), ldap (389), ldp (646), login (513), mobileip-agent (434),
mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139),
nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515),
radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161),
snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs (49),
tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except
number
Do not match the UDP or TCP desnaon port eld. For details, see the destination-
port match condion.
destination-prefix-list
prefix-list-name
[ except ]
Match the IPv6 desnaon prex to the specied list unless the except opon is
included. If the opon is included, do not match the IPv6 desnaon prex to the
specied list.
The prex list is dened at the [edit policy-options prefix-list
prefix-list-name
]
hierarchy level.
1820
Table 106: IPv6 Supported Match Condions
(Connued)
Match Condion Descripon
icmp-code
message-code
Match the ICMP message code eld.
If you congure this match condion, we recommend that you also congure the
next-header icmp or next-header icmp6 match condion in the same term.
An ICMP message code provides more specic informaon than an ICMP message
type, but the meaning of an ICMP message code is dependent on the associated
ICMP message type.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed). The keywords are grouped by the ICMP type with
which they are associated:
• parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-
option (2)
• me-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• desnaon-unreachable: administratively-prohibited (1), address-unreachable (3),
no-route-to-destination (0), port-unreachable (4)
icmp-code-except
message-code
Do not match the ICMP message code eld. For details, see the icmp-code match
condion.
1821
Table 106: IPv6 Supported Match Condions
(Connued)
Match Condion Descripon
message-type
Match the ICMP message type eld.
You must also congure icmp or next-header icmp6 match condion in the same term.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): certificate-path-advertisement (149), certificate-
path-solicitation (148), destination-unreachable (1), echo-reply (129), echo-
request (128), home-agent-address-discovery-reply (145), home-agent-address-discovery-
request (144), inverse-neighbor-discovery-advertisement (142), inverse-neighbor-
discovery-solicitation (141), membership-query (130), membership-report (131),
membership-termination (132), mobile-prefix-advertisement-reply (147), mobile-prefix-
solicitation (146), neighbor-advertisement (136), neighbor-solicit (135), node-
information-reply (140), node-information-request (139), packet-too-big (2), parameter-
problem (4), private-experimentation-100 (100), private-experimentation-101 (101),
private-experimentation-200 (200), private-experimentation-201 (201), redirect (137),
router-advertisement (134), router-renumbering (138), router-solicit (133), or time-
exceeded (3).
For private-experimentation-201 (201), you can also specify a range of values within
square brackets.
icmp-type-except
message-type
Do not match the ICMP message type eld. For details, see the icmp-type match
condion.
next
Connue to the next term in a lter.
next-header
header-type
Match the rst 8-bit Next Header eld in the packet.
In place of the numeric value, you can specify one of the following text synonyms
(the eld values are also listed): ah (51), dstops (60), egp (8), esp (50), fragment (44),
gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41),
mobility (135), no-next-header (59), ospf (89), pim (103), routing (43), rsvp (46),
sctp (132), tcp (6), udp (17), or vrrp (112).
NOTE: next-header icmp6 and next-header icmpv6 match condions perform the same
funcon. next-header icmp6 is the preferred opon. next-header icmpv6 is hidden in the
Junos OS CLI.
1822
Table 106: IPv6 Supported Match Condions
(Connued)
Match Condion Descripon
next-header-except
header-type
Do not match the 8-bit Next Header eld that idenes the type of header between
the IPv6 header and payload. For details, see the next-header match type.
port
number
Match the UDP or TCP source or desnaon port eld.
If you congure this match condion, you cannot congure the destination-port
match condion or the source-port match condion in the same term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
In place of the numeric value, you can specify one of the text synonyms listed under
destination-port.
port-except
number
Do not match the UDP or TCP source or desnaon port eld. For details, see the
port match condion.
port-mirror
instance-
name
Port-mirror the packet.
port-mirror-instance
instance-name
Port mirror a packet for an instance.
prefix-list
prefix-list-
name
[ except ]
Match the prexes of the source or desnaon address elds to the prexes in the
specied list unless the except opon is included. If the opon is included, do not
match the prexes of the source or desnaon address elds to the prexes in the
specied list.
The prex list is dened at the [edit policy-options prefix-list
prefix-list-name
]
hierarchy level.
sample
Sample the packet.
1823
Table 106: IPv6 Supported Match Condions
(Connued)
Match Condion Descripon
source-address
address
[ except ]
Match the IPv6 address of the source node sending the packet unless the except
opon is included. If the opon is included, do not match the IPv6 address of the
source node sending the packet.
You cannot specify both the address and source-address match condions in the same
term.
source-port
number
Match the UDP or TCP source port eld.
You cannot specify the port and source-port match condions in the same term.
If you congure this match condion, we recommend that you also congure the
next-header udp or next-header tcp match condion in the same term to specify which
protocol is being used on the port.
NOTE: For Junos OS Evolved, you must congure the next-header udp or next-header
tcp match statement in the same term.
In place of the numeric value, you can specify one of the text synonyms listed with
the destination-port
number
match condion.
source-port-except
number
Do not match the UDP or TCP source port eld. For details, see the source-port
match condion.
source-prefix-list
name
[ except ]
Match the IPv6 address prex of the packet source eld unless the except opon is
included. If the opon is included, do not match the IPv6 address prex of the packet
source eld.
Specify a prex list name dened at the [edit policy-options prefix-list
prefix-
list-name
] hierarchy level.
NOTE: If you specify an IPv6 address in a match condion (the address, destination-address, or
source-address match condions), use the syntax for text representaons described in RFC 4291,
IP Version 6 Addressing Architecture
. For more informaon about IPv6 addresses, see IPv6
Overview and Supported IPv6 Standards.
1824
Table 107: Acons for IPv6 Firewall Filters
Acon Descripon
accept
Accept a packet. This is the default acon for packets that match a term.
discard
Discard a packet silently without sending an Internet Control Message Protocol (ICMP) message.
redirect
instance-
name
(Supported on PTX10004, PTX10008, and PTX10016 devices running Junos Evolved OS Release
22.1R1 only.)
Send packets to the P4 controller, as specied in the instance dened at the [services inline-
monitoring instance
instance-name
controller p4] level of the Junos hierarchy.
Table 108: Acon Modiers for IPv6 Firewall Filters
Acon
Modier
Descripon
count
counter-name
Count the number of packets that match the term.
forwarding-
class
class
Classify the packet in one of the following default forwarding classes, or in a user-dened
forwarding class:
• best-effort
• fcoe
• mcast
• network-control
• no-loss
NOTE: To congure a forwarding class, you must also congure loss priority.
1825
Table 108: Acon Modiers for IPv6 Firewall Filters
(Connued)
Acon
Modier
Descripon
loss-priority
(low |
medium-low |
medium-high |
high)
Set the packet loss priority (PLP).
RELATED DOCUMENTATION
Overview of Firewall Filters (QFX Series) | 1720
Conguring Firewall Filters | 1829
Overview of Policers | 2202
Understanding Mulple Firewall Filters Applied as a List | 1342
Guidelines for Applying Mulple Firewall Filters as a List | 1346
Firewall and Policing Dierences Between PTX Series Packet Transport
Routers and T Series Matrix Routers
This topic provides a list of rewall and policier features available on PTX Packet Transport Routers and
compares them with rewall and policing features on T Series routers.
Firewall Filters
Junos OS rewall and policing soware on PTX Series Packet Transport Routers supports IPv4 lters,
IPv6 lters, MPLS lters, CCC lters, interface policing, LSP policing, MAC ltering, ARP policing, L2
policing, and other features. Excepons are noted below.
• PTX Series Packet Transport Routers do not support:
• Egress Forwarding Table Filters
• Forwarding Table Filters for MPLS/CCC
• Family VPLS
1826
• PTX Series Packet Transport Routers do not support nested rewall lters. The filter statement at
the [edit firewall family
family-name
filter
filter-name
term
term-name
] hierarchy level is disabled.
• Because no service PICs are present in PTX Series Packet Transport Routers, service lters are not
supported for both IPv4 and IPv6 trac. The service-filter statement at [edit firewall family (inet |
inet6)] hierarchy level is disabled.
• The PTX Series Packet Transport Routers exclude simple lters. These lters are supported on
Gigabit Ethernet intelligent queuing (IQ2) and Enhanced Queuing Dense Port Concentrator (EQ DPC)
interfaces only. The simple-filter statement at the [edit firewall family inet)] hierarchy level is
disabled.
• Physical interface ltering is not supported. The physical-interface-filter statement at the [edit
firewall family
family-name
filter
filter-name
] hierarchy level is disabled.
• The prex acon feature is not supported on PTX Series Packet Transport Routers. The prefix-action
statement at [edit firewall family inet] hierarchy level is disabled.
• On T Series routers, you can collect a variety of informaon about trac passing through the device
by seng up one or more accounng proles that specify some common characteriscs of the data.
The PTX Series Packet Transport Routers do not support accounng conguraons for rewall lters.
The accounting-profile statement at the [edit firewall family
family-name
filter
filter-name
] hierarchy
level is disabled.
• The reject acon is not supported on the loopback (lo0) interface. If you apply a lter to the lo0
interface and the lter includes a reject acon, an error message appears.
• PTX Series Packet Transport Routers do not support aggregated ethernet logical interface match
condions. However, child link interface matching is supported.
• PTX Series Packet Transport Routers displays both counts if two dierent terms in a lter have the
same match condion but they have dierent counts. T Series routers display one count only.
• PTX Series Packet Transport Routers do not have separate policer instances when a lter is bound to
mulple interfaces. Use the interface-specific conguraon statement to create the conguraon.
• On PTX Series Packet Transport Routers, when an ingress interface has CCC encapsulaon, packets
coming in through the ingress CCC interface will not be processed by the egress lters.
• For CCC encapsulaon, the PTX Series Packet Transport Routers append an extra 8 bytes for egress
Layer 2 ltering. The T Series routers do not. Therefore, egress counters on PTX Series Packet
Transport Routers show an extra eight bytes for each packet which impacts policer accuracy.
• On PTX Series Packet Transport Routers, output for the show pfe statistics traffic CLI command
includes the packets discarded by DMAC and SMAC ltering. On T Series routers, the command
1827
output does not include these discarded packets because MAC lters are implemented in the PIC
and not in the FPC.
• The last-fragment packet that goes through a PTX rewall cannot be matched by the is-fragment
matching condion. This feature is supported on T Series routers.
A possible workaround on PTX Series Packet Transport Routers is to congure two separate terms
with same the acons: one term contains a match to is-fragment and the other term contains a match
to fragment-offset -except 0.
• On PTX Series Packet Transport Routers, MAC pause frames are generated when packet discards
exceed 100 Mbps. This occurs only for frame sizes that are less than 105 bytes.
Trac Policiers
Junos OS rewall and policing soware on PTX Series Packet Transport Routers supports IPv4 lters,
IPv6 lters, MPLS lters, CCC lters, interface policing, LSP policing, MAC ltering, ARP policing, L2
policing, and other features. Excepons are noted below.
• PTX Series Packet Transport Routers support ARP policing. T Series routers do not.
• PTX Series Packet Transport Routers do not support LSP policing.
• PTX Series Packet Transport Routers do not support the hierarchical-policer conguraon statement. .
• PTX Series Packet Transport Routers do not support the interface-set conguraon statement. This
statement groups a number of interfaces into a single, named interface set.
• PTX Series Packet Transport Routers do not support the following policer types for both normal
policers and three-color policers:
• logical-bandwidth-policer — Policer uses logical interface bandwidth.
• physical-interface-policer — Policer is a physical interface policer.
• shared-bandwidth-policer — Share policer bandwidth among bundle links.
• When a policer acon and forwarding-class, loss-priority acons are congured within the same rule
(a
Muleld Classicaon
), the PTX Series Packet Transport Routers work dierently than T Series
routers. As shown below, you can congure two rules in the lter to make the PTX lter behave the
same as the T Series lter:
PTX Series conguraon:
rule-1 {
match: {x, y, z}
action: {forwarding-class, loss-prio, next}
1828
}
rule-2 {
match: {x, y, z}
action: {policer}
}
T Series conguraon:
rule-1 {
match: {x, y, z}
action: {forwarding-class, loss-prio, policer}
}
RELATED DOCUMENTATION
Roung Policies, Firewall Filters, and Trac Policers User Guide
Conguring Firewall Filters
IN THIS SECTION
Conguring a Firewall Filter | 1829
Conguring Enhanced Egress Firewall Filters (QFX5110 and QFX5220 Switches) | 1833
Applying a Firewall Filter to a Port | 1834
Applying a Firewall Filter to a VLAN | 1835
Applying a Firewall Filter to a Layer 3 (Routed) Interface | 1835
Applying a Firewall Filter to a Layer 2 CCC (QFX10000 Switches) | 1837
Follow the steps in the following secons to congure and apply a rewall lter on your switch.
Conguring a Firewall Filter
To congure a rewall lter:
1829
1. Congure the family address type, lter name, term name, and at least one match condion—for
example, match on packets that contain a specic source address.
[edit]
user@switch# set firewall family ethernet-switching filter ingress-port-filter term term-one
from source-address 192.0.2.14
• To lter Layer 2 trac (port or VLAN), specify the family address type ethernet-switching.
• To lter Layer 3 (routed) trac, specify the family address type (inet for IPv4) or (inet6 for IPv6).
• To lter Layer 2 circuit interface trac, specify the family address type ccc.
The lter and term names can contain leers, numbers, and hyphens (-) and can be up to 64
characters long. Each lter name must be unique. A lter can contain one or more terms, and each
term name must be unique within a lter.
2. Congure addional match condions. For example:
In this conguraon, the lter matches on Layer 2 packets that contain source port 80.
[edit firewall family ethernet-switching filter ingress-port-filter term term-one from]
user@switch# set source-port 80
In this conguraon, the lter matches on VLANs that contain interface ge-0/0/6.0.
[edit firewall family inet filter ingress-interface-match-condition term term-one from]
user@switch#set interface ge-0/0/6.0.
You can specify one or more match condions in a single from statement. For a match to occur, the
packet must match all the condions in the term. The from statement is oponal, but if you include it
in a term, it can’t be empty. If you omit the from statement, all packets are considered to match.
3. If you want to apply a rewall lter to mulple interfaces and be able to see counters specic to each
interface, congure the interface-specific opon:
[edit firewall family ethernet-switching filter ingress-port-filter]
user@switch# set interface-specific
4. In each rewall lter term, specify the acons to take if the packet matches all the condions in that
term. You can specify an acon and acon modiers:
1830
• To specify a lter acon, for example, to discard packets that match the condions of the lter
term:
[edit firewall family ethernet-switching filter ingress-port-filter term term-one then]
user@switch# set discard
You can specify only one acon per term (accept, discard, flood, reject, routing-instance, or vlan).
• To specify a lter acon, for example, to ood packets that match the MAC address on
QFX5100/QFX5110/ QFX5120-32C/QFX5200/QFX5210:
[edit firewall family ethernet-switching filter f1 term t2 then]
user@switch# set flood
You can congure the ingress port-based rewall lters to ood or discard the following BPDUs
by using the desnaon MAC address as the match condion.
Protocols Desnaon Media Access
Control (DMAC) Address
Firewall Acon
Link Aggregaon Control Protocol (LACP) 01:80:c2:00:00:02 Flood/Discard/Count
Link Layer Discovery Protocol (LLDP) 01:80:c2:00:00:0E Flood/Discard/Count
Extensible Authencaon Protocol over LAN
(EAPOL)
01:80:c2:00:00:03 Flood/Discard/Count
Spanning Tree Protocol (STP) 01:80:c2:00:00:00 Flood/Discard/Coun
VLAN Spanning Tree Protocol (VSTP) 01:00:0c:cc:cc:cd Flood/Discard/Count
Cisco Discovery Protocol (CDP)/VLAN Trunk
Protocol (VTP)
01:00:0C:cc:cc:cc Discard/Count
ISIS L1 01:80:c2:00:00:14 Discard/Count
ISIS L2 01:80:c2:00:00:15 Discard/Count
1831
NOTE:
• CDP/VTP, ISIS L1/L2 protocols ood by using the default dynamic lter. Therefore,
conguring addional lters for these protocols is not necessary.
• As ingress port-based rewall lters are applied at the port level, only one lter can be
applied for a physical interface in the service provider style conguraon.
• The nave VLAN must be congured to ensure ooding of the untagged BPDUs
received on the trunk port. If the nave VLAN is not congured, then the untagged
BPDUs will be ooded on all the interfaces in the local FPC.
• When IGMP snooping or mulcast listener discovery (MLD) snooping is enabled then,
the ood funconality does not work.
• When the rewall lter with ood acon is applied on an interface and later if the
interface goes down, then the BPDUs received on that interface will be ooded if it
sases the match condions.
• To specify acon modiers, for example, to count and classify packets to a forwarding class:
[edit firewall family ethernet-switching filter ingress-port-filter term term-one then]
user@switch# set count counter-one
user@switch# set forwarding-class expedited-forwarding
user@switch# set loss-priority high
You can specify any of the following acon modiers in a then statement:
• analyzer
analyzer-name
—Mirror port trac to a specied analyzer, which you must congure at
the [ethernet-switching-options] level.
• count
counter-name
—Count the number of packets that pass this lter term.
NOTE: We recommend that you congure a counter for each term in a rewall lter, so
that you can monitor the number of packets that match the condions specied in
each lter term.
NOTE: On QFX3500 and QFX3600 switches, lters automacally count packets that
were dropped in the ingress direcon because of cyclic redundancy check (CRC) errors.
1832
• forwarding-class
class
—Assign packets to a forwarding class.
• log—Log the packet header informaon in the Roung Engine.
• loss-priority
priority
—Set the priority of dropping a packet.
• policer
policer-name
—Apply rate-liming to the trac.
• flood—Flood the packets.
• syslog—Log an alert for this packet.
If you omit the then statement or don’t specify an acon, packets matching all the condions in the
from statement are accepted. But make sure that you always congure an acon in the then statement.
You can only include one acon statement, but can use any combinaon of acon modiers. For an
acon or acon modier to take eect, all condions in the from statement must match.
NOTE: The implicit discard acon applicable to a rewall lter applied to the loopback
interface, lo0.
Conguring Enhanced Egress Firewall Filters (QFX5110 and QFX5220 Switches)
Due to a hardware limitaon, the QFX5110 and QFX5220 switches can only support a maximum of
1000 egress rewall lters (eRACLs). You can increase this number to 2000, by conguring the switch in
scaled mode. In this mode, the switch uses ingress TCAM space (IFP) to achieve the higher scale.
To congure the egress lter, specify the family address type (inet for IPv4) or (inet6 for IPv6), lter
name, and term name. Include the applicable scaling opon for your switch and specify a match
condion and acon to take if a match occurs. Then apply the lter in the output direcon on the
interface.
Aer conguring, modifying, or deleng a scaling opon, you must commit the conguraon, and the
packet forwarding engine (PFE) must be restarted.
To increase the number of egress lters on the QFX5110, include the egress-to-ingress opon in your
conguraon. You can add this opon under any term. The following is a sample conguraon:
set firewall family inet filter f1 term t1 from egress-to-ingress
set firewall family inet filter f1 term t1 from source-port 1500
set firewall family inet filter f1 term t1 then accept
set interfaces irb unit 100 family inet filter output f1
To increase the number of egress lters on the QFX5220, include the eracl-scale opon under the egress-
profile statement. The following is a sample conguraon:
1833
NOTE: The eracl-scale opon comes congured in global mode. When enabled, exisng egress
lters will be automacally reinstalled in scaled mode.
set system packet-forwarding-options firewall eracl-profile eracl-scale
set firewall family inet filter f1 term t1 from source-port 1500
set firewall family inet filter f1 term t1 then accept
set interfaces irb unit 100 family inet filter output f1
When you enable scaled mode, these limitaons apply:
• You can only apply a lter in the egress direcon (trac exing the VLAN).
• Only inet and inet6 protocol families are supported.
• Generic Roung Encapsulaon (GRE) interfaces are not supported.
• Only use the scaling opons for egress rewall lters.
• You cannot apply lters with the same match condion to dierent egress VLANs or Layer 3
interfaces. The only supported acons are accept, discard, and count.
• Match condions are programmed in the ingress rewall lter TCAM. This means that any counters
aached to the lter counts trac on any incoming VLANs.
Applying a Firewall Filter to a Port
To apply a rewall lter to a port:
1. Provide a meaningful and descripve name for the rewall lter. The name is what you use to apply
the lter to the port.
[edit]
user@switch# set interfaces ge-0/0/6 description "filter to limit tcp traffic at trunk port
for employee-vlan"
2.
Apply the lter to the interface, specifying the unit number, family address type (ethernet-switching),
the direcon of the lter (for packets entering the port), and the lter name:
[edit]
user@switch# set ge-0/0/6 unit 0 family ethernet-switching filter input ingress-port-filter
1834
NOTE: You can apply only one lter to a port in the ingress direcon.
Applying a Firewall Filter to a VLAN
NOTE: VLAN rewall lters are not supported on QFX5100, QFX5100 Virtual Chassis,
QFX5110, and QFX5120 switches in an EVPN-VXLAN environment.
To apply a rewall lter to a VLAN:
1. Provide a meaningful and descripve name for the rewall lter. This name is what you use to apply
the lter to the VLAN.
[edit]
user@switch# set vlans employee-vlan vlan-id 20 description "filter to block rogue devices on
employee-vlan"
2. Apply rewall lters to lter packets entering or exing the VLAN:
• To apply a lter to match packets entering the VLAN:
[edit]
user@switch# set vlans employee-vlan vlan-id 20 filter input ingress-vlan-rogue-block
• To apply a rewall lter to match packets exing the VLAN:
[edit]
user@switch# set vlans employee-vlan vlan-id 20 filter output egress-vlan-filter
NOTE: You can apply only one lter to a VLAN for a given direcon (ingress or egress).
Applying a Firewall Filter to a Layer 3 (Routed) Interface
You can apply a rewall lter to IPv4 and IPv6 interfaces, routed VLAN interfaces (RVI) (also known as
an integrated roung and bridging (IRB) interface), and the loopback interface. These are all considered
Layer 3 routed interfaces.
1835
NOTE: (QFX5100 and QFX5110 switches) In an EVPN-VXLAN environment, you can use an IRB
interface to provide layer 3 connecvity to the switch. To congure an IRB interface, see
Example: Conguring IRB Interfaces in an EVPN-VXLAN Environment to Provide Layer 3
Connecvity for Hosts in a Data Center
. You can then apply a rewall lter to the IRB interface
by following the steps below (only the ingress direcon is supported). For a list of supported
match condions, see "Firewall Filter Match Condions and Acons (QFX5100, QFX5110,
QFX5120, QFX5200, EX4600, EX4650)" on page 1735.
NOTE: When you apply a lter to an IRB interface associated with a given VLAN, the lter is
executed on any Layer 3 interface with a matching VLAN ID. This is because the lter matches
on all Layer 3 interfaces with the corresponding VLAN tag.
To apply a rewall lter to a Layer 3 interface:
1. Provide a meaningful and descripve name for the rewall lter. This name is what you use to apply
the lter to the interface.
[edit]
user@switch# set interfaces ge-0/1/6 description "filter to count and monitor traffic on
layer 3 interface"
2. Apply the rewall lters.
• To lter packets entering the interface:
[edit]
user@switch# set interfaces ge-0/1/6 unit 0 family inet filter input ingress-router-filter
• To lter packets exing the interface:
[edit]
user@switch# set interfaces ge-0/1/6 unit 0 family inet filter output egress-router-filter
The family address type can either be (inet for IPv4) or (inet6 for IPv6).
NOTE: You can apply only one lter to an interface for a given direcon (ingress or egress).
1836
Applying a Firewall Filter to a Layer 2 CCC (QFX10000 Switches)
You can apply rewall lters with count and policer acons on Layer 2 circuit cross-connect (CCC) trac
on QFX10000 switches. This lets you count and monitor the policer acvity set at the [edit firewall
family ccc] hierarchy level.
In this example, count is the policer acon.
set firewall policer traffic-cnt if-exceeding bandwidth-limit 1g
set firewall policer traffic-cnt if-exceeding burst-size-limit 100m
set firewall policer traffic-cnt then loss-priority low
set firewall family ccc filter srTCM-cnt term t1 then policer traffic-cnt
set firewall family ccc filter srTCM-cnt term t1 then count traffic-counter
In this example, discard is the policer acon.
set firewall policer discard-traffic if-exceeding bandwidth-limit 1g
set firewall policer discard-traffic if-exceeding burst-size-limit 500m
set firewall policer discard-traffic then discard
set firewall family ccc filter srTCM1 term t1 then policer discard-traffic
RELATED DOCUMENTATION
Overview of Firewall Filters (QFX Series) | 1720
Planning the Number of Firewall Filters to Create | 1725
Firewall Filter Match Condions and Acons (QFX and EX Series Switches) | 1734
Firewall Filter Match Condions and Acons (QFX10000 Switches) | 1783
Monitoring Firewall Filter Trac | 829
1837
Applying Firewall Filters to Interfaces
For a rewall lter to work, you must apply it to at least one interface. To do this, include the filter
statement when conguring a logical interface at the [edit interfaces] hierarchy level:
[edit interfaces]
user@switch# set
interface-name
unit
logical-unit-number
family
family-name
filter (input |
output)
filter-name
In the input statement, specify a rewall lter to be evaluated when packets are received on the
interface. Input lters applied to a loopback interface aect only trac desned for the Roung Engine.
In the output statement, specify a lter to be evaluated when packets exit the interface.
NOTE: When you create a loopback interface, it is important to apply an ingress lter to it so the
Roung Engine is protected. We recommend that when you apply a lter to the loopback
interface lo0, you include the apply-groups statement. Doing so ensures that the lter is
automacally inherited on every loopback interface, including lo0 and other loopback interfaces.
RELATED DOCUMENTATION
Conguring Firewall Filters | 1829
Overview of MPLS Firewall Filters on Loopback Interface
IN THIS SECTION
Benets of Adding MPLS Firewall Filters on the Loopback Interface | 1839
Guidelines and Limitaons | 1839
Although all interfaces are important, the loopback interface might be the most important because it is
the link to the Roung Engine, which runs and manages all the roung protocols. The loopback interface
is a gateway for all the control trac that enters the Roung Engine of the switch. You can control this
1838
trac by conguring a rewall lter on the loopback interface (lo0) on family mpls. Loopback rewall
lters aect only trac desned for the Roung Engine CPU. You can apply a loopback rewall lter
only in the
ingress
direcon (packets entering the interface). Starng with Junos OS Release 19.2R1, you
can apply an MPLS rewall lter to a loopback interface on a label switch router (LSR) on QFX5100,
QFX5110, QFX5200, and QFX5210 switches.
When you congure an MPLS rewall lter, you dene ltering criteria (
terms, with match condions
)
for the packets and an
acon
for the switch to take if the packets match the ltering criteria. Because
you apply the lter to a loopback interface, you must explicitly specify the me to live (TTL) match
condion under family mpls and set its TTL value to 1 (ttl=1). The TTL is an 8-bit (IPv4) header eld that
signies the remaining me an IP packet has le before its life ends and is dropped. You can also match
packets with other MPLS qualiers such as label, exp, Layer 4 source port, and Layer 4 destination port.
Benets of Adding MPLS Firewall Filters on the Loopback Interface
• Protects the Roung Engine by ensuring that it accepts trac only from trusted networks.
• Helps protect the Roung Engine from denial-of-service aacks.
• Gives you the exibility to match packets on the source port and desnaon port. For example, if
you run a traceroute, you can selecvely lter trac by choosing either TCP or UDP.
Guidelines and Limitaons
• You can apply a loopback rewall lter only in the
ingress
direcon
• Only MPLS elds label, exp, ttl=1 and Layer 4 elds tcp and udp port numbers are supported.
• Only accept, discard, and count acons are supported.
• You must explicitly specify ttl=1 under family mpls to match on TLL packets.
• Filters applied on the loopback interface cannot be matched on the desnaon port (inner payload)
of an IPv6 packet.
• You cannot apply a lter on packets that have more than two MPLS labels.
• You cannot specify a port range for TCP or UDP match condions.
• Only 255 rewall terms are supported.
Change History Table
1839
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release Descripon
19.2R1 Starng with Junos OS Release 19.2R1, you can apply an MPLS rewall lter to a loopback interface on
a label switch router (LSR) on QFX5100, QFX5110, QFX5200, and QFX5210 switches.
Conguring MPLS Firewall Filters and Policers on Switches
IN THIS SECTION
Conguring an MPLS Firewall Filter | 1840
Applying an MPLS Firewall Filter to an MPLS Interface | 1841
Applying an MPLS Firewall Filter to a Loopback Interface | 1841
Conguring Policers for LSPs | 1842
You can congure rewall lters to lter MPLS trac. To use an MPLS rewall lter, you must rst
congure the lter and then apply it to an interface you have congured for forwarding MPLS trac.
You can also congure a policer for the MPLS lter to police (that is, rate-limit) the trac on the
interface to which the lter is aached.
When you congure an MPLS rewall lter, you dene the ltering criteria (terms, with match
condions) and an acon for the switch to take if the packets match the ltering criteria.
NOTE: You can only congure MPLS lters in the ingress direcon. Egress MPLS rewall lters
are not supported.
Conguring an MPLS Firewall Filter
To congure an MPLS rewall lter:
1840
1. Congure the lter name, term name, and at least one match condion—for example, match on
MPLS packets with EXP bits set to either 0 or 4:
[edit firewall family mpls]
user@switch# set filter ingress-exp-filter term term-one from exp 0,4
2. In each rewall lter term, specify the acons to take if the packet matches all the condions in that
term—for example, count MPLS packets with EXP bits set to either 0 or 4:
[edit firewall family mpls filter ingress-exp-filter term term-one then]
user@switch# set count counter0
user@switch# set accept
3. When you are nished, follow the steps below to apply the lter to an interface.
Applying an MPLS Firewall Filter to an MPLS Interface
To apply the MPLS rewall lter to an interface you have congured for forwarding MPLS trac (using
the family mpls statement at the [edit interfaces
interface-name
unit
unit-number
] hierarchy level):
NOTE: You can apply rewall lters only to lter MPLS packets that enter an interface.
1. Apply the rewall lter to an MPLS interface—for example, apply the rewall lter to interface
xe-0/0/5:
[edit interfaces]
user@switch# set xe-0/0/5 unit 0 family mpls filter input ingress-exp-filter
2. Review your conguraon and issue the commit command:
[edit interfaces]
user@switch# commit
commit complete
Applying an MPLS Firewall Filter to a Loopback Interface
To apply an MPLS rewall lter to a loopback interface (lo0):
1. First, specify the packet format by using the
packet-format-match
command. You must restart the
PFE every me you congure this command.
1841
2. Congure the rewall lter match condions and acons as described in "Conguring an MPLS
Firewall Filter" on page 1840. You must explicitly set the TTL match condion to (ttl=1). You can also
match packets with other MPLS qualiers such as label, exp, and Layer 4 source port, and destination
port.
3. Apply the lter to the loopback interface as an input lter.
[edit interfaces]
user@switch# set lo0 unit 0 family mpls filter input ingress-exp-filter
4. Review your conguraon and issue the commit command:
[edit interfaces]
user@switch# commit
commit complete
The following is an example conguraon.
set groups lo_mpls_filter interfaces lo0 unit 0 family mpls filter input mpls_lo
set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term from ttl 1
set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term from ip-version ipv4
protocol udp source-port 10
set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term from ip-version ipv4
protocol udp destination-port 11
set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term then count c1
set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term then accept
Conguring Policers for LSPs
Starng with Junos OS 13.2X51-D15, you can send trac matched by an MPLS lter to a two-color
policer or three-color policer. MPLS LSP policing allows you to control the amount of trac forwarded
through a parcular LSP. Policing helps to ensure that the amount of trac forwarded through an LSP
never exceeds the requested bandwidth allocaon. LSP policing is supported on regular LSPs, LSPs
congured with DiServ-aware trac engineering, and mulclass LSPs. You can congure mulple
policers for each mulclass LSP. For regular LSPs, each LSP policer is applied to all of the trac
traversing the LSP. The policer's bandwidth limitaons become eecve as soon as the total sum of
trac traversing the LSP exceeds the congured limit.
You congure the mulclass LSP and DiServ-aware trac engineering LSP policers in a lter. The lter
can be congured to disnguish between the dierent class types and apply the relevant policer to each
class type. The policers disnguish between class types based on the EXP bits.
1842
You congure LSP policers under the family any lter. The family any lter is used because the policer is
applied to trac entering the LSP. This trac might be from dierent families: IPv6, MPLS, and so on.
You do not need to know what sort of trac is entering the LSP, as long as the match condions apply
to all types of trac.
When conguring MPLS LSP policers, be aware of the following limitaons:
• LSP policers are supported for packet LSPs only.
• LSP policers are supported for unicast next hops only. Mulcast next hops are not supported.
• The LSP policer runs before any output lters.
• Trac sourced from the Roung Engine (for example, ping trac) does not take the same forwarding
path as transit trac. This type of trac cannot be policed.
Conguring MPLS Firewall Filters and Policers on Routers
IN THIS SECTION
Conguring MPLS Firewall Filters | 1843
Examples: Conguring MPLS Firewall Filters | 1844
Conguring Policers for LSPs | 1845
Example: Conguring an LSP Policer | 1847
Conguring Automac Policers | 1848
Wring Dierent DSCP and EXP Values in MPLS-Tagged IP Packets | 1852
You can congure an MPLS rewall lter to count packets based on the EXP bits for the top-level MPLS
label in a packet. You can also congure policers for MPLS LSPs.
The following secons discuss MPLS rewall lters and policers:
Conguring MPLS Firewall Filters
You can congure an MPLS rewall lter to count packets based on the EXP bits for the top-level MPLS
label in a packet. You can then apply this lter to a specic interface. You can also congure a policer for
the MPLS lter to police (that is, rate-limit) the trac on the interface to which the lter is aached. You
cannot apply MPLS rewall lters to Ethernet (fxp0) or loopback (lo0) interfaces.
1843
You can congure the following match criteria aributes for MPLS lters at the [edit firewall family mpls
filter
filter-name
term
term-name
from] hierarchy level:
• exp
• exp-except
These aributes can accept EXP bits in the range 0 through 7. You can congure the following choices:
• A single EXP bit—for example, exp 3;
• Several EXP bits—for example, exp 0, 4;
• A range of EXP bits—for example, exp [0-5];
If you do not specify a match criterion (that is, you do not congure the from statement and use only the
then statement with the count acon keyword), all the MPLS packets passing through the interface on
which the lter is applied will be counted.
You also can congure any of the following acon keywords at the [edit firewall family mpls filter
filter-
name
term
term-name
then] hierarchy level:
• count
• accept
• discard
• next
• policer
For more informaon about how to congure rewall lters, see the Roung Policies, Firewall Filters,
and Trac Policers User Guide. For more informaon about how to congure interfaces, see the Junos
OS Network Interfaces Library for Roung Devices and the Junos OS Services Interfaces Library for
Roung Devices.
Examples: Conguring MPLS Firewall Filters
The following examples illustrate how you might congure an MPLS rewall lter and then apply the
lter to an interface. This lter is congured to count MPLS packets with EXP bits set to either 0 or 4.
The following shows a conguraon for an MPLS rewall lter:
[edit firewall]
family mpls {
filter expf {
1844
term expt0 {
from {
exp 0,4;
}
then {
count counter0;
accept;
}
}
}
}
The following shows how to apply the MPLS rewall lter to an interface:
[edit interfaces]
so-0/0/0 {
mtu 4474;
encapsulation ppp;
sonet-options {
fcs 32;
}
unit 0 {
point-to-point;
family mpls {
filter {
input expf;
output expf;
}
}
}
}
The MPLS rewall lter is applied to the input and output of an interface (see the input and output
statements in the preceding example).
Conguring Policers for LSPs
MPLS LSP policing allows you to control the amount of trac forwarded through a parcular LSP.
Policing helps to ensure that the amount of trac forwarded through an LSP never exceeds the
requested bandwidth allocaon. LSP policing is supported on regular LSPs, LSPs congured with
DiServ-aware trac engineering, and mulclass LSPs. You can congure mulple policers for each
mulclass LSP. For regular LSPs, each LSP policer is applied to all of the trac traversing the LSP. The
1845
policer's bandwidth limitaons become eecve as soon as the total sum of trac traversing the LSP
exceeds the congured limit.
NOTE: The PTX10003 router only supports regular LSPs.
You congure the mulclass LSP and DiServ-aware trac engineering LSP policers in a lter. The lter
can be congured to disnguish between the dierent class types and apply the relevant policer to each
class type. The policers disnguish between class types based on the EXP bits.
You congure LSP policers under the family any lter. The family any lter is used because the policer is
applied to trac entering the LSP. This trac might be from dierent families: IPv6, MPLS, and so on.
You do not need to know what sort of trac is entering the LSP, as long as the match condions apply
to all types of trac.
You can congure only those match condions that apply across all types of trac. The following are
the supported match condions for LSP policers:
• forwarding-class
• packet-length
• interface
• interface-set
To enable a policer on an LSP, rst you need to congure a policing lter and then include it in the LSP
conguraon. For informaon about how to congure policers, see the Roung Policies, Firewall Filters,
and Trac Policers User Guide.
To congure a policer for an LSP, specify a lter by including the filter opon to the policing statement:
policing {
filter
filter-name
;
}
You can include the policing statement at the following hierarchy levels:
•
[edit protocols mpls label-switched-path
lsp-name
]
• [edit protocols mpls static-label-switched-path
lsp-name
]
•
[edit logical-systems
logical-system-name
protocols mpls label-switched-path
lsp-name
]
• [edit logical-systems
logical-system-name
protocols mpls static-label-switched-path
lsp-name
]
1846
LSP Policer Limitaons
When conguring MPLS LSP policers, be aware of the following limitaons:
• LSP policers are supported for packet LSPs only.
• LSP policers are supported for unicast next hops only. Mulcast next hops are not supported.
• LSP policers are not supported on aggregated interfaces.
• The LSP policer runs before any output lters.
• Trac sourced from the Roung Engine (for example, ping trac) does not take the same forwarding
path as transit trac. This type of trac cannot be policed.
• LSP policers work on all T Series routers and on M Series routers that have the Internet Processor II
applicaon-specic integrated circuit (ASIC).
• LSP policers are not supported for point-to-mulpoint LSPs.
NOTE: Starng with Junos OS Release 12.2R2, on T Series routers only, you can congure an
LSP policer for a specic LSP to be shared across dierent protocol family types. To do so, you
must congure the
logical-interface-policer
statement at the [edit firewall policer
policer-name
]
hierarchy level.
Example: Conguring an LSP Policer
The following example shows how you can congure a policing lter for an LSP:
[edit firewall]
policer police-ct1 {
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 1500;
}
then {
discard;
}
}
policer police-ct0 {
if-exceeding {
bandwidth-limit 200m;
1847
burst-size-limit 1500;
}
then {
discard;
}
}
family any {
filter bar {
term discard-ct0 {
then {
policer police-ct0;
accept;
}
}
}
term discard-ct1 {
then {
policer police-ct1;
accept;
}
}
}
Conguring Automac Policers
Automac policing of LSPs allows you to provide strict service guarantees for network trac. Such
guarantees are especially useful in the context of Dierenated Services for trac engineered LSPs,
providing beer emulaon for ATM wires over an MPLS network. For more informaon about
Dierenated Services for LSPs, see DiServ-Aware Trac Engineering Introducon.
Dierenated Services for trac engineered LSPs allow you to provide dierenal treatment to MPLS
trac based on the EXP bits. To ensure these trac guarantees, it is insucient to simply mark the
trac appropriately. If trac follows a congested path, the requirements might not be met.
LSPs are guaranteed to be established along paths where enough resources are available to meet the
requirements. However, even if the LSPs are established along such paths and are marked properly,
these requirements cannot be guaranteed unless you ensure that no more trac is sent to an LSP than
there is bandwidth available.
It is possible to police LSP trac by manually conguring an appropriate lter and applying it to the LSP
in the conguraon. However, for large deployments it is cumbersome to congure thousands of
dierent lters. Conguraon groups cannot solve this problem either, since dierent LSPs might have
1848
dierent bandwidth requirements, requiring dierent lters. To police trac for numerous LSPs, it is
best to congure automac policers.
When you congure automac policers for LSPs, a policer is applied to all of the LSPs congured on the
router. However, you can disable automac policing on specic LSPs.
NOTE: When you congure automac policers for DiServ-aware trac engineering LSP, GRES
is not supported.
NOTE: You cannot congure automac policing for LSPs carrying CCC trac.
The following secons describe how to congure automac policers for LSPs:
Conguring Automac Policers for LSPs
To congure automac policers for standard LSPs (neither DiServ-aware trac engineered LSPs nor
mulclass LSPs), include the auto-policing statement with either the class all
policer-action
opon or the
class ct0
policer-action
opon:
auto-policing {
class all
policer-action
;
class ct0
policer-action
;
}
You can include this statement at the following hierarchy levels:
• [edit protocols mpls]
• [edit logical-systems
logical-system-name
protocols mpls]
You can congure the following policer acons for automac policers:
• drop—Drop all packets.
•
loss-priority-high—Set the packet loss priority (PLP) to high.
• loss-priority-low—Set the PLP to low.
These policer acons are applicable to all types of LSPs. The default policer acon is to do nothing.
Automac policers for LSPs police trac based on the amount of bandwidth congured for the LSPs.
You congure the bandwidth for an LSP using the
bandwidth
statement at the
[edit protocols mpls label-
1849
switched-path
lsp-path-name
] hierarchy level. If you have enabled automac policers on a router, change the
bandwidth congured for an LSP, and commit the revised conguraon, the change does not take aect
on the acve LSPs. To force the LSPs to use the new bandwidth allocaon, issue a clear mpls lsp
command.
NOTE: You cannot congure automac policers for LSPs that traverse aggregated interfaces or
Mullink Point-to-Point Protocol (MLPPP) interfaces.
Conguring Automac Policers for DiServ-Aware Trac Engineering LSPs
To congure automac policers for DiServ-aware trac engineering LSPs and for mulclass LSPs,
include the auto-policing statement:
auto-policing {
class all
policer-action
;
class ct
number
policer-action
;
}
You can include this statement at the following hierarchy levels:
• [edit protocols mpls]
• [edit logical-systems
logical-system-name
protocols mpls]
You include either the class all
policer-action
statement or a class ct
number
policer-action
statement for
each of one or more classes (you can congure a dierent policer acon for each class). For a list of the
acons that you can substute for the
policer-action
variable, see "Conguring Automac Policers for
LSPs" on page 1849. The default policer acon is to do nothing.
NOTE: You cannot congure automac policers for LSPs that traverse aggregated interfaces or
MLPPP interfaces.
Conguring Automac Policers for Point-to-Mulpoint LSPs
You can congure automac policers for point-to-mulpoint LSPs by including the auto-policing
statement with either the class all
policer-action
opon or the class ct0
policer-action
opon. You only
need to congure the auto-policing statement on the primary point-to-mulpoint LSP (for more
informaon on primary point-to-mulpoint LSPs, see Conguring the Primary Point-to-Mulpoint LSP).
No addional conguraon is required on the subLSPs for the point-to-mulpoint LSP. Point-to-
1850
mulpoint automac policing is applied to all branches of the point-to-mulpoint LSP. In addion,
automac policing is applied to any local VRF interfaces that have the same forwarding entry as a point-
to-mulpoint branch. Feature parity for automac policers for MPLS point-to-mulpoint LSPs on the
Junos Trio chipset is supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4.
The automac policer conguraon for point-to-mulpoint LSPs is idencal to the automac policer
conguraon for standard LSPs. For more informaon, see "Conguring Automac Policers for LSPs" on
page 1849.
Disabling Automac Policing on an LSP
When you enable automac policing, all of the LSPs on the router or logical system are aected. To
disable automac policing on a specic LSP on a router where you have enabled automac policing,
include the policing statement with the no-auto-policing opon:
policing no-auto-policing;
You can include this statement at the following hierarchy levels:
• [edit protocols mpls label-switched-path
lsp-name
]
• [edit logical-systems
logical-system-name
protocols mpls label-switched-path
lsp-name
]
Example: Conguring Automac Policing for an LSP
Congure automac policing for a mulclass LSP, specifying dierent acons for class types ct0, ct1, ct2,
and ct3.
[edit protocols mpls]
diffserv-te {
bandwidth-model extended-mam;
}
auto-policing {
class ct1 loss-priority-low;
class ct0 loss-priority-high;
class ct2 drop;
class ct3 loss-priority-low;
}
traffic-engineering bgp-igp;
label-switched-path sample-lsp {
to 3.3.3.3;
bandwidth {
1851
ct0 11;
ct1 1;
ct2 1;
ct3 1;
}
}
interface fxp0.0 {
disable;
}
interface t1-0/5/3.0;
interface t1-0/5/4.0;
Wring Dierent DSCP and EXP Values in MPLS-Tagged IP Packets
You can selecvely set the DiServ code point (DSCP) eld of MPLS-tagged IPv4 and IPv6 packets to 0
without aecng output queue assignment, and connue to set the MPLS EXP eld according to the
congured rewrite table, which is based on forwarding classes. You can accomplish this by conguring a
rewall lter for the MPLS-tagged packets.
Conguring MPLS Firewall Filters and Policers
IN THIS SECTION
Conguring MPLS Firewall Filters | 1852
Examples: Conguring MPLS Firewall Filters | 1853
Conguring Policers for LSPs | 1854
You can congure an MPLS rewall lter to count packets based on the EXP bits for the top-level MPLS
label in a packet. You can also congure policers for MPLS LSPs.
The following secons discuss MPLS rewall lters and policers:
Conguring MPLS Firewall Filters
You can congure an MPLS rewall lter to count packets based on the EXP bits for the top-level MPLS
label in a packet. You can then apply this lter to a specic interface on input or output. You can also
1852
congure a policer for the MPLS lter to police (that is, rate-limit) the trac on the interface to which
the lter is aached. You cannot apply MPLS rewall lters to loopback interfaces.
You can congure the following match condions for MPLS lters at the [edit firewall family mpls filter
filter-name
term
term-name
from] hierarchy level:
• exp
• label
These exp match condion can accept EXP bits in the range 0 through 7. You can congure the following
choices:
• A single EXP bit—for example, exp 3;
• Several EXP bits—for example, exp 0, 4;
• A range of EXP bits—for example, exp [0-5];
The label match condion can accept a range of values from 0 to 1048575.
If you do not specify a match criterion (that is, you do not congure the from statement and use only the
then statement with the count acon keyword), all the MPLS packets passing through the interface on
which the lter is applied will be counted.
You also can congure any of the following acon keywords at the [edit firewall family mpls filter
filter-
name
term
term-name
then] hierarchy level:
• accept
• count
• discard
• policer
• three-color-policer
Examples: Conguring MPLS Firewall Filters
The following examples illustrate how you might congure an MPLS rewall lter and then apply the
lter to an interface. This lter is congured to count MPLS packets with EXP bits set to either 0 or 4.
The following shows a conguraon for an MPLS rewall lter:
[edit firewall]
family mpls {
1853
filter expf {
term expt0 {
from {
exp 0,4;
}
then {
count counter0;
accept;
}
}
}
}
Conguring Policers for LSPs
MPLS LSP policing allows you to control the amount of trac forwarded through a parcular LSP.
Policing helps to ensure that the amount of trac forwarded through an LSP never exceeds the
requested bandwidth allocaon. LSP policing is supported on regular LSPs, LSPs congured with
DiServ-aware trac engineering, and mulclass LSPs. You can congure mulple policers for each
mulclass LSP. For regular LSPs, each LSP policer is applied to all of the trac traversing the LSP. The
policer's bandwidth limitaons become eecve as soon as the total sum of trac traversing the LSP
exceeds the congured limit.
You congure the mulclass LSP and DiServ-aware trac engineering LSP policers in a lter. The lter
can be congured to disnguish between the dierent class types and apply the relevant policer to each
class type. The policers disnguish between class types based on the EXP bits.
You congure LSP policers under the family any lter. The family any lter is used because the policer is
applied to trac entering the LSP. This trac might be from dierent families: IPv6, MPLS, and so on.
You do not need to know what sort of trac is entering the LSP, as long as the match condions apply
to all types of trac.
LSP Policer Limitaons
When conguring MPLS LSP policers, be aware of the following limitaons:
• LSP policers are supported for packet LSPs only.
• LSP policers are supported for unicast next hops only. Mulcast next hops are not supported.
• LSP policers are not supported on aggregated interfaces.
• The LSP policer runs before any output lters.
1854
• Trac sourced from the Roung Engine (for example, ping trac) does not take the same forwarding
path as transit trac. This type of trac cannot be policed.
•
RELATED DOCUMENTATION
Overview of Policers | 2202
Understanding How a Firewall Filter Tests a Protocol
When examining match condions in a
rewall lter
, a switch tests only the elds that you specify. It
does not implicitly test any elds that you do not explicitly congure. For example, if you specify a
match condion of source-port ssh, there is no implied test to determine if the protocol is TCP. In this
case, the switch considers any packet that has a value of 22 (decimal) in the 2-byte eld that follows a
presumed
IP header to be a match. To ensure that the term matches on TCP packets, you also specify an
ip-protocol tcp match condion.
For the following match condions, you should explicitly specify the protocol match condion in the
same term:
• destination-port—Specify protocol tcp or protocol udp.
• icmp-code—Specify protocol icmp and icmp-type.
• icmp-type—Specify protocol icmp or protocol icmp6.
• source-port—Specify protocol tcp or protocol udp.
• tcp-flags—Specify protocol tcp.
RELATED DOCUMENTATION
Understanding Firewall Filter Match Condions | 858
Conguring Firewall Filters | 1829
1855
Understanding Firewall Filter Processing Points for Bridged and Routed
Packets
You apply rewall lters at mulple processing points in the forwarding path. At each processing point,
the acon to be taken on a packet is determined by the conguraon of the lter and the results of the
lookup in the forwarding or roung table.
For both bridged (Layer 2) unicast packets and routed (Layer 3) unicast packets, rewall lters are
applied in the prescribed order shown below (assuming that each lter is present and a packet is
accepted by each one).
Bridged packets:
1. Ingress port lter
2. Ingress VLAN lter
3. Egress VLAN lter
4. Egress port lter
Routed packets:
1. Ingress port rewall lter
2. Ingress VLAN rewall lter (Layer 2 CoS)
3. Ingress router rewall lter (Layer 3 CoS)
4. Egress router rewall lter
5. Egress VLAN rewall lter
6. Egress port lter
NOTE: MAC learning occurs before lters are applied, so switches learn the MAC addresses of
packets that are dropped by ingress lters.
RELATED DOCUMENTATION
Overview of Firewall Filters (QFX Series) | 1720
Understanding How Firewall Filters Control Packet Flows | 781
Conguring Firewall Filters | 1829
1856
Understanding Filter-Based Forwarding
IN THIS SECTION
Benets of Filter-Based Forwarding | 1857
For IPv4 or IPv6 trac, you can use rewall lters in conjuncon with virtual roung instances to
specify dierent routes for packets to travel in their networks. This feature is called lter-based
forwarding (FBF), and is also known as policy-based roung (PBR).
You might want to use FBF to route specic types of trac through a rewall or other security device
before the trac connues on its path. You can also use FBF to give certain types of trac preferenal
treatment. For example, you might want to ensure that the highest-priority trac is forwarded over a
40-Gigabit Ethernet link.
To set up FBF, you specify a rewall lter match condion and acon and then specify the virtual
roung instance to send packets to.
NOTE: You can create as many as 128 lters or terms that direct packets to a given virtual
roung instance.
(QFX5100, QFX5110, QFX5200 switches) Starng in Junos OS Release 19.1R1, lter-based
forwarding is supported on IPv6 interfaces (ingress direcon only).
Benets of Filter-Based Forwarding
• Allows you to have more control over load balancing than dynamic roung protocols typically
provide.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
19.1R1 (QFX5100, QFX5110, QFX5200 switches) Starng in Junos OS Release 19.1R1, lter-based forwarding
is supported on IPv6 interfaces (ingress direcon only).
1857
RELATED DOCUMENTATION
Overview of Firewall Filters (QFX Series) | 1720
Firewall Filter Match Condions and Acons (EX4100, EX4100-F, EX4400, EX4600, EX4650,
QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, QFX5700) | 1735
Understanding Virtual Router Roung Instances
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a
Security Device
IN THIS SECTION
Requirements | 1858
Overview and Topology | 1858
Conguraon | 1859
Vericaon | 1862
This example describes how to set up lter-based forwarding on EX Series switches or a QFX10000.
You can congure lter-based forwarding by using a rewall lter to forward matched trac to a specic
virtual roung instance.
Requirements
This example applies to both EX Series switches running Junos OS Release 9.4 or later, and QFX10000
switches running Junos OS Release 15.1X53-D10 or later.
Overview and Topology
In this example, we create a rewall lter to match trac being sent from one applicaon server to
another according to the desnaon address (192.168.0.1) of packets egressing the source applicaon
server. Matching packets are routed to a virtual roung instance which forwards the trac to a security
device, which then forwards the trac on to the desnaon applicaon server.
NOTE: Filter-based forwarding does not work with IPv6 interfaces on some Juniper switches.
1858
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1859
Procedure | 1860
Results | 1861
To congure lter-based forwarding:
CLI Quick Conguraon
To use this example on your own device, copy the following commands into a text le, remove the line
breaks, and change the necessary details to t your conguraon. Then copy and paste the commands
into your CLI at the [edit] hierarchy level.
[edit]
set interfaces xe-0/0/0 unit 0 family inet address
10.1.0.1/24
set interfaces xe-0/0/3 unit 0 family inet address
10.1.3.1/24
set firewall family inet filter f1 term t1 from source-address
10.1.0.50/32
set firewall family inet filter f1 term t1 from protocol
tcp
set interfaces xe-0/0/0 unit 0 family inet filter input f1
set routing-instances vrf01 instance-type virtual-router
set routing-instances vrf01 interface xe-0/0/3.0
set routing-instances vrf01 routing-options static route 192.168.0.1/24
next-hop 10.1.3.254
set firewall family inet filter f1 term t1 then routing-instance
vrf01
1859
Procedure
Step-by-Step Procedure
To congure lter-based forwarding:
1. Congure an interface to connect to the applicaon server:
[edit interfaces]
user@switch# set xe-0/0/0 unit 0 family inet address 10.1.0.1/24
2. Congure an interface to connect to the security device:
[edit interfaces]
user@switch# set xe-0/0/3 unit 0 family inet address 10.1.3.1/24
3. Create a rewall lter that matches packets based on the address of the applicaon server that the
trac will be sent from. Also congure the lter so that it matches only TCP packets:
[edit firewall]
user@switch# set family inet filter f1 term t1 from source-address 10.1.0.50/32
user@switch# set firewall family inet filter f1 term t1 from protocol
tcp
4. Apply the lter to the interface that connects to the source applicaon server and congure it to
match incoming packets:
[edit interfaces]
user@switch# set xe-0/0/0 unit 0 family inet filter input f1
5. Create a virtual router:
[edit]
user@switch# set routing-instances vrf01 instance-type virtual-router
1860
6. Associate the virtual router with the interface that connects to the security device:
[edit routing-instances]
user@switch# set vrf01 interface xe-0/0/3.0
7. Congure the roung informaon for the virtual roung instance:
[edit routing-instances]
user@switch# set vrf01 routing-options static route 192.168.0.1/24 next-hop 10.1.3.254
8. Set the lter to forward packets to the virtual router:
[edit firewall]
user@switch# set family inet filter f1 term t1 then routing-instance
vrf01
Results
Check the results of the conguraon:
user@switch> show configuration
interfaces {
xe-0/0/0 {
unit 0 {
family inet {
filter {
input f1;
}
address 10.1.0.1/24;
}
}
}
xe-0/0/3 {
unit 0 {
family inet {
address 10.1.3.1/24;
}
}
}
1861
}
firewall {
family inet {
filter f1 {
term t1 {
from {
source-address {
10.1.0.50/32;
}
protocol tcp;
}
then {
routing-instance vrf01;
}
}
}
}
}
routing-instances {
vrf01 {
instance-type virtual-router;
interface xe-0/0/3.0;
routing-options {
static {
route 192.168.0.1/24 next-hop 10.1.3.254;
}
}
}
}
Vericaon
IN THIS SECTION
Verifying That Filter-Based Forwarding Was Congured | 1863
To conrm that the conguraon is working properly, perform these tasks:
1862
Verifying That Filter-Based Forwarding Was Congured
Purpose
Verify that lter-based forwarding was properly enabled on the switch.
Acon
1. Use the show interfaces filters command:
user@switch> show interfaces filters
xe-0/0/0.0
Interface Admin Link Proto Input Filter Output Filter
xe-0/0/0.0 up down inet fil
2.
Use the show route forwarding-table command:
user@switch> show route forwarding-table
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default user 1 0:12:f2:21:cf:0 ucst 331 4 me0.0
default perm 0 rjct 36 3
0.0.0.0/32 perm 0 dscd 34 1
10.1.0.0/24 ifdn 0 rslv 613 1 xe-0/0/0.0
10.1.0.0/32 iddn 0 10.1.0.0 recv 611 1 xe-0/0/0.0
10.1.0.1/32 user 0 rjct 36 3
10.1.0.1/32 intf 0 10.1.0.1 locl 612 2
10.1.0.1/32 iddn 0 10.1.0.1 locl 612 2
10.1.0.255/32 iddn 0 10.1.0.255 bcst 610 1 xe-0/0/0.0
10.1.1.0/26 ifdn 0 rslv 583 1 vlan.0
10.1.1.0/32 iddn 0 10.1.1.0 recv 581 1 vlan.0
10.1.1.1/32 user 0 rjct 36 3
10.1.1.1/32 intf 0 10.1.1.1 locl 582 2
10.1.1.1/32 iddn 0 10.1.1.1 locl 582 2
10.1.1.63/32 iddn 0 10.1.1.63 bcst 580 1 vlan.0
255.255.255.255/32 perm 0 bcst 32 1
Routing table: vrf01.inet
Internet:
1863
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 559 2
0.0.0.0/32 perm 0 dscd 545 1
10.1.3.0/24 ifdn 0 rslv 617 1 xe-0/0/3.0
10.1.3.0/32 iddn 0 10.1.3.0 recv 615 1 xe-0/0/3.0
10.1.3.1/32 user 0 rjct 559 2
192.168.0.1/24 user 0 10.1.3.254 ucst 616 2 xe-0/0/3.0
192.168.0.1/24 user 0 10.1.3.254 ucst 616 2 xe-0/0/3.0
10.1.3.255/32 iddn 0 10.1.3.255 bcst 614 1 xe-0/0/3.0
224.0.0.0/4 perm 0 mdsc 546 1
224.0.0.1/32 perm 0 224.0.0.1 mcst 529 1
255.255.255.255/32 perm 0 bcst 543 1
Routing table: default.iso
ISO:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 60 1
Routing table: vrf01.iso
ISO:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 600 1
Meaning
The output indicates that the lter was created on the interface and that the virtual roung instance is
forwarding matching trac to the correct IP address.
RELATED DOCUMENTATION
Conguring Firewall Filters | 1829
Understanding Filter-Based Forwarding | 1857
Understanding Virtual Router Roung Instances
1864
Conguring a Firewall Filter to De-Encapsulate GRE or IPIP Trac
IN THIS SECTION
Conguring a Filter to De-Encapsulate GRE Trac | 1865
Conguring a Filter to De-Encapsulate IPIP Trac | 1867
Applying the Filter to an Interface | 1868
Generic roung encapsulaon (GRE) and IP over IP (IPIP) both provide a private, secure path for
transporng packets through a network by encapsulang (or tunneling) the packets. The tunneling is
performed by tunnel endpoints that encapsulate or de-encapsulate trac.
You can use a rewall lter to de-encapsulate tunnel trac on the switch. This feature provides
signicant benets in terms of scalability, performance, and exibility because you don't need to create
a tunnel interface to perform the de-encapsulaon. For example, you can terminate many tunnels from
mulple source IP addresses with one rewall term.
NOTE: The EX4600, QFX5100 and OCX switches support as many as 512 GRE tunnels,
including tunnels created with a rewall lter. That is, you can create a total of 512 GRE tunnels,
regardless of which method you use.
Conguring a Filter to De-Encapsulate GRE Trac
To congure a rewall lter to de-encapsulate GRE trac:
1. Create an IPv4 rewall lter and (oponally) specify a source address for the tunnel:
[edit ]
user@switch# set firewall family (QFX) inet filter
filter-name
term-name
from source-address
address
You must create an IPv4 lter by using family inet because the outer header of a GRE packet must be
IPv4. If you specify a source address, it should be an address on a device that will encapsulate trac
into GRE packets.
1865
NOTE: To terminate many tunnels from mulple source IP addresses with one rewall term,
do not congure a source address. In this case, the lter will de-encapsulate any GRE packets
received by the interface that you apply the lter to.
2. Specify a desnaon address for the tunnel:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
from destination-
address
address
This should be an address on an interface of the switch on which you want the tunnel or tunnels to
terminate and the GRE packets to be de-encapsulated. You should also congure this address as a
tunnel endpoint on all the tunnel source routers that you want to form tunnels with on the switch.
3. Specify that the lter should match and accept GRE trac:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
from protocol gre
4. Specify that the lter should de-encapsulate GRE trac:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
then decapsulate gre
Based on the conguraon you have performed so far, the switch forwards the de-encapsulated
packets by comparing the inner header to the default roung table (inet0). If you want the switch to
use a virtual roung instance to forward the de-encapsulated packets, perform the following steps:
5. Specify the name of the virtual roung instance:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
then decapsulate
routing-instance
instance-name
6. Specify that the virtual roung instance is a virtual router:
[edit ]
user@switch# set routing-instances
instance-name
instance-type virtual-router
1866
7. Specify the interfaces that belong to the virtual router:
[edit ]
user@switch# set routing-instances
instance-name
interface
interface-name
Conguring a Filter to De-Encapsulate IPIP Trac
To congure a rewall lter to de-encapsulate IPIP trac::
1. Create an IPv4 rewall lter and (oponally) specify a source address for the tunnel:
[edit ]
user@switch# set firewall family (QFX) inet filter
filter-name
term-name
from source-address
address
You must create an IPv4 lter by using family inet because the outer header of an IPIP packet must
be IPv4. If you specify a source address, it should be an address on a device that will encapsulate
trac into IPIP packets.
NOTE: To terminate many tunnels from mulple source IP addresses with one rewall term,
do not congure a source address. In this case, the lter will de-encapsulate any IPIP packets
received by the interface that you apply the lter to.
2. Specify a desnaon address for the tunnel:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
from destination-
address
address
This should be an address on an interface of the switch on which you want the tunnel or tunnels to
terminate and the IPIP packets to be de-encapsulated. You should also congure this address as a
tunnel endpoint on all the tunnel source routers that you want to form tunnels with on the switch.
3. Specify that the lter should match and accept IPIP trac:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
from protocol ipip
1867
4. Specify that the lter should de-encapsulate IPIP trac:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
then decapsulate ipip
Based on the conguraon you have performed so far, the switch forwards the de-encapsulated
packets by comparing the inner header to the default roung table (inet0). If you want the switch to
use a virtual roung instance to forward the de-encapsulated packets, perform the following steps:
5. Specify the name of the virtual roung instance:
[edit ]
user@switch# set firewall family inet filter
filter-name
term
term-name
then decapsulate
routing-instance
instance-name
6. Specify that the virtual roung instance is a virtual router:
[edit ]
user@switch# set routing-instances
instance-name
instance-type virtual-router
7. Specify the interfaces that belong to the virtual router:
[edit ]
user@switch# set routing-instances
instance-name
interface
interface-name
Applying the Filter to an Interface
Aer you create the rewall lter, you must also apply it to an interface that will receive GRE or IPIP
trac. Be sure to apply it in the input direcon. For example, enter
[edit ]
user@switch# set interfaces
interface-name
unit
logical-unit-number
family inet filter input
filter-name
Because the outer header of a GRE or IPIP packet must be IPv4, you must apply the lter to an IPv4
interface and specify family inet.
RELATED DOCUMENTATION
Understanding Generic Roung Encapsulaon
1868
Conguring Generic Roung Encapsulaon Tunneling
Conguring Firewall Filters | 1829
Verifying That Firewall Filters Are Operaonal
IN THIS SECTION
Purpose | 1869
Acon | 1869
Meaning | 1870
Purpose
Aer you congure and apply rewall lters to ports, VLANs, or Layer 3 interfaces, you can perform the
following task to verify that the rewall lters congured on EX Series switches are working properly.
Acon
Use the operaonal mode command to verify that the rewall lters on the switch are working properly:
user@switch> show firewall
Filter: egress-vlan-watch-employee
Counters:
Name Bytes Packets
counter-employee-web 0 0
Filter: ingress-port-voip-class-limit-tcp-icmp
Counters:
Name Bytes Packets
icmp-counter 0 0
Policers:
Name Packets
icmp-connection-policer 0
tcp-connection-policer 0
Filter: ingress-vlan-rogue-block
Filter: ingress-vlan-limit-guest
1869
Meaning
The show firewall command displays the names of all rewall lters, policers, and counters that are
congured on the switch. For each counter that is specied in a lter conguraon, the output eld
shows the byte count and packet count for the term in which the counter is specied. For each policer
that is specied in a lter conguraon, the output eld shows the packet count for packets that exceed
the specied rate limits.
RELATED DOCUMENTATION
Conguring Firewall Filters (CLI Procedure) | 1642
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Monitoring Firewall Filter Trac | 1870
Monitoring Firewall Filter Trac
IN THIS SECTION
Monitoring Trac for All Firewall Filters and Policers That Are Congured on the Switch | 1870
Monitoring Trac for a Specic Firewall Filter | 1872
Monitoring Trac for a Specic Policer | 1872
You can monitor rewall lter trac on EX Series switches.
Monitoring Trac for All Firewall Filters and Policers That Are Congured on the
Switch
IN THIS SECTION
Purpose | 1871
Acon | 1871
1870
Meaning | 1871
Purpose
Perform the following task to monitor the number of packets and bytes that matched the rewall lters
and monitor the number of packets that exceeded policer rate limits:
Acon
Use the operaonal mode command:
user@switch> show firewall
Filter: egress-vlan-watch-employee
Counters:
Name Bytes Packets
counter-employee-web 3348 27
Filter: ingress-port-voip-class-limit-tcp-icmp
Counters:
Name Bytes Packets
icmp-counter 4100 49
Policers:
Name Packets
icmp-connection-policer 0
tcp-connection-policer 0
Filter: ingress-vlan-rogue-block
Filter: ingress-vlan-limit-guest
Meaning
The show firewall command displays the names of all rewall lters, policers, and counters that are
congured on the switch. The output elds show byte and packet counts for counters and packet count
for policers.
1871
Monitoring Trac for a Specic Firewall Filter
IN THIS SECTION
Purpose | 1872
Acon | 1872
Meaning | 1872
Purpose
Perform the following task to monitor the number of packets and bytes that matched a rewall lter and
monitor the number of packets that exceeded the policer rate limits.
Acon
Use the operaonal mode command:
user@switch> show firewall filter ingress-vlan-rogue-block
Filter: ingress-vlan-rogue-block
Counters:
Name Bytes Packets
rogue-counter 2308 20
Meaning
The show firewall filter
filter-name
command displays the name of the rewall lter, the packet and byte
count for all counters congured with the lter, and the packet count for all policers congured with the
lter.
Monitoring Trac for a Specic Policer
IN THIS SECTION
Purpose | 1873
Acon | 1873
1872
Meaning | 1873
Purpose
Perform the following task to monitor the number of packets that exceeded policer rate limits:
Acon
Use the operaonal mode command:
user@switch> show policer tcp-connection-policer
Filter: ingress-port-voip-class-limit-tcp-icmp
Policers:
Name Packets
tcp-connection-policer 0
Meaning
The show policer
policer-name
command displays the name of the rewall lter that species the policer-
acon and displays the number of packets that exceeded rate limits for the specied lter.
RELATED DOCUMENTATION
Conguring Firewall Filters (CLI Procedure) | 1642
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Verifying That Firewall Filters Are Operaonal | 1869
1873
Troubleshoong Firewall Filter Conguraon
IN THIS SECTION
Firewall Filter Conguraon Returns a No Space Available in TCAM Message | 1874
Filter Counts Previously Dropped Packet | 1877
Matching Packets Not Counted | 1878
Counter Reset When Eding Filter | 1879
Cannot Include loss-priority and policer Acons in Same Term | 1879
Cannot Egress Filter Certain Trac Originang on QFX Switch | 1880
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling | 1881
Egress Firewall Filters with Private VLANs | 1881
Egress Filtering of L2PT Trac Not Supported | 1882
Cannot Drop BGP Packets in Certain Circumstances | 1883
Invalid Stascs for Policer | 1884
Policers can Limit Egress Filters | 1884
Use the following informaon to troubleshoot your rewall lter conguraon.
Firewall Filter Conguraon Returns a No Space Available in TCAM Message
IN THIS SECTION
Problem | 1875
Soluon | 1875
1874
Problem
Descripon
When a rewall lter conguraon exceeds the amount of available Ternary Content Addressable
Memory (TCAM) space, the system returns the following syslogd message:
No space available in tcam.
Rules for filter
filter-name
will not be installed.
A switch returns this message during the commit operaon if the rewall lter that has been applied to
a port, VLAN, or Layer 3 interface exceeds the amount of space available in the TCAM table. The lter is
not applied, but the commit operaon for the rewall lter conguraon is completed in the CLI
module.
Soluon
When a rewall lter conguraon exceeds the amount of available TCAM table space, you must
congure a new rewall lter with fewer lter terms so that the space requirements for the lter do not
exceed the available space in the TCAM table.
You can perform either of the following procedures to correct the problem:
To delete the lter and its binding and apply the new smaller rewall lter to the same binding:
1. Delete the lter and its binding to ports, VLANs, or Layer 3 interfaces. For example:
[edit]
user@switch# delete firewall family ethernet-switching filter ingress-vlan-rogue-block
user@switch# delete vlans employee-vlan description "filter to block rogue devices on
employee-vlan"
user@switch# delete vlans employee-vlan filter input ingress-vlan-rogue-block
2. Commit the changes:
[edit]
user@switch# commit
1875
3. Congure a smaller lter with fewer terms that does not exceed the amount of available TCAM
space. For example:
[edit]
user@switch# set firewall family ethernet-switching filter new-ingress-vlan-rogue-block ...
4. Apply (bind) the new rewall lter to a port, VLAN , or Layer 3 interface. For example:
[edit]
user@switch# set vlans employee-vlan description "filter to block rogue devices on employee-
vlan"
user@switch# set vlans employee-vlan filter input new-ingress-vlan-rogue-block
5. Commit the changes:
[edit]
user@switch# commit
To apply a new rewall lter and overwrite the exisng binding but not delete the original lter:
1. Congure a rewall lter with fewer terms than the original lter:
[edit]
user@switch# set firewall family ethernet-switching filter new-ingress-vlan-rogue-block...
2. Apply the rewall lter to the port, VLAN, or Layer 3 interfaces to overwrite the binding of the
original lter—for example:
[edit]
user@switch# set vlans employee-vlan description "smaller filter to block rogue devices on
employee-vlan"
user@switch# set vlans employee-vlan filter input new-ingress-vlan-rogue-block
Because you can apply no more than one rewall lter per VLAN per direcon, the binding of the
original rewall lter to the VLAN is overwrien with the new rewall lter new-ingress-vlan-rogue-
block.
1876
3. Commit the changes:
[edit]
user@switch# commit
NOTE: The original lter is not deleted and is sll available in the conguraon.
Filter Counts Previously Dropped Packet
IN THIS SECTION
Problem | 1877
Soluon | 1878
Problem
Descripon
If you congure two or more lters in the same direcon for a physical interface and one of the lters
includes a counter, the counter will be incorrect if the following circumstances apply:
• You congure the lter that is applied to packets rst to discard certain packets. For example,
imagine that you have a VLAN lter that accepts packets sent to 10.10.1.0/24 addresses and
implicitly discards packets sent to any other addresses. You apply the lter to the admin VLAN in the
output direcon, and interface xe-0/0/1 is a member of that VLAN.
• You congure a subsequent lter to accept and count packets that are dropped by the rst lter. In
this example, you have a port lter that accepts and counts packets sent to 192.168.1.0/24
addresses that is also applied to xe-0/0/1 in the output direcon.
The egress VLAN lter is applied rst and correctly discards packets sent to 192.168.1.0/24 addresses.
The egress port lter is applied next and counts the discarded packets as matched packets. The packets
are not forwarded, but the counter displayed by the egress port lter is incorrect.
Remember that the order in which lters are applied depends on the direcon in which they are applied,
as indicated here:
Ingress lters:
1877
1. Port (Layer 2) lter
2. VLAN lter
3. Router (Layer 3) lter
Egress lters:
1. Router (Layer 3) lter
2. VLAN lter
3. Port (Layer 2) lter
Soluon
This is expected behavior.
Matching Packets Not Counted
IN THIS SECTION
Problem | 1878
Soluon | 1879
Problem
Descripon
If you congure two egress lters with counters for a physical interface and a packet matches both of
the lters, only one of the counters includes that packet.
For example:
• You congure an egress port lter with a counter for interface xe-0/0/1.
• You congure an egress VLAN lter with a counter for the adminVLAN, and interface xe-0/0/1 is a
member of that VLAN.
• A packet matches both lters.
In this case, the packet is counted by only one of the counters even though it matched both lters.
1878
Soluon
This is expected behavior.
Counter Reset When Eding Filter
IN THIS SECTION
Problem | 1879
Soluon | 1879
Problem
Descripon
If you edit a rewall lter term, the value of any counter associated with any term in the same lter is set
to 0, including the implicit counter for any policer referenced by the lter. Consider the following
examples:
• Assume that your lter has term1, term2, and term3, and each term has a counter that has already
counted matching packets. If you edit any of the terms in any way, the counters for all the terms are
reset to 0.
• Assume that your lter has term1 and term2. Also assume that term2 has a policer acon modier and
the implicit counter of the policer has already counted 1000 matching packets. If you edit term1 or
term2 in any way, the counter for the policer referenced by term2 is reset to 0.
Soluon
This is expected behavior.
Cannot Include loss-priority and policer Acons in Same Term
IN THIS SECTION
Problem | 1880
Soluon | 1880
1879
Problem
Descripon
You cannot include both of the following acons in the same rewall lter term in a QFX Series switch:
• loss-priority
• policer
If you do so, you see the following error message when you aempt to commit the conguraon:
“cannot support policer acon if loss-priority is congured.”
Soluon
This is expected behavior.
Cannot Egress Filter Certain Trac Originang on QFX Switch
IN THIS SECTION
Problem | 1880
Soluon | 1880
Problem
Descripon
On a QFX Series switch, you cannot lter certain trac with a rewall lter applied in the output
direcon if the trac originates on the QFX switch. This limitaon applies to control trac for protocols
such as ICMP (ping), STP, LACP, and so on.
Soluon
This is expected behavior.
1880
Firewall Filter Match Condion Not Working with Q-in-Q Tunneling
IN THIS SECTION
Problem | 1881
Soluon | 1881
Problem
Descripon
If you create a rewall lter that includes a match condion of dot1q-tag or dot1q-user-priority and apply
the lter on input to a trunk port that parcipates in a service VLAN, the match condion does not work
if the Q-in-Q EtherType is not 0x8100. (When Q-in-Q tunneling is enabled, trunk interfaces are assumed
to be part of the service provider or data center network and therefore parcipate in service VLANs.)
Soluon
This is expected behavior. To set the Q-in-Q EtherType to 0x8100, enter the set dot1q-tunneling
ethertype 0x8100 statement at the [edit ethernet-switching-options] hierarchy level. You must also
congure the other end of the link to use the same Ethertype.
Egress Firewall Filters with Private VLANs
IN THIS SECTION
Problem | 1881
Soluon | 1882
Problem
Descripon
If you apply a rewall lter in the output direcon to a primary VLAN, the lter also applies to the
secondary VLANs that are members of the primary VLAN when the trac egresses with the primary
VLAN tag or isolated VLAN tag, as listed below:
1881
• Trac forwarded from a secondary VLAN trunk port to a promiscuous port (trunk or access)
• Trac forwarded from a secondary VLAN trunk port that carries an isolated VLAN to a PVLAN trunk
port.
• Trac forwarded from a promiscuous port (trunk or access) to a secondary VLAN trunk port
• Trac forwarded from a PVLAN trunk port. to a secondary VLAN trunk port
• Trac forwarded from a community port to a promiscuous port (trunk or access)
If you apply a rewall lter in the output direcon to a primary VLAN, the lter does
not
apply to trac
that egresses with a community VLAN tag, as listed below:
• Trac forwarded from a community trunk port to a PVLAN trunk port
• Trac forwarded from a secondary VLAN trunk port that carries a community VLAN to a PVLAN
trunk port
• Trac forwarded from a promiscuous port (trunk or access) to a community trunk port
• Trac forwarded from a PVLAN trunk port. to a community trunk port
If you apply a rewall lter in the output direcon to a community VLAN, the following behaviors apply:
• The lter is applied to trac forwarded from a promiscuous port (trunk or access) to a community
trunk port (because the trac egresses with the community VLAN tag).
• The lter is applied to trac forwarded from a community port to a PVLAN trunk port (because the
trac egresses with the community VLAN tag).
• The lter is
not
applied to trac forwarded from a community port to a promiscuous port (because
the trac egresses with the primary VLAN tag or untagged).
Soluon
These are expected behaviors. They occur only if you apply a rewall lter to a private VLAN in the
output direcon and do not occur if you apply a rewall lter to a private VLAN in the input direcon.
Egress Filtering of L2PT Trac Not Supported
IN THIS SECTION
Problem | 1883
Soluon | 1883
1882
Problem
Descripon
Egress ltering of L2PT trac is not supported on the QFX3500 switch. That is, if you congure L2PT to
tunnel a protocol on an interface, you cannot also use a rewall lter to lter trac for that protocol on
that interface in the output direcon. If you commit a conguraon for this purpose, the rewall lter is
not applied to the L2PT-tunneled trac.
Soluon
This is expected behavior.
Cannot Drop BGP Packets in Certain Circumstances
IN THIS SECTION
Problem | 1883
Soluon | 1883
Problem
Descripon
BGP packets with a me-to-live (TTL) value greater than 1 cannot be discarded using a rewall lter
applied to a loopback interface or applied on input to a Layer 3 interface. BGP packets with TTL value of
1 or 0 can be discarded using a rewall lter applied to a loopback interface or applied on input to a
Layer 3 interface.
Soluon
This is expected behavior.
1883
Invalid Stascs for Policer
IN THIS SECTION
Problem | 1884
Soluon | 1884
Problem
Descripon
If you apply a single-rate two-color policer in more than 128 terms in a rewall lter, the output of the
show firewall command displays incorrect data for the policer.
Soluon
This is expected behavior.
Policers can Limit Egress Filters
IN THIS SECTION
Problem | 1884
Soluon | 1885
Problem
Descripon
On some switches, the number of egress policers you congure can aect the total number of allowed
egress rewall lters. Every policer has two implicit counters that take up two entries in a 1024-entry
TCAM. These are used for counters, including counters that are congured as acon modiers in rewall
lter terms. (Policers consume two entries because one is used for green packets and one is used for
nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any
more egress rewall lters that have terms with counters. For example, if you congure and commit 512
egress policers (two-color, three-color, or a combinaon of both policer types), all of the memory entries
1884
for counters get used up. If later in your conguraon le you insert addional egress rewall lters with
terms that also include counters,
none
of the terms in those lters are commied because there is no
available memory space for the counters.
Here are some addional examples:
• Assume that you congure egress lters that include a total of 512 policers and no counters. Later in
your conguraon le you include another egress lter with 10 terms, 1 of which has a counter
acon modier. None of the terms in this lter are commied because there is not enough TCAM
space for the counter.
• Assume that you congure egress lters that include a total of 500 policers, so 1000 TCAM entries
are occupied. Later in your conguraon le you include the following two egress lters:
• Filter A with 20 terms and 20 counters. All the terms in this lter are commied because there is
enough TCAM space for all the counters.
• Filter B comes aer Filter A and has ve terms and ve counters.
None
of the terms in this lter
are commied because there is not enough memory space for
all
the counters. (Five TCAM
entries are required but only four are available.)
Soluon
You can prevent this problem by ensuring that egress rewall lter terms with counter acons are placed
earlier in your conguraon le than terms that include policers. In this circumstance, Junos OS commits
policers even if there is not enough TCAM space for the implicit counters. For example, assume the
following:
• You have 1024 egress rewall lter terms with counter acons.
• Later in your conguraon le you have an egress lter with 10 terms. None of the terms have
counters but one has a policer acon modier.
You can successfully commit the lter with 10 terms even though there is not enough TCAM space for
the implicit counters of the policer. The policer is commied without the counters.
RELATED DOCUMENTATION
Understanding FIP Snooping, FBF, and MVR Filter Scalability
Conguring Firewall Filters
1885
CHAPTER 28
Conguring Firewall Filter Accounng and Logging
(EX9200 Switches)
IN THIS CHAPTER
Example: Conguring Logging for a Stateless Firewall Filter Term | 1886
Use the CLI Editor in Conguraon Mode | 1892
Example: Conguring Logging for a Stateless Firewall Filter Term
IN THIS SECTION
Requirements | 1886
Overview | 1886
Conguraon | 1887
Vericaon | 1891
This example shows how to congure a standard stateless rewall lter to log packet headers.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
In this example, you use a stateless rewall lter that logs and counts ICMP packets that have
192.168.207.222 as either their source or desnaon.
1886
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1887
Congure the Syslog Messages File for the Firewall Facility | 1887
Congure the Stateless Firewall Filter | 1888
Apply the Stateless Firewall Filter to a Logical Interface | 1889
Conrm and Commit Your Candidate Conguraon | 1889
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set system syslog file ICMP_filter firewall info
set system syslog file ICMP_filter archive no-world-readable
set firewall family inet filter icmp_syslog term icmp_match from address 192.168.207.222/32
set firewall family inet filter icmp_syslog term icmp_match from protocol icmp
set firewall family inet filter icmp_syslog term icmp_match then count packets
set firewall family inet filter icmp_syslog term icmp_match then syslog
set firewall family inet filter icmp_syslog term icmp_match then accept
set firewall family inet filter icmp_syslog term default_term then accept
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
set interfaces ge-0/0/1 unit 0 family inet filter input icmp_syslog
Congure the Syslog Messages File for the Firewall Facility
Step-by-Step Procedure
To congure a syslog messages le for the rewall facility:
1887
1. Congure a messages le for all syslog messages generated for the rewall facility.
user@host# set system syslog file ICMP_filter firewall info
2. Restrict permission to the archived rewall facility syslog les to the root user and users who have
the Junos OS maintenance permission.
user@host# set system syslog file ICMP_filter archive no-world-readable
Congure the Stateless Firewall Filter
Step-by-Step Procedure
To congure the stateless rewall lter icmp_syslog that logs and counts ICMP packets that have
192.168.207.222 as either their source or desnaon:
1. Create the stateless rewall lter icmp_syslog.
[edit]
user@host# edit firewall family inet filter icmp_syslog
2. Congure matching on the ICMP protocol and an address.
[edit firewall family inet filter icmp_syslog]
user@host# set term icmp_match from address 192.168.207.222/32
user@host# set term icmp_match from protocol icmp
3. Count, log,, and accept matching packets.
[edit firewall family inet filter icmp_syslog]
user@host# set term icmp_match then count packets
user@host# set term icmp_match then syslog
user@host# set term icmp_match then accept
1888
4. Accept all other packets.
[edit firewall family inet filter icmp_syslog]
user@host# set term default_term then accept
Apply the Stateless Firewall Filter to a Logical Interface
Step-by-Step Procedure
To apply the stateless rewall lter to a logical interface:
1. Congure the logical interface to which you will apply the stateless rewall lter.
[edit]
user@host# edit interfaces ge-0/0/1 unit 0 family inet
2. Congure the interface address for the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set address 10.1.2.3/30
3. Apply the stateless rewall lter to the logical interface.
[edit interfaces ge-0/0/1 unit 0 family inet]
user@host# set filter input icmp_syslog
Conrm and Commit Your Candidate Conguraon
Step-by-Step Procedure
To conrm and then commit your candidate conguraon:
1. Conrm the conguraon of the syslog message le for the rewall facility by entering the show system
conguraon mode command. If the command output does not display the intended conguraon,
repeat the instrucons in this example to correct the conguraon.
[edit]
user@host# show system
1889
syslog {
file ICMP_filter {
firewall info;
archive no-world-readable;
}
}
2. Conrm the conguraon of the stateless rewall lter by entering the show firewall conguraon
mode command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter icmp_syslog {
term icmp_match {
from {
address {
192.168.207.222/32;
}
protocol icmp;
}
then {
count packets;
log;
accept;
}
}
term default_term {
then accept;
}
}
}
3.
Conrm the conguraon of the interface by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
[edit]
user@host# show interfaces
ge-0/0/1 {
1890
unit 0 {
family inet {
filter {
input icmp_syslog;
}
address 10.1.2.3/30;
}
}
}
4. If you are done conguring the device, commit your candidate conguraon.
[edit]
user@host# commit
Vericaon
To conrm that the conguraon is working properly, enter the show log filter command:
user@host> show log ICMP_filter
Mar 20 08:03:11 hostname feb FW: ge-0/1/0.0 A icmp 192.168.207.222
192.168.207.223 0 0 (1 packets)
This output le contains the following elds:
• Date and Time—Date and me at which the packet was received (not shown in the default).
• Filter acon:
• A—Accept (or next term)
• D—Discard
• R—Reject
• Protocol—Packet’s protocol name or number.
• Source address—Source IP address in the packet.
• Desnaon address—Desnaon IP address in the packet.
1891
NOTE: If the protocol is ICMP, the ICMP type and code are displayed. For all other protocols,
the source and desnaon ports are displayed.
The last two elds (both zero) are the source and desnaon TCP/UDP ports, respecvely, and are
shown for TCP or UDP packets only. This log message indicates that only one packet for this match has
been detected in about a one second interval. If packets arrive faster, the system log funcon
compresses the informaon so that less output is generated, and displays an output similar to the
following:
user@host> show log
filename
Mar 20 08:18:45 hostname feb FW: ge-0/1/0.0 A icmp 192.168.207.222
192.168.207.223 0 0 (515 packets)
RELATED DOCUMENTATION
System Logging Overview | 1282
Firewall Filter Logging Acons | 1286
System Log Explorer
System Log Explorer
Use the CLI Editor in Conguraon Mode
This topic describes basic commands that you can use to enter conguraon mode in the CLI editor. The
topic also describes commands that you use to navigate the conguraon hierarchy, get help, and
commit or revert the changes that you make during the conguraon session.
Task Command/
Statement
Example
Edit Your Conguraon
1892
(Connued)
Task Command/
Statement
Example
Enter conguraon mode.
When you start the CLI, the device is
in operaonal mode. You must
explicitly enter conguraon mode.
When you do, the CLI prompt changes
from user@host> to user@host#, and the
hierarchy level appears in square
brackets.
configure
user@host> configure
[edit]
user@host#
Create a statement hierarchy.
You can use the edit command to
simultaneously create a hierarchy and
move to that new level in the
hierarchy. You cannot use the edit
command to change the value of
ideners.
edit
hierarchy-
level value
[edit]
user@host# edit security zones security-zone myzone
[edit security zones security-zone myzone]
user@host#
Create a statement hierarchy, and set
idener values.
The set command is like edit, except
that your current level in the hierarchy
does not change.
set
hierarchy-
level value
[edit]
user@host# set security zones security-zone myzone
[edit]
user@host#
Navigate the Hierarchy
Navigate down to an exisng
hierarchy level.
edit
hierarchy-
level
[edit]
user@host# edit security zones
[edit security zones]
user@host#
1893
(Connued)
Task Command/
Statement
Example
Navigate up one level in the hierarchy.
up [edit security zones]
user@host# up
[edit security]
user@host#
Navigate to the top of the hierarchy.
top [edit security zones]
user@host# top
[edit]
user@host#
Commit or Revert Changes
Commit your conguraon.
commit [edit]
user@host# commit
commit complete
1894
(Connued)
Task Command/
Statement
Example
Roll changes back from the current
session.
Use the rollback command to revert all
changes from the current
conguraon session. When you run
the rollback command before you exit
your session or commit changes, the
soware loads the most recently
commied conguraon onto the
device. You must enter the rollback
statement at the edit level in the
hierarchy.
rollback [edit]
user@host# rollback
load complete
Exit Conguraon Mode
Commit the conguraon, and exit
conguraon mode.
commit and-quit [edit]
user@host# commit and-quit
user@host>
Exit conguraon mode without
comming your conguraon.
You must navigate to the top of the
hierarchy using the up or top
commands before you can exit
conguraon mode.
exit [edit]
user@host# exit
The configuration has been changed but not
committed
Exit with uncommitted changes? [yes,no] (yes)
Get Help
1895
(Connued)
Task Command/
Statement
Example
Display a list of valid opons for the
current hierarchy level.
? [edit ]
user@host# edit security zones ?
Possible completions:
<[Enter]> Execute this command
> functional-zone Functional zone
> security-zone Security zones
| Pipe through a
command
[edit]
RELATED DOCUMENTATION
Understanding Junos OS CLI Conguraon Mode
1896
3
PART
Conguring Trac Policers
Understanding Trac Policers | 1898
Conguring Policer Rate Limits and Acons | 1970
Conguring Layer 2 Policers | 1980
Conguring Two-Color and Three-Color Trac Policers at Layer 3 | 2038
Conguring Logical and Physical Interface Trac Policers at Layer 3 | 2170
Conguring Policers on Switches | 2201
CHAPTER 29
Understanding Trac Policers
IN THIS CHAPTER
Policer Implementaon Overview | 1899
ARP Policer Overview | 1903
Example: Conguring ARP Policer | 1905
Understanding the Benets of Policers and Token Bucket Algorithms | 1910
Determining Proper Burst Size for Trac Policers | 1912
Controlling Network Access Using Trac Policing Overview | 1920
Trac Policer Types | 1926
Order of Policer and Firewall Filter Operaons | 1930
Understanding the Frame Length for Policing Packets | 1930
Supported Standards for Policing | 1931
Hierarchical Policer Conguraon Overview | 1932
Understanding Enhanced Hierarchical Policers | 1934
Packets-Per-Second (pps)-Based Policer Overview | 1938
Guidelines for Applying Trac Policers | 1938
Policer Support for Aggregated Ethernet Interfaces Overview | 1939
Example: Conguring a Physical Interface Policer for Aggregate Trac at a Physical Interface | 1941
Firewall and Policing Dierences Between PTX Series Packet Transport Routers and T Series Matrix
Routers | 1950
Hierarchical Policers on ACX Series Routers Overview | 1953
Guidelines for Conguring Hierarchical Policers on ACX Series Routers | 1955
Hierarchical Policer Modes on ACX Series Routers | 1957
Processing of Hierarchical Policers on ACX Series Routers | 1962
Acons Performed for Hierarchical Policers on ACX Series Routers | 1963
Conguring Aggregate Parent and Child Policers on ACX Series Routers | 1966
1898
Policer Implementaon Overview
The Juniper Networks® Junos® operang system (Junos OS) supports three types of policers:
•
Single-rate two-color policer
— The most common policer. Single-rate means that there is only a
single bandwidth and burst rate referenced in the policer. The two colors associated with this policer
are red (nonconforming) and green (conforming).
•
Single-rate three-color policer
— Similar to the single-rate two-color policer with the addion of the
color yellow. This type also introduces the
commied informaon rate
(CIR) and a
commied burst
rate
(CBR).
•
Two-rate three-color policer
— Builds o of the single-rate three-color policer by adding a second
rate er.
Two-rate
means there is an upper bandwidth limit and associated burst size as well as a
peak informaon rate
(PIR) and a
peak burst rate
(PBS).
There are two types of token bucket algorithms that can be used, depending on the type of policer that
is applied to network trac. Single-rate two-color policers use the
single token bucket algorithm
to
measure trac ow conformance to a two-color policer rate limit. Single-rate three-color policers and
two-rate three-color policers both use the
dual token bucket algorithm
to measure trac ow
conformance to a three-color policer rate. The main dierence between these two token bucket
algorithms is that the single token bucket algorithm allows bursts of trac for short periods, whereas
the dual token bucket algorithm allows more sustained bursts of trac. (The remainder of this topic
discusses the single token bucket algorithm.)
To congure a policer, you need to set two parameters:
• Bandwidth limit congured in bps (using the bandwidth-limit statement)
• Burst size congured in bytes (using the burst-size-limit statement)
NOTE: For single-rate two-color policers only, you can also specify the bandwidth limit as a
percentage of either the physical interface port speed or the congured
logical interface
shaping
rate by using the bandwidth-percent
percentage
statement. You cannot congure a policer to
use bandwidth percentage for aggregate, tunnel, or soware interfaces.
Use the following command to set the policer condions:
user@router# set firewall policer <policer name> if-exceeding ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
1899
bandwidth-limit Bandwidth limit (8000..100000000000 bits per second)
bandwidth-percent Bandwidth limit in percentage (1..100 percent)
burst-size-limit Burst size limit (1500..100000000000 bytes)
| Pipe through a command
The bandwidth limit parameter is used to determine the average rate limit applied to the trac, while
the burst-size parameter is used to allow for short periods of trac bursng (back-to-back trac at
average rates that exceed the congured bandwidth limit). Once you apply a set of policer conguraon
sengs (bandwidth limit and burst size), the congured values are adjusted to hardware programmable
values. The conversion adjustment introduced is normally less than 1 percent of the congured
bandwidth limit. This adjustment is needed because the soware allows you to congure the bandwidth
limit and burst size to any value within the specied ranges, but those values must be adjusted to the
nearest value that can be programmed in the hardware.
The policer bandwidth limit conguraon in the hardware is represented by two values: the
credit
update frequency
and the
credit size
. The credit update frequency is used by the hardware to determine
how frequently tokens (bits of unused bandwidth) are added to the token bucket. The credit size is
based on the number of tokens that can t in the token bucket. The MX Series, M120, M320 routers,
and EX Series switches contain a set of credit update frequencies instead of having a single credit
update frequency to minimize the adjustment dierence from the congured bandwidth limit and to
support a wide range of policer bandwidth rates (from 40 Kbps to 40 Gbps). One of the frequencies is
used to program the policer (bandwidth limit and burst size) in the hardware.
The burst size is based on the overall trac load and allows bursts of trac to exceed the congured
bandwidth limit. A policer with a large burst size eecvely disables the congured bandwidth limit
funcon, so the burst size must be relave to the congured bandwidth limit. You need to consider the
trac paerns in your network before determining the burst size. For more informaon about
determining burst size, see "Determining Proper Burst Size for Trac Policers" on page 1912.
The congured burst size is adjusted in the hardware to a value that is based on the congured
bandwidth limit. The burst size extends the congured bandwidth limit for bursty trac that exceeds
the congured bandwidth limit.
When a policer is applied to the trac at an interface, the inial capacity for trac bursng is equal to
the number of bytes specied in the burst-size-limit statement.
Figure 76 on page 1901 represents how a policer is implemented using the token bucket algorithm. The
token allocator allocates tokens to the policer based on the congured bandwidth limit, which is the
token size mulplied by the token arrival rate.
token size x token arrival rate = policer rate (congured bandwidth limit)
1900
Figure 76: Token Bucket Algorithm
When a packet arrives at an interface congured with a policer, tokens that represent the number of bits
that correspond to the length of the packet are used (or “cashed in”) from the token bucket. If the token
arrival rate is higher than the rate of trac so that there are tokens not being used, the token bucket is
lled to capacity, and arriving tokens “overow” the bucket and are lost. The token bucket depth
represents the single user-congured burst size for the policer.
If there are tokens in the token bucket and the incoming trac rate is higher than the token rate (the
congured policer rate, bandwidth limit), the trac can use the tokens unl the bucket is empty. The
token consumpon rate can be as high as the incoming trac rate, which creates the burst of trac
shown in Figure 77 on page 1902.
By using the token bucket algorithm, the average bandwidth rate being allowed is close to the
congured bandwidth limit while simultaneously supporng bursty trac, as shown in Figure 77 on
page 1902.
1901
Figure 77: Trac Behavior Using Policer and Burst Size
NOTE: The measured length of a packet changes according to the family type that the policer
applies to. If the policer is applied under the family inet hierarchy, the policer considers only the
IPv4 packet length. If the policer is applied under the family vpls hierarchy, the enre Ethernet
frame (including the Ethernet MAC header) is included in the packet length.
The major factor that aects the policer shaping result is not the conversion adjustment, but the trac
paern since most network trac is not consistent and is not sent at a constant rate. Due to the
uctuaon of the incoming trac rate, some of the allocated tokens are not used. As a result, the
shaped trac rate is lower than you might expect, and the TCP connecon behavior discussed in
"Understanding the Benets of Policers and Token Bucket Algorithms" on page 1910 is a typical example
of this. To alleviate this eect of the lower shaped trac rate, a proper burst size conguraon is
required.
RELATED DOCUMENTATION
Understanding the Benets of Policers and Token Bucket Algorithms | 1910
Determining Proper Burst Size for Trac Policers | 1912
1902
ARP Policer Overview
IN THIS SECTION
Benets of the ARP Policer | 1904
Sending IP packets on a mul access network requires mapping from an IP address to a media access
control (MAC) address (the physical or hardware address).
In an Ethernet environment, Address Resoluon Protocol (ARP) is used to map a MAC address to an IP
address. ARP dynamically binds the IP address (the logical address) to the correct MAC address. Before
sending unicast IP packets, ARP discovers the MAC address used for the Ethernet interface where the IP
address is congured.
Hosts that use ARP maintain a cache of discovered Internet-to-Ethernet address mappings to minimize
the number of ARP broadcast messages. To keep the cache from growing too large, an entry is removed
if it is not used within a certain period of me. Before sending a packet, the host searches its cache for
Internet-to-Ethernet address mapping. If you cannot nd the mapping, the host sends an ARP request.
Starng in Junos OS Release 18.4R1, you can apply policers on ARP trac on SRX Series Firewalls.
Support for ARP policers on pseudowire interfaces on MX Series routers is available in Junos OS Release
20.2R1. The conguraon principles are the same.
You can congure rate liming for the policer by specifying the bandwidth and the burst-size limit.
Packets exceeding the policer limits are discarded. The trac to the Roung Engine is controlled by
applying the policer on ARP trac. Using policers helps prevent network congeson caused by
broadcast storms. You can use policers to specify rate limits on trac. A rewall lter congured with a
policer permits only trac within a specied set of rate limits, thereby providing protecon from denial-
of-service (DoS) aacks. Trac that exceeds the rate limits specied by the policer is either discarded
immediately or is marked as lower priority than trac that is within the rate limits. The switch discards
the lower-priority trac when there is trac congeson.
A policer applies two types of rate limits on trac:
• Bandwidth—The number of bits per second permied, on average
• Maximum burst size—The maximum size permied for bursts of data that exceed the given
bandwidth limit
Policing uses an algorithm to enforce a limit on average bandwidth while allowing bursts up to a
specied maximum value. You can dene specic classes of trac on an interface and apply a set of rate
1903
limits to each class. Aer you name and congure a policer, it is stored as a template. You can then use
the policer in a rewall lter conguraon.
NOTE: On SRX5400, SRX5600, and SRX5800 devices, ARP policer acons are applied on the
SPUs as well as on the Roung Engine. For example, SPU A handles 15000 packets of ARP
trac, and SPU B handles 5000 packets. A policer is congured as rate-limit 10K, discard and
applied to the ARP protocol. As a result, SPU A discards 5000 packets of ARP trac and
forwards 10000 packets to the Roung Engine, and SPU B forwards 5000 packets of ARP the
Roung Engine. The Roung Engine therefore receives a total of 15000 packets of ARP trac.
Benets of the ARP Policer
• Prevents network congeson caused by broadcast storms
• Protects Roung Engines on SRX Series Firewalls that are impacted by broadcast storms
• Provides protecon from denial-of-service (DoS) aacks
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
20.2R1 Support for ARP policers on pseudowire interfaces on MX Series routers is available in Junos OS Release
20.2R1.
18.4R1 Starng in Junos OS Release 18.4R1, you can apply policers on ARP trac on SRX Series Firewalls.
RELATED DOCUMENTATION
bandwidth-limit (Hierarchical Policer)
burst-size-limit (Hierarchical Policer)
Example: Conguring ARP Policer | 1905
1904
Example: Conguring ARP Policer
IN THIS SECTION
Requirements | 1905
Overview | 1905
Conguraon | 1906
Vericaon | 1908
This example shows how to congure an Address Resoluon Protocol (ARP) policer on SRX Series
Firewalls.
Support for ARP policers on pseudowire interfaces on MX Series routers is available in Junos OS Release
20.2R1. The conguraon principles are the same as shown here.
Requirements
This example uses the following hardware and soware components:
• SRX Series Firewall.
• Junos OS Release 18.4R1 or later.
Before you begin, see "ARP Policer Overview" on page 1903.
Overview
ARP is used to map a MAC address to an IP address. ARP dynamically binds the IP address (the logical
address) to the correct MAC address. Before IP unicast packets can be sent, ARP discovers the MAC
address used by the Ethernet interface where the IP address is congured. This feature is supported on
all SRX Series Firewalls. The trac to the Roung Engine on the SRX Series Firewall is controlled by
applying the policer on ARP. This prevents network congeson caused by broadcast storms.
NOTE: A default ARP policer named
__default_arp_policer__
is used and shared by all Ethernet
interfaces with family inet congured, by default.
On MX Series routers, you can create policers for ARP trac on pseudowire interfaces. (You congure
rate liming for the policer by specifying the bandwidth and the burst-size limit of a rewall policer and
aaching the policy to a pseudowire interface, just like you would any other interface, and apply the
1905
ARP policer to a pseudowire interface at the [edit interfaces interface-name unit unit-number family inet
policer arp policy-name] level of the hierarchy. Trac that exceeds the specied rate limits can be dropped
or marked as low priority and delivered when congeson permits.
Conguraon
IN THIS SECTION
Conguring ARP Policer on Interface | 1906
This example shows how to
congure rate liming for the policer by specifying the bandwidth and the
burst-size limit.
Conguring ARP Policer on Interface
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from conguraon mode.
set firewall policer arp_limit if-exceeding bandwidth-limit 1m
set firewall policer arp_limit if-exceeding burst-size-limit 1m
set firewall policer arp_limit then discard
set interfaces ge-0/0/7 unit 0 family inet policer arp arp_limit
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
instrucons on how to do that, see "Use the CLI Editor in Conguraon Mode" on page 1892 in the CLI
User Guide.
To congure the ARP policer:
1906
1. Specify the name of the policer.
[edit firewall]
user@host# set policer arp-limit
2. Congure rate liming for the policer.
• Specify the bandwidth limit in bits per second (bps) to control the trac rate on an interface:
[edit firewall policer arp_limit]
user@host# set if-exceeding bandwidth-limit 1m
The range for the bandwidth limit is 1 through 150,000 bps.
• Specify the burst-size limit (the maximum allowed burst size in bytes) to control the amount of
trac bursng:
[edit firewall policer arp_limit]
user@host# set if-exceeding burst-size-limit 1m
To determine the value for the burst-size limit, mulply the bandwidth of the interface on which
the lter is applied by the amount of me to allow a burst of trac at that bandwidth to occur:
burst size = (bandwidth) * (allowable me for burst trac)
The range for the burst-size limit is 1 through 150,00 bytes.
3. Specify the policer acon discard to discard packets that exceed the rate limits.
[edit firewall]
user@host# set policer arp_limit then discard
Discard is the only supported policer acon.
4. Congure the interfaces.
user@host# set interfaces ge-0/0/7 unit 0 family inet policer arp arp_limit
1907
Results
From conguraon mode, conrm your conguraon by entering the show firewall command. If the
output does not display the intended conguraon, repeat the instrucons in this example to correct.
[edit]
user@host# show firewall
policer arp_limit {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 1m;
}
then discard;
}
[edit]
user@host# show interfaces
ge-0/0/7 {
unit 0 {
family inet {
policer {
arp arp_limit;
}
}
}
}
Aer you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Verifying the results of arp policer | 1909
To conrm that the conguraon is working properly, perform these tasks:
1908
Verifying the results of arp policer
Purpose
Verify the results of the Arp policer.
Acon
From the top of the conguraon in operaonal mode, enter the show policer
policer-name
command.
user@host> show policer
arp_limit-ge-0/0/7.0-inet-arp
Policers:
Name Bytes Packets
arp_limit-ge-0/0/7.0-inet-arp 0 0
Meaning
The show policer
policer-name
command displays the names of all rewall lters and policers that are
congured on the device.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
20.2R1 Support for MX Series routers is available in Junos OS Release 20.2R1, and the conguraon principles
are the same as shown here.
RELATED DOCUMENTATION
ARP Policer Overview | 1903
1909
Understanding the Benets of Policers and Token Bucket Algorithms
IN THIS SECTION
Scenario 1: Single TCP Connecon | 1910
Scenario 2: Mulple TCP Connecons | 1911
This topic describes some scenarios that demonstrate how dicult it is to control trac that comes into
your network without the help of policers and the token bucket algorithm. These scenarios assume that
trac is coming from a TCP-based connecon. Depending on the number of TCP connecons, policers
can have dierent aects on rate limits.
This topic presents the following scenarios:
• "Scenario 1: Single TCP Connecon" on page 1910
• "Scenario 2: Mulple TCP Connecons" on page 1911
Scenario 1: Single TCP Connecon
Figure 78 on page 1911 shows the trac loading on an interface with a policer congured. When the
trac rate reaches the congured bandwidth limit (which results in a packet drop), a TCP slow-start
mechanism reduces the trac rate down to half of what it was. When the trac rate rises again, the
same cycle repeats.
1910
Figure 78: Policer Behavior with a Single TCP Connecon
The problem presented in this scenario is that some bandwidth is available, but it is not being used by
the trac. The unused bandwidth shown in Figure 78 on page 1911 is the result of an overall data
throughput that is lower than the congured bandwidth value. This example is an extreme case because
there is only a single TCP connecon.
Scenario 2: Mulple TCP Connecons
With mulple TCP connecons or some background non-TCP-based trac, there is less unused
bandwidth, as depicted in Figure 79 on page 1912. However, the same issue of unused bandwidth sll
exists if all the TCP connecons experience a drop when the aggregated trac rate exceeds the
congured bandwidth limit.
1911
Figure 79: Policer Behavior with Background Trac (Mulple TCP Connecons)
To reduce the problem of unused bandwidth in your network, you can congure a burst size.
RELATED DOCUMENTATION
Policer Implementaon Overview | 1899
Determining Proper Burst Size for Trac Policers | 1912
Determining Proper Burst Size for Trac Policers
IN THIS SECTION
Policer Burst Size Limit Overview | 1913
Eect of Burst-Size Limit | 1913
Two Methods for Calculang Burst-Size Limit | 1915
Comparison of the Two Methods | 1916
1912
Policer Burst Size Limit Overview
A policer burst-size limit controls the number of bytes of trac that can pass unrestricted through a
policed interface when a burst of trac pushes the average transmit or receive rate above the
congured bandwidth limit. The actual number of bytes of bursty trac allowed to pass through a
policed interface can vary from zero to the congured burst-size limit, depending on the overall trac
load.
By conguring a proper burst size, the eect of a lower shaped rate is alleviated. Use the burst-size-limit
statement to congure the burst size.
NOTE: If you set the burst-size limit too low, too many packets will be subjected to rate liming.
If you set the burst-size limit too high, too few packets will be rate-limited.
Consider these two main factors when determining the burst size to use:
• The allowed duraon of a blast of trac on the line.
• The burst size is large enough to handle the maximum transmission unit (MTU) size of the packets.
The following general guidelines apply to choosing a policer burst-size limit:
• A burst-size limit should not be set lower than 10 mes the MTU of the trac on the interface to be
policed.
• The amount of me to allow a burst of trac at the full line rate of a policed interface should not be
lower than 5 ms.
• The minimum and maximum values you can specify for a policer burst-size limit depends on the
policer type (two-color or three-color).
BEST PRACTICE: The preferred method for choosing a burst-size limit is based on the line
rate of the interface on which you apply the policer and the amount of me you want to
allow a burst of trac at the full line rate.
Eect of Burst-Size Limit
Bursty trac requires a relavely large burst size so that extra tokens can be allocated into the token
bucket for upcoming trac to use.
1913
Bursty Trac Policed Without a Burst-Size Limit
Figure 80 on page 1914 shows an extreme case of bursty trac where the opportunity to allocate
tokens is missed, and the bandwidth goes unused because a large burst size is not congured.
Figure 80: Bursty Trac Without Congured Burst Size (Excessive Unused Bandwidth)
Burst-Size Limit Congured to Match Bandwidth Limit and Flow Bursness
Figure 81 on page 1915 depicts how bandwidth usage changes when a large burst size is congured to
handle bursty trac. The large burst size minimizes the amount of unused bandwidth because tokens
are being allocated in between the bursts of trac that can be used during trac peaks. The burst size
determines the depth of the token bucket.
1914
Figure 81: Bursty Trac with Congured Burst Size (Less Unused Bandwidth)
Burst-Size Limit That Depletes All Accumulated Tokens
Conguring a large burst size for the unused tokens creates another issue. If the burst size is set to a
very large value, the burst of trac can be transmied from the interface at line rate unl all the
accumulated tokens in the token bucket are used up. This means that conguring a large burst size can
allow too many packets to avoid rate liming, which can lead to a trac rate that exceeds the
bandwidth limit for an extended period of me.
If the average rate is considered within 1 second, the rate is sll below the congured bandwidth limit.
However, the downstream device might not be able to handle bursty trac, so some packets might be
dropped.
Two Methods for Calculang Burst-Size Limit
For policers congured on MX Series, M120, and M320 routers, and EX Series switches, congurable
burst-size limit values range from 1 ms through 600 ms of trac at the policer rate (the congured
bandwidth limit).
Because one burst size is not suitable for every trac paern, select the best burst size for an interface
by performing experimental conguraons. For your rst test conguraon, select the burst-size limit by
using one of the calculaon methods described in the next two secons.
Calculaon Based on Interface Bandwidth and Allowable Burst Time
If the bandwidth of the policed interface is known, the preferred method for calculang the policer
burst-size limit is based on the following values:
1915
• bandwidth—Line rate of the policed interface (in bps units)
• burst-period—Allowable trac-burst me (5 ms or longer)
To calculate policer bandwidth in bytes:
bandwidth X burst-period / 8
Calculaon Based on Interface Trac MTU
If the bandwidth of the policed interface is unknown, calculate the policer burst-size limit based on the
following value:
• interface MTU—Maximum transmission unit (in bytes) for the policed interface.
To calculate policer bandwidth in bytes:
interface MTU Χ 10
Comparison of the Two Methods
Figure 82 on page 1917 illustrates the relaonship between the policer rate (the congured bandwidth
limit) and the eecve burst-size limit for the two methods of calculang the best policer burst-size
limit. For the method based on interface bandwidth and allowable burst me, the correlaon is labeled
5 ms. For the method based on MTU size, the correlaon is labeled 10 MTU.
1916
Figure 82: Comparing Burst Size Calculaon Methods
For a policer burst-size limit calculated using the 5 ms method, the eecve burst-size limit is
proporonal to the congured bandwidth limit. With a very low bandwidth limit, the eecve burst-size
limit might be so small that the policer rate-limits trac more aggressively than desired. For example, a
trac “burst” consisng of two MTU-sized packets might be rate-limited. In this scenario, a policer
burst-size limit calculated using the 10 MTU method appears to be a beer choice.
10 x MTU Method for Selecng Inial Burst Size for Gigabit Ethernet with 100 Kbps
Bandwidth
The following sequence illustrates the use of the 10 x MTU method for selecng an inial burst size for
test conguraons for a Gigabit Ethernet interface congured with a 100 Kbps bandwidth limit:
1. If you congure a 100 ms burst-size limit, the maximum amount of trac allowed to pass through the
interface unrestricted is 1250 bytes, calculated as follows:
100,000 bps x 0.1 s
100 Kbps x 100 ms = ————————————————————— = 1250 bytes
8 bits per byte
2. In theory, a 10 x MTU burst size would allow up to 15,000 bytes to pass unrestricted. However, the
maximum congurable burst-size limit for MX Series, M120, and M320 routers is 600 ms of the
bandwidth limit. If you congure the maximum burst-size limit of 600 ms of the bandwidth limit, the
1917
maximum amount of trac allowed to pass through the interface unrestricted is 7500 bytes,
calculated as follows:
100,000 bps x 0.6 s
100 Kbps x 600 ms = ————————————————————— = 7500 bytes
8 bits per byte
On a Gigabit Ethernet interface, a congured burst-size limit of 600 ms creates a burst duraon of
60 μs at Gigabit Ethernet line rate, calculated as follows:
7500 bytes 60,000 bits
———————————— = ——————————————————— = 0.00006 s = 60 μs
1 Gbps 1,000,000,000 bps
3. If the downstream device is unable to handle the amount of bursty trac allowed using the inial
burst size conguraon, reduce the burst-size limit unl you achieve acceptable results.
5 ms Method for Selecng Inial Burst Size for Gigabit Ethernet Interface with 200 Mbps
Bandwidth
The following sequence illustrates the use of the 5 ms method for selecng an inial burst size for test
conguraons for a Gigabit Ethernet interface congured with a 200 Mbps bandwidth limit. This
example calculaon shows how a larger burst-size limit can aect the measured bandwidth rate.
1. If you congure a 5 ms burst-size limit, the maximum amount of trac allowed to pass through the
interface unrestricted is 125,000 bytes (approximately 83 1500-byte packets), calculated as follows:
200,000,000 bps x 0.005 s
200 Mbps x 5 ms = —————————————————————————— = 125,000 bytes
8 bits per byte
1918
On a Gigabit Ethernet interface, a congured burst-size limit of 5 ms creates a burst duraon of 1 ms
at Gigabit Ethernet line rate, calculated as follows:
125,000 bytes 1,000,000 bits
——————————————— = ——————————————————— = 0.001 s = 1 ms
1 Gbps 1,000,000,000 bps
The average bandwidth rate in 1 second becomes 200 Mbps + 1 Mbps = 201 Mbps, which is a
minimal increase over the congured bandwidth limit at 200 Mbps.
2. If you congure a 600 ms burst-size limit, the maximum amount of trac allowed to pass through the
interface unrestricted is 15 Mbytes (approximately 10,000 1500-byte packets), calculated as follows:
200,000,000 bps x 0.6 s
200 Mbps x 600 ms = ————————————————————————— = 15,000,000 bytes
8 bits per byte
On a Gigabit Ethernet interface, a congured burst-size limit of 600 ms creates a burst duraon of
120 ms at Gigabit Ethernet line rate, calculated as follows:
15,000,000 bytes 120,000,000 bits
—————————————— = ——————————————————— = 0.12 s = 120 ms
1 Gbps 1,000,000,000 bps
The average bandwidth rate in 1 second becomes 200 Mbps + 120 Mbps = 320 Mbps, which is much
higher than the congured bandwidth limit at 200 Mbps.
200 Mbps Bandwidth Limit, 5 ms Burst Duraon
If a 200 Mbps bandwidth limit is congured with a 5 ms burst size, the calculaon becomes 200 Mbps x
5 ms = 125 Kbytes, which is approximately 83 1500-byte packets. If the 200 Mbps bandwidth limit is
1919
congured on a Gigabit Ethernet interface, the burst duraon is 125000 bytes / 1 Gbps = 1 ms at the
Gigabit Ethernet line rate.
200 Mbps Bandwidth Limit, 600 ms Burst Duraon
If a large burst size is congured at 600 ms with the bandwidth limit congured at 200 Mbps, the
calculaon becomes 200 Mbps x 600 ms = 15 Mbytes. This creates a burst duraon of 120 ms at the
Gigabit Ethernet line rate. The average bandwidth rate in 1 second becomes 200 Mbps + 15 Mbytes =
320 Mbps, which is much higher than the congured bandwidth limit at 200 Mbps. This example shows
that a larger burst size can aect the measured bandwidth rate.
RELATED DOCUMENTATION
Policer Implementaon Overview | 1899
Understanding the Benets of Policers and Token Bucket Algorithms | 1910
Controlling Network Access Using Trac Policing Overview
IN THIS SECTION
Congeson Management for IP Trac Flows | 1920
Trac Limits | 1921
Trac Color Marking | 1922
Forwarding Classes and PLP Levels | 1924
Policer Applicaon to Trac | 1925
Congeson Management for IP Trac Flows
Trac policing, also known as
rate liming
, is an essenal component of network access security that is
designed to thwart denial-of-service (DoS) aacks. Trac policing enables you to control the maximum
rate of IP trac sent or received on an interface and also to paron network trac into mulple
priority levels, also known as
classes of service
. A policer denes a set of trac rate limits and sets
consequences for trac that does not conform to the congured limits. Packets in a trac ow that
do not conform to trac limits are either discarded or marked with a dierent forwarding class or packet
loss priority (PLP) level.
1920
With the excepon of policers congured to rate-limit aggregate trac (all protocol families and logical
interfaces congured on a physical interface), you can apply a policer to all IP packets in a Layer 2 or
Layer 3 trac ow at a
logical interface
.
With the excepon of policers congured to rate-limit based on physical interface media rate, you can
apply a policer to specic IP packets in a Layer 3 trac ow at a logical interface by using a stateless
rewall lter
.
You can apply a policer to inbound or outbound interface trac. Policers applied to inbound trac help
to conserve resources by dropping trac that does not need to be routed through a network. Dropping
inbound trac also helps to thwart denial-of-service (DoS) aacks. Policers applied to outbound trac
control the bandwidth used.
NOTE: Trac policers are instanated on a per-PIC basis. Trac policing does not work when
the trac for one local policy decision funcon (L-PDF) subscriber is distributed over mulple
Mulservices PICs in an AMS group.
Trac Limits
Junos OS policers use a
token bucket algorithm
to enforce a limit on an average transmit or receive rate
of trac at an interface while allowing bursts of trac up to a maximum value based on the congured
bandwidth limit and congured burst size. The token bucket algorithm oers more exibility than a
leaky
bucket algorithm
in that you can allow a specied trac burst before starng to discard packets or apply
a penalty such as packet output-queuing priority or packet-drop priority.
In the token-bucket model, the bucket represents the rate-liming funcon of the policer. Tokens are
added to the bucket at a xed rate, but once the specied depth of the bucket is reached, tokens
allocated aer cannot be stored and used. Each token represents a “credit” for some number of bits, and
tokens in the bucket are “cashed in” for the ability to transmit or receive trac at the interface. When
sucient tokens are present in the bucket, a trac ow connues unrestricted. Otherwise, packets
might be dropped or else re-marked with a lower forwarding class, a higher packet loss priority (PLP)
level, or both.
• The rate at which tokens are added to the bucket represents the highest average transmit or receive
rate in bits per second allowed for a given service level. You specify this highest average trac rate
as the
bandwidth limit
of the policer. If the trac arrival rate (or xed bits-per-second) is so high that
at some point insucient tokens are present in the bucket, then the trac ow is no longer
conforming to the trac limit. During periods of relavely low trac (trac that arrives at or departs
from the interface at average rates below the token arrival rate), unused tokens accumulate in the
bucket.
• The depth of the bucket in bytes controls the amount of back-to-back bursng allowed. You specify
this factor as the
burst-size limit
of the policer. This second limit aects the average transmit or
1921
receive rate by liming the number of bytes permied in a transmission burst for a given interval of
me. Bursts exceeding the current burst-size limit are dropped unl there are sucient tokens
available to permit the burst to proceed.
Figure 83: Network Trac and Burst Rates
As shown in the gure above, a UPC bar code is a good facsimile of what trac looks like on the line;
an interface is either transming (bursng at full rate) or it is not. The black lines represent periods
of data transmission and the white space represents periods of silence when the token bucket can
replenish.
Depending on the type of policer used, packets in a policed trac ow that surpasses the dened limits
might be implicitly set to a higher PLP level, assigned to a congured forwarding class or set to a
congured PLP level (or both), or simply discarded. If packets encounter downstream congeson,
packets with a low PLP level are less likely to be discarded than those with a medium-low, medium-high, or high
PLP level.
Trac Color Marking
Based on the parcular set of trac limits congured, a policer idenes a trac ow as belonging to
one of either two or three categories that are similar to the colors of a trac light used to control
automobile trac.
•
Single-rate two-color
—A two-color marking policer (or “policer” when used without qualicaon)
meters the trac stream and classies packets into two categories of packet loss priority (PLP)
according to a congured bandwidth and burst-size limit. You can mark packets that exceed the
bandwidth and burst-size limit in some way, or simply discard them.
A policer is most useful for metering trac at the port (physical interface) level.
•
Single-rate three-color
—This type of policer is dened in RFC 2697,
A Single Rate Three Color
Marker
, as part of an assured forwarding (AF) per-hop-behavior (PHB) classicaon system for a
1922
Dierenated Services (DiServ) environment. This type of policer meters trac based on the
congured commied informaon rate (CIR), commied burst size (CBS), and the excess burst size
(EBS). Trac is marked as belonging to one of three categories (green, yellow, or red) based on
whether the packets arriving are below the CBS (green), exceed the CBS (yellow) but not the EBS, or
exceed the EBS (red).
A single-rate three-color policer is most useful when a service is structured according to packet
length and not peak arrival rate.
•
Two-rate three-color
—This type of policer is dened in RFC 2698,
A Two Rate Three Color Marker
, as
part of an assured forwarding (AF) per-hop-behavior (PHB) classicaon system for a Dierenated
Services (DiServ) environment. This type of policer meters trac based on the congured CIR and
peak informaon rate (PIR), along with their associated burst sizes, the CBS and
peak burst size
(PBS). Trac is marked as belonging to one of three categories (green, yellow, or red) based on
whether the packets arriving are below the CIR (green), exceed the CIR (yellow) but not the PIR, or
exceed the PIR (red).
A two-rate three-color policer is most useful when a service is structured according to arrival rates
and not necessarily packet length.
Policer acons are implicit or explicit and vary by policer type. The term
Implicit
means that Junos
assigns the loss-priority automacally. Table 109 on page 1923 describes the policer acons.
Table 109: Policer
Acons
Policer Marking Implicit Acon Congurable Acon
Single-rate two-color Green (Conforming) Assign low loss priority None
Red (Nonconforming) None Assign low or high loss
priority, assign a
forwarding class, or
discard
On some plaorms, you
can assign medium-low or
medium-high loss priority
Single-rate three-color Green (Conforming) Assign low loss priority None
Yellow (Above the CIR
and CBS)
Assign medium-high loss
priority
None
1923
Table 109: Policer Acons
(Connued)
Policer Marking Implicit Acon Congurable Acon
Red (Above the EBS) Assign high loss priority Discard
Two-rate three-color Green (Conforming) Assign low loss priority None
Yellow (Above the CIR
and CBS)
Assign medium-high loss
priority
None
Red (Above the PIR and
PBS)
Assign high loss priority Discard
Forwarding Classes and PLP Levels
A packet’s forwarding class assignment and PLP level are used by the Junos OS class of service (CoS)
features. The Junos OS CoS features include a set of mechanisms that you can use to provide
dierenated services when best-eort trac delivery is insucient. For router (and switch) interfaces
that carry IPv4, IPv6, and MPLS trac, you can congure CoS features to take in a single ow of trac
entering at the edge of your network and provide dierent levels of service across the network—internal
forwarding and scheduling (queuing) for output—based on the forwarding class assignments and PLP
levels of the individual packets.
NOTE: Forwarding-class or loss-priority assignments performed by a policer or a stateless
rewall lter override any such assignments performed on the ingress by the CoS default IP
precedence classicaon at all logical interfaces or by any congured behavior aggregate (BA)
classier that is explicitly mapped to a logical interface.
Based on CoS conguraons, packets of a given forwarding class are transmied through a specic
output queue, and each output queue is associated with a transmission service level dened in a
scheduler
.
Based on other CoS conguraons, when packets in an output queue encounter congeson, packets
with higher loss-priority values are more likely to be dropped by the random early detecon (RED)
algorithm. Packet loss priority values aect the scheduling of a packet without aecng the packet’s
relave ordering within the trac ow.
1924
Policer Applicaon to Trac
Aer you have dened and named a policer, it is stored as a template. You can later use the same policer
name to provide the same policer conguraon each me you want to use it. This eliminates the need to
dene the same policer values more than once.
You can apply a policer to a trac ow in either of two ways:
• You can congure a standard stateless rewall lter that species the policer
policer-name
nonterminang acon or the three-color-policer (single-rate | two-rate)
policer-name
nonterminang
acon. When you apply the standard lter to the input or output at a logical interface, the policer is
applied to all packets of the lter-specic protocol family that match the condions specied in the
lter conguraon.
With this method of applying a policer, you can dene specic classes of trac on an interface and
apply trac rate-liming to each class.
• You can apply a policer directly to an interface so that trac rate-liming applies to all trac on that
interface, regardless of protocol family or any match condions.
You can congure policers at the queue, logical interface, or Layer 2 (MAC) level. Only a single policer is
applied to a packet at the egress queue, and the search for policers occurs in this order:
• Queue level
• Logical interface level
• Layer 2 (MAC) level
RELATED DOCUMENTATION
Stateless Firewall Filter Overview | 778
Trac Policer Types | 1926
Order of Policer and Firewall Filter Operaons | 1930
Packet Flow Through the Junos OS CoS Process Overview
1925
Trac Policer Types
IN THIS SECTION
Single-Rate Two-Color Policers | 1926
Three-Color Policers | 1927
Hierarchical Policers | 1928
Two-Color and Three-Color Policer Opons | 1928
Single-Rate Two-Color Policers
You can use a single-rate two-color policer, or “policer” when used without qualicaon, to rate-limit a
trac ow to an average bits-per-second arrival rate (specied by the single specied bandwidth limit)
while allowing bursts of trac for short periods (controlled by the single specied burst-size limit). This
type of policer categorizes a trac ow as either green (conforming) or red (nonconforming). Packets in
a green ow are implicitly set to a low loss priority and then transmied. Packets in a red ow are
handled according to acons specied in the policer conguraon. Packets in a red ow can be marked
—set to a specied forwarding class, set to a specied loss priority, or both—or they can be discarded.
A single-rate two-color policer is most useful for metering trac at the port (physical interface) level.
Basic Single-Rate Two-Color Policer
You can apply a basic single-rate two-color policer to Layer 3 trac in either of two ways: as an
interface policer or as a
rewall lter
policer. You can apply the policer as an <!--<new-
term>interface policer</new-term>-->, meaning that you apply the policer directly to a
logical interface
at the protocol family level. If you want to apply the policer to selected packets only, you can apply the
policer as a
rewall lter policer
, meaning that you reference the policer in a stateless rewall lter term
and then apply the lter to a logical interface at the protocol family level.
Bandwidth Policer
A bandwidth policer is simply a single-rate two-color policer that is dened using a bandwidth limit
specied as a percentage value rather than as an absolute number of bits per second. When you apply
the policer (as an interface policer or as a rewall lter policer) to a logical interface at the protocol
family level, the eecve bandwidth limit is calculated based on either the physical interface media rate
or the logical interface congured shaping rate.
1926
Logical Bandwidth Policer
A logical bandwidth policer is a bandwidth policer for which the eecve bandwidth limit is calculated
based on the logical interface congured shaping rate. You can apply the policer as a rewall lter
policer only, and the rewall lter must be congured as an interface-specic lter. When you apply an
interface-specic lter to mulple logical interfaces on supported roung plaorms, any count or policer
acons act on the trac stream entering or exing each individual interface, regardless of the sum of
trac on the mulple interfaces.
Three-Color Policers
The Junos OS supports two types of three-color policers: single-rate and two-rate. The main dierence
between a single-rate and a two-rate policer is that the single-rate policer allows bursts of trac for
short periods, while the two-rate policer allows more sustained bursts of trac. Single-rate policing is
implemented using a single token-bucket model, so that periods of relavely low trac must occur
between trac bursts to allow the token bucket to rell. Two-rate policing is implemented using a dual
token-bucket model, which allows bursts of trac for longer periods.
Single-Rate Three-Color Policers
The single-rate three-color type of policer is dened in RFC 2697,
A Single Rate Three Color Marker
.
You use this type of policer to rate-limit a trac ow to a single rate and three trac categories (green,
yellow, and red). A single-rate three-color policer denes a
commied
bandwidth limit and burst-size
limit plus an
excess
burst-size limit. Trac that conforms to the commied trac limits is categorized as
green (conforming). Trac that conforms to the bandwidth limit while allowing bursts of trac as
controlled by the excess burst-size limit is categorized as yellow. All other trac is categorized as red.
A single-rate three-color policer is most useful when a service is structured according to packet length,
not peak arrival rate.
Two-Rate Three-Color Policers
The two-rate three-color type of policer is dened in RFC 2698,
A Two Rate Three Color Marker
. You
use this type of policer to rate-limit a trac ow to two rates and three trac categories (green, yellow,
and red). A two-rate three-color policer denes a
commied
bandwidth limit and burst-size limit plus a
peak
bandwidth limit and burst-size limit. Trac that conforms to the commied trac limits is
categorized as green (conforming). Trac that exceeds the commied trac limits but remains below
the peak trac limits is categorized as yellow. Trac that exceeds the peak trac limits is categorized as
red.
A two-rate three-color policer is most useful when a service is structured according to arrival rates and
not necessarily packet length.
1927
Hierarchical Policers
You can use a hierarchical policer to rate-limit ingress Layer 2 trac at a physical or logical interface and
apply dierent policing acons based on whether the packets are classied for expedited forwarding
(EF) or for a lower priority output queue. This feature is supported on SONET interfaces hosted on
M40e, M120, and M320 edge routers with incoming Flexible PIC Concentrators (FPCs) as SFPC and
outgoing FPCs as FFPC, and on T320, T640, and T1600 core routers with Enhanced Intelligent Queuing
(IQE) PICs.
Two-Color and Three-Color Policer Opons
Both two-color and three-color policers can be congured with the following opons:
Logical Interface (Aggregate) Policers
A logical interface policer—also called an aggregate policer—is a two-color or three-color policer that you
can apply to mulple protocol families on the same logical interface without creang mulple instances
of the policer. You apply a logical interface policer directly to a logical interface conguraon (and not by
referencing the policer in a stateless rewall lter and then applying the lter to the logical interface).
• You can apply the policer at the interface logical unit level to rate-limit all trac types, regardless of
the protocol family.
When applied in this manner, the logical interface policer will be used by all trac types (inet, intet6,
etc.) and across all layers (layer 2, layer 3) no maer where the policer is aached on the logical
interface.
• You can also apply the policer at the logical interface protocol family level, to rate-limit trac for a
specic protocol family.
You can apply a logical interface policer to unicast trac only. For informaon about conguring a
stateless rewall lter for ooded trac, see “
Applying Forwarding Table Filters
” in the “Trac Sampling,
Forwarding, and Monitoring” secon of the Roung Policies, Firewall Filters, and Trac Policers User
Guide.
Physical Interface Policers
A physical interface policer is a two-color or three-color policer that applies to all logical interfaces and
protocol families congured on a physical interface, even if the logical interfaces belong to dierent
roung instances. You apply a physical interface policer to a logical interface at the protocol level
through a physical interface lter only, but rate liming is performed aggregately for all logical interfaces
and protocol families congured on the underlying physical interface.
1928
This feature enables you to use a single policer instance to perform aggregate policing for dierent
protocol families and dierent logical interfaces on the same physical interface.
Policers Applied to Layer 2 Trac
In addion to hierarchical policing, you can also apply single-rate two-color policers and three-color
policers (both single-rate and two-rate) to Layer 2 input or output trac. You must congure the two-
color or three-color policer as a logical interface policer and reference the policer in the interface
conguraon at the logical unit level, and not at the protocol level. You cannot apply a two-color or
three-color policer to Layer 2 trac as a stateless rewall lter acon.
Muleld Classicaon
Like behavior aggregate (BA) classicaon, which is somemes referred to as class-of-service (CoS) value
trac classicaon, muleld classicaon is a method of classifying incoming trac by associang
each packet with a forwarding class, a packet loss priority level, or both. The CoS scheduling
conguraon assigns packets to output queues based on forwarding class. The CoS random early
detecon (RED) process uses the drop probability conguraon, output queue fullness percentage, and
packet loss priority to drop packets as needed to control congeson at the output stage.
BA classicaon and muleld classicaon use dierent elds of a packet to perform trac
classicaon. BA classicaon is based on a
CoS value
in the IP packet header. Muleld classicaon
can be based on
mulple elds
in the IP packet header, including CoS values. Muleld classicaon is
used instead of BA classicaon when you need to classify packets based on informaon in the packet
other than the CoS values only. Muleld classicaon is congured using a stateless rewall lter term
that matches on any packet header elds and associates matched packets with a forwarding class, a loss
priority, or both. The forwarding class or loss priority can be set by a rewall lter acon or by a policer
referenced as a rewall lter acon.
RELATED DOCUMENTATION
Controlling Network Access Using Trac Policing Overview | 1920
Order of Policer and Firewall Filter Operaons | 1930
Two-Color Policer Conguraon Overview | 2038
Three-Color Policer Conguraon Overview | 2122
Hierarchical Policer Conguraon Overview | 1932
Two-Color Policing at Layer 2 Overview
Three-Color Policing at Layer 2 Overview
1929
Order of Policer and Firewall Filter Operaons
You can apply a both a trac policer and a stateless
rewall lter
(with or without policing acons) to a
single
logical interface
at the same me. In this case, the order of precedence of operaons is such that
policers applied directly to the logical interface are evaluated before input lters but aer output lters.
• If an input rewall lter is congured on the same logical interface as a policer, the policer is
executed rst.
• If an output rewall lter is congured on the same logical interface as a policer, the rewall lter is
executed rst.
Figure 84 on page 1930 illustrates the order of policer and rewall lter processing at the same
interface.
Figure 84: Incoming and Outgoing Policers and Firewall Filters
NOTE: Order of policer and rewall operaons applies only to policers that have been applied
directly to the logical interface and not to policers referenced within a rewall lter.
RELATED DOCUMENTATION
How Standard Firewall Filters Evaluate Packets | 795
Comparison of Roung Policies and Firewall Filters | 9
Two-Color Policer Conguraon Overview | 2038
Three-Color Policer Conguraon Overview | 2122
Hierarchical Policer Conguraon Overview | 1932
Understanding the Frame Length for Policing Packets
Table 110 on page 1931 describes the packet lengths that are considered when you use a trac policer.
1930
Table 110: Packet Lengths Considered for Trac Policers
Protocol Policing Packet Lengths
Any L3 frame including header
IPv4 L3 frame including header
IPv6 L3 frame including header
MPLS L3 frame including header
VPLS MAC
Bridge MAC
CCC MAC
RELATED DOCUMENTATION
Policer Overhead to Account for Rate Shaping in the Trac Manager | 2110
Supported Standards for Policing
Three-color policers are part of an assured forwarding (AF) per-hop-behavior (PHB) classicaon system
for a Dierenated Services (DiServ) environment, which is described and dened in the following
RFCs:
• RFC 2474,
Denion of the Dierenated Services Field (DS Field) in the IPv4 and IPv6 Headers
• RFC 2475,
An Architecture for Dierenated Service
• RFC 2597,
Assured Forwarding PHB Group
• RFC 2598,
An Expedited Forwarding PHB
• RFC 2698,
A Two Rate Three Color Marker
1931
In a DiServ environment, the most signicant 6 bits of the type-of-service (ToS) octet in the IP header
contain a value called the
Dierenated Services code point
(DSCP). Within the DSCP eld, the most
signicant 3 bits are interpreted as the
IP precedence
eld, which can be used to select dierent per-
hop forwarding treatments for the packet.
Hierarchical Policer Conguraon Overview
Hierarchically rate-limits Layer 2 ingress trac for all protocol families. Cannot be applied to egress
trac, Layer 3 trac, or at a specic protocol level of the interface hierarchy.
Supported on the following interfaces:
• SONET interfaces hosted on M40e, M120, and M320 edge routers with incoming FPCs as SFPC and
outgoing FPCs as FFPC.
• SONET interfaces hosted on T320, T640, and T1600 core routers with Enhanced Intelligent Queuing
(IQE) PICs.
• Ethernet interfaces on Gigabit Ethernet Intelligent Queuing 2 (IQ2) and Ethernet Enhanced IQ2
(IQ2E) PICs.
• MX Series routers with MPC or DPC.
Table 111 on page 1932 describes the hierarchy levels at which you can congure and apply hierarchical
policers.
Table 111: Hierarchical Policer
Conguraon and Applicaon Summary
Policer Conguraon Layer 2 Applicaon Key Points
Hierarchical Policer
1932
Table 111: Hierarchical Policer Conguraon and Applicaon Summary
(Connued)
Policer Conguraon Layer 2 Applicaon Key Points
Aggregate and premium policing
components of a hierarchical
policer:
[edit firewall]
hierarchical-policer
policer-name
{
aggregate {
if-exceeding {
bandwidth-limit
bps
;
burst-size-limit
bytes
;
}
then {
discard;
forwarding-class
class-name
;
loss-priority
supported-value
;
}
}
premium {
if-exceeding {
bandwidth-limit
bps
;
burst-size-limit
bytes
;
}
then {
discard;
}
}
}
Opon A—Apply directly to Layer 2 input
trac on a physical interface:
[edit interfaces]
interface-name
{
layer2-policer {
input-hierarchical-policer
policer-
name
;
}
}
Hierarchically rate-limit
Layer 2 ingress trac for all
protocol families and logical
interfaces congured on a
physical interface.
Include the layer2-policer
conguraon statement at
the [edit interfaces
interface-name
] hierarchy
level.
NOTE: If you apply a
hierarchical policer at a
physical interface, you
cannot also apply a
hierarchical policer to any of
the member logical
interfaces.
Opon B—Apply directly to Layer 2 input
trac on a logical interface.
[edit interfaces]
interface-name
{
unit
unit-number
{
layer2-policer {
input-hierarchical-policer
policer-name
;
}
}
}
Hierarchically rate-limit
Layer 2 ingress trac for all
protocol families congured
on a specic logical
interface.
Include the layer2-policer
conguraon statement at
the [edit interfaces
interface-name
unit
unit-
number
] hierarchy level.
NOTE: You must congure
at least one protocol family
for the logical interface.
RELATED DOCUMENTATION
Hierarchical Policers | 1980
1933
Understanding Enhanced Hierarchical Policers
IN THIS SECTION
Guidelines for conguring enhanced hierarchical policer | 1935
Example: Conguring an enhanced hierarchical policer | 1935
Use the enhanced hierarchical policer conguraon to rate limit trac based on packets classied on
the trac priority. Congure trac policing at four levels of hierarchies with respect to the trac
priority.
NOTE: This feature is available only on ACX7100-32C, ACX7100-48L, ACX7509, and ACX7024
devices.
In an enhanced hierarchical policer conguraon, up to four policers are dened. Each policer maps to a
trac priority. The four trac priories, arranged as per their order of precedence are High, Medium-
High, Medium-Low, and Low. The trac priories are hierarchical – High is the trac priority with the
highest precedence and Low is the trac priority with the lowest precedence. It implies that a policer
dened for the High trac priority has a higher precedence than the rest of the policers or a policer
dened for the Low trac priority has a lower precedence than the rest of the policers.
All policers (one or up to four) in an enhanced hierarchical policer conguraon, consume bandwidth
from a maximum alloed bandwidth – in Table 1 this maximum alloed bandwidth is 65 mbps. Each
policer is alloed a Conrmed Informaon Rate (CIR) and Maximum Conrmed Informaon Rate from
this maximum alloed bandwidth. As a guideline, the CIR and Max CIR values are always the same for
the policer with the highest precedence.
Residue bandwidth or unused bandwidth is carried over to lower precedence policers. As can be noted
in Table 112 on page 1935, medium-high policer inherits unused bandwidth from high policer. Medium-
low policer inherits from high and medium-high policers. Low policer inherits from the other three higher
precedence policers. It is recommended that MAX CIR of a parcular level is equal to the CIR of current
level + combined CIR of previous/top levels.
1934
Table 112: Example enhanced hierarchical policer conguraon
Policer Conguraons
Policer-level/trac-priority CIR MAX CIR
high 5mbps 5mbps
medium-high 10mbps 15mbps
medium-low 20mbps 35mbps
low 30mbps 65mbps
Guidelines for conguring enhanced hierarchical policer
• An enhanced hierarchical policer is lter-specic. Filter-specic policer semancs is to be used for
hierarchical policer as mulple terms will point to same policer.
• Counter name must be same for all the terms mapped to enhanced-hierarchical-policer acon under
same hierarchy level.
• It is mandatory to congure all the levels of an enhanced hierarchical policer with respecve policer
bandwidth rates and burst size conguraons. If there is no requirement to congure all four levels,
the unwanted levels must specify least supported CIR, MAX CIR and CBS rates. It is recommended
that rewall lter terms not be mapped to these unwanted levels.
• Each enhanced hierarchical policer level must be congured with the acon to discard the packets
exceeding the congured bandwidth.
Example: Conguring an enhanced hierarchical policer
In this example:
• An enhanced hierarchical policer is dened.
• A rewall lter is dened and policer is applied in the rewall lter. The rewall lter is applied to an
interface.
• Policer stascs is displayed.
1935
Requirements:
• Junos OS Release 23.3 R1 or later.
• An ACX7100-32C, ACX7100-48L, ACX7509, or ACX7024 device.
Step-by-Step Procedure
1. Dene the policer name.
[edit]
user@host# set firewall enhanced-hierarchical-policer hpol
2. Dene commied informaon rate (CIR), maximum commied informaon rate (MIR), and
commied burst size (CBS) for the four trac priories, namely high, medium-high, medium-low, and
low.
user@host# set firewall enhanced-hierarchical-policer hpol filter-specific
user@host# set firewall enhanced-hierarchical-policer hpol high committed-information-rate 5m
user@host# set firewall enhanced-hierarchical-policer hpol high max-committed-information-
rate 5m
user@host# set firewall enhanced-hierarchical-policer hpol high committed-burst-size 5k
user@host# set firewall enhanced-hierarchical-policer hpol high then discard
user@host# set firewall enhanced-hierarchical-policer hpol medium-high committed-information-
rate 10m
user@host# set firewall enhanced-hierarchical-policer hpol medium-high max-committed-
information-rate 15m
user@host# set firewall enhanced-hierarchical-policer hpol medium-high committed-burst-size
15k
user@host# set firewall enhanced-hierarchical-policer hpol medium-high then discard
user@host# set firewall enhanced-hierarchical-policer hpol medium-low committed-information-
rate 20m
user@host# set firewall enhanced-hierarchical-policer hpol medium-low max-committed-
information-rate 35m
user@host# set firewall enhanced-hierarchical-policer hpol medium-low committed-burst-size 35k
user@host# set firewall enhanced-hierarchical-policer hpol medium-low then discard
user@host# set firewall enhanced-hierarchical-policer hpol low committed-information-rate 30m
user@host# set firewall enhanced-hierarchical-policer hpol low max-committed-information-rate
65m
1936
user@host# set firewall enhanced-hierarchical-policer hpol low committed-burst-size 65k
user@host# set firewall enhanced-hierarchical-policer hpol low then discard
3. Dene a rewall lter. Apply the enhanced hierarchical policer by specifying the trac priority in the
acon of the rewall lter term.
user@host# set firewall family inet filter hpol-inet interface-specific
user@host# set firewall family inet filter hpol-inet term platinum from dscp af11
user@host# set firewall family inet filter hpol-inet term platinum then enhanced-hierarchical-
policer hpol traffic-priority high
user@host# set firewall family inet filter hpol-inet term gold from dscp af12
user@host# set firewall family inet filter hpol-inet term gold then enhanced-hierarchical-
policer hpol traffic-priority medium-high
user@host# set firewall family inet filter hpol-inet term silver from dscp af13
user@host# set firewall family inet filter hpol-inet term silver then enhanced-hierarchical-
policer hpol traffic-priority medium-low
user@host# set firewall family inet filter hpol-inet term dflt then enhanced-hierarchical-
policer hpol traffic-priority low
4. Apply the rewall lter to an interface.
user@host# set interfaces et-0/0/1 unit 0 family inet address 100.1.1.6/32
user@host# set interfaces et-0/0/1 unit 0 family inet filter input hpol-inet
5. Display enhanced hierarchical policer stascs. The dropped/red bytes and packets are displayed per
level.
user@host# show firewall
Filter: hpol-inet-et-0/0/1.0-i
Enchanced Hierarchical Policers:
Name Bytes Packets
hpol
High 0 0
Medium-High 0 0
Medium-Low 0 0
Low 0 0
1937
Packets-Per-Second (pps)-Based Policer Overview
In a modern network environment, both denial-of-service (DoS) and distributed denial-of-service (DDoS)
aacks are very common. Over me, these aacks have evolved from brute force types of aacks,
where the aacker might try to overrun a connecon’s available bandwidth with a vast amount of
directed trac to more low-and-slow aacks that use smaller packets, sent at a slower rate to target
specic resources in order to deny service.
Trac policers, both interface-based and lter-based, have been available to migate brute force types
of DDoS aacks since Junos OS Release 9.6. These policers operate by liming the trac rate through a
logical interface or by liming the trac rate as the "nonterminang acon" on page 873 within a
rewall lter.
In Junos OS Release 15.1 and earlier releases, there were two parameters available for policers:
bandwidth and burst-size. The unit of measure for the bandwidth parameter is bits per second (bps), and
the unit of measure for the burst-size parameter is bytes (B). See "Policer Bandwidth and Burst-Size
Limits" on page 1970 for details. Policers dened within these parameters are not eecve at stopping
low-and-slow types of DDoS aacks.
Starng in Junos OS Release 16.1, trac policers can be dened using packets per second (pps) with the
pps-limit and packet-burst statements. The unit of measure for pps-limit is packets per second (pps), and
the unit of measure for packet-burst is packets. These pps-based policers are more eecve at migang
low-and-slow types of DDoS aacks.
Policers congured with the if-exceeding-pps statement are applied in the same manner and in the same
locaons as bandwidth-based policers. Pps-based policers cannot be applied simultaneously with
bandwidth-based policers. Only one policer can be applied at a me except for hierarchical policers,
which allow the conguraon of two policing acons based on trac classicaon.
RELATED DOCUMENTATION
if-exceeding-pps
pps-limit
packet-burst
Guidelines for Applying Trac Policers
The following general guidelines pertain to applying trac policers:
1938
• Only one type of policer can be applied to the input or output of the same physical or logical
interface. For example, you are not allowed to apply a policer and a hierarchical policer in the same
direcon at the same logical interface.
• Chaining of policers—that is, applying policers to both a port and the logical interfaces of that port—is
not allowed.
• A maximum of 64 policers is supported per physical or logical interface, provided no behavior
aggregate (BA) classicaon—trac classicaon based on CoS values in the packet headers—is
applied to the logical interface.
• The policer should be independent of BA classicaon. Without BA classicaon, all trac on an
interface is treated either as expedited forwarding (EF) or non-EF, based on the conguraon. With
BA classicaon, a physical or logical interface can support up to 64 policers. The interface might be
a physical interface or logical interface.
• With BA classicaon, the miscellaneous trac (the trac
not
matching any of the BA classicaon
DSCP/EXP bits) is policed as non-EF trac. No separate policers are installed for this trac.
• Policers can be applied to unicast packets only. For informaon about conguring a lter for ooded
trac, see
Applying Forwarding Table Filters
.
RELATED DOCUMENTATION
Two-Color Policer Conguraon Overview | 2038
Three-Color Policer Conguraon Overview | 2122
Hierarchical Policer Conguraon Overview | 1932
Policer Support for Aggregated Ethernet Interfaces Overview
Aggregated interfaces support single-rate policers, three-color marking policers, two-rate three-color
marking policers, hierarchical policers, and percentage-based policers. By default, policer bandwidth and
burst-size applied on aggregated bundles is not matched to the user-congured bandwidth and burst-
size.
You can congure interface-specic policers applied on an aggregated Ethernet bundle or an aggregated
SONET bundle to match the eecve bandwidth and burst-size to user-congured values. The shared-
bandwidth-policer statement is required to achieve this match behavior.
This capability applies to all interface-specic policers of the following types: single-rate policers, single-
rate three-color marking policers, two-rate three-color marking policers, and hierarchical policers.
1939
Percentage-based policers match the bandwidth to the user-congured values by default, and do not
require shared-bandwidth-policer conguraon. The shared-bandwidth-policer statement causes a split in
burst-size for percentage-based policers.
NOTE: This feature is supported on the following plaorms: T Series routers (excluding T4000
Type 5 FPCs), M120, M10i, M7i (CFEB-E only), M320 (SFPC only), MX240, MX480, and MX960
with DPC, MIC, and MPC interfaces, and EX Series switches.
The following usage scenarios are supported:
• Interface policers used by the following conguraon:
[edit] interfaces (ae
X
| as
X
) unit
unit-num
family
family
policer [input | output | arp]
• Policers and three-color policers (both single-rate three-color marking and two-rate three-color
marking) used inside interface-specic lters; that is, lters that have an interface-specic keyword
and are used by the following conguraon:
[edit] interfaces (ae
X
| as
X
) unit
unit-num
family
family
filter [input | output]
• Common-edge service lters, which are derived from CLI-congured lters and thus inherit
interface-specic properes. All policers and three-color policers used by these lters are also
aected.
The following usage scenarios are not supported:
• Policers and three-color policers used inside lters that are not interface specic; such a lter is
meant to be shared across mulple interfaces.
• Any implicit policers or policers that are part of implicit lters; for example, the default ARP policer
applied to an aggregate Ethernet interface. Such a policer is meant to be shared across mulple
interfaces.
• Prex-specic acon policers.
To congure this feature, include the shared-bandwidth-policer statement at the following hierarchy levels:
[edit firewall policer
policer-name
], [edit firewall three-color-policer
policer-name
], or [edit firewall
hierarchical-policer
policer-name
].
1940
RELATED DOCUMENTATION
shared-bandwidth-policer
Example: Conguring a Physical Interface Policer for Aggregate Trac at
a Physical Interface
IN THIS SECTION
Requirements | 1941
Overview | 1941
Conguraon | 1942
Vericaon | 1948
This example shows how to congure a single-rate two-color policer as a physical interface policer.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 1942
A
physical interface policer
species rate-liming for aggregate trac, which encompasses all protocol
families and logical interfaces congured on a physical interface, even if the interfaces belong to
dierent roung instances.
You can apply a physical interface policer to Layer 3 input or output trac only by referencing the
policer from a stateless rewall lter that is congured for specic a specic protocol family (not for
family any) and congured as a physical interface lter. You congure the lter terms with match
1941
condions that select the types of packets you want to rate-limit, and you specify the physical interface
policer as the acon to apply to matched packets.
NOTE: Physical interface policers/lters are not supported for list lters.
Topology
The physical interface policer in this example, shared-policer-A, rate-limits to 10,000,000 bps and permits
a maximum burst of trac of 500,000 bytes. You congure the policer to discard packets in
nonconforming ows, but you could instead congure the policer to re-mark nonconforming trac with
a forwarding class, a packet loss priority (PLP) level, or both.
To be able to use the policer to rate-limit IPv4 trac, you reference the policer from an IPv4 physical
interface lter. For this example, you congure the lter to pass the policer IPv4 packets that meet
either of the following match terms:
• Packets received through TCP and with the IP precedence elds critical-ecp (0xa0), immediate (0x40),
or priority (0x20)
• Packets received through TCP and with the IP precedence elds internet-control (0xc0) or
routine (0x00)
You could also reference the policer from physical interface lters for other protocol families.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1943
Conguring the Logical Interfaces on the Physical Interface | 1943
Conguring a Physical Interface Policer | 1944
Conguring an IPv4 Physical Interface Filter | 1945
Applying the IPv4 Physical interface Filter to Reference the Physical Interface Policers | 1947
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
1942
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces so-1/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces so-1/0/0 unit 0 family vpls
set interfaces so-1/0/0 unit 1 family mpls
set firewall policer shared-policer-A physical-interface-policer
set firewall policer shared-policer-A if-exceeding bandwidth-limit 100m burst-size-limit 500k
set firewall policer shared-policer-A then discard
set firewall family inet filter ipv4-filter physical-interface-filter
set firewall family inet filter ipv4-filter term tcp-police-1 from precedence [ critical-ecp
immediate priority ]
set firewall family inet filter ipv4-filter term tcp-police-1 from protocol tcp
set firewall family inet filter ipv4-filter term tcp-police-1 then policer shared-policer-A
set firewall family inet filter ipv4-filter term tcp-police-2 from precedence [ internet-control
routine ]
set firewall family inet filter ipv4-filter term tcp-police-2 from protocol tcp
set firewall family inet filter ipv4-filter term tcp-police-2 then policer shared-policer-A
set interfaces so-1/0/0 unit 0 family inet filter input ipv4-filter
Conguring the Logical Interfaces on the Physical Interface
Step-by-Step Procedure
To congure the logical interfaces on the physical interface:
1. Enable conguraon of logical interfaces.
[edit]
user@host# edit interfaces so-1/0/0
2. Congure protocol families on logical unit 0.
[edit interfaces so-1/0/0]
user@host# set unit 0 family inet address 192.168.1.1/24
user@host# set unit 0 family vpls
1943
3. Congure protocol families on logical unit 1.
[edit interfaces so-1/0/0]
user@host# set unit 1 family mpls
Results
Conrm the conguraon of the rewall lter by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
so-1/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
family vpls;
}
unit 1 {
family mpls;
}
}
Conguring a Physical Interface Policer
Step-by-Step Procedure
To congure a physical interface policer:
1. Enable conguraon of the two-color policer.
[edit]
user@host# edit firewall policer shared-policer-A
1944
2. Congure the type of two-color policer.
[edit firewall policer shared-policer-A]
user@host# set physical-interface-policer
3. Congure the trac limits and the acon for packets in a nonconforming trac ow.
[edit firewall policer shared-policer-A]
user@host# set if-exceeding bandwidth-limit 100m burst-size-limit 500k
user@host# set then discard
For a physical interface lter, the acons you can congure for packets in a nonconforming trac
ow are to discard the packets, assign a forwarding class, assign a PLP value, or assign both a
forwarding class and a PLP value.
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
policer shared-policer-A {
physical-interface-policer;
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 500k;
}
then discard;
}
Conguring an IPv4 Physical Interface Filter
Step-by-Step Procedure
To congure a physical interface policer as the acon for terms in an IPv4 physical interface policer:
1945
1. Congure a standard stateless rewall lter under a specic protocol family.
[edit]
user@host# edit firewall family inet filter ipv4-filter
You cannot congure a physical interface rewall lter for family any.
2. Congure the lter as a physical interface lter so that you can apply the physical interface policer as
an acon.
[edit firewall family inet filter ipv4-filter]
user@host# set physical-interface-filter
3. Congure the rst term to match IPv4 packets received through TCP with the IP precedence elds
critical-ecp, immediate, or priority and to apply the physical interface policer as a lter acon.
[edit firewall family inet filter ipv4-filter]
user@host# set term tcp-police-1 from precedence [ critical-ecp immediate priority ]
user@host# set term tcp-police-1 from protocol tcp
user@host# set term tcp-police-1 then policer shared-policer-A
4. Congure the rst term to match IPv4 packets received through TCP with the IP precedence elds
internet-control or routine and to apply the physical interface policer as a lter acon.
[edit firewall family inet filter ipv4-filter]
user@host# set term tcp-police-2 from precedence [ internet-control routine ]
user@host# set term tcp-police-2 from protocol tcp
user@host# set term tcp-police-2 then policer shared-policer-A
Results
Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
1946
filter ipv4-filter {
physical-interface-filter;
term tcp-police-1 {
from {
precedence [ critical-ecp immediate priority ];
protocol tcp;
}
then policer shared-policer-A;
}
term tcp-police-2 {
from {
precedence [ internet-control routine ];
protocol tcp;
}
then policer shared-policer-A;
}
}
}
policer shared-policer-A {
physical-interface-policer;
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 500k;
}
then discard;
}
Applying the IPv4 Physical interface Filter to Reference the Physical Interface Policers
Step-by-Step Procedure
To apply the physical interface lter so it references the physical interface policers:
1. Enable conguraon of IPv4 on the logical interface.
[edit]
user@host# edit interfaces so-1/0/0 unit 0 family inet
1947
2. Apply the IPv4 physical interface lter in the input direcon.
[edit interfaces so-1/0/0 unit 0 family inet]
user@host# set filter input ipv4-filter
Results
Conrm the conguraon of the rewall lter by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
so-1/0/0 {
unit 0 {
family inet {
filter {
input ipv4-filter;
}
address 192.168.1.1/24;
}
family vpls;
}
unit 1 {
family mpls;
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying the Firewall Filters Applied to an Interface | 1949
Displaying the Number of Packets Processed by the Policer at the Logical Interface | 1949
1948
Conrm that the conguraon is working properly.
Displaying the Firewall Filters Applied to an Interface
Purpose
Verify that the rewall lter ipv4-filter is applied to the IPv4 input trac at logical interface so-1/0/0.0.
Acon
Use the show interfaces statistics operaonal mode command for logical interface so-1/0/0.0, and include
the detail opon. In the Protocol inet secon of the command output, the Input Filters eld shows that
the rewall lter ipv4-filter is applied in the input direcon.
user@host> show interfaces statistics so-1/0/0 detail
Logical interface so-1/0/0.0 (Index 79) (SNMP ifIndex 510) (Generation 149)
Flags: Hardware-Down Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPP
Protocol inet, MTU: 4470, Generation: 173, Route table: 0
Flags: Sendbcast-pkt-to-re, Protocol-Down
Input Filters: ipv4-filter
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 10.39/16, Local: 10.39.1.1, Broadcast: 10.39.255.255, Generation: 163
Displaying the Number of Packets Processed by the Policer at the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show firewall operaonal mode command for the lter you applied to the logical interface.
user@host> show firewall filter ipv4-filter
Filter: ipv4-filter
Policers:
Name Packets
1949
shared-policer-A-tcp-police-1 32863
shared-policer-A-tcp-police-2 3870
The command output displays the name of policer (shared-policer-A), the name of the lter term (police-1)
under which the policer acon is specied, and the number of packets that matched the lter term. This
is only the number of out-of-specicaon (out-of-spec) packet counts, not all packets policed by the
policer.
RELATED DOCUMENTATION
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Fields | 986
Firewall Filter Match Condions Based on Address Classes | 996
Two-Color Policer Conguraon Overview | 2038
Physical Interface Policer Overview
Firewall and Policing Dierences Between PTX Series Packet Transport
Routers and T Series Matrix Routers
This topic provides a list of rewall and policier features available on PTX Packet Transport Routers and
compares them with rewall and policing features on T Series routers.
Firewall Filters
Junos OS rewall and policing soware on PTX Series Packet Transport Routers supports IPv4 lters,
IPv6 lters, MPLS lters, CCC lters, interface policing, LSP policing, MAC ltering, ARP policing, L2
policing, and other features. Excepons are noted below.
• PTX Series Packet Transport Routers do not support:
• Egress Forwarding Table Filters
• Forwarding Table Filters for MPLS/CCC
• Family VPLS
• PTX Series Packet Transport Routers do not support nested rewall lters. The filter statement at
the [edit firewall family
family-name
filter
filter-name
term
term-name
] hierarchy level is disabled.
1950
• Because no service PICs are present in PTX Series Packet Transport Routers, service lters are not
supported for both IPv4 and IPv6 trac. The service-filter statement at [edit firewall family (inet |
inet6)] hierarchy level is disabled.
• The PTX Series Packet Transport Routers exclude simple lters. These lters are supported on
Gigabit Ethernet intelligent queuing (IQ2) and Enhanced Queuing Dense Port Concentrator (EQ DPC)
interfaces only. The simple-filter statement at the [edit firewall family inet)] hierarchy level is
disabled.
• Physical interface ltering is not supported. The physical-interface-filter statement at the [edit
firewall family
family-name
filter
filter-name
] hierarchy level is disabled.
• The prex acon feature is not supported on PTX Series Packet Transport Routers. The prefix-action
statement at [edit firewall family inet] hierarchy level is disabled.
• On T Series routers, you can collect a variety of informaon about trac passing through the device
by seng up one or more accounng proles that specify some common characteriscs of the data.
The PTX Series Packet Transport Routers do not support accounng conguraons for rewall lters.
The accounting-profile statement at the [edit firewall family
family-name
filter
filter-name
] hierarchy
level is disabled.
• The reject acon is not supported on the loopback (lo0) interface. If you apply a lter to the lo0
interface and the lter includes a reject acon, an error message appears.
• PTX Series Packet Transport Routers do not support aggregated ethernet logical interface match
condions. However, child link interface matching is supported.
• PTX Series Packet Transport Routers displays both counts if two dierent terms in a lter have the
same match condion but they have dierent counts. T Series routers display one count only.
• PTX Series Packet Transport Routers do not have separate policer instances when a lter is bound to
mulple interfaces. Use the interface-specific conguraon statement to create the conguraon.
• On PTX Series Packet Transport Routers, when an ingress interface has CCC encapsulaon, packets
coming in through the ingress CCC interface will not be processed by the egress lters.
• For CCC encapsulaon, the PTX Series Packet Transport Routers append an extra 8 bytes for egress
Layer 2 ltering. The T Series routers do not. Therefore, egress counters on PTX Series Packet
Transport Routers show an extra eight bytes for each packet which impacts policer accuracy.
•
On PTX Series Packet Transport Routers, output for the show pfe statistics traffic CLI command
includes the packets discarded by DMAC and SMAC ltering. On T Series routers, the command
output does not include these discarded packets because MAC lters are implemented in the PIC
and not in the FPC.
1951
• The last-fragment packet that goes through a PTX rewall cannot be matched by the is-fragment
matching condion. This feature is supported on T Series routers.
A possible workaround on PTX Series Packet Transport Routers is to congure two separate terms
with same the acons: one term contains a match to is-fragment and the other term contains a match
to fragment-offset -except 0.
• On PTX Series Packet Transport Routers, MAC pause frames are generated when packet discards
exceed 100 Mbps. This occurs only for frame sizes that are less than 105 bytes.
Trac Policiers
Junos OS rewall and policing soware on PTX Series Packet Transport Routers supports IPv4 lters,
IPv6 lters, MPLS lters, CCC lters, interface policing, LSP policing, MAC ltering, ARP policing, L2
policing, and other features. Excepons are noted below.
• PTX Series Packet Transport Routers support ARP policing. T Series routers do not.
• PTX Series Packet Transport Routers do not support LSP policing.
• PTX Series Packet Transport Routers do not support the hierarchical-policer conguraon statement. .
• PTX Series Packet Transport Routers do not support the interface-set conguraon statement. This
statement groups a number of interfaces into a single, named interface set.
• PTX Series Packet Transport Routers do not support the following policer types for both normal
policers and three-color policers:
• logical-bandwidth-policer — Policer uses logical interface bandwidth.
• physical-interface-policer — Policer is a physical interface policer.
• shared-bandwidth-policer — Share policer bandwidth among bundle links.
• When a policer acon and forwarding-class, loss-priority acons are congured within the same rule
(a
Muleld Classicaon
), the PTX Series Packet Transport Routers work dierently than T Series
routers. As shown below, you can congure two rules in the lter to make the PTX lter behave the
same as the T Series lter:
PTX Series conguraon:
rule-1 {
match: {x, y, z}
action: {forwarding-class, loss-prio, next}
}
rule-2 {
match: {x, y, z}
1952
action: {policer}
}
T Series conguraon:
rule-1 {
match: {x, y, z}
action: {forwarding-class, loss-prio, policer}
}
RELATED DOCUMENTATION
Roung Policies, Firewall Filters, and Trac Policers User Guide
Hierarchical Policers on ACX Series Routers Overview
On ACX Series routers, two-level ingress hierarchical policing is supported. Single-level policers dene a
single bandwidth prole that is used by mulple trac ows with dierent priories. Two-level policers
enable a single bandwidth prole to be opmally used for mulple trac ows, based on bandwidth and
priority needs of a network. Typically, mulple trac ows can share a single policer instance. With
single-level policers, you cannot adminster the method using which the commied informaon rate (CIR)
and the peak informaon rate (PIR) values specied in the bandwidth prole are shared across dierent
ows. For example, in a certain network deployment, you might want an equal or even distribuon of
CIR across the individual ows. In such a scenario, you cannot accomplish this requirement using single-
level policers and need to congure aggregate or hierarchical policers.
NOTE: Hierarchical policers is not applicable on ACX5048 and ACX5096 routers.
Hierarchical policers control the sharing of an aggregate trac rate across mulple micro-ows, which
constute the aggregate ow or the macro-ow. Micro-ows are dened and matched using rewall
lter rules and the acon of these rules point to a macro-policer. This macro- policer or aggregate
policer determines the amount of aggregate bandwidth that can be used by the micro-ows that are
associated with it. You can control the bandwidth to be ulized among the micro-ows in dierent ways.
1953
NOTE: The hierarchical policing mechanism on ACX routers is dierent from the hierarching
policing capability supported on MX Series routers. On MX Series routers, with a hierarchical
policer, only one child or subordinate policer can be congured under a parent, top-level policer,
whereas on ACX Series routers, you can aggregate and specify mulple child policers under a
single parent policer. The hierarchical policing methodology on ACX routers is also called
aggregate policing.
Policers are used to enforce bandwidth proles on the transmied trac. A bandwidth prole is
congured for each user based on the service level agreement (SLA) and the subscripon plan that has
been requested by the user from the service or enterprise provider. A bandwidth prole is dened using
the following parameters:
• Commied informaon rate (CIR) denoted in bits per second (bps).
• Commied burst size (CBS) denoted in bytes.
• Excess informaon rate (EIR) denoted in bps.
• Excess burst size (EBS) denoted in bytes.
• Color mode (CM) can contain only one of two possible values, color-blind or color-aware. In color-
aware mode, the local router can assign a higher packet loss priority, but cannot assign a lower
packet loss priority. In color-blind mode, the local router ignores the preclassicaon of packets and
can assign a higher or lower packet loss priority.
A policer is then used to enforce the bandwidth prole and perform dierent acons, depending on
whether a certain packet conrms to the aributes in the bandwidth prole or does not sasfy the
values in the congured bandwidth prole. Hierarchical policers can be considered to be an alternave
technique for hierarchical queuing and shaping. However, a few dierences exist between the
operaons that a hierarchical policer performs when matched against the processes that a hierarchical
scheduler performs.
Hierarchical scheduler enables ne-grained bandwidth sharing in terms of percentages of the available
bandwidth, whereas hierarchical policing only enables a coarse-grained bandwidth sharing based on the
absolute micro-ow values of CIR and EIR. Hierarchical policing enables the packet loss priority (PLP)
and also the forwarding class to be modied in certain cases, depending on whether the packet is
conrming, exceeding, or violang the parcular bandwidth prole. Hierarchical scheduler does not
cause any modicaons to the PLP or forwarding class values of a packet. Modicaons are performed
only for violang packets.
ACX routers do not support hierarchical queuing and shaping. Ingress hierarchical policers can work in
conjuncon with ingress, egress, or both ingress and egress hierarchical queues. For example, a two-
1954
level ingress hierarchical policer combined with a two-level egress queuing framework results in a four-
level CoS capability.
RELATED DOCUMENTATION
Guidelines for Conguring Hierarchical Policers on ACX Series Routers | 1955
Hierarchical Policer Modes on ACX Series Routers | 1957
Processing of Hierarchical Policers on ACX Series Routers | 1962
Acons Performed for Hierarchical Policers on ACX Series Routers | 1963
Conguring Aggregate Parent and Child Policers on ACX Series Routers | 1966
Guidelines for Conguring Hierarchical Policers on ACX Series Routers
Keep the following points in mind when you congure hierarchical or aggregate policers:
• You cannot specify the same policer as both a child policer and a parent policer.
• The child policers of a hierarchical policer use the same resources as normal policers. Therefore, the
maximum number of child policers and normal policers in the system for bridge domains and IPv4
services is as follows:
• Family Bridge
A group of 124 entries of policers shared with other family-bridge lters.
A maximum of approximately 62 policers when no other family-bridge lters with the count
acon for the rewall lter.
Along with 62 policers, you can congure up to 62 family-bridge lters without the count acon
for the rewall lter.
• Family inet
A group of 250 entries of policers shared with other family-inet lters.
A maximum of about 125 policers when no other family-inet lters with the count acon.
Along with 125 policers, you can dene up to 62 family-inet lters without the count acon.
• The hierarchical policer supports the same policer ranger and burst size behavior as normal policers.
• You must congure the same hierarchical policer mode for all child policers that refer or link with the
same parent policer instance.
1955
• You cannot use the same policer template as both a normal policer and a child policer.
• You cannot use the same base policer sengs as both a normal policer and an aggregate or
hierarchical policer.
• You cannot use the lter-specic statement at the [edit firewall policer
policer-name
] hierarchy level to
instanate an aggregate policer. Instead, the instanaon of the policer is performed by including the
aggregate statement at the [edit firewall policer
policer-name
] hierarchy level.
• All the child policers of a certain aggregate policer must contain the same denions of sengs or
aributes.
• All the policer instanaon formats are supported for the aggregate policer.
• Ingress two-level hierarchical policing is supported on all ACX routers.
• All the supported match condions for lters used with normal policers are supported with micro-
ow policers.
• You can congure up to 32 hierarchical policer instances. You can congure up to 32 child policers
per macro policer instance.
• You can congure hierarchical policers on aggregated Ethernet interfaces.
NOTE: Hierarchical policers is not applicable on ACX5048 and ACX5096 routers.
RELATED DOCUMENTATION
Hierarchical Policers on ACX Series Routers Overview | 1953
Hierarchical Policer Modes on ACX Series Routers | 1957
Processing of Hierarchical Policers on ACX Series Routers | 1962
Acons Performed for Hierarchical Policers on ACX Series Routers | 1963
Conguring Aggregate Parent and Child Policers on ACX Series Routers | 1966
1956
Hierarchical Policer Modes on ACX Series Routers
IN THIS SECTION
Guarantee Mode | 1957
Peak Mode | 1959
Hybrid Mode | 1960
The method in which the micro-ow policer determines and manages the share of the aggregate
bandwidth for the micro-ow is dened by the hierarchical policer mode. ACX routers support the
following three hierarchical policer modes. You can congure the mode or type of the policer for each
hierarchical policer instance.
NOTE: Hierarchical policer is not applicable on ACX5048 and ACX5096 routers.
Guarantee Mode
This mode, also called bandwidth-guarantee mode, is used when the micro-ow policer is used to
specify that a poron of the aggregate parent policer bandwidth is guaranteed for its micro-ow. When
this micro-ow contains no trac, then amount allocated for this micro-ow out of the aggregate
bandwidth is used by the other micro-ows that are transming trac with a size-limit or bandwidth
that is higher than their respecve guaranteed bandwidth rates.
Consider a sample scenario in which the maximum allowed rate or peak informaon rate (PIR) for a user
is 140 Mbps. A total of four services or applicaons called expedited forwarding (EF), Gold, Silver and
Bronze are dened for the guaranteed bandwidth mode of policer with a CIR of 50 Mbps, 40 Mbps, 30
Mbps, and 20 Mbps respecvely. For example, if 140 Mbps of trac is received for each of the four
services, then the permied trac rates are 50, 40, 30 and 20 Mbps respecvely. If 150 Mbps of Gold
trac is received, only 140 Mbps is permied for Gold trac.
All the child policers must be of single-rate, single-bucket, and two-color modes for bandwidth
guarantee mode of hiearchical policer. This combinaon of aributes is also called oor mode. The
micro-ow policer value species the minimum guaranteed bandwidth (CIR) for the micro-ow. The
macro-ow policer value species the maximum allowed bandwidth (PIR) for all the ows. The sum or
the cumulave value of all CIR values of the congured micro-ows must be less than or equal to the
macro-ow PIR. The burst size of macro-ow must be greater than the sum of the aggregate of the
1957
burst size of all the child policers and the largest MTU of the physical interface among all the physical
interfaces of the logical interfaces or interface families to which the child policers are aached.
Consider a sample conguraon that has two child policers aggregated by a parent PIR in bandwidth-
guarantee mode. PIRs for the children policers and the parent policer are congured. When two ows,
ow 1 and ow 2, transmit trac at a rate that exceeds the congured PIR values, then the share of the
parent PIR is adjusted to permit trac for the child policers based on their priories dened for the
ows, while the bandwidth is maintained.
Policers use a token bucket algorithm to enforce a limit on an average transmit or receive rate of trac
at an interface while allowing bursts of trac up to a maximum value based on the congured
bandwidth limit and congured burst size. The token bucket algorithm oers more exibility than a leaky
bucket algorithm in that you can allow a specied trac burst before starng to discard packets or apply
a penalty such as packet output-queuing priority or packet-drop priority. Following are the main
components of the token bucket algorithm:
• The bucket represents a rate-liming funcon of the policer on the interface input or output trac.
• Each token in the bucket represents a “credit” for some number of bits, and tokens in the bucket are
“cashed in” for the ability to receive or transmit trac that conforms to a rate limit congured for the
policer.
• The token arrival rate is a periodic allocaon of tokens into the token bucket that is calculated from
the congured bandwidth limit.
• The token bucket depth denes the capacity of the bucket in bytes. Tokens that are allocated aer
the bucket reaches capacity are not able to be stored and used.
An arriving packet complies with the bandwidth-guarantee mode if tokens are present in the peak burst
size (PBS) of either the parent policer or the commied burst size (CBS) of the child policer. If sucient
tokens are not present in the PBS or CBS of either of the parent or child policers respecvely, the packet
does not conform to the guarantee mode of the hierarchical policer working. In such a case, the child
policer rate is guaranteed for the member ows. The following table describes the dierent scenarios of
color-coding for micro-ow and macro-ow policers and the resultant color or priority that is assigned:
Micro-Color Macro-Color Result
Green Green Green
Green Red Green
Red Green Green
1958
(Connued)
Micro-Color Macro-Color Result
Red Red Red
Peak Mode
This mode, also called bandwidth-protecon mode, is used when the micro-ow policer is used to
specify the maximum amount of the aggregate parent policer bandwidth that the micro-ow can use.
This mode is used to protect a given micro-ow from starving the other ows. Even when the other
micro-ows contain no trac (the available aggregate bandwidth rate is greater than the rate of the
parcular micro-ow, the micro-ow cannot use more than the rate congured on its micro-ow policer.
Consider a sample scenario in which the total maximum allowed rate (PIR) for a user is 100 Mbps. A
total of four services or applicaons called expedited forwarding (EF), Gold, Silver and Bronze are
dened for the peak or bandwidth-restricon mode of the policer with PIR values of 50 Mbps, 40 Mbps,
30 Mbps, and 20 Mbps respecvely. Such a seng is used in topologies in which you want to prevent a
certain subscriber or user from ulizing an increased share ohe macro-ow or the parent CIR for real-
me applicaons, such as video-on-demand (VoD) or voice over IP (VoIP). For example, if only 100 Mbps
of EF packets are received, the permied bandwidth rate for the trac is 50 Mbps. When 100 Mbps of
trac is received for each of the four services, then the aggregate allowed trac is 100 Mbps, in which
the rates are as follows for the dierent services:
• Less than or equal to 50 Mbps for EF trac
• Less than or equal to 40 Mbps for Gold trac
• Less than or equal to 30 Mbps for Silver trac
• Less than or equal to 20 Mbps for Bronze trac
All the child policers must be of single-rate, single-bucket, and two-color types for bandwidth-protecon
or peak mode of the hierarchical policer. The micro-ow policer value species the maximum allowed
bandwidth (PIR) for the micro-ow. The macro-ow policer value species the maximum allowed
bandwidth (PIR) for all the ows. The sum of the PIR values of the micro-ows must be greater than or
equal to the PIR values of the child policers. The macro-ow burst-size must be greater than or equal to
that of the micro-ow with the largest burst-size.
Consider a sample conguraon that has two child policers aggregated by a parent PIR in bandwidth-
guarantee mode. PIRs for the children policers and the parent policer are congured. When two ows,
ow 1 and ow 2, transmit trac at a rate that exceeds the congured PIR values, then the share of the
1959
parent PIR is adjusted to permit trac for the child policers based on their priories dened for the
ows, while the bandwidth is restricted to maintain the minimum or commied rates of trac ows.
An arriving packet complies with the bandwidth-guarantee mode if tokens are present in the peak burst
size (PBS) of both the child policer and the parent policer. If sucient tokens are not present in the PBS
of both the policers, the packet does not conform to the peak mode of the hierarchical policer working.
In such a case, the child policer rate is the maximum allowed rate or PIR for the member ows. The
following table describes the dierent scenarios of color-coding for micro-ow and macro-ow policers
and the resultant color or priority that is assigned:
Micro-Color Macro-Color Result
Green Green Green
Green Red Red
Red Green Red
Red Red Red
Hybrid Mode
This mode, which is a combinaon of the bandwidth-guarantee and bandwidth-protecon modes,
enables the capabilies of bandwidth restricon and the per-ow bandwidth moderaon to be
accomplished simultanouesly. Bandwidth-guarentee or bandwidth-restricon mode controls the
guaranteed rates for a given micro-ow. However, it does not adminster or manage the manner in which
the excess aggregate bandwidth can be shared among the micro-ows. A certain micro-ow can
potenally use all the excess aggregate bandwidth starving the other micro-ows of any excess
bandwidth.
Bandwidth-protecon or peak mode controls the amount of bandwidth that a parcular micro-ow can
consume, thereby protecng other ows from being starved. However, it does not specify any
guaranteed rates for the micro-ows. For example, if micro-ow rates for ows f1, f2 and f3 are 50
Mbps, 60 Mbps, 50 Mbps respecvely, and the aggregate rate is 70 Mbps, it is possible that f1 and f2
ows might be provided 50 Mbps and 20 Mbps respecvely, with no bandwidth allocated for f3.
Hybrid mode implements the benets of the peak and guaranteed modes to overcome their individual
limitaons. In hybird mode, the micro-ow policer species two rates, CIR and EIR, for the micro-ow.
The CIR species the guaranteed poron out of the total macro-ow bandwidth for a micro-ow, and
the PIR species the maximum poron of the total macro-ow bandwidth for a micro-ow. This
1960
mechanism is analogues to CIR funconing in guarantee mode and EIR funconing in peak mode,
thereby combining the advantages of both models. In hyrbid mode, both color-aware and color-blind
modes are supported for child policers.
Child policers operate in compliance with the RFC 4115 mode of two-rate three color markers. Normal
two-rate three color markers on ACX routers operate in compliance with the RFC2698 mode.
Consider a sample conguraon in which the maximum allowed rate for a user is 140 Mbps. A total of
four services or applicaons called expedited forwarding (EF), Gold, Silver and Bronze are dened for the
hybrid mode of the policer with PIR values of 55Mbps, 60 Mbps, 130 Mbps, and 140 Mbps respecvely.
The dened CIR values are 50 Mbps, 40 Mbps, 30 Mbps, and 20 Mbps for EF, Gold, Silver, and Bronze
services respecvely. For example, when 140 Mbps of trac is received for each of the four services,
then the permied green-colored trac is 50, 40, 30 and 20 Mbps respecvely for the four services. If
only 140 Mbps of EF trac is received, 50 Mbps of EF trac as green and 5 Mbps of EF trac as yellow
are permied. In the same scenario, assume the macro-policer rate to be 26 Mbps. Also, assume two
child policers in color-aware mode, namely, child policer-1 with a CIR of 10 Mbps and an EIR of 10
Mbps. Child policer-2 has a CIR of 15 Mbps and an EIR of 5 Mbps. When ow-1 is a 100 Mbps stream
of yellow trac, and ow-2 is an 100 Mbps stream of green trac, the output of this policer hierarchy is
as follows:
• Flow-1 has 0 Mbps of green trac and has less than or equal to 5 Mbps of yellow trac.
• Flow-2 has 10 Mbps of green trac and has greater than or equal to 10 Mbps of yellow trac.
• The sum of yellow trac is less than or equal to 11 Mbps .
Consider a sample conguraon that has two child policers aggregated by a parent PIR in hybrid mode.
PIRs for the children policers and the parent policer are congured. When two ows, ow 1 and ow 2,
transmit trac at a rate that exceeds the congured PIR values, then the share of the parent PIR is
adjusted to permit trac for the child policers while the child PIR values are preserved for the two
ows.
Hybrid mode of working of the aggregate or hierarchical policer supports two rates (CIR and PIR) and
three colors for micro-ows. On ACX routers, for hybrid type of the policer, the micro-policer must be of
type modied-trtcm as dened in RFC 4115. Both color-blind and color- aware modes are supported for
child policers. Macro policer must be a single rate, single bucket, two color policer with the sum of the
CIR values of the micro-ows being less than the PIR value of the macro-ow, and the cumulave value
of all the PIR values of the micro-ows being greater than the PIR value of the macro-ow. When micro-
ow trac is less than the CIR value of the micro-ow CIR, the policer causes either the micro-ow CIR
to be maintained or PIR to be achieved. When micro-ow trac is greater than the CIR value of the
micro-ow, the micro-ow CIR is guaranteed. Micro-ow excess rates are shared based on the available
macro-ow bandwidth with the limitaon of the excess informaon rate distributed for the micro-ows
being implemented by the micro-ow PIR. The CBS of the macro-ow must be greater than or equal to
the aggregate of the micro-ow CBS. The excess burst size (EBS) of the macro-ow must be greater
than or equal to that of the micro-ow with the largest EBS.
1961
An arriving packet complies with the hybrid mode if tokens are present in the commied burst size (CBS)
of the child policer. The packet does not comply with hybrid mode if tokens are present in both the EBS
of the child policer and the PBS of the parent policer. When a packet does not sasfy the hybrid mode
of working of a policer, the CIR of the child policer is guaranteed for the member trac ows and the
PIR value of the child policer is the maximum permied rate for the member ows. The following table
describes the dierent scenarios of color-coding for micro-ow and macro-ow policers and the
resultant color or priority that is assigned:
Micro-Color Macro-Color Result
Green Green Green
Red Green Green
Yellow Green Yellow
Yellow Red Red
Red Green Red
Red Red Red
RELATED DOCUMENTATION
Hierarchical Policers on ACX Series Routers Overview | 1953
Guidelines for Conguring Hierarchical Policers on ACX Series Routers | 1955
Processing of Hierarchical Policers on ACX Series Routers | 1962
Acons Performed for Hierarchical Policers on ACX Series Routers | 1963
Conguring Aggregate Parent and Child Policers on ACX Series Routers | 1966
Processing of Hierarchical Policers on ACX Series Routers
Hierarchical policer provisions a controlled sharing of an aggregate among micro-ows. For example, a
hierarchical policer is used to share the bandwidth of a certain subscriber or user across dierent CoS
1962
sengs of that user. Assume that the user is congured to connect using a logical interface, and the CoS
funconality is congured using DiServ code point (DSCP) in the traversed packet. The user is assigned
an aggregate bandwidth of 140 Mbps. This consolidated bandwidth must be distributed and shared
amongst the four supported CoS sengs represented by DSCP values of 11, 12, 21, and 22 respecvely
in the order of 50 Mbps, 40 Mbps, 30 Mbps and 20 Mbps. To obtain this behavior, you must perform the
following conguraons:
• Congure micro-ows--A micro-ow is characterized by all packets that pass through the same micro
policer (or child policer) instance. To enable this conguraon, packets must be classied as micro-
ows by using lters to match the packets, and the acon of the lter to refer to the macro policer.
You can group and combine packets matching mulple dierent lters or terms into a single micro-
ow by specifying the same policer instance across the dierent lters and terms. These sengs are
idencal to the conguraon required to associate a single-level policer with a lter.
• Assign child policers to the aggregate policer--This step is addional, from the procedure to create a
single-level policer, to congure a hierarchical policer. You must link or associate the child policers to
the parent or aggregate policer. You can perform this linking by specifying at each child policer by
using the aggregate-policing
aggregate-policer-name
statement at the [edit firewall policer
policer-name
]
hierarchy level.
NOTE: Hierarchical policer is not applicable on ACX5048 and ACX5096 routers.
RELATED DOCUMENTATION
Hierarchical Policers on ACX Series Routers Overview | 1953
Guidelines for Conguring Hierarchical Policers on ACX Series Routers | 1955
Hierarchical Policer Modes on ACX Series Routers | 1957
Acons Performed for Hierarchical Policers on ACX Series Routers | 1963
Conguring Aggregate Parent and Child Policers on ACX Series Routers | 1966
Acons Performed for Hierarchical Policers on ACX Series Routers
IN THIS SECTION
Instanaon Methods for Child and Aggregate Policers | 1964
1963
Instanaon Methods for Child Policers or Normal Policers | 1964
Instanaon Methods for Aggregate Policers | 1965
The hierarchical parent policer impacts the packet loss priority (PLP) of the child policer. The PLP-based
acons dened in the then statement of the are performed, based on the PLP derived from the
combined processing of the child and parent policers. The then statement dened in the parent policer is
not eecve. This secon contains the following topics that describe the methods of instanaon of
aggregate or hierarchical policers and child or normal policers.
NOTE: Hierarchical policer is not applicable on ACX5048 and ACX5096 routers.
Instanaon Methods for Child and Aggregate Policers
In the Junos OS, a certain policer conguraon or a policer template is used to create mulple instances
of the policer in the hardware using the template aributes such as the CIR, PIR, CBS, and PBS values
specied in the template. You need not create mulple policer conguraons with the same aributes
for eecve management by using aggregate policers.
Instanaon Methods for Child Policers or Normal Policers
For a normal policer or a child policer, if you specify a lter-specic aribute for a policer by entering the
filter-specific statement at the [edit firewall policer policer-name] or [edit logical-systems logical-system-
name firewall policer policer-name] hierarchy level, when you specify a ‘lter-specic’ clause, a single
policer instance is used by all terms (within the same rewall lter) that reference the policer. For
example, if a lter F1 contains terms T1 and T2, they refer to the same policer, say P1. If you congure
the policer P1 as a lter-specic type, the same policer instance on the device is referred by both the
terms T1 and T2. In this case, F1 is aached to a logical interface named IFL1, which is congured on
the physical interface named IFD1.
By default, a policer operates in term-specic mode so that, for a given rewall lter, the Junos OS
creates a separate policer instance for every lter term that references the policer. This operaon is the
default instanaon mode if you do not congure the filter-specific statement. For example, consider a
lter F1 that has two terms, T1 and T2. Both these terms refer to the same policer, namely P1. With a
term-specic mode of the policer, two policer instances are created on the device, one each for terms
T1 and T2.
1964
Instanaon Methods for Aggregate Policers
The following modes of operaons are possible for aggregate policers.
• Global—Shares the same parent policer across all the child policer instances in the system.
• Physical interface-specic—Shares the same parent policer across all the child policer instances of a
certain physical interface. This mode is not supported on ACX routers.
• Filter-specic—Shares the same parent policer across all the child policer instances of the same lter.
This mode is not supported on ACX routers.
• Interface-specic—Shares the same parent policer across all the child policer instances of the same
logical interface. This mode is not supported on ACX routers.
You can include the aggregate global statement at the [edit firewall policer policer-template-name] hierarchy
level to dene an aggregate policer to be shared or applicable across all of the child policer instances in
the router. You can include the aggregate parent statement at the [edit rewall policer policer-template-
name] hierarchy level to dene an aggregate policer as the parent policer. The following statement does
not take eect for aggregate policers: set firewall policer
policer-template-name
filter-specific.
Consider a sample deployment in which an aggregate policer named P3 is congured. P1 and P2 are
child policers. T1, T2, T3, and T4 are terms. F1 and F2 are lters. Logical interfaces, IFL1 and IFL2, are
created on the underlying physical interfaces, IFD1 and IFD2 in this conguraon. Interface address
families are correspondingly created on the interfaces as IFF1 and IFF2.
If you congure an interface-specic lter, term-specic child policer, and the aggregate policer as the
global policer, a single instance of P3 is created and associated with the child policers, P1 and P2. Two
instances each of P1 and P2 are created, one for T1 within F1 and the other for T2 within F1. The two
instances each of P1 and P2 are associated with IFL1 and IFL2, which in turn are bound to IFD1 and
IFD2.
If you congure an interface-specic lter, term-specic or lter-specic child policer, and the aggregate
policer is physical interface- specic policer, two instances of P3 are created. One instance of P3
contains two child policer instances of P1. P1 contains the lter F1 and term T1 to be applied to IFL1
and IFL2. The other instance of P3 contains two child policer instances of P1. P1 contains F1 and T1 to
be applied to another two logical interfaces, IFL3 and IFL4.
If you congure an interface-specic lter, term-specic child policer, and interface-specic aggregate
policer, two instances of P3 are created. Each P3 instance contains two P1 instances. One P1 instance
contains F1 and T1 for IFF1 to be applied to IFL1. The other P1 instance contains F2 for IFF2 to be
applied to IFL1. The other P3 instance contains two P1 instances. Here, one P1 contains F1 and T1 for
IFF3 and the other P1 contains F2 and T1 for IFF4 to be applied on IFL2.
If you congure an interface-specic lter, term-specic child policer, and lter-specic aggregate
policer, two P3 instances are created. Each P3 contains two P1 instances. One P1 contains P1, T1, F1
1965
IFF1, applied to IFL1. The other P1 contains P1, T2, F1, IFF1, applied to IFL1. The third P1 contains P1,
T3, F2, IFF2, applied to IFL1. The last P1 contains P1, T4, F2, IFF2, applied to IFL1.
RELATED DOCUMENTATION
Hierarchical Policers on ACX Series Routers Overview | 1953
Guidelines for Conguring Hierarchical Policers on ACX Series Routers | 1955
Hierarchical Policer Modes on ACX Series Routers | 1957
Processing of Hierarchical Policers on ACX Series Routers | 1962
Conguring Aggregate Parent and Child Policers on ACX Series Routers | 1966
Conguring Aggregate Parent and Child Policers on ACX Series Routers
On ACX Series routers, two-level ingress hierarchical policing is supported. Single-level policers dene a
single bandwidth prole. You must rst dene the child or subordinate policers and associate or link
them with the aggregate parent policer, which is globally applicable for the enre system. You can
congure the mode of hierarchical or aggregate policing for the child policers, such as peak mode,
guarantee mode, or hybrid mode of policing.
NOTE: Hierarchical policer is not applicable on ACX5048, ACX5096, ACX7332, ACX7348,
ACX7059, ACX7024, ACX7024X, and ACX7100 routers.
NOTE: The hierarchical policing mechanism on ACX routers is dierent from the hierarching
policing capability supported on MX Series routers. On MX Series routers, with a hierarchical
policer, only one child or subordinate policer can be congured under a parent, top-level policer,
whereas on ACX Series routers, you can aggregate and specify mulple child policers under a
single parent policer under the [edit firewall] hierarchy level. The hierarchical policing
methodology on ACX routers is also called aggregate policing. The hierarchical-policer statement
and its substatements at the [edit firewall] hierarchy level that are supported on MX Series
routers are not available for ACX Series routers.
To congure child or micro policers for an aggregate parent policer and associate the parent policer with
the child policers:
1966
1. Congure one normal policer as a child policer and specify the aggregate policing mode.
user@host# set policer mi_pol_1 if-exceeding bandwidth-limit 25m
user@host# set policer mi_pol_1 if-exceeding burst-size-limit 3k
user@host# set policer mi_pol_1 if-exceeding aggregate-policing policer mi_pol_x aggregate-
sharing-mode peak;
user@host# set policer mi_pol_1 then discard
2. Congure another normal policer as a child policer and specify the aggregate policing mode. The
aggregate-sharing-mode opon is a Packet Forwarding Engine statement.
user@host# set policer mi_pol_2 if-exceeding bandwidth-limit 30m
user@host# set policer mi_pol_2 if-exceeding burst-size-limit 30k
user@host# set policer mi_pol_2 if-exceeding aggregate-policing policer mi_pol_x aggregate-
sharing-mode peak;
user@host# set policer mi_pol_2 then discard
3. Dene the aggregate parent policer as the global policer for the system. The aggregate-sharing-mode
opon is a Packet Forwarding Engine statement.
user@host# set policer mi_pol_x if-exceeding bandwidth-limit 55m
user@host# set policer mi_pol_x if-exceeding burst-size-limit 35k
user@host# set policer mi_pol_x aggregate global
4. Verify the sengs of all policer templates congured by using the show filter policer template
command.
user@host# show filter policer template
AppType Template name Bw limit-bits/sec Burst-bytes Action Options
------- ------------- ----------------- ----------- --------------
0 mi_pol_1
25000000 3000 DROP
Aggregate Child of mi_pol_x mode=2
0 mi_pol_2
30000000 30000 DROP
Aggregate Child of mi_pol_x mode=2
0 mi_pol_x
55000000 35000 DROP
Aggregate Parent
1967
5. View the congured policer instances that are linked to the aggregate parent policer by using the show
filter aggregate-policer command.
user@host# show filter aggregate-policer p1
CHILDREN
-------
#1) [UNI1_filtermi_pol_trtcm1-t2] CBS[1000]kB; CIR[10000]kbps; CBS[2000]kB; PIR[30000]kbps;
Agg mode = 3;
#2) [UNI2_filtermi_pol_trtcm2-t2] CBS[1000]kB; CIR[15000]kbps; CBS[2000]kB; PIR[35000]kbps;
Agg mode = 3;
PARENT
------
[p1] PBS[3000]kB; PIR[38000]kbps;
Sum child CIR[25000]kbps;CBS[2000]kB;
Sum child PIR[65000]kbps;PBS[4000]kB;
Max child CIR[15000]kbps;CBS[1000]kB;
Max child PIR[35000]kbps;PBS[2000]kB;
RESULTS
-------
STATUS = OK
The show filter policer template and show filter aggregate-policer CLI commands need to be run at the PFE
level. To go to the PFE level, you need to:
1. Enter the start shell CLI command.
user@host> start shell
2. Establish a vty session by entering the vty shell command followed by the executable name for the
component. For example, vty feb0.
user@host% vty feb0
1968
3. Type the show filter policer ... CLI command.
RELATED DOCUMENTATION
Hierarchical Policers on ACX Series Routers Overview | 1953
Guidelines for Conguring Hierarchical Policers on ACX Series Routers | 1955
Hierarchical Policer Modes on ACX Series Routers | 1957
Processing of Hierarchical Policers on ACX Series Routers | 1962
Acons Performed for Hierarchical Policers on ACX Series Routers | 1963
1969
CHAPTER 30
Conguring Policer Rate Limits and Acons
IN THIS CHAPTER
Policer Bandwidth and Burst-Size Limits | 1970
Policer Color-Marking and Acons | 1972
Single Token Bucket Algorithm | 1975
Dual Token Bucket Algorithms | 1978
Policer Bandwidth and Burst-Size Limits
Table 113 on page 1970 lists each of the Junos OS policer types supported. For each policer type, the
table summarizes the bandwidth limits and burst-size limits used to rate-limit trac.
Table 113: Policer Bandwidth Limits and Burst-Size Limits
Policer Type Bandwidth Limits Burst-Size Limits
Single-Rate Two-Color Policer
Denes a single rate limit: a bandwidth limit and
an allowed burst size for conforming trac.
For a single-rate two-color policer only, you can
specify the bandwidth limit as a percentage
value from 1 through 100 instead of as an
absolute number of bits per second. The
eecve bandwidth limit is calculated as a
percentage of either the physical interface
media rate or the logical interface congured
shaping rate.
bandwidth-limit
bps
;
M and T Series routers:
8000..100000000000
MX Series routers:
8000..184467440737095516
15
burst-size-limit
bytes
;
M, MX, and T Series routers:
1500..10000000000
bandwidth-percent
1..100 percent
1970
Table 113: Policer Bandwidth Limits and Burst-Size Limits
(Connued)
Policer Type Bandwidth Limits Burst-Size Limits
Single-Rate Three-Color Policer
Denes a single rate limit: a bandwidth limit and
an allowed burst size for conforming trac.
Also denes a second, larger burst size. This
second burst size is used to dierenate
between two categories of nonconforming
trac (yellow or red).
committed-information-rate
bps
;
M and T Series routers:
1500..100000000000
MX Series routers:
8000..184467440737095516
15
committed-burst-size
bytes
;
M, MX, and T Series routers:
1500..100000000000
excess-burst-size
bytes
;
M, MX, and T Series routers:
1500..100000000000
Two-Rate Three-Color Policer
Denes a commied rate limit: a bandwidth
limit and an allowed burst size for conforming
trac.
Also denes a peak rate limit: a second, larger
burst size and a second, higher bandwidth limit.
These addional rate-limit components are
used to dierenate between two categories of
nonconforming trac (yellow or red).
committed-information-rate
bps
;
M and T Series routers:
1500..100000000000
MX Series routers:
8000..184467440737095516
15
committed-burst-size
bytes
;
M, MX, and T Series routers:
1500..100000000000
peak-information-rate
bps
;
M and T Series routers:
1500..100000000000
MX Series routers:
8000..184467440737095516
15
peak-burst-size
bytes
;
M, MX, and T Series routers:
1500..100000000000
Hierarchical Policer
1971
Table 113: Policer Bandwidth Limits and Burst-Size Limits
(Connued)
Policer Type Bandwidth Limits Burst-Size Limits
Denes two policers, each with a bandwidth
limit and an allowed burst size for conforming
trac. Dierent policing acons are applied
based on whether the packets are classied for
expedited forwarding (EF) or for a lower
priority.
Rate-limits ingress Layer 2 trac at a SONET
physical or logical interface hosted on
supported roung plaorms only.
bandwidth-limit
bps
;
M40e, M120, and M320 (with
FFPC and SFPC) edge routers
and T320, T640, and T1600
core routers with Enhanced
Intelligent Queuing (IQE) PICs:
32000..50000000000
MX Series routers:
8000..184467440737095516
15
burst-size-limit
bytes
;
M40e, M120, and M320 (with
FFPC and SFPC) edge routers
and T320, T640, and T1600
core routers with Enhanced
Intelligent Queuing (IQE) PICs:
1500..2147450880
NOTE: On some plaorms such as EX2300, packets with smaller frame size create addional
headers which results in more trac. For calculang bandwidth of incoming trac, these
plaorms consider packet data and packet headers. The addional headers plus data can cause
the trac rate to exceed the congured policer bandwidth-limit and cause drops. So ensure to
take into consideraon this addional header trac when conguring policer bandwidth-limit
and burst-size-limit for such plaorms.
RELATED DOCUMENTATION
Policer Color-Marking and Acons | 1972
Determining Proper Burst Size for Trac Policers | 1912
Policer Color-Marking and Acons
Table 114 on page 1973 lists each of the Junos OS policer types supported. For each policer type, the
table summarizes the color-marking criteria used to categorize a trac ow and, for each color, the
acons taken on packets in that type of trac ow.
1972
Table 114: Implicit and Congurable Policer Acons Based on Color Marking
Policer Rate Limits and Color
Marking
Implicit Acon Congurable Acons
Single-Rate Two-Color Policer
• Bandwidth limit
• Burst size
Green
Conforms to rate and
burst size limits
Set PLP to low
–
Red
Exceeds rate and burst
size limits
–
• Discard the packet.
• Assign to a forwarding class.
• Set PLP to low or high.
On some plaorms, you can also set the PLP to
medium-low or medium-high.
Single-Rate Three-Color Policer
• Commied informaon rate (CIR)
• Commied burst size (CBS)
• Excess burst size (EBS)
Green
Conforms to the CIR and
CBS
Set PLP to low
–
Yellow
Exceeds the CIR and CBS
but
conforms to the EBS
Set PLP to medium-high
–
Red
Exceeds the EBS
Set PLP to high
• Discard the packet.
1973
Table 114: Implicit and Congurable Policer Acons Based on Color Marking
(Connued)
Policer Rate Limits and Color
Marking
Implicit Acon Congurable Acons
Two-Rate Three-Color Policer
• Commied informaon rate (CIR)
• Commied burst size (CBS)
• Peak informaon rate (PIR)
• Peak burst size (PBS)
Green
Conforms to the CIR and
CBS
Set PLP to low
–
Yellow
Exceeds the CIR and CBS,
but
conforms to the PIR
Set PLP to medium-high
–
Red
Exceeds the PIR and PBS
Set PLP to high
• Discard the packet.
Hierarchical Policer
Aggregate policer
• Bandwidth limit
• Burst size
Green
Conforms to rate limits
Set PLP to low
–
1974
Table 114: Implicit and Congurable Policer Acons Based on Color Marking
(Connued)
Policer Rate Limits and Color
Marking
Implicit Acon Congurable Acons
Red
Exceeds rate limits
–
• Discard the packet.
• Assign to a forwarding class.
• Set PLP to low or high.
On some plaorms, you can also set the PLP to
medium-low or medium-high.
Premium policer
• Bandwidth limit
• Burst size
Green
Conforms to rate limits
Set PLP to low
–
Red
Exceeds rate limits
–
• Discard the packet.
RELATED DOCUMENTATION
Policer Bandwidth and Burst-Size Limits | 1970
Determining Proper Burst Size for Trac Policers | 1912
Single Token Bucket Algorithm
IN THIS SECTION
Token Bucket Concepts | 1976
1975
Single Token Bucket Algorithm | 1976
Conformance Measurement for Two-Color Marking | 1977
Token Bucket Concepts
When you apply trac policing to the input or output trac at an interface, the rate limits and acons
specied in the policer conguraon are used to enforce a limit on the average throughput rate at the
interface while also allowing bursts of trac up to a maximum number of bytes based on the overall
trac load. Junos OS policers measure trac-ow conformance to a policing rate limit by using a
token bucket algorithm
. An algorithm based on a single token bucket allows burst of trac for short
periods, whereas an algorithm based dual token buckets allows more sustained bursts of trac.
Single Token Bucket Algorithm
A single-rate two-color policer limits trac throughput at an interface based on how the trac
conforms to rate-limit values specied in the policer conguraon. Similarly, a hierarchical policer limits
trac throughput at an interface based on how aggregate and premium trac subows conform to
aggregate and premium rate-limit values specied in the policer conguraon. For both two-color
policer types, packets in a conforming trac ow are categorized as
green
, and packets in a non-
conforming trac ow are categorized as
red
.
The single token bucket algorithm measures trac-ow conformance to a two-color policer rate limit as
follows:
• The token arrival rate represents the single
bandwidth limit
congured for the policer. You can
specify the bandwidth limit as an absolute number of bits per second by including the bandwidth-
limit
bps
statement. Alternavely, for single-rate two-color policers only, you can use the bandwidth-
percent
percentage
statement to specify the bandwidth limit as a percentage of either the physical
interface port speed or the congured
logical interface
shaping rate.
• The token bucket depth represents the single
burst size
congured for the policer. You specify the
burst size by including the burst-size-limit
bytes
statement.
• If the bucket is lled to capacity, arriving tokens “overow” the bucket and are lost.
When the bucket contains insucient tokens for receiving or transming the trac at the interface,
packets might be dropped or else re-marked with a lower forwarding class, a higher packet loss priority
(PLP) level, or both.
1976
Conformance Measurement for Two-Color Marking
In two-color-marking policing, a trac ow whose average arrival or departure rate does not exceed the
token arrival rate (bandwidth limit) is considered
conforming trac
. Packets in a conforming trac ow
(categorized as green trac) are implicitly marked with a packet loss priority (PLP) level of low and then
passed through the interface.
For a trac ow whose average arrival or departure rate exceeds the token arrival rate, conformance to
a two-color policer rate limit depends on the tokens in the bucket. If sucient tokens remain in the
bucket, the ow is considered conforming trac. If the bucket does not contain sucient tokens, the
ow is considered
non-conforming trac
. Packets in a non-conforming trac ow (categorized as red
trac) are handled according to policing acons. Depending on the conguraon of the two-color
policer, packets might be implicitly discarded; or the packets might be re-marked with a specied
forwarding class, a specied PLP, or both, and then passed through the interface.
NOTE: The number of tokens remaining in the bucket at any given me is a funcon of the token
bucket depth and the overall trac load.
The token bucket is inially lled to capacity, and so the policer allows an inial trac burst (back-to-
back trac at average rates that exceed the token arrival rate) up to the size of the token bucket depth.
During periods of relavely low trac (trac that arrives at or departs from the interface at average
rates below the token arrival rate), unused tokens accumulate in the bucket, but only up to the
congured token bucket depth.
RELATED DOCUMENTATION
Two-Color Policer Conguraon Overview | 2038
Hierarchical Policer Conguraon Overview | 1932
Policer Color-Marking and Acons | 1972
bandwidth-limit (Hierarchical Policer)
bandwidth-limit (Policer)
bandwidth-percent
burst-size-limit (Hierarchical Policer)
burst-size-limit (Policer)
1977
Dual Token Bucket Algorithms
IN THIS SECTION
Token Bucket Concepts | 1978
Guaranteed Bandwidth for Three-Color Marking | 1978
Nonconformance Measurement for Single-Rate Three-Color Marking | 1978
Nonconformance Measurement for Two-Rate Three-Color Marking | 1979
Token Bucket Concepts
When you apply trac policing to the input or output trac at an interface, the rate limits and acons
specied in the policer conguraon are used to enforce a limit on the average throughput rate at the
interface while also allowing bursts of trac up to a maximum number of bytes based on the overall
trac load. Junos OS policers measure trac-ow conformance to a policing rate limit by using a
token bucket algorithm
. An algorithm based on a single token bucket allows burst of trac for short
periods, whereas an algorithm based dual token buckets allows more sustained bursts of trac.
Guaranteed Bandwidth for Three-Color Marking
A commied informaon rate (CIR) denes the guaranteed bandwidth for trac arriving at or deparng
from the interface under normal line condions. A ow of trac at an average rate that conforms to the
CIR is categorized green, and packets in a green ow are implicitly marked with low packet loss priority
(PLP) and then passed through the interface. During periods of relavely low trac (trac that arrives at
or departs from the interface at average rates below the CIR), any unused bandwidth capacity
accumulates in the rst token bucket, but only up to a congured number of bytes. If any unused
bandwidth capacity overows the rst bucket, the excess accumulates in a second token bucket.
The commied burst size (CBS) denes the maximum number of bytes for which unused amounts of the
guaranteed bandwidth can be accumulated in the rst token bucket. A burst of trac at an average rate
that exceeds the CIR is also categorized as green provided that sucient unused bandwidth capacity is
available in the rst token bucket.
Nonconformance Measurement for Single-Rate Three-Color Marking
Single-rate three-color policer conguraons specify a second burst size—the excess burst size (EBS)—
that denes the maximum number of bytes for which the second token bucket can accumulate unused
bandwidth that overows from the rst bucket.
1978
A trac ow is categorized yellow if its average rate exceeds the CIR and the available bandwidth
capacity accumulated in the rst bucket if sucient unused bandwidth capacity is available in the
second token bucket. Packets in a yellow ow are implicitly marked with medium-high PLP and then passed
through the interface.
A trac ow is categorized red its average rate exceeds the CIR and the available bandwidth capacity
accumulated in the second bucket. Packets in a red ow are implicitly marked with high PLP and then
either passed through the interface or oponally discarded.
Nonconformance Measurement for Two-Rate Three-Color Marking
Two-rate three-color policer conguraons include a second rate limit—the peak-informaon-rate (PIR)
—that you set to the expected average data rate for trac arriving at or deparng from the interface
under peak condions.
Two-rate three-color policer conguraons also include a second burst size—the peak burst size (PBS)—
that denes the maximum number of bytes for which the second token bucket can accumulate unused
peak bandwidth capacity. During periods of relavely lile peak trac (trac that arrives at or departs
from the interface at average rates that exceed the PIR), any unused peak bandwidth capacity
accumulates in the second token bucket, but only up to the maximum number of bytes specied by the
PBS.
A trac ow is categorized yellow if it exceeds the CIR and the available commied bandwidth capacity
accumulated in the rst token bucket but conforms to the PIR. Packets in a yellow ow are implicitly
marked with medium-high PLP and then passed through the interface.
A trac ow is categorized red if it exceeds the PIR and the available peak bandwidth capacity
accumulated in the second token bucket. Packets in a red ow are implicitly marked with high PLP and
then either passed through the interface or oponally discarded.
RELATED DOCUMENTATION
Three-Color Policer Conguraon Overview | 2122
Policer Color-Marking and Acons | 1972
commied-burst-size
commied-informaon-rate
excess-burst-size
peak-burst-size
peak-informaon-rate
1979
CHAPTER 31
Conguring Layer 2 Policers
IN THIS CHAPTER
Hierarchical Policers | 1980
Conguring a Policer Overhead | 2005
Two-Color and Three-Color Policers at Layer 2 | 2007
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Conguring a Two-Color Layer 2 Policer for the Pseudowire | 2022
Conguring a Three-Color Layer 2 Policer for the Pseudowire | 2023
Applying the Policers to Dynamic Prole Interfaces | 2024
Aaching Dynamic Proles to Roung Instances | 2025
Using Variables for Layer 2 Trac Policing at the Pseudowire Overview | 2027
Conguring a Policer for the Complex Conguraon | 2027
Creang a Dynamic Prole for the Complex Conguraon | 2028
Aaching Dynamic Proles to Roung Instances for the Complex Conguraon | 2030
Verifying Layer 2 Trac Policers on VPLS Connecons | 2031
Understanding Policers on OVSDB-Managed Interfaces | 2032
Example: Applying a Policer to OVSDB-Managed Interfaces | 2033
Hierarchical Policers
IN THIS SECTION
Hierarchical Policer Overview | 1981
Example: Conguring a Hierarchical Policer | 1982
Example: Conguring a Hierarchical Policer for Subscriber Services Firewall (ACX7100-48L Devices) | 1991
1980
Hierarchical Policer Overview
IN THIS SECTION
Subscriber Services Firewall Policer (ACX7100-48L Devices) | 1982
You can use a hierarchical policer to rate-limit ingress Layer 2 trac at a physical or
logical interface
and
apply dierent policing acons based on whether the packets are classied for expedited forwarding
(EF) or for a lower priority.
Hierarchical policing is supported on M40E, M120, and M320 edge routers with incoming Flexible PIC
Concentrators (FPCs) as SFPC and outgoing FPCs as FFPC, and on MX Series, ACX7100-L, T320, T640,
and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs.
You can apply hierarchical policing to a logical interface.
A hierarchical policer conguraon denes two policers—one for EF trac only and another for non-EF
trac—that funcon in a hierarchical manner:
• Premium policer—You congure the premium policer with trac limits for high-priority EF trac
only: a guaranteed bandwidth and a corresponding burst-size limit. EF trac is categorized as
nonconforming when its average arrival rate exceeds the guaranteed bandwidth and its average
packet size exceeds the premium burst-size limit. For a premium policer, the only congurable acon
for nonconforming trac is to discard the packets.
• Aggregate policer—You congure the aggregate policer with an aggregate bandwidth (to
accommodate both high-priority EF trac up to the guaranteed bandwidth and normal-priority non-
EF trac) and a burst-size limit for non-EF trac only. Non-EF trac is categorized as
nonconforming when its average arrival rate exceeds the amount of aggregate bandwidth not
currently consumed by EF trac and its average packet size exceeds the burst-size limit dened in
the aggregate policer. For an aggregate policer, the congurable acons for nonconforming trac are
to discard the packets, assign a forwarding class, or assign a packet loss priority (PLP) level.
NOTE: You must congure the bandwidth limit of the premium policer at or below the
bandwidth limit of the aggregate policer. If the two bandwidth limits are equal, then non-EF
trac passes through the interface unrestricted only while no EF trac arrives at the interface.
EF trac is guaranteed the bandwidth specied as the premium bandwidth limit, while non-EF trac is
rate-limited to the amount of aggregate bandwidth not currently consumed by the EF trac. Non-EF
trac is rate-limited to the enre aggregate bandwidth only while no EF trac is present.
1981
For example, suppose that you congure a hierarchical policer with the following components:
• Premium policer with bandwidth limit set to 2 Mbps, burst-size limit set to 3000 bytes, and
nonconforming acon set to discard packets.
• Aggregate policer with bandwidth limit set to 10 Mbps, burst-size limit set to 3000 bytes, and
nonconforming acon set to discard packets.
EF trac is guaranteed a bandwidth of 2 Mbps. Bursts of EF trac—EF trac that arrives at the
interface at rates above 2 Mbps—can also pass through the interface provided sucient tokens are
available in the 3000-byte bucket. When no tokens are available for a burst of non-EF trac, packets
are rate-limited using policing acons for the premium policer.
Non-EF trac is metered to a bandwidth limit that ranges between 8 Mbps and 10 Mbps, depending on
the average arrival rate of the EF trac. Bursts of non-EF trac—non-EF trac that arrives at the
interface at rates above the current limit for non-EF trac—also pass through the interface provided
sucient tokens are available in the 3000-byte bucket. When non-EF trac exceeds the currently
allowed bandwidth or when no tokens are available for a burst of non-EF trac, packets are rate-limited
using policing acons for the aggregate policer.
Subscriber Services Firewall Policer (ACX7100-48L Devices)
• Starng Junos Evolved release 23.4R1, you can congure the hierarchical policer on DHCP and
PPPoE access models at subscriber interfaces, that is acvated during subscriber login or CoA. This
feature supports colour coded trac policing according to the colour classicaon of a packet. The
packet colour is classied with packet matching criteria specied for two user-dened trac classes.
See the No Link Title secon for related conguraon examples and limitaons of the feature.
SEE ALSO
Hierarchical Policer Conguraon Overview | 1932
Example: Conguring a Hierarchical Policer
No Link Title
Example: Conguring a Hierarchical Policer
IN THIS SECTION
Requirements | 1983
Overview | 1983
1982
Conguraon | 1984
Vericaon | 1990
This example shows how to congure a hierarchical policer and apply the policer to ingress Layer 2
trac at a logical interface on a supported plaorm.
Requirements
Before you begin, be sure that your environment meets the following requirements:
• The interface on which you apply the hierarchical policer is a SONET interface hosted on one of the
following roung plaorms:
• M40e, M120, or M320 edge router with incoming FPCs as SFPC and outgoing FPCs as FFPC.
• MX Series, T320, T640, or T1600 core router with Enhanced Intelligent Queuing (IQE) PICs.
• No other policer is applied to the input of the interface on which you apply the hierarchical policer.
• You are aware that, if you apply the hierarchical policer to logical interface on which an input lter is
also applied, the policer is executed rst.
Overview
IN THIS SECTION
Topology | 1983
In this example, you congure a hierarchical policer and apply the policer to ingress Layer 2 trac at a
logical interface.
Topology
You apply the policer to the SONET logical interface so-1/0/0.0, which you congure for IPv4 and VPLS
trac. When you apply the hierarchical policer to that logical interface, both IPv4 and VPLS trac is
hierarchically rate-limited.
1983
You also congure the logical interface so-1/0/0.1 for MPLS trac. If you choose to apply the hierarchical
policer to physical interface so-1/0/0, hierarchical policing would apply to IPv4 and VPLS trac at
so-1/0/0.0 and to MPLS trac at so-1/0/0.1.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 1984
Dening the Interfaces | 1985
Dening the Forwarding Classes | 1986
Conguring the Hierarchical Policer | 1987
Applying the Hierarchical Policer to Layer 2 Ingress Trac at a Physical or Logical Interface | 1988
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces so-1/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces so-1/0/0 unit 0 family vpls
set interfaces so-1/0/0 unit 1 family mpls
set class-of-service forwarding-classes class fc0 queue-num 0 priority high policing-priority
premium
set class-of-service forwarding-classes class fc1 queue-num 1 priority low policing-priority
normal
set class-of-service forwarding-classes class fc2 queue-num 2 priority low policing-priority
normal
set class-of-service forwarding-classes class fc3 queue-num 3 priority low policing-priority
normal
set firewall hierarchical-policer policer1 aggregate if-exceeding bandwidth-limit 300m burst-
size-limit 30k
set firewall hierarchical-policer policer1 aggregate then forwarding-class fc1
1984
set firewall hierarchical-policer policer1 premium if-exceeding bandwidth-limit 100m burst-size-
limit 50k
set firewall hierarchical-policer policer1 premium then discard
set interfaces so-1/0/0 unit 0 layer2-policer input-hierarchical-policer policer1
Dening the Interfaces
Step-by-Step Procedure
To dene the interfaces:
1. Enable conguraon of the physical interface.
[edit]
user@host# edit interfaces so-1/0/0
2. Congure logical unit 0.
[edit interfaces so-1/0/0]
user@host# set unit 0 family inet address 192.168.1.1/24
user@host# set unit 0 family vpls
If you apply a Layer 2 policer to this logical interface, you must congure at least one protocol family.
3. Congure logical unit 1.
[edit interfaces so-1/0/0]
user@host# set unit 1 family mpls
Results
Conrm the conguraon of the interfaces by entering the show interfaces conguraon command. If the
command output does not display the intended conguraon, repeat the instrucons in this procedure
to correct the conguraon.
[edit]
user@host# show interfaces
so-1/0/0 {
unit 0 {
1985
family inet {
address 192.168.1.1/24;
}
family vpls;
}
unit 1 {
family mpls;
}
}
Dening the Forwarding Classes
Step-by-Step Procedure
To dene the forwarding classes referenced as aggregate policer acons:
1. Enable conguraon of the forwarding classes.
[edit]
user@host# edit class-of-service forwarding-classes
2. Dene the forwarding classes.
[edit class-of-service forwarding-classes]
user@host# set class fc0 queue-num 0 priority high policing-priority premium
user@host# set class fc1 queue-num 1 priority low policing-priority normal
user@host# set class fc2 queue-num 2 priority low policing-priority normal
user@host# set class fc3 queue-num 3 priority low policing-priority normal
Results
Conrm the conguraon of the forwarding classes referenced as aggregate policer acons by entering
the show class-of-service conguraon command. If the command output does not display the intended
conguraon, repeat the instrucons in this procedure to correct the conguraon.
[edit]
user@host# show class-of-service
forwarding-classes {
class fc0 queue-num 0 priority high policing-priority premium;
1986
class fc1 queue-num 1 priority low policing-priority normal;
class fc2 queue-num 2 priority low policing-priority normal;
class fc3 queue-num 3 priority low policing-priority normal;
}
Conguring the Hierarchical Policer
Step-by-Step Procedure
To congure a hierarchical policer:
1. Enable conguraon of the hierarchical policer.
[edit]
user@host# edit firewall hierarchical-policer policer1
2. Congure the aggregate policer.
[edit firewall hierarchical-policer policer1]
user@host# set aggregate if-exceeding bandwidth-limit 300m burst-size-limit 30k
user@host# set aggregate then forwarding-class fc1
For the aggregate policer, the congurable acons for a packet in a nonconforming ow are to
discard the packet, change the loss priority, or change the forwarding class.
3. Congure the premium policer.
[edit firewall hierarchical-policer policer1]
user@host# set premium if-exceeding bandwidth-limit 100m burst-size-limit 50k
user@host# set premium then discard
The bandwidth limit for the premium policer must not be greater than that of the aggregate policer.
For the premium policer, the only congurable acon for a packet in a nonconforming trac ow is
to discard the packet.
1987
Results
Conrm the conguraon of the hierarchical policer by entering the show firewall conguraon
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
hierarchical-policer policer1 {
aggregate {
if-exceeding {
bandwidth-limit 300m;
burst-size-limit 30k;
}
then {
forwarding-class fc1;
}
}
premium {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 50k;
}
then {
discard;
}
}
}
Applying the Hierarchical Policer to Layer 2 Ingress Trac at a Physical or Logical Interface
Step-by-Step Procedure
To hierarchically rate-limit Layer 2 ingress trac for IPv4 and VPLS trac only on logical interface
so-1/0/0.0, reference the policer from the logical interface conguraon:
1. Enable conguraon of the logical interface.
[edit]
user@host# edit interfaces so-1/0/0 unit 0
1988
When you apply a policer to Layer 2 trac at a logical interface, you must dene at least one
protocol family for the logical interface.
2. Apply the policer to the logical interface.
[edit]
user@host# set layer2-policer input-hierarchical-policer policer1
Alternavely, to hierarchically rate-limit Layer 2 ingress trac for all protocol families and for
all
logical interfaces
congured on physical interface so-1/0/0, you could reference the policer from the
physical interface conguraon.
Results
Conrm the conguraon of the hierarchical policer by entering the show interfaces conguraon
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
so-1/0/0 {
unit 0 {
layer2-policer {
input-hierarchical-policer policer1;
}
family inet {
address 192.168.1.1/24;
}
family vpls;
}
unit 1 {
family mpls;
}
}
If you are done conguring the device, enter commit from conguraon mode.
1989
Vericaon
IN THIS SECTION
Displaying Trac Stascs and Policers for the Logical Interface | 1990
Displaying Stascs for the Policer | 1990
Conrm that the conguraon is working properly.
Displaying Trac Stascs and Policers for the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show interfaces operaonal mode command for logical interface so-1/0/0.0, and include the detail
or extensive opon. The command output secon for Trac stascs lists the number of bytes and
packets received and transmied on the logical interface, and the Protocol inet secon contains a
Policer eld that would list the policer policer1 as an input or output policer as follows:
• Input: policer1-so-1/0/0.0-inet-i
• Output: policer1-so-1/0/0.0-inet-o
In this example, the policer is applied to logical interface trac in the input direcon only.
Displaying Stascs for the Policer
Purpose
Verify the number of packets evaluated by the policer.
Acon
Use the show policer operaonal mode command and oponally specify the name of the policer. The
command output displays the number of packets evaluated by each congured policer (or the specied
1990
policer), in each direcon. For the policer policer1, the input and output policer names are displayed as
follows:
• policer1-so-1/0/0.0-inet-i
• policer1-so-1/0/0.0-inet-o
The -inet-i sux denotes a policer applied to IPv4 input trac, while the -inet-o sux denotes a policer
applied to IPv4 output trac. In this example, the policer is applied to input trac only.
SEE ALSO
Hierarchical Policer Conguraon Overview | 1932
Hierarchical Policer Overview
Example: Conguring a Hierarchical Policer for Subscriber Services Firewall
(ACX7100-48L Devices)
IN THIS SECTION
Overview | 1991
Conguraon Scenarios | 1992
This example shows how to congure a hierarchical policer and apply the policer to ingress trac at a
subscriber interface on a supported plaorm (ACX7100-48L).
Overview
Starng Junos Evolved release 23.4R1, you can congure hierarchical policers and apply the policers to
ingress trac at a subscriber interface. This feature is supported on ACX7100-48L devices.
NOTE:
• The subscriber services hierarchical policer has the following limitaons:
1991
• You can congure only four levels of hierarchical policers with each level having aggregate
and premium conguraon.
• Logical interface policers and aggregate policers are not supported for subscriber services.
• Policing priority set inside forwarding class is not supported. For example:
class-of-service
{
forwarding-classes
{
class BestEffort queue-num 0 priority low policing-priority normal;
}
}
• next term is allowed only for hierarchical policers and not for lters.
• Aaching policers directly to an interface or family is not supported. Policers are
supported only through rewall lter acon.
• Policer acon forwarding-class is not supported in ingress and egress. loss-priority high
acon is supported in ingress. Only discard acon is supported in egress.
• A single policy cannot have loss-priority and policer acons congured. Only one of both
acons are supported at any given me.
• filter-specific opon is not supported in policer conguraon.
• Hierarchical policers and tri-color policers are not supported in the Egress direcon.
• Filter terms chaining feature is not available.
• Tri-color policer and hierarchical policers are not supported in Egress direcon.
Conguraon Scenarios
IN THIS SECTION
Single Rate Two Color Marking Policer Conguraon | 1993
Single Rate Tri Color Marking Policer Conguraon | 1993
Two Rate Tri Color Marking Policer | 1997
1992
Hierarchical Policer for DHCP and PPPoE | 1999
The following secon provides the dierent conguraons for various hierarchical policer opons:
Single Rate Two Color Marking Policer Conguraon
Single Rate Tri Color Marking Policer Conguraon
You can congure single rate two color marking policer on DHCP and PPPoE access models. The
conguraon is acvated during subscriber login or CoA. View the conguraon by entering the show
dynamic-profiles pppoe-client-policer-1-profile command. A sample conguraon is as follows:
[edit]
root@bng-controller# show dynamic-profiles pppoe-client-policer-1-profile
variables {
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
1993
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
firewall
{
family inet
{
filter "$downstream-inet"
{
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-in";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
}
policer "$HPolicer-in" {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
1994
}
then discard;
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
}
You can congure single rate tri-color marking policer on DHCP and PPPoE access models. It is acvated
during subscriber login or CoA. View the conguraon by entering the show dynamic-profiles pppoe-client-
policer-1-profile command. A sample conguraon is as follows:
[edit]
user@bng-controller# show dynamic-profiles pppoe-client-policer-2-profile | no-more
variables
{
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
}
interfaces
{
pp0
{
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options
{
chap;
pap;
}
pppoe-options
{
underlying-interface "$junos-underlying-interface";
server;
}
1995
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
firewall {
family inet {
filter "$downstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
three-color-policer {
single-rate "$HPolicer-in";
}
count three-color-policer-count;
accept;
}
}
1996
}
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
three-color-policer "$HPolicer-in" {
action {
loss-priority high then discard;
}
single-rate {
color-blind;
committed-information-rate 5m;
committed-burst-size 5k;
excess-burst-size 15k;
}
}
}
Two Rate Tri Color Marking Policer
You can congure two rate tri color marking policer on DHCP and PPPoE access models. It is acvated
during subscriber login or CoA.
In this secon you can see a sample dynamic prole conguraon on controller point. Contents of
dynamic prole are propagated forward during subscriber login for a client prole or during service
acvaon for a service prole. View the conguraon by entering the show dynamic-profiles pppoe-client-
policer-1-profile command. A sample conguraon is as follows:
[edit]
root@bng-controller# show dynamic-profiles pppoe-client-policer-3-profile | no-more
variables {
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
}
1997
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
firewall {
family inet {
filter "$downstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
1998
term t1 {
from {
source-port 80;
}
then {
three-color-policer {
two-rate "$HPolicer-in";
}
count three-color-policer-count;
accept;
}
}
}
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
three-color-policer "$HPolicer-in" {
action {
loss-priority high then discard;
}
two-rate {
color-blind;
committed-information-rate 5m;
committed-burst-size 5k;
peak-information-rate 10m;
peak-burst-size 10k;
}
}
}
Hierarchical Policer for DHCP and PPPoE
In this secon you can see a sample dynamic prole conguraon at the controller point on DHCP and
PPPoE access models. Contents of dynamic prole are propagated forward during subscriber login for a
1999
client prole or during service acvaon for a service prole. View the conguraon by entering the show
dynamic-profiles pppoe-client-policer-1-profile command. A sample conguraon is as follows:
[edit]
user@host# show dynamic-profiles pppoe-client-policer-4-profile
variables {
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
P0-IN uid;
P1-IN uid;
P2-IN uid;
Session-IN uid;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
2000
firewall {
family inet {
filter "$downstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
term P0-Aggregate {
from {
dscp 46;
}
then {
hierarchical-policer "$P0-IN";
next term;
}
}
term P1-Premium {
from {
dscp [ 46 22 ];
}
then {
force-premium;
next term;
}
}
term P1-Aggregate {
from {
dscp [ 46 22 ];
}
then {
hierarchical-policer "$P1-IN";
next term;
}
}
2001
term P2-Premium {
from {
dscp [ 46 22 56 ];
}
then {
force-premium;
next term;
}
}
term P2-Aggregate {
from {
dscp [ 46 22 56 ];
}
then {
hierarchical-policer "$P2-IN";
next term;
}
}
term final-Premium {
from {
dscp [ 46 22 56 00 ];
}
then {
force-premium;
next term;
}
}
term final {
then {
hierarchical-policer "$Session-IN";
accept;
}
}
}
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
hierarchical-policer "$HPolicer-in" {
2002
aggregate {
if-exceeding {
bandwidth-limit 30m;
burst-size-limit 30k;
}
then {
loss-priority high;
}
}
premium {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then {
discard;
}
}
}
hierarchical-policer "$P0-IN" {
logical-interface-policer;
aggregate {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
hierarchical-policer "$P1-IN" {
logical-interface-policer;
aggregate {
2003
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
hierarchical-policer "$P2-IN" {
logical-interface-policer;
aggregate {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
hierarchical-policer "$Session-IN" {
logical-interface-policer;
aggregate {
if-exceeding {
2004
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
SEE ALSO
Hierarchical Policer Conguraon Overview | 1932
Hierarchical Policer Overview
RELATED DOCUMENTATION
Hierarchical Policer Conguraon Overview | 1932
Guidelines for Applying Trac Policers | 1938
Conguring a Policer Overhead
Conguring a policer overhead allows you to control the rate of trac sent or received on an interface.
When you congure a policer overhead, the congured policer overhead value (bytes) is added to the
length of the nal Ethernet frame. This calculated length of frame is used to determine the policer or the
rate limit acon. Therefore, the policer overhead enables you to control the rate of trac sent or
received on an interface. You can congure the policer overhead to rate-limit queues and Layer 2 and
2005
MAC policers. The policer overhead and the shaping overhead can be congured simultaneously on an
interface.
This feature is supported on M Series and T Series routers with IQ2 PICs or IQ2E PICs, and on MX
Series DPCs.
To congure a policer overhead for controlling the rate of trac sent or received on an interface:
1. In the [edit chassis] hierarchy level in conguraon mode, create the interface on which to add the
policer overhead to input or output trac.
[edit chassis]
user@host# edit fpc
fpc
pic
pic
For example:
[edit chassis]
user@host# edit fpc 0 pic 1
2. Congure the policer overhead to control the input or output trac on the interface. You could use
either statement or both the statements for this conguraon.
[edit chassis fpc
fpc
pic
pic
]
user@host# set ingress-policer-overhead
bytes
;
user@host# set egress-policer-overhead
bytes
;
For example:
[edit chassis fpc 0 pic 1]
user@host# set ingress-policer-overhead 10;
user@host# set egress-policer-overhead 20;
3. Verify the conguraon:
[edit chassis]
user@host# show
fpc 0 {
pic 1 {
ingress-policer-overhead 10;
egress-policer-overhead 20;
2006
}
}
NOTE: When the conguraon for the policer overhead bytes on a PIC is changed, the PIC goes
oine and then comes back online. In addion, the conguraon in the CLI is on a per-PIC basis
and, therefore, applies to all the ports on the PIC.
RELATED DOCUMENTATION
egress-policer-overhead
ingress-policer-overhead
Two-Color and Three-Color Policers at Layer 2
IN THIS SECTION
Two-Color Policing at Layer 2 Overview | 2007
Three-Color Policing at Layer 2 Overview | 2009
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer | 2012
Two-Color Policing at Layer 2 Overview
IN THIS SECTION
Guidelines for Conguring Two-Color Policing of Layer 2 Trac | 2008
Statement Hierarchy for Conguring a Two-Color Policer for Layer 2 Trac | 2008
Statement Hierarchy for Applying a Two-Color Policer to Layer 2 Trac | 2009
2007
Guidelines for Conguring Two-Color Policing of Layer 2 Trac
The following guidelines apply to two-color policing of Layer 2 trac:
• You can apply a two-color policer to ingress or egress Layer 2 trac at a
logical interface
hosted on a
Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) only.
• A single logical interface supports Layer 2 policing in both direcons.
• You can apply a two-color policer to Layer 2 trac as a logical interface policer only. You cannot
apply a two-color policer to Layer 2 trac as a stateless
rewall lter
acon.
• You can apply a two-color policer to Layer 2 trac by referencing the policer in the interface
conguraon at the logical unit level, and not at the protocol level.
For informaon about conguring three-color policing of Layer 2 trac, see Three-Color Policing at
Layer 2 Overview.
Statement Hierarchy for Conguring a Two-Color Policer for Layer 2 Trac
To enable a single-rate two-color policer to rate-limit Layer 2 trac, include the logical-interface-policer
statement in the policer conguraon.
firewall {
policer
policer-name
{
logical-interface-policer;
if-exceeding {
(bandwidth-limit
bps
| bandwidth-percent
percentage
);
burst-size-limit
bytes
;
}
then {
discard;
forwarding-class
class-name
;
loss-priority (high | low | medium-high | medium-low);
}
}
}
You can include the conguraon at the following hierarchy levels:
• [edit]
•
[edit logical-systems
logical-system-name
]
2008
Statement Hierarchy for Applying a Two-Color Policer to Layer 2 Trac
To apply a logical interface policer to Layer 2 trac, include the layer2-policer input-policer
policer-name
statement or the layer2-policer output-policer
policer-name
statement to a supported logical interface. Use
the input-policer or output-policer statements to apply a two-color policer at Layer 2.
interfaces {
(ge-
fpc/pic/port
| xe-
fpc/pic/port
) {
unit
unit-number
{
layer2-policer {
input-policer
policer-name
;
output-policer
policer-name
;
}
}
}
}
You can include the conguraon at the following hierarchy levels:
• [edit]
• [edit logical-systems
logical-system-name
]
SEE ALSO
logical-interface-policer
Example: Conguring a Two-Color Logical Interface (Aggregate) Policer
Three-Color Policing at Layer 2 Overview
IN THIS SECTION
Guidelines for Conguring Three-Color Policing of Layer 2 Trac | 2010
Statement Hierarchy for Conguring a Three-Color Policer for Layer 2 Trac | 2010
Statement Hierarchy for Applying a Three-Color Policer to Layer 2 Trac | 2011
2009
Guidelines for Conguring Three-Color Policing of Layer 2 Trac
The following guidelines apply to three-color policing of Layer 2 trac:
• You can apply a three-color policer to Layer 2 trac at a
logical interface
hosted on a Gigabit
Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) only.
• A single logical interface supports Layer 2 policing in both direcons.
• You can apply a three-color policer to Layer 2 trac as a logical interface policer only. You cannot
apply a two-color policer to Layer 2 trac as a stateless
rewall lter
acon.
• You can apply a three-color policer to Layer 2 trac by referencing the policer in the interface
conguraon at the logical unit level, and not at the protocol level.
• You can apply a color-aware three-color policer to Layer 2 trac in the egress direcon only, but you
apply a color-blind three-color policer to Layer 2 trac in either direcon.
For informaon about conguring two-color policing of Layer 2 trac, see Two-Color Policing at Layer 2
Overview.
Statement Hierarchy for Conguring a Three-Color Policer for Layer 2 Trac
To enable a single-rate or two-rate three-color policer to rate-limit Layer 2 trac, include the logical-
interface-policer statement in the three-color-policer conguraon.
firewall {
three-color-policer
policer-name
{
action {
loss-priority high then discard;
}
logical-interface-policer;
single-rate {
(color-aware | color-blind);
committed-burst-size
bytes
;
committed-information-rate
bps
;
excess-burst-size
bytes
;
}
two-rate {
(color-aware | color-blind);
committed-burst-size
bytes
;
committed-information-rate
bps
;
peak-burst-size
bytes
;
peak-information-rate
bps
;
2010
}
}
}
You can include the conguraon at the following hierarchy levels:
• [edit]
• [edit logical-systems
logical-system-name
]
Statement Hierarchy for Applying a Three-Color Policer to Layer 2 Trac
To apply a logical interface policer to Layer 2 trac, include the layer2-policer statement for a supported
logical interface at the logical unit level. Use the input-three-color
policer-name
statement or output-three-
color
policer-name
statement to specify the direcon of the trac to be policed.
interfaces {
(ge-
fpc/pic/port
| xe-
fpc/pic/port
) {
unit
unit-number
{
layer2-policer {
input-three-color
policer-name
;
output-three-color
policer-name
;
}
}
}
}
You can include the conguraon at the following hierarchy levels:
• [edit]
• [edit logical-systems
logical-system-name
]
SEE ALSO
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer
layer2-policer
logical-interface-policer
three-color-policer (Conguring)
2011
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer
IN THIS SECTION
Requirements | 2012
Overview | 2012
Conguraon | 2013
Vericaon | 2019
This example shows how to congure a two-rate three-color color-blind policer as a logical interface
(aggregate) policer and apply the policer directly to Layer 2 input trac at a supported logical interface.
Requirements
Before you begin, make sure that the logical interface to which you apply the three-color logical
interface policer is hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) on
an MX Series router.
Overview
IN THIS SECTION
Topology | 2013
A two-rate three-color policer meters a trac ow against a bandwidth limit and burst-size limit for
guaranteed trac, plus a second set of bandwidth and burst-size limits for peak trac. Trac that
conforms to the limits for guaranteed trac is categorized as green, and nonconforming trac falls into
one of two categories:
• Nonconforming trac that does not exceed the bandwidth and burst-size limits for peak trac is
categorized as yellow.
• Nonconforming trac that exceeds the bandwidth and burst-size limits for peak trac is categorized
as red.
2012
A logical interface policer denes trac rate-liming rules that you can apply to mulple protocol
families on the same logical interface without creang mulple instances of the policer.
NOTE: You apply a logical interface policer directly to a logical interface at the logical unit level,
and not by referencing the policer in a stateless rewall lter and then applying the lter to the
logical interface at the protocol family level.
Topology
In this example, you congure the two-rate three-color policer trTCM2-cb as a color-blind logical interface
policer and apply the policer to incoming Layer 2 trac on logical interface ge-1/3/1.0.
NOTE: When using a three-color policer to rate-limit Layer 2 trac, color-aware policing can be
applied to egress trac only.
The policer denes guaranteed trac rate limits such that trac that conforms to the bandwidth limit of
40 Mbps with a 100 KB allowance for trac bursng (based on the token-bucket formula) is categorized
as green. As with any policed trac, the packets in a green ow are implicitly set to a low loss priority
and then transmied.
Nonconforming trac that falls within the peak trac limits of a 60 Mbps bandwidth limit and a 200 KB
allowance for trac bursng (based on the token-bucket formula) is categorized as yellow. The packets
in a yellow trac ow are implicitly set to a medium-high loss priority and then transmied.
Nonconforming trac that exceeds the peak trac limits are categorized as red. The packets in a red
trac ow are implicitly set to a high loss priority. In this example, the oponal policer acon for red
trac (loss-priority high then discard) is congured, so packets in a red trac ow are discarded instead
of transmied.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2014
Conguring the Logical Interfaces | 2014
Conguring the Two-Rate Three-Color Policer as a Logical Interface Policer | 2016
Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface | 2018
2013
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-1/3/1 vlan-tagging
set interfaces ge-1/3/1 unit 0 vlan-id 100
set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30
set interfaces ge-1/3/1 unit 1 vlan-id 101
set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac
00:00:11:22:33:44
set firewall three-color-policer trTCM2-cb logical-interface-policer
set firewall three-color-policer trTCM2-cb two-rate color-blind
set firewall three-color-policer trTCM2-cb two-rate committed-information-rate 40m
set firewall three-color-policer trTCM2-cb two-rate committed-burst-size 100k
set firewall three-color-policer trTCM2-cb two-rate peak-information-rate 60m
set firewall three-color-policer trTCM2-cb two-rate peak-burst-size 200k
set firewall three-color-policer trTCM2-cb action loss-priority high then discard
set interfaces ge-1/3/1 unit 0 layer2-policer input-three-color trTCM2-cb
Conguring the Logical Interfaces
Step-by-Step Procedure
To congure the logical interfaces:
1. Enable conguraon of the interface.
[edit]
user@host# edit interfaces ge-1/3/1
2014
2. Congure single tagging.
[edit interfaces ge-1/3/1]
user@host# set vlan-tagging
3. Congure logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1]
user@host# set unit 0 vlan-id 100
user@host# set unit 0 family inet address 10.10.10.1/30
4. Congure logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1]
user@host# set unit 1 vlan-id 101
user@host# set unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44
Results
Conrm the conguraon of the logical interfaces by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 10.10.10.1/30;
}
}
unit 1 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
2015
}
}
}
}
Conguring the Two-Rate Three-Color Policer as a Logical Interface Policer
Step-by-Step Procedure
To congure the two-rate three-color policer as a logical interface policer:
1. Enable conguraon of a three-color policer.
[edit]
user@host# edit firewall three-color-policer trTCM2-cb
2. Specify that the policer is a logical interface (aggregate) policer.
[edit firewall three-color-policer trTCM2-cb]
user@host# set logical-interface-policer
A logical interface policer rate-limits trac based on a percentage of the media rate of the physical
interface underlying the logical interface to which the policer is applied, and the policer is applied
directly to the interface rather than referenced by a rewall lter.
3. Specify that the policer is two-rate and color-blind.
[edit firewall three-color-policer trTCM2-cb]
user@host# set two-rate color-blind
A color-aware three-color policer takes into account any coloring markings that might have been set
for a packet by another trac policer congured at a previous network node, and any preexisng
color markings are used in determining the appropriate policing acon for the packet.
Because you are applying this three-color policer applied to input at Layer 2, you must congure the
policer to be color-blind.
2016
4. Specify the policer trac limits used to classify a green trac ow.
[edit firewall three-color-policer trTCM2-cb]
user@host# set two-rate committed-information-rate 40m
user@host# set two-rate committed-burst-size 100k
5. Specify the addional policer trac limits used to classify a yellow or red trac ow.
[edit firewall three-color-policer trTCM2-cb]
user@host# set two-rate peak-information-rate 60m
user@host# set two-rate peak-burst-size 200k
6. (Oponal) Specify the congured policer acon for packets in a red trac ow.
[edit firewall three-color-policer trTCM2-cb]
user@host# set action loss-priority high then discard
In color-aware mode, the three-color policer congured acon can increase the packet loss priority
(PLP) level of a packet, but never decrease it. For example, if a color-aware three-color policer meters
a packet with a medium PLP marking, it can raise the PLP level to high, but cannot reduce the PLP
level to low.
Results
Conrm the conguraon of the three-color policer by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
three-color-policer trTCM2-cb {
logical-interface-policer;
action {
loss-priority high then discard;
}
two-rate {
color-blind;
committed-information-rate 40m;
committed-burst-size 100k;
2017
peak-information-rate 60m;
peak-burst-size 200k;
}
}
Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface
Step-by-Step Procedure
To apply the three-color policer to the Layer 2 input at the logical interface:
1. Enable applicaon of Layer 2 logical interface policers.
[edit]
user@host# edit interfaces ge-1/3/1 unit 0
2. Apply the three-color logical interface policer to a logical interface input.
[edit interfaces ge-1/3/1 unit 0]
user@host# set layer2-policerinput-three-color trTCM2-cb
Results
Conrm the conguraon of the logical interfaces by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
layer2-policer {
input-three-color trTCM2-cb;
}
family inet {
address 10.10.10.1/30;
}
2018
}
unit 1 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying Trac Stascs and Policers for the Logical Interface | 2019
Displaying Stascs for the Policer | 2020
Conrm that the conguraon is working properly.
Displaying Trac Stascs and Policers for the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show interfaces operaonal mode command for logical interface ge-1/3/1.0, and include the detail
or extensive opon. The command output secon for Trac stascs lists the number of bytes and
packets received and transmied on the logical interface, and the Protocol inet secon contains a
Policer eld that would list the policer trTCM2-cb as an input or output policer as follows:
• Input: trTCM2-cb-ge-1/3/1.0-log_int-i
• Output: trTCM2-cb-ge-1/3/1.0-log_int-o
2019
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to in the input direcon only.
Displaying Stascs for the Policer
Purpose
Verify the number of packets evaluated by the policer.
Acon
Use the show policer operaonal mode command and oponally specify the name of the policer. The
command output displays the number of packets evaluated by each congured policer (or the specied
policer), in each direcon. For the policer trTCM2-cb, the input and output policer names are displayed as
follows:
• trTCM2-cb-ge-1/3/1.0-log_int-i
• trTCM2-cb-e-1/3/1.0-log_int-o
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to input trac only.
SEE ALSO
Logical Interface (Aggregate) Policer Overview
Example: Conguring a Two-Color Logical Interface (Aggregate) Policer
Three-Color Policing at Layer 2 Overview
layer2-policer (EX)
logical-interface-policer
three-color-policer (Conguring)
RELATED DOCUMENTATION
Guidelines for Applying Trac Policers | 1938
layer2-policer (EX)
logical-interface-policer
2020
policer (Conguring)
three-color-policer (Conguring)
Layer 2 Trac Policing at the Pseudowire Overview
This feature limits trac that is sent over the core by policing trac at the Layer 2 pseudowire level. It
uses dynamic proles to aach two- or three-color policers to pseudowire logical interfaces. You apply
the dynamic proles to core-facing egress interfaces so that they can police unicast, mulcast, and
broadcast trac that is going over the MPLS core network.
NOTE: Pseudowire policer stascs collected by the Roung Engine, kernel, and Packet
Forwarding Engine can be displayed on the Roung Engine when you execute the show interfaces
command.
Figure 85 on page 2021 shows an MX Series 5G Universal Roung Plaorm congured as a provider
edge (PE) router. It communicates with other PE routers over pseudowires. It can aggregate both unicast
and mulcast trac and send it over pseudowires. To limit trac over the pseudowires, you can set up
policers on each pseudowire that faces the MPLS core network.
Figure 85: Liming Trac to the Core Using Layer 2 Policers at the Pseudowire Level
NOTE: This feature is supported only on pseudowire logical interfaces at the egress. It is not
supported on tunnel interfaces.
2021
Conguring a Two-Color Layer 2 Policer for the Pseudowire
For the basic conguraon of Layer 2 policers for pseudowires, create a two-color policer.
To congure a two-color policer:
1. Create a two-color policer.
[edit firewall]
user@host# edit policer 2color-l2-policer
2. Specify that the policer is to be used on a logical interface.
[edit firewall policer 2color-l2-policer]
user@host# set logical-interface-policer
3. Congure the policer.
[edit firewall policer 2color-l2-policer]
user@host# edit if-exceeding
[edit firewall policer 2color-l2-policer if-exceeding]
user@host# set bandwidth-limit 30m
user@host# set burst-size-limit 300k
4. Set the acon that the policer takes to loss-priority and specify that the packet loss priority (PLP) is
high.
[edit firewall policer 2color-l2-policer]
user@host# set then loss-priority high
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Conguring a Three-Color Layer 2 Policer for the Pseudowire | 2023
Applying the Policers to Dynamic Prole Interfaces | 2024
Aaching Dynamic Proles to Roung Instances | 2025
2022
Conguring a Three-Color Layer 2 Policer for the Pseudowire
For the basic conguraon of Layer 2 policers for pseudowires, create a three-color policer. This
scenario shows a two-rate three-color-marking (trTCM) policer.
To congure a three-color policer:
1. Create a three-color policer.
[edit firewall]
user@host# edit three-color-policer trTCM-policer
2. Specify that the policer is to be used on a logical interface.
[edit firewall three-color-policer trTCM-policer]
user@host# set logical-interface-policer
3. Set the acon for the policer.
[edit firewall three-color-policer trTCM-policer]
user@host# set action loss-priority high then discard
4. Specify that the policer is a two-rate policer and congure the policer.
[edit firewall three-color-policer trTCM-policer]
user@host# edit two-rate
user@host# set color-aware
user@host# set committed-information-rate 10m
user@host# set committed-burst-size 50m
user@host# set committed-burst-size 150k
user@host# set peak-information-rate 50m
user@host# set peak-burst-size 450k
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Two-Rate Three-Color Policer Overview | 2151
Conguring a Two-Color Layer 2 Policer for the Pseudowire | 2022
2023
Applying the Policers to Dynamic Prole Interfaces | 2024
Aaching Dynamic Proles to Roung Instances | 2025
Applying the Policers to Dynamic Prole Interfaces
This conguraon shows how to apply policers to a dynamic prole.
Before you can apply policers, you need to have congured your policers as described in:
• "Conguring a Three-Color Layer 2 Policer for the Pseudowire" on page 2023
• "Conguring a Two-Color Layer 2 Policer for the Pseudowire" on page 2022
To congure the dynamic proles:
1. Create a dynamic prole for the three-color policer.
[edit dynamic-profiles]
user@host# edit pw-trTCM-policer
2. Create a dynamic prole interface that has a dynamic underlying interface unit.
[edit dynamic-profiles pw-trTCM-policer]
user@host# edit interfaces $junos-interface-ifd-name unit $junos-underlying-interface-unit
3. Specify that VPLS is the protocol family.
[edit dynamic-profiles pw-trTCM-policer interfaces "$junos-interface-ifd-name" unit "$junos-
underlying-interface-unit"]
user@host# set family vpls
4. Assign the three-color policer to the dynamic prole.
[edit dynamic-profiles pw-trTCM-policer interfaces "$junos-interface-ifd-name" unit "$junos-
underlying-interface-unit"]
user@host# set layer2-policer output-three-color trTCM-policer
2024
5. Create a dynamic prole for the two-color policer.
[edit dynamic-profiles]
user@host# edit pw-2color-l2-policer
6. Create a dynamic prole interface that has a dynamic underlying interface unit.
[edit dynamic-profiles pw-2color-l2-policer]
user@host# edit interfaces $junos-interface-ifd-name unit $junos-underlying-interface-unit
7. Specify that VPLS is the protocol family.
[edit dynamic-profiles pw-2color-l2-policer interfaces "$junos-interface-ifd-name" unit
"$junos-underlying-interface-unit"]
user@host# set family vpls
8. Assign the two-color policer to the dynamic prole.
[edit dynamic-profiles pw-2color-l2-policer interfaces "$junos-interface-ifd-name" unit
"$junos-underlying-interface-unit"]
user@host# set layer2-policer output-policer 2color-l2-policer
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Conguring a Three-Color Layer 2 Policer for the Pseudowire | 2023
Conguring a Two-Color Layer 2 Policer for the Pseudowire | 2022
Aaching Dynamic Proles to Roung Instances | 2025
Aaching Dynamic Proles to Roung Instances
To bind the dynamic prole to the pseudowire, aach it to a roung instance. The roung instance can
be a VPLS instance type or a virtual switch instance type. You can aach dynamic proles to the roung
instance at the VPLS protocol level, at the mesh-group level, or at the neighbor level.
2025
Because this feature is not supported on tunnel interfaces, for VPLS roung interfaces, you must include
the no-tunnel-services statement at the [edit routing-instances
routing-instance-name
protocols vpls] hierarchy
level.
• To aach the dynamic prole at the VPLS protocol level:
[edit routing-instances]
user@host# edit green protocols vpls associate-profile
[edit routing-instances green protocols vpls associate-profile]
user@host# set pw-2color-l2-policer
• To aach the dynamic prole at the mesh-group level:
[edit routing-instances]
user@host# edit green protocols vpls mesh-group lata-1 associate-profile
[edit routing-instances green protocols vpls mesh-group lata-1 associate-profile]
user@host# set pw-trTCM-policer
• To aach the dynamic prole at the neighbor level:
[edit routing-instances]
user@host# edit green protocols vpls mesh-group lata-1 neighbor 10.10.1.1 associate-profile
[edit routing-instances green protocols vpls mesh-group lata-1 neighbor 10.10.1.1 associate-
profile]
user@host# set pw-2color-l2-policer
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Conguring a Three-Color Layer 2 Policer for the Pseudowire | 2023
Conguring a Two-Color Layer 2 Policer for the Pseudowire | 2022
Applying the Policers to Dynamic Prole Interfaces | 2024
2026
Using Variables for Layer 2 Trac Policing at the Pseudowire Overview
To reduce the number of dynamic proles needed to police trac at the core, you can use a variable for
the output policer in your dynamic proles. The variable that you dene is called junos-layer2-output-
policer. The variable is a placeholder that gets lled in when the dynamic prole obtains the value from
the roung instance.
To use variables for policers for Layer 2 pseudowires:
1. Create policers.
2. Create a dynamic prole and add a prole variable set to the dynamic prole.
3. In the prole variable set, assign a value to the junos-layer2-output-policer variable. This value is the
name of one of your policers.
4. In the dynamic prole interface conguraon at the [edit dynamic-profiles
profile-name
interfaces
"$junos-interface-ifd-name" unit "$junos-underlying-interface-unit"] hierarchy, assign junos-layer2-output-
policer as one of your Layer 2 policers.
5. When you aach the dynamic prole to a roung instance, assign the prole variable set that you
congured in the dynamic prole as the associate-prole value.
6. Aach the dynamic prole and the prole variable set to the roung instance.
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Conguring a Policer for the Complex Conguraon | 2027
Creang a Dynamic Prole for the Complex Conguraon | 2028
Aaching Dynamic Proles to Roung Instances for the Complex Conguraon | 2030
Conguring a Policer for the Complex Conguraon
For the complex conguraon of Layer 2 policers for pseudowires, create a two-color policer.
To congure a two-color policer:
2027
1. Create a two-color policer.
[edit firewall]
user@host# edit policer 10m-policer
2. Specify that the policer is to be used on a logical interface.
[edit firewall policer 10m-policer]
user@host# set logical-interface-policer
3. Congure the policer.
[edit firewall policer 10m-policer]
user@host# edit if-exceeding
[edit firewall policer 10m-policer if-exceeding]
user@host# set bandwidth-limit 10m
user@host# set burst-size-limit 100k
4. Set the acon that the policer takes to loss-priority and specify that the packet loss priority (PLP) is
high.
[edit firewall policer 10m-policer]
user@host# set then loss-priority high
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Using Variables for Layer 2 Trac Policing at the Pseudowire Overview | 2027
Creang a Dynamic Prole for the Complex Conguraon | 2028
Aaching Dynamic Proles to Roung Instances for the Complex Conguraon | 2030
Creang a Dynamic Prole for the Complex Conguraon
For this conguraon, the dynamic prole denes a prole variable set and then assigns the variable to
the output policer.
2028
To congure dynamic proles:
1. Create a dynamic prole.
[edit dynamic-profiles]
user@host# edit pw-policer
2. Create a prole variable set and dene the junos-layer2-output-policer variable. In this scenario, set
the variable to the 10m-policer.
[edit dynamic-profiles pw-policer]
user@host# edit profile-variable-set pw-policer-var-set
user@host# set junos-layer2-output-policer 10m-policer
3. Create a dynamic prole interface that has a dynamic underlying interface unit.
[edit dynamic-profiles pw-policer]
user@host# edit interfaces $junos-interface-ifd-name unit $junos-underlying-interface-unit
4. Assign the junos-layer2-output-policer variable to the two-color output policer.
[edit dynamic-profiles pw-policer interfaces "$junos-interface-ifd-name" unit "$junos-
underlying-interface-unit"]
user@host# set layer2-policer output-policer $junos-layer2-output-policer
5. Specify that VPLS is the protocol family.
[edit dynamic-profiles pw-2color-l2-policer interfaces "$junos-interface-ifd-name" unit
"$junos-underlying-interface-unit"]
user@host# set family vpls
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Using Variables for Layer 2 Trac Policing at the Pseudowire Overview | 2027
Conguring a Policer for the Complex Conguraon | 2027
Aaching Dynamic Proles to Roung Instances for the Complex Conguraon | 2030
2029
Aaching Dynamic Proles to Roung Instances for the Complex
Conguraon
To bind the dynamic prole to the pseudowire, aach it to a roung instance. When your dynamic
prole contains variables, you assign one of the prole variable sets that you congured in your dynamic
prole when you associate the prole with the roung instance.
The roung instance can be a VPLS instance type or a virtual switch instance type. You can aach the
dynamic prole and the prole variable set to the roung instance at the VPLS protocol level, at the
mesh-group level, or at the neighbor level.
Because this feature is not supported on tunnel interfaces, for VPLS roung interfaces, you must include
the no-tunnel-services statement at the [edit routing-instances
routing-instance-name
protocols vpls] hierarchy
level.
• To aach the dynamic prole and the prole variable set at the VPLS protocol level:
[edit routing-instances]
user@host# edit green protocols vpls associate-profile
[edit routing-instances green protocols vpls associate-profile]
user@host# set profile-variable-set pw-policer
user@host# set profile-variable-set pw-policer-var-set
• To aach the dynamic prole and the prole variable set at the mesh-group level:
[edit routing-instances]
user@host# edit green protocols vpls mesh-group lata-1 associate-profile
[edit routing-instances green protocols vpls mesh-group lata-1 associate-profile]
user@host# set profile-variable-set pw-policer
user@host# setprofile-variable-set pw-policer-var-set
• To aach the dynamic prole and the prole variable set at the neighbor level:
[edit routing-instances]
user@host# edit green protocols vpls mesh-group lata-1 neighbor 10.10.1.1 associate-profile
[edit routing-instances green protocols vpls mesh-group lata-1 neighbor 10.10.1.1 associate-
profile]
user@host# profile-variable-set pw-policer
user@host# profile-variable-set pw-policer-var-set
2030
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Using Variables for Layer 2 Trac Policing at the Pseudowire Overview | 2027
Conguring a Policer for the Complex Conguraon | 2027
Creang a Dynamic Prole for the Complex Conguraon | 2028
Verifying Layer 2 Trac Policers on VPLS Connecons
IN THIS SECTION
Purpose | 2031
Acon | 2031
Meaning | 2032
Purpose
Display VPLS connecons to verify that the dynamic prole is running on the Layer 2 VPN connecon.
Acon
user@host> show vpls connections
Layer-2 VPN connections:
...
Instance: vpls-10gige
Local site: 10Gige-PE (2)
connection-site Type St Time last up # Up trans
1 rmt Up Mar 28 21:27:57 2010 1
Remote PE: 10.10.1.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262146
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Dynamic profile: pw-policer
Description: Intf - vpls vpls-10gige local site 2 remote site 1
2031
Meaning
The Dynamic prole eld displays the policer that is currently running on the VPLS connecon.
RELATED DOCUMENTATION
Layer 2 Trac Policing at the Pseudowire Overview | 2021
Understanding Policers on OVSDB-Managed Interfaces
When you use a Contrail controller to manage VXLANs on a QFX switch (through the Open vSwitch
Database—OVSDB—management protocol), the VXLAN interfaces are automacally congured with the
flexible-vlan-tagging and encapsulation extended-vlan-bridge statements. Starng with Junos OS Release
14.1X53-D30, you can create family ethernet-switching logical units (subinterfaces) on VXLAN interfaces.
This enables you to apply rewall lters with the acon three-color-policer to these subinterfaces, which
means that you can apply two-rate three-color markers (policers) to OVSDB-managed interfaces. See
"Example: Applying a Policer to OVSDB-Managed Interfaces" on page 2033 for informaon about how
to congure policers on VXLAN interfaces managed by a Contrail controller.
NOTE: Firewall lters are the only supported conguraon items on family ethernet-switching
subinterfaces of OVSDB-managed interfaces. Two-rate three-color markers are the only
supported policers.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
14.1X53-D30
Starng with Junos OS Release 14.1X53-D30, you can create family ethernet-switching logical
units (subinterfaces) on VXLAN interfaces.
RELATED DOCUMENTATION
Example: Applying a Policer to OVSDB-Managed Interfaces | 2033
Overview of Policers | 2202
2032
Understanding VXLANs
Understanding the OVSDB Protocol Running on Juniper Networks Devices
Understanding Firewall Filters on OVSDB-Managed Interfaces | 1492
Example: Applying a Policer to OVSDB-Managed Interfaces
IN THIS SECTION
Requirements | 2033
Overview | 2034
Conguraon | 2034
Starng with Junos OS Release 14.1X53-D30, you can create family ethernet-switching logical units
(subinterfaces) on VXLAN interfaces managed by a Contrail controller. (The controller and switch
communicate through the Open vSwitch Database—OVSDB—management protocol). This support
enables you to apply rewall lters with the acon three-color-policer to these subinterfaces, which
means that you can apply two-rate three-color markers (policers) to OVSDB-managed interfaces.
Because a Contrail controller can create subinterfaces dynamically, you need to apply rewall lters in
such a way that the lters will apply to subinterfaces whenever the controller creates them. You
accomplish this by using conguraon groups to congure and apply the rewall lters. (You must use
conguraon groups for this purpose—that is, you cannot apply a rewall lter directly to these
subinterfaces.)
NOTE: Firewall lters are the only supported conguraon items on family ethernet-switching
subinterfaces of OVSDB-managed interfaces. Two-rate three-color markers are the only
supported policers.
Requirements
This example uses the following hardware and soware components:
• A QFX5100 switch
• Junos OS Release 14.1X53-D30 or later
2033
Overview
This example assumes that interfaces xe-0/0/0 and xe-0/0/1 on the switch are VXLAN interfaces
managed by a Contrail controller, which means that the controller has applied the flexible-vlan-tagging
and encapsulation extended-vlan-bridge statements to these interfaces. To apply a rewall lter Layer 2
(port) rewall lter with a policer acon to any subinterfaces that the controller creates dynamically, you
must create and apply the lter as shown in this example.
NOTE: As shown in the example, all of the statements must be part of a conguraon group
when you want to apply a rewall lter (and policer) to an OVSDB-managed subinterface.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2034
Procedure | 2035
To congure a rewall lter with a policer acon to be automacally applied to subinterfaces created
dynamically by a Contrail controller, perform these tasks:
CLI Quick Conguraon
[edit]
set groups vxlan-policer-group interfaces xe-0/0/0 unit <*> family ethernet-switching filter
input vxlan-filter
set groups vxlan-policer-group interfaces xe-0/0/1 unit <*> family ethernet-switching filter
input vxlan-filter
set groups vxlan-policer-group firewall three-color-policer vxlan-policer action loss-priority
high then discard
set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-rate color-blind
set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-rate committed-
burst-size 2m
set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-rate committed-
information-rate 100m
set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-rate peak-burst-
2034
size 4m
set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-rate peak-
information-rate 100m
set groups vxlan-policer-group firewall family ethernet-switching filter vxlan-filter term t1
then three-color-policer two-rate vxlan-policer
set apply-groups vxlan-policer-group
Procedure
Step-by-Step Procedure
1. Create conguraon group vxlan-policer-group to apply rewall lter vxlan-filter to any subinterface
of interface xe-0/0/0. The lter applies to any subinterface because you specify unit <*>:
[edit]
user@switch# set groups vxlan-policer-group interfaces xe-0/0/0 unit <*> family ethernet-
switching filter input vxlan-filter
2. Create the same conguraon for interface xe-0/0/1:
[edit]
user@switch# set groups vxlan-policer-group interfaces xe-0/0/1 unit <*> family ethernet-
switching filter input vxlan-filter
3. Congure the policer to discard packets with high loss priority. (Junos OS assigns high loss priority
to packets that exceed the peak informaon rate and the peak burst size.) As with the interface
conguraon, you must also congure the policer to be part of a conguraon group.
[edit]
user@switch# set groups vxlan-policer-group firewall three-color-policer vxlan-policer
action loss-priority high then discard
2035
4. Congure the policer to be color blind, which means that it ignores any preclassicaon of packets
and can assign a higher or lower packet loss priority.
[edit]
user@switch# set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-
rate color-blind
5. Congure the policer to allow incoming trac to burst a maximum of 2 megabytes above the
commied informaon rate and sll be marked with low packet loss priority (green).
[edit]
user@switch# set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-
rate committed-burst-size 2m
6. Congure the policer to allow guaranteed bandwidth of 100 megabytes under normal line
condions. This is the average rate up threshold under which packets are marked with low packet
loss priority (green).
[edit]
user@switch# set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-
rate committed-information-rate 100m
7. Congure the policer to allow incoming packets to burst a maximum of 4 megabytes above the
peak informaon rate and sll be marked with medium-high packet loss priority (yellow). Packets
that exceed the peak burst size are marked with high packet loss priority (red).
[edit]
user@switch# set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-
rate peak-burst-size 4m
8. Congure the policer to allow a maximum achievable rate of 100 megabytes. Packets that exceed
the commied informaon rate but are below the peak informaon rate are marked with medium-
2036
high packet loss priority (yellow). Packets that exceed the peak informaon rate are marked with
high packet loss priority (red).
[edit]
user@switch# set groups vxlan-policer-group firewall three-color-policer vxlan-policer two-
rate peak-information-rate 100m
9. Congure the rewall lter vxlan-filter to send matching packets (all packets, because there is no
from statement) to the policer:
[edit]
user@switch# set groups vxlan-policer-group firewall family ethernet-switching filter vxlan-
filter term t1 then three-color-policer two-rate vxlan-policer
10. Apply the group to enable its conguraon:
[edit]
user@switch# set apply-groups vxlan-policer-group
RELATED DOCUMENTATION
Understanding Junos OS Conguraon Groups
Overview of Firewall Filters (QFX Series) | 1720
Overview of Policers | 2202
Understanding VXLANs
Understanding the OVSDB Protocol Running on Juniper Networks Devices
Understanding Policers on OVSDB-Managed Interfaces | 2032
2037
CHAPTER 32
Conguring Two-Color and Three-Color Trac
Policers at Layer 3
IN THIS CHAPTER
Two-Color Policer Conguraon Overview | 2038
Basic Single-Rate Two-Color Policers | 2046
Bandwidth Policers | 2074
Prex-Specic Counng and Policing Acons | 2087
Policer Overhead to Account for Rate Shaping in the Trac Manager | 2110
Three-Color Policer Conguraon Overview | 2122
Applying Policers | 2126
Three-Color Policer Conguraon Guidelines | 2138
Basic Single-Rate Three-Color Policers | 2142
Basic Two-Rate Three-Color Policers | 2151
Example: Conguring a Two-Rate Three-Color Policer | 2161
Two-Color Policer Conguraon Overview
Table 115 on page 2039 describes the hierarchy levels at which you can congure and apply single-rate
two-color policers to Layer 3 trac. For informaon about applying single-rate two-color policers to
Layer 2 trac, see "Two-Color Policing at Layer 2 Overview" on page 2007.
2038
Table 115: Two-Color Policer Conguraon and Applicaon Overview
Policer Conguraon Layer 3 Applicaon Key Points
Single-Rate Two-Color Policer
Denes trac rate liming that you can apply to Layer 3 protocol-specic trac at a logical interface. Can be applied
as an interface policer or as a rewall lter policer.
2039
Table 115: Two-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
Basic policer conguraon:
[edit firewall]
policer
policer-name
{
if-exceeding {
bandwidth-limit
bps
;
burst-size-limit
bytes
;
}
then {
discard;
forwarding-class
class-
name
;
loss-priority
supported-
value
;
}
}
Method A—Apply as an interface policer at the
protocol family level:
[edit interfaces]
interface-name
{
unit
unit-number
{
family
family-name
{
policer {
input
policer-name
;
output
policer-name
;
}
}
}
}
Method B—Apply as a rewall lter policer at
the protocol family level:
[edit firewall]
family
family-name
{
filter
filter-name
{
interface-specific; # (*)
from {
...
match-conditions
...
}
then {
policer
policer-name
;
}
}
}
[edit interfaces]
interface-name
{
unit
unit-number
{
family
family-name
{
filter {
input
filter-name
;
output
filter-name
;
}
...
protocol-configuration
...
}
Policer conguraon:
• Use bandwidth-limit
bps
to specify an absolute
value.
Firewall lter conguraon
(*)
• If applying to mulple
interfaces, include the
interface-specic
statement to create
unique policers and
counters for each
interface.
Interface policer vericaon:
•
Use the show interfaces
(detail | extensive)
operaonal mode
command.
• Use the show policer
operaonal mode
command.
Firewall lter policer
vericaon:
• Use the show interfaces
(detail | extensive)
operaonal mode
command.
• Use the show rewall
lter
lter-name
operaonal mode
command.
2040
Table 115: Two-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
}
}
Bandwidth Policer
Denes trac rate liming that you can apply to Layer 3 protocol-specic trac at a logical interface, but the
bandwidth limit is specied as a percentage value. Bandwidth can be based on physical interface line rate (the
default) or the logical interface shaping rate. Can be applied as an interface policer or as a rewall lter policer where
the lter is either interface-specic or a physical interface lter.
2041
Table 115: Two-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
Bandwidth policer conguraon:
[edit firewall]
policer
policer-name
{
logical-bandwidth-policer;
if-exceeding {
bandwidth-percent
(1..100);
burst-size-limit
bytes
;
}
then {
discard;
forwarding-class
class-
name
;
loss-priority
supported-
value
;
}
}
Method A—Apply as an interface policer at the
protocol family level:
[edit interfaces]
interface-name
{
unit
unit-number
{
family
family-name
{
policer {
input
policer-name
;
output
policer-name
;
}
}
}
}
Method B—Apply as a rewall lter policer at
the protocol family level:
[edit firewall]
family
family-name
{
filter
filter-name
{
interface-specific;
from {
...
match-conditions
...
}
then {
policer
policer-name
;
}
}
}
[edit interfaces]
interface-name
{
unit
unit-number
{
family
family-name
{
filter {
input
filter-name
;
output
filter-name
;
}
...
protocol-configuration
...
}
Policer conguraon:
• Use the bandwidth-
percent
percentage
statement instead of the
bandwidth-limit
bps
statement.
By default, bandwidth
policing rate-limits trac
based on a percentage of
the physical interface
media rate.
•
To rate-limit trac based
on a percentage of the
logical interface
congured shaping rate,
also include the logical-
bandwidth-policer
statement.
Firewall lter conguraon:
• Percentage bandwidth
policers can only be
referenced by lters
congured with the
interface-specic
statement.
Interface policer vericaon:
• Use the show interfaces
(detail | extensive)
operaonal mode
command.
• Use the show policer
operaonal mode
command.
Firewall lter policer
vericaon:
2042
Table 115: Two-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
}
}
• Use the show interfaces
(detail | extensive)
operaonal mode
command.
• Use the show rewall
lter
lter-name
operaonal mode
command.
Logical Interface (Aggregate) Policer
Denes trac rate liming that you can apply to mulple protocol families on the same logical interface without
creang mulple instances of the policer. Can be applied directly to a logical interface conguraon only.
2043
Table 115: Two-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
Logical interface policer
conguraon:
[edit firewall]
policer
policer-name
{
logical-interface-policer;
if-exceeding {
bandwidth-limit
bps
;
burst-size-limit
bytes
;
}
then {
discard;
forwarding-class
class-
name
;
loss-priority
supported-
value
;
}
}
Apply as an interface policer only:
[edit interfaces]
interface-name
{
unit
unit-number
{
policer { # All protocols
input
policer-name
;
output
policer-name
;
}
family
family-name
{
policer { # One protocol
input
policer-name
;
output
policer-name
;
}
}
}
}
Policer conguraon:
• Include the logical-
interface-policer
statement.
Two opons for interface
policer applicaon:
• To rate-limit all trac
types, regardless of the
protocol family, apply the
logical interface policer
at the logical unit level.
•
To rate-limit trac of a
specic protocol family,
apply the logical
interface policer at the
protocol family level.
Interface policer vericaon:
• Use the show interfaces
(detail | extensive)
operaonal mode
command.
• Use the show policer
operaonal mode
command.
Physical Interface Policer
Denes trac rate liming that applies to all logical interfaces and protocol families congured on a physical
interface, even if the interfaces belong to dierent roung instances. Can be applied as a rewall lter policer
referenced from a physical interface lter only.
2044
Table 115: Two-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
Physical interface policer
conguraon:
[edit firewall]
policer
policer-name
{
physical-interface-policer;
if-exceeding {
bandwidth-limit
bps
;
burst-size-limit
bytes
;
}
then {
discard;
forwarding-class
class-
name
;
loss-priority
supported-
value
;
}
}
Apply as a rewall lter policer referenced
from a physical interface lter that you apply
at the protocol family level:
[edit firewall]
family
family-name
{
filter
filter-name
{
physical-interface-filter;
from {
...
match-conditions
...
}
then {
policer
policer-name
;
}
}
}
[edit interfaces]
interface-name
{
unit
number
{
family
family-name
{
filter {
input
filter-name
;
output
filter-name
;
}
...
protocol-configuration
...
}
}
}
Policer conguraon:
• Include the physical-
interface-policer
statement.
Firewall lter conguraon:
• Include the physical-
interface-lter
statement.
Applicaon:
•
Apply the lter to the
input or output of a
logical interface at the
protocol family level.
Firewall lter policer
vericaon:
• Use the show interfaces
(detail | extensive)
operaonal mode
command.
• Use the show rewall
lter
lter-name
operaonal mode
command.
RELATED DOCUMENTATION
Basic Single-Rate Two-Color Policers | 2046
Bandwidth Policers | 2074
Prex-Specic Counng and Policing Acons | 2087
Muleld Classier Example: Conguring Muleld Classicaon | 1308
Policer Overhead to Account for Rate Shaping in the Trac Manager | 2110
2045
Two-Color and Three-Color Physical Interface Policers | 2189
Basic Single-Rate Two-Color Policers
IN THIS SECTION
Single-Rate Two-Color Policer Overview | 2046
Example: Liming Inbound Trac at Your Network Border by Conguring an Ingress Single-Rate Two-Color
Policer | 2047
Example: Conguring Interface and Firewall Filter Policers at the Same Interface | 2059
Single-Rate Two-Color Policer Overview
Single-rate two color policing enforces a congured rate of trac ow for a parcular service level by
applying implicit or congured acons to trac that does not conform to the limits. When you apply a
single-rate two-color policer to the input or output trac at an interface, the policer meters the trac
ow to the rate limit dened by the following components:
• Bandwidth limit—The average number of bits per second permied for packets received or
transmied at the interface. You can specify the bandwidth limit as an absolute number of bits per
second or as a percentage value from 1 through 100. If a percentage value is specied, the eecve
bandwidth limit is calculated as a percentage of either the physical interface media rate or the
logical
interface
congured shaping rate.
• Packets per second (pps) limit (MX Series with MPC only)–The average number of packets per
second permied for packets received or transmied at the interface. You specify the pps limit as an
absolute number of packets per second.
• Burst-size limit—The maximum size permied for bursts of data.
• Packet burst limit–
For a trac ow that conforms to the congured limits (categorized as green trac), packets are
implicitly marked with a packet loss priority (PLP) level of low and are allowed to pass through the
interface unrestricted.
For a trac ow that exceeds the congured limits (categorized as red trac), packets are handled
according to the trac-policing acons congured for the policer. The acon might be to discard the
2046
packet, or the acon might be to re-mark the packet with a specied forwarding class, a specied PLP, or
both, and then transmit the packet.
To rate-limit Layer 3 trac, you can apply a two-color policer in the following ways:
• Directly to a logical interface, at a specic protocol level.
• As the acon of a standard stateless
rewall lter
that is applied to a logical interface, at a specic
protocol level.
To rate-limit Layer 2 trac, you can apply a two-color policer as a
logical interface policer
only. You
cannot apply a two-color policer to Layer 2 trac through a rewall lter.
NOTE: On MX plaorms, Packet Loss Priority (PLP) is not implicitly to low (green) when the
trac ow conrms to the congured policer limit. Instead it takes the user congured PLP
values like high, medium-high, medium-low. Use dp-rewrite under edit firewall policer <policer-
name> to enable this behavior on MX plaorms. If the knob is not enabled, then the packets may
carry their original color and loss priority.
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Example: Liming Inbound Trac at Your Network Border by Conguring an Ingress Single-Rate
Two-Color Policer
Example: Conguring Interface and Firewall Filter Policers at the Same Interface
Example: Liming Inbound Trac at Your Network Border by Conguring an Ingress
Single-Rate Two-Color Policer
IN THIS SECTION
Requirements | 2048
Overview | 2048
Conguraon | 2051
Vericaon | 2057
2047
This example shows you how to congure an ingress single-rate two-color policer to lter incoming
trac. The policer enforces the class-of-service (CoS) strategy for in-contract and out-of-contract trac.
You can apply a single-rate two-color policer to incoming packets, outgoing packets, or both. This
example applies the policer as an input (ingress) policer. The goal of this topic is to provide you with an
introducon to policing by using a example that shows trac policing in acon.
Policers use a concept known as a token bucket to allocate system resources based on the parameters
dened for the policer. A thorough explanaon of the token bucket concept and its underlying
algorithms is beyond the scope of this document. For more informaon about trac policing, and CoS in
general, refer to
QOS-Enabled Networks—Tools and Foundaons
by Miguel Barreiros and Peter
Lundqvist. This book is available at many online booksellers and at www.juniper.net/books.
Requirements
To verify this procedure, this example uses a trac generator. The trac generator can be hardware-
based or it can be soware running on a server or host machine.
The funconality in this procedure is widely supported on devices that run Junos OS. The example
shown here was tested and veried on MX Series routers running Junos OS Release 10.4.
Overview
IN THIS SECTION
Topology | 2050
Single-rate two-color policing enforces a congured rate of trac ow for a parcular service level by
applying implicit or congured acons to trac that does not conform to the limits. When you apply a
single-rate two-color policer to the input or output trac at an interface, the policer meters the trac
ow to the rate limit dened by the following components:
• Bandwidth limit—The average number of bits per second permied for packets received or
transmied at the interface. You can specify the bandwidth limit as an absolute number of bits per
second or as a percentage value from 1 through 100. If a percentage value is specied, the eecve
bandwidth limit is calculated as a percentage of either the physical interface media rate or the logical
interface congured shaping rate.
• Burst-size limit—The maximum size permied for bursts of data. Burst sizes are measured in bytes.
We recommend two formulas for calculang burst size:
Burst size = bandwidth x allowable me for burst trac / 8
2048
Or
Burst size = interface mtu x 10
For informaon about conguring the burst size, see "Determining Proper Burst Size for Trac
Policers" on page 1912.
NOTE: There is a nite buer space for an interface. In general, the esmated total buer
depth for an interface is about 125 ms.
For a trac ow that conforms to the congured limits (categorized as green trac), packets are
implicitly marked with a packet loss priority (PLP) level of low and are allowed to pass through the
interface unrestricted.
For a trac ow that exceeds the congured limits (categorized as red trac), packets are handled
according to the trac-policing acons congured for the policer. This example discards packets that
burst over the 15 KBps limit.
To rate-limit Layer 3 trac, you can apply a two-color policer in the following ways:
• Directly to a logical interface, at a specic protocol level.
• As the acon of a standard stateless rewall lter that is applied to a logical interface, at a specic
protocol level. This is the technique used in this example.
To rate-limit Layer 2 trac, you can apply a two-color policer as a logical interface policer only. You
cannot apply a two-color policer to Layer 2 trac through a rewall lter.
CAUTION: You can choose either bandwidth-limit or bandwidth percent within the
policer, as they are mutually exclusive. You cannot congure a policer to use bandwidth
percent for aggregate, tunnel, and soware interfaces.
In this example, the host is a trac generator emulang a webserver. Devices R1 and R2 are owned by a
service provider. The webserver is accessed by users on Device Host2. Device Host1 will be sending
trac with a source TCP HTTP port of 80 to the users. A single-rate two-color policer is congured and
applied to the interface on Device R1 that connects to Device Host1. The policer enforces the
contractual bandwidth availability made between the owner of the webserver and the service provider
that owns Device R1 for the web trac that ows over the link that connects Device Host1 to Device
R1.
In accordance with the contractual bandwidth availability made between the owner of the webserver
and the service provider that owns Devices R1 and R2, the policer will limit the HTTP port 80 trac
originang from Device Host1 to using 700 Mbps (70 percent) of the available bandwidth with an
2049
allowable burst rate of 10 x the MTU size of the gigabit Ethernet interface between the host Device
Host1 and Device R1.
NOTE: In a real-world scenario you would probably also rate limit trac for a variety of other
ports such as FTP, SFTP, SSH, TELNET, SMTP, IMAP, and POP3 because they are oen included
as addional services with web hosng services.
NOTE: You need to leave some addional bandwidth available that is not rate limited for
network control protocols such as roung protocols, DNS, and any other protocols required to
keep network connecvity operaonal. This is why the rewall lter has a nal accept condion
on it.
Topology
This example uses the topology in Figure 86 on page 2050.
Figure 86: Single-Rate Two-Color Policer Scenario
Figure 87 on page 2051 shows the policing behavior.
2050
Figure 87: Trac Liming in a Single-Rate Two-Color Policer Scenario
Conguraon
IN THIS SECTION
Procedure | 2051
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces ge-2/0/5 description to-Host
set interfaces ge-2/0/5 unit 0 family inet address 172.16.70.2/30
set interfaces ge-2/0/5 unit 0 family inet filter input mf-classifier
set interfaces ge-2/0/8 description to-R2
set interfaces ge-2/0/8 unit 0 family inet address 10.50.0.1/30
set interfaces lo0 unit 0 description looback-interface
set interfaces lo0 unit 0 family inet address 192.168.13.1/32
set firewall policer discard if-exceeding bandwidth-limit 700m
2051
set firewall policer discard if-exceeding burst-size-limit 15k
set firewall policer discard then discard
set firewall family inet filter mf-classifier term t1 from protocol tcp
set firewall family inet filter mf-classifier term t1 from port 80
set firewall family inet filter mf-classifier term t1 then policer discard
set firewall family inet filter mf-classifier term t2 then accept
set protocols ospf area 0.0.0.0 interface ge-2/0/5.0 passive
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-2/0/8.0
Device R2
set interfaces ge-2/0/8 description to-R1
set interfaces ge-2/0/8 unit 0 family inet address 10.50.0.2/30
set interfaces ge-2/0/7 description to-Host
set interfaces ge-2/0/7 unit 0 family inet address 172.16.80.2/30
set interfaces lo0 unit 0 description looback-interface
set interfaces lo0 unit 0 family inet address 192.168.14.1/32
set protocols ospf area 0.0.0.0 interface ge-2/0/7.0 passive
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-2/0/8.0
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
in the Junos OS
CLI User Guide.
To congure Device R1:
1. Congure the device interfaces.
[edit interfaces]
user@R1# set ge-2/0/5 description to-Host
user@R1# set ge-2/0/5 unit 0 family inet address 172.16.70.2/30
user@R1# set ge-2/0/8 description to-R2
user@R1# set ge-2/0/8 unit 0 family inet address 10.50.0.1/30
user@R1# set lo0 unit 0 description looback-interface
user@R1# set lo0 unit 0 family inet address 192.168.13.1/32
2052
2. Apply the rewall lter to interface ge-2/0/5 as an input lter.
[edit interfaces ge-2/0/5 unit 0 family inet]
user@R1# set filter input mf-classifier
3. Congure the policer to rate-limit to a bandwidth of 700 Mbps and a burst size of 15000 KBps for
HTTP trac (TCP port 80).
[edit firewall policer discard]
user@R1# set if-exceeding bandwidth-limit 700m
user@R1# set if-exceeding burst-size-limit 15k
4. Congure the policer to discard packets in the red trac ow.
[edit firewall policer discard]
user@R1# set then discard
5. Congure the two condions of the rewall to accept all TCP trac to port HTTP (port 80).
[edit firewall family inet filter mf-classifier]
user@R1# set term t1 from protocol tcp
user@R1# set term t1 from port 80
6. Congure the rewall acon to rate-limit HTTP TCP trac using the policer.
[edit firewall family inet filter mf-classifier]
user@R1# set term t1 then policer discard
7. At the end of the rewall lter, congure a default acon that accepts all other trac.
Otherwise, all trac that arrives on the interface and is not explicitly accepted by the rewall is
discarded.
[edit firewall family inet filter mf-classifier]
user@R1# set term t2 then accept
2053
8. Congure OSPF.
[edit protocols ospf]
user@R1# set area 0.0.0.0 interface ge-2/0/5.0 passive
user@R1# set area 0.0.0.0 interface lo0.0 passive
user@R1# set area 0.0.0.0 interface ge-2/0/8.0
Step-by-Step Procedure
To congure Device R2:
1. Congure the device interfaces.
[edit interfaces]
user@R1# set ge-2/0/8 description to-R1
user@R1# set ge-2/0/7 description to-Host
user@R1# set lo0 unit 0 description looback-interface
user@R1# set ge-2/0/8 unit 0 family inet address 10.50.0.2/30
user@R1# set ge-2/0/7 unit 0 family inet address 172.16.80.2/30
user@R1# set lo0 unit 0 family inet address 192.168.14.1/32
2. Congure OSPF.
[edit protocols ospf]
user@R1# set area 0.0.0.0 interface ge-2/0/7.0 passive
user@R1# set area 0.0.0.0 interface lo0.0 passive
user@R1# set area 0.0.0.0 interface ge-2/0/8.0
Results
From conguraon mode, conrm your conguraon by entering the show interfaces , show firewall, and
show protocols ospf commands. If the output does not display the intended conguraon, repeat the
instrucons in this example to correct the conguraon.
user@R1# show interfaces
ge-2/0/5 {
description to-Host;
unit 0 {
2054
family inet {
filter {
input mf-classifier;
}
address 172.16.70.2/30;
}
}
}
ge-2/0/8 {
description to-R2;
unit 0 {
family inet {
address 10.50.0.1/30;
}
}
}
lo0 {
unit 0 {
description looback-interface;
family inet {
address 192.168.13.1/32;
}
}
}
user@R1# show firewall
family inet {
filter mf-classifier {
term t1 {
from {
protocol tcp;
port 80;
}
then policer discard;
}
term t2 {
then accept;
}
}
}
policer discard {
2055
if-exceeding {
bandwidth-limit 700m;
burst-size-limit 15k;
}
then discard;
}
user@R1# show protocols ospf
area 0.0.0.0 {
interface ge-2/0/5.0 {
passive;
}
interface lo0.0 {
passive;
}
interface ge-2/0/8.0;
}
If you are done conguring Device R1, enter commit from conguraon mode.
user@R2# show interfaces
ge-2/0/7 {
description to-Host;
unit 0 {
family inet {
address 172.16.80.2/30;
}
}
}
ge-2/0/8 {
description to-R1;
unit 0 {
family inet {
address 10.50.0.2/30;
}
}
}
lo0 {
unit 0 {
description looback-interface;
family inet {
2056
address 192.168.14.1/32;
}
}
}
user@R2# show protocols ospf
area 0.0.0.0 {
interface ge-2/0/7.0 {
passive;
}
interface lo0.0 {
passive;
}
interface ge-2/0/8.0;
}
If you are done conguring Device R2, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Clearing the Counters | 2057
Sending TCP Trac into the Network and Monitoring the Discards | 2058
Conrm that the conguraon is working properly.
Clearing the Counters
Purpose
Conrm that the rewall counters are cleared.
2057
Acon
On Device R1, run the clear firewall all command to reset the rewall counters to 0.
user@R1> clear firewall all
Sending TCP Trac into the Network and Monitoring the Discards
Purpose
Make sure that the trac of interest that is sent is rate-limited on the input interface (ge-2/0/5).
Acon
1. Use a trac generator to send 10 TCP packets with a source port of 80.
The -s ag sets the source port. The -k ag causes the source port to remain steady at 80 instead of
incremenng. The -c ag sets the number of packets to 10. The -d ag sets the packet size.
The desnaon IP address of 172.16.80.1 belongs to Device Host 2 that is connected to Device R2.
The user on Device Host 2 has requested a webpage from Device Host 1 (the webserver emulated by
the trac generator on Device Host 1). The packets that being rate-limited are sent from Device
Host 1 in response to the request from Device Host 2.
NOTE: In this example the policer numbers are reduced to a bandwidth limit of 8 Kbps and a
burst size limit of 1500 KBps to ensure that some packets are dropped during this test.
[root@host]# hping 172.16.80.1 -c 10 -s 80 -k -d 300
[User@Host]# hping 172.16.80.1 -c 10 -s 80 -k -d 350
HPING 172.16.80.1 (eth1 172.16.80.1): NO FLAGS are set, 40 headers + 350 data bytes
len=46 ip=172.16.80.1 ttl=62 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=0.5 ms
.
.
.
--- 172.16.80.1 hping statistic ---
10 packets transmitted, 6 packets received, 40% packet loss
round-trip min/avg/max = 0.5/3000.8/7001.3 ms
2058
2. On Device R1, check the rewall counters by using the show firewall command.
user@R1> show firewall
User@R1# run show firewall
Filter: __default_bpdu_filter__
Filter: mf-classifier
Policers:
Name Bytes Packets
discard-t1 1560 4
Meaning
In Steps 1 and 2 the output from both devices shows that 4 packets were discarded This means that
there was at least 8 Kbps of green (in-contract HTTP port 80) trac and that the 1500 KBps burst
opon for red out-of-contract HTTP port 80 trac was exceeded.
Example: Conguring Interface and Firewall Filter Policers at the Same Interface
IN THIS SECTION
Requirements | 2059
Overview | 2060
Conguraon | 2061
Vericaon | 2071
This example shows how to congure three single-rate two-color policers and apply the policers to the
IPv4 input trac at the same single-tag virtual LAN (VLAN) logical interface.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
2059
Overview
IN THIS SECTION
Topology | 2060
In this example, you congure three single-rate two-color policers and apply the policers to the IPv4
input trac at the same single-tag VLAN logical interface. Two policers are applied to the interface
through a rewall lter, and one policer is applied directly to the interface.
You congure one policer, named p-all-1m-5k-discard, to rate-limit trac to 1 Mbps with a burst size of
5000 bytes. You apply this policer directly to IPv4 input trac at the logical interface. When you apply a
policer directly to protocol-specic trac at a logical interface, the policer is said to be applied as an
interface policer
.
You congure the other two policers to allow burst sizes of 500 KB, and you apply these policers to IPv4
input trac at the logical interface by using an IPv4 standard stateless rewall lter. When you apply a
policer to protocol-specic trac at a logical interface through a rewall lter acon, the policer is said
to be applied as a
rewall-lter policer
.
• You congure the policer named p-icmp-500k-500k-discard to rate-limit trac to 500 Kbps with a burst
size of 500 K bytes by discarding packets that do not conform to these limits. You congure one of
the rewall lter terms to apply this policer to Internet Control Message Protocol (ICMP) packets.
• You congure the policer named p-ftp-10p-500k-discard to rate-limit trac to a 10 percent bandwidth
with a burst size of 500 KB by discarding packets that do not conform to these limits. You congure
another rewall-lter term to apply this policer to File Transfer Protocol (FTP) packets.
A policer that you congure with a bandwidth limit expressed as a percentage value (rather than as an
absolute bandwidth value) is called a
bandwidth policer
. Only single-rate two-color policers can be
congured with a percentage bandwidth specicaon. By default, a bandwidth policer rate-limits trac
to the specied percentage of the line rate of the physical interface underlying the target logical
interface.
Topology
You congure the target logical interface as a single-tag VLAN logical interface on a Fast Ethernet
interface operang at 100 Mbps. This means that the policer you congure with the 10-percent
bandwidth-limit (the policer that you apply to FTP packets) rate-limits the FTP trac on this interface to
10 Mbps.
2060
NOTE: In this example, you do not congure the bandwidth policer as a
logical-bandwidth
policer
. Therefore, the percentage is based on the physical media rate rather than on the
congured shaping rate of the logical interface.
The rewall lter that you congure to reference two of the policers must be congured as an
interface-
specic lter
. Because the policer that is used to rate-limit FTP packets species the bandwidth limit as
a percentage value, the rewall lter that references this policer must be congured as an interface-
specic lter. Thus, if this rewall lter were to be applied to mulple interfaces instead of just the Fast
Ethernet interface in this example, unique policers and counters would be created for each interface to
which the lter is applied.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2061
Conguring the Single-Tag VLAN Logical Interface | 2062
Conguring the Three Policers | 2064
Conguring the IPv4 Firewall Filter | 2066
Applying the Interface Policer and Firewall Filter Policers to the Logical Interface | 2069
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces fe-0/1/1 vlan-tagging
set interfaces fe-0/1/1 unit 0 vlan-id 100
set interfaces fe-0/1/1 unit 0 family inet address 10.20.15.1/24
set interfaces fe-0/1/1 unit 1 vlan-id 101
2061
set interfaces fe-0/1/1 unit 1 family inet address 10.20.240.1/24
set firewall policer p-all-1m-5k-discard if-exceeding bandwidth-limit 1m
set firewall policer p-all-1m-5k-discard if-exceeding burst-size-limit 5k
set firewall policer p-all-1m-5k-discard then discard
set firewall policer p-ftp-10p-500k-discard if-exceeding bandwidth-percent 10
set firewall policer p-ftp-10p-500k-discard if-exceeding burst-size-limit 500k
set firewall policer p-ftp-10p-500k-discard then discard
set firewall policer p-icmp-500k-500k-discard if-exceeding bandwidth-limit 500k
set firewall policer p-icmp-500k-500k-discard if-exceeding burst-size-limit 500k
set firewall policer p-icmp-500k-500k-discard then discard
set firewall family inet filter filter-ipv4-with-limits interface-specific
set firewall family inet filter filter-ipv4-with-limits term t-ftp from protocol tcp
set firewall family inet filter filter-ipv4-with-limits term t-ftp from port ftp
set firewall family inet filter filter-ipv4-with-limits term t-ftp from port ftp-data
set firewall family inet filter filter-ipv4-with-limits term t-ftp then policer p-ftp-10p-500k-
discard
set firewall family inet filter filter-ipv4-with-limits term t-icmp from protocol icmp
set firewall family inet filter filter-ipv4-with-limits term t-icmp then policer p-
icmp-500k-500k-discard
set firewall family inet filter filter-ipv4-with-limits term catch-all then accept
set interfaces fe-0/1/1 unit 1 family inet filter input filter-ipv4-with-limits
set interfaces fe-0/1/1 unit 1 family inet policer input p-all-1m-5k-discard
Conguring the Single-Tag VLAN Logical Interface
Step-by-Step Procedure
To congure the single-tag VLAN logical interface:
1. Enable conguraon of the Fast Ethernet interface.
[edit]
user@host# edit interfaces fe-0/1/1
2. Enable single-tag VLAN framing.
[edit interfaces fe-0/1/1]
user@host# set vlan-tagging
2062
3. Bind VLAN IDs to the logical interfaces.
[edit interfaces fe-0/1/1]
user@host# set unit 0 vlan-id 100
user@host# set unit 1 vlan-id 101
4. Congure IPv4 on the single-tag VLAN logical interfaces.
[edit interfaces fe-0/1/1]
user@host# set unit 0 family inet address 10.20.15.1/24
user@host# set unit 1 family inet address 10.20.240.1/24
Results
Conrm the conguraon of the VLAN by entering the show interfaces conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
fe-0/1/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 10.20.15.1/24;
}
}
unit 1 {
vlan-id 101;
family inet {
address 10.20.240.1/24;
}
}
}
2063
Conguring the Three Policers
Step-by-Step Procedure
To congure the three policers:
1. Enable conguraon of a two-color policer that discards packets that do not conform to a bandwidth
of 1 Mbps and a burst size of 5000 bytes.
NOTE: You apply this policer directly to all IPv4 input trac at the single-tag VLAN logical
interface, so the packets will not be ltered before being subjected to rate liming.
[edit]
user@host# edit firewall policer p-all-1m-5k-discard
2. Congure the rst policer.
[edit firewall policer p-all-1m-5k-discard]
user@host# set if-exceeding bandwidth-limit 1m
user@host# set if-exceeding burst-size-limit 5k
user@host# set then discard
3. Enable conguraon of a two-color policer that discards packets that do not conform to a bandwidth
specied as “10 percent” and a burst size of 500,000 bytes.
You apply this policer only to the FTP trac at the single-tag VLAN logical interface.
You apply this policer as the acon of an IPv4 rewall lter term that matches FTP packets from TCP.
[edit firewall policer p-all-1m-5k-discard]
user@host# up
[edit]
user@host# edit firewall policer p-ftp-10p-500k-discard
2064
4. Congure policing limits and acons.
[edit firewall policer p-ftp-10p-500k-discard]
user@host# set if-exceeding bandwidth-percent 10
user@host# set if-exceeding burst-size-limit 500k
user@host# set then discard
Because the bandwidth limit is specied as a percentage, the rewall lter that references this policer
must be congured as an interface-specic lter.
NOTE: If you wanted this policer to rate-limit to 10 percent of the logical interface congured
shaping rate (rather than to 10 percent of the physical interface media rate), you would need
to include the logical-bandwidth-policer statement at the [edit firewall policer p-all-1m-5k-
discard] hierarchy level. This type of policer is called a
logical-bandwidth policer
.
5. Enable conguraon of the IPv4 rewall lter policer for ICMP packets.
[edit firewall policer p-ftp-10p-500k-discard]
user@host# up
[edit]
user@host# edit firewall policer p-icmp-500k-500k-discard
6. Congure policing limits and acons.
[edit firewall policer p-icmp-500k-500k-discard]
user@host# set if-exceeding bandwidth-limit 500k
user@host# set if-exceeding burst-size-limit 500k
user@host# set then discard
2065
Results
Conrm the conguraon of the policers by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
policer p-all-1m-5k-discard {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 5k;
}
then discard;
}
policer p-ftp-10p-500k-discard {
if-exceeding {
bandwidth-percent 10;
burst-size-limit 500k;
}
then discard;
}
policer p-icmp-500k-500k-discard {
if-exceeding {
bandwidth-limit 500k;
burst-size-limit 500k;
}
then discard;
}
Conguring the IPv4 Firewall Filter
Step-by-Step Procedure
To congure the IPv4 rewall lter:
1. Enable conguraon of the IPv4 rewall lter.
[edit]
user@host# edit firewall family inet filter filter-ipv4-with-limits
2066
2. Congure the rewall lter as interface-specic.
[edit firewall family inet filter filter-ipv4-with-limits]
user@host# set interface-specific
The rewall lter must be interface-specic because one of the policers referenced is congured with
a bandwidth limit expressed as a percentage value.
3. Enable conguraon of a lter term to rate-limit FTP packets.
[edit firewall family inet filter filter-ipv4-with-limits]
user@host# edit term t-ftp
[edit firewall family inet filter filter-ipv4-with-limits term t-ftp]
user@host# set from protocol tcp
user@host# set from port [ ftp ftp-data ]
FTP messages are sent over TCP port 20 (ftp) and received over TCP port 21 (ftp-data).
4. Congure the lter term to match FTP packets.
[edit firewall family inet filter filter-ipv4-with-limits term t-ftp]
user@host# set then policer p-ftp-10p-500k-discard
5. Enable conguraon of a lter term to rate-limit ICMP packets.
[edit firewall family inet filter filter-ipv4-with-limits term t-ftp]
user@host# up
[edit firewall family inet filter filter-ipv4-with-limits]
user@host# edit term t-icmp
6. Congure the lter term for ICMP packets
[edit firewall family inet filter filter-ipv4-with-limits term t-icmp]
user@host# set from protocol icmp
user@host# set then policer p-icmp-500k-500k-discard
2067
7. Congure a lter term to accept all other packets without policing.
[edit firewall family inet filter filter-ipv4-with-limits term t-icmp]
user@host# up
[edit firewall family inet filter filter-ipv4-with-limits]
user@host# set term catch-all then accept
Results
Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter filter-ipv4-with-limits {
interface-specific;
term t-ftp {
from {
protocol tcp;
port [ ftp ftp-data ];
}
then policer p-ftp-10p-500k-discard;
}
term t-icmp {
from {
protocol icmp;
}
then policer p-icmp-500k-500k-discard;
}
term catch-all {
then accept;
}
}
}
policer p-all-1m-5k-discard {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 5k;
2068
}
then discard;
}
policer p-ftp-10p-500k-discard {
if-exceeding {
bandwidth-percent 10;
burst-size-limit 500k;
}
then discard;
}
policer p-icmp-500k-500k-discard {
if-exceeding {
bandwidth-limit 500k;
burst-size-limit 500k;
}
then discard;
}
Applying the Interface Policer and Firewall Filter Policers to the Logical Interface
Step-by-Step Procedure
To apply the three policers to the VLAN:
1. Enable conguraon of IPv4 on the logical interface.
[edit]
user@host# edit interfaces fe-0/1/1 unit 1 family inet
2. Apply the rewall lter policers to the interface.
[edit interfaces fe-0/1/1 unit 1 family inet]
user@host# set filter input filter-ipv4-with-limits
3. Apply the interface policer to the interface.
[edit interfaces fe-0/1/1 unit 1 family inet]
user@host# set policer input p-all-1m-5k-discard
2069
Input packets at fe-0/1/1.0 are evaluated against the interface policer before they are evaluated
against the rewall lter policers. For more informaon, see "Order of Policer and Firewall Filter
Operaons" on page 1930.
Results
Conrm the conguraon of the interface by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
fe-0/1/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 10.20.15.1/24;
}
}
unit 1 {
vlan-id 101;
family inet {
filter {
input filter-ipv4-with-limits;
}
policer {
input p-all-1m-5k-discard;
}
address 10.20.240.1/24;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
2070
Vericaon
IN THIS SECTION
Displaying Policers Applied Directly to the Logical Interface | 2071
Displaying Stascs for the Policer Applied Directly to the Logical Interface | 2071
Displaying the Policers and Firewall Filters Applied to an Interface | 2072
Displaying Stascs for the Firewall Filter Policers | 2073
Conrm that the conguraon is working properly.
Displaying Policers Applied Directly to the Logical Interface
Purpose
Verify that the interface policer is evaluated when packets are received on the logical interface.
Acon
Use the show interfaces policers operaonal mode command for logical interface fe-0/1/1.1. The command
output secon for the Proto column and Input Policer column shows that the policer p-all-1m-5k-discard
is evaluated when packets are received on the logical interface.
user@host> show interfaces policers fe-0/1/1.1
Interface Admin Link Proto Input Policer Output Policer
fe-0/1/1.1 up up
inet p-all-1m-5k-discard-fe-0/1/1.1-inet-i
In this example, the interface policer is applied to logical interface trac in the input direcon only.
Displaying Stascs for the Policer Applied Directly to the Logical Interface
Purpose
Verify the number of packets evaluated by the interface policer.
2071
Acon
Use the show policer operaonal mode command and oponally specify the name of the policer. The
command output displays the number of packets evaluated by each congured policer (or the specied
policer), in each direcon.
user@host> show policer p-all-1m-5k-discard-fe-0/1/1.1-inet-i
Policers:
Name Bytes Packets
p-all-1m-5k-discard-fe-0/1/1.1-inet-i 200 5
Displaying the Policers and Firewall Filters Applied to an Interface
Purpose
Verify that the rewall lter filter-ipv4-with-limits is applied to the IPv4 input trac at logical interface
fe-0/1/1.1.
Acon
Use the show interfaces statistics operaonal mode command for logical interface fe-0/1/1.1, and include
the detail opon. Under the Protocol inet secon of the command output secon, the Input Filters and
Policer lines display the names of lter and policer applied to the logical interface in the input direcon.
user@host> show interfaces statistics fe-0/1/1.1 detail
Logical interface fe-0/1/1.1 (Index 83) (SNMP ifIndex 545) (Generation 153)
Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.100 ] Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 46
Input packets: 0
Output packets: 1
Local statistics:
Input bytes : 0
Output bytes : 46
Input packets: 0
Output packets: 1
Transit statistics:
Input bytes : 0 0 bps
2072
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 176, Route table: 0
Flags: Sendbcast-pkt-to-re
Input Filters: filter-ipv4-with-limits-fe-0/1/1.1-i
Policer: Input: p-all-1m-5k-discard-fe-0/1/1.1-inet-i
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.20.130/24, Local: 10.20.130.1, Broadcast: 10.20.130.255,
Generation: 169
In this example, the two rewall lter policers are applied to logical interface trac in the input direcon
only.
Displaying Stascs for the Firewall Filter Policers
Purpose
Verify the number of packets evaluated by the rewall lter policers.
Acon
Use the show firewall operaonal mode command for the lter you applied to the logical interface.
[edit]
user@host> show firewall filter filter-ipv4-with-limits-fe-0/1/1.1-i
Filter: filter-ipv4-with-limits-fe-0/1/1.1-i
Policers:
Name Bytes Packets
p-ftp-10p-500k-discard-t-ftp-fe-0/1/1.1-i 0 0
p-icmp-500k-500k-discard-t-icmp-fe-0/1/1.1-i 0 0
The command output displays the names of the policers (p-ftp-10p-500k-discard and p-icmp-500k-500k-
discard), combined with the names of the lter terms (t-ftp and t-icmp, respecvely) under which the
policer acon is specied. The policer-specic output lines display the number of packets that matched
the lter term. This is only the number of out-of-specicaon (out-of-spec) packet counts, not all
packets policed by the policer.
2073
SEE ALSO
Order of Policer and Firewall Filter Operaons | 1930
Two-Color Policer Conguraon Overview | 2038
Single-Rate Two-Color Policer Overview
Example: Liming Inbound Trac at Your Network Border by Conguring an Ingress Single-Rate
Two-Color Policer
RELATED DOCUMENTATION
Order of Policer and Firewall Filter Operaons | 1930
Two-Color Policer Conguraon Overview | 2038
Guidelines for Applying Trac Policers | 1938
Determining Proper Burst Size for Trac Policers | 1912
Bandwidth Policers
IN THIS SECTION
Bandwidth Policer Overview | 2074
Example: Conguring a Logical Bandwidth Policer | 2076
Bandwidth Policer Overview
IN THIS SECTION
Guidelines for Conguring a Bandwidth Policer | 2075
Guidelines for Applying a Bandwidth Policer | 2075
For a single-rate two-color policer only, you can specify the bandwidth limit as a percentage value from
1 through 100 instead of as an absolute number of bits per second. This type of two-color policer, called
2074
a
bandwidth policer
, rate-limits trac to a bandwidth limit that is calculated as a percentage of either
the physical interface media rate or the
logical interface
congured shaping rate.
Guidelines for Conguring a Bandwidth Policer
The following guidelines apply to conguring a bandwidth policer:
• To specify a percentage bandwidth limit, you include the bandwidth-percent
percentage
statement
in place of the bandwidth-limit
bps
statement.
• By default, a bandwidth policer calculates the percentage bandwidth limit based on the physical
interface port speed. To congure a bandwidth policer to calculate the percentage bandwidth limit
based on the congured logical interface shaping rate instead, include the logical-bandwidth-policer
statement at the [edit firewall policer
policer-name
] hierarchy level. This type of bandwidth policer is
called a
logical bandwidth policer
.
You can congure a logical interface shaping rate by including the shaping-rate
bps
statement at the
[edit class-of-service interfaces interface
interface-name
unit
logical-unit-number
] hierarchy level. A
logical interface shaping rate causes the specied amount of bandwidth to be allocated to the logical
interface.
NOTE: If you congure a logical-bandwidth policer and then apply the policer to a logical
interface that is not congured with a shaping rate, then the policer rate-limits trac on that
logical interface to calculate the percentage bandwidth limit based on the physical interface
port speed, even if you include the logical-bandwidth-policer statement in the bandwidth policer
conguraon.
• If you reference a bandwidth policer from a stateless
rewall lter
term, you must include the
interface-specific statement in the rewall lter conguraon.
Guidelines for Applying a Bandwidth Policer
The following guidelines pertain to applying a bandwidth policer to trac:
• You can use a bandwidth policer to rate-limit protocol-specic trac (not family any) at the input or
output of a logical interface.
• You can apply a bandwidth policer directly to protocol-specic input or output trac at a logical
interface.
• To send only selected packets to a bandwidth policer, you can reference the bandwidth policer from
a stateless rewall lter term and then apply the lter to logical interface trac for a specic
protocol family.
2075
• To reference a
logical bandwidth policer
from a rewall lter, you must include the interface-
specific statement in the rewall lter conguraon.
• You cannot use a bandwidth policer for forwarding-table lters.
• You cannot apply a bandwidth policer to an aggregate interface, a tunnel interface, or a soware
interface.
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Example: Conguring a Logical Bandwidth Policer
bandwidth-percent
interface-specic
logical-bandwidth-policer
shaping-rate (Applying to an Interface)
Example: Conguring a Logical Bandwidth Policer
IN THIS SECTION
Requirements | 2076
Overview | 2077
Conguraon | 2078
Vericaon | 2084
This example shows how to congure a logical bandwidth policer.
Requirements
Before you begin, make sure that you have two logical units available on a Gigabit Ethernet interface.
2076
Overview
IN THIS SECTION
Topology | 2077
In this example, you congure a single-rate two-color policer that species the bandwidth limit as a
percentage value rather than as an absolute number of bits per second. This type of policer is called a
bandwidth policer
. By default, a bandwidth policer enforces a bandwidth limit based on the line rate of
the underlying physical interface. As an opon, you can congure a bandwidth policer to enforce a
bandwidth limit based on the congured shaping rate of the logical interface. To congure this type of
bandwidth policer, called a
logical bandwidth policer
, you include the logical-bandwidth-policer statement
in the policer conguraon.
To congure a logical interface shaping rate, include the shaping-rate
bps
statement at the [edit class-of-
service interfaces interface
interface-name
unit
logical-unit-number
] hierarchy level. This class-of-service
(CoS) conguraon statement causes the specied amount of bandwidth to be allocated to the logical
interface.
NOTE: If you congure a policer bandwidth limit as a percentage but a shaping rate is not
congured for the target logical interface, the policer bandwidth limit is calculated as a
percentage of the physical interface media rate, even if you enable the logical-bandwidth policing
feature.
To apply a logical bandwidth policer to a logical interface, you can apply the policer directly to the logical
interface at the protocol family level or (if you only need to rate-limit ltered packets) you can reference
the policer from a stateless rewall lter congured to operate in
interface-specic
mode.
Topology
In this example, you congure two logical interfaces on a single Gigabit Ethernet interface and congure
a shaping rate on each logical interface. On logical interface ge-1/3/0.0, you allocate 4 Mbps of
bandwidth. On logical interface ge-1/3/0.1, you allocate 2 Mbps of bandwidth.
You also congure a logical bandwidth policer with a bandwidth limit of 50 percent and a maximum
burst size of 125,000 bytes, and then you apply the policer to input and output trac at the logical units
congured on ge-1/3/0.0. For logical interface ge-1/3/0.0, the policer rate-limits to a bandwidth limit of
2 Mbps (50 percent of the 4 Mbps shaping rate congured for the logical interface). For logical interface
2077
ge-1/3/0.1, the policer rate-limits trac to a bandwidth limit of 1 Mbps (50 percent of the 2 Mbps
shaping rate congured for the logical interface).
If no shaping rate is congured for a target logical interface, the policer rate-limits to a bandwidth limit
calculated as 50 percent of the physical interface media rate. For example, if you apply a 50 percent
bandwidth policer to input or output trac at a Gigabit Ethernet logical interface without rate shaping,
the policer applies a bandwidth limit of 500 Mbps (50 percent of 1000 Mbps).
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2078
Conguring the Logical Interfaces | 2079
Conguring Trac Rate-Shaping by Specifying the Amount of Bandwidth to be Allocated to the Logical
Interface | 2080
Conguring the Logical Bandwidth Policer | 2081
Applying the Logical Bandwidth Policers to the Logical Interfaces | 2082
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-1/3/0 per-unit-scheduler
set interfaces ge-1/3/0 vlan-tagging
set interfaces ge-1/3/0 unit 0 vlan-id 100
set interfaces ge-1/3/0 unit 0 family inet address 172.16.1.1/30
set interfaces ge-1/3/0 unit 1 vlan-id 200
set interfaces ge-1/3/0 unit 1 family inet address 172.16.2.1/30
set class-of-service interfaces ge-1/3/0 unit 0 shaping-rate 4m
set class-of-service interfaces ge-1/3/0 unit 1 shaping-rate 2m
set firewall policer LB-policer logical-bandwidth-policer
2078
set firewall policer LB-policer if-exceeding bandwidth-percent 50
set firewall policer LB-policer if-exceeding burst-size-limit 125k
set firewall policer LB-policer then discard
set interfaces ge-1/3/0 unit 0 family inet policer input LB-policer
set interfaces ge-1/3/0 unit 0 family inet policer output LB-policer
set interfaces ge-1/3/0 unit 1 family inet policer input LB-policer
set interfaces ge-1/3/0 unit 1 family inet policer output LB-policer
Conguring the Logical Interfaces
Step-by-Step Procedure
To congure the logical interfaces:
1. Enable conguraon of the physical interface.
[edit]
user@host# edit interfaces ge-1/3/0
[edit interfaces ge-1/3/0]
user@host# set per-unit-scheduler
user@host# set vlan-tagging
2. Congure the rst logical interface.
[edit interfaces ge-1/3/0]
user@host# set unit 0 vlan-id 100
user@host# set unit 0 family inet address 172.16.1.1/30
3. Congure the second logical interface.
[edit interfaces ge-1/3/0]
user@host# set unit 1 vlan-id 200
user@host# set unit 1 family inet address 172.16.2.1/30
2079
Results
Conrm the conguraon of the interfaces by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/0 {
per-unit-scheduler;
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 172.16.1.1/30;
}
}
unit 1 {
vlan-id 200;
family inet {
address 172.16.2.1/30;
}
}
}
Conguring Trac Rate-Shaping by Specifying the Amount of Bandwidth to be Allocated to the Logical
Interface
Step-by-Step Procedure
To congure rate shaping by specifying the bandwidth to be allocated to the logical interface:
1. Enable CoS conguraon on the physical interface.
[edit]
user@host# edit class-of-service interfaces ge-1/3/0
2080
2. Congure rate shaping for the logical interfaces.
[edit class-of-service interfaces ge-1/3/0]
user@host# set unit 0 shaping-rate 4m
user@host# set unit 1 shaping-rate 2m
These statements allocate 4 Mbps of bandwidth to logical unit ge-1/3/0.0 and 2 Mbps of bandwidth to
logical unit ge-1/3/0.1.
Results
Conrm the conguraon of the rate shaping by entering the show class-of-service conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show class-of-service
interfaces {
ge-1/3/0 {
unit 0 {
shaping-rate 4m;
}
unit 1 {
shaping-rate 2m;
}
}
}
Conguring the Logical Bandwidth Policer
Step-by-Step Procedure
To congure the logical bandwidth policer:
1. Enable conguraon of a single-rate two-color policer.
[edit]
user@host# edit firewall policer LB-policer
2081
2. Congure the policer as a logical-bandwidth policer.
[edit firewall policer LB-policer]
user@host# set logical-bandwidth-policer
This applies the rate-liming to logical interfaces.
3. Congure the policer trac limits and acons.
[edit firewall policer LB-policer]
user@host# set if-exceeding bandwidth-percent 50
user@host# set if-exceeding burst-size-limit 125k
user@host# set then discard
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
policer LB-policer {
logical-bandwidth-policer;
if-exceeding {
bandwidth-percent 50;
burst-size-limit 125k;
}
then discard;
}
Applying the Logical Bandwidth Policers to the Logical Interfaces
Step-by-Step Procedure
To congure the logical bandwidth policers to the logical interfaces:
2082
1. Enable conguraon of the interface.
[edit]
user@host# edit interfaces ge-1/3/0
2. Apply the logical bandwidth policer to the rst logical interface.
[edit interfaces ge-1/3/0]
user@host# set unit 0 family inet policer input LB-policer
user@host# set unit 0 family inet policer output LB-policer
3. Apply the policing to the second logical interface.
[edit interfaces ge-1/3/0]
user@host# set unit 1 family inet policer input LB-policer
user@host# set unit 1 family inet policer output LB-policer
Results
Conrm the conguraon of the interfaces by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/0 {
per-unit-scheduler;
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
policer {
input LB-policer;
output LB-policer;
}
address 172.16.1.1/30;
}
}
unit 1 {
2083
vlan-id 200;
family inet {
policer {
input LB-policer;
output LB-policer;
}
address 172.16.2.1/30;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying Trac Stascs and Policers for the Logical Interface | 2084
Displaying Stascs for the Policer | 2086
Conrm that the conguraon is working properly.
Displaying Trac Stascs and Policers for the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show interfaces operaonal mode command for logical interfaces ge-1/3/0.0 and ge-1/3/0.1, and
include the detail or extensive opon. The command output secon for Trac stascs lists the number
of bytes and packets received and transmied on the logical interface, and the Protocol inet secon
contains a Policer eld that lists the policer LB-policer as an input or output policer as follows:
• Input: LB-policer-ge-1/3/0.0-inet-i
• Output: LB-policer-ge-1/3/0.0-inet-o
2084
In this example, the policer is applied to logical interface trac in both the input and output direcons.
user@host> show interfaces ge-1/3/0.0 detail
Logical interface ge-1/3/0.0 (Index 80) (SNMP ifIndex 154) (Generation 150)
Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.100 ] Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 46
Input packets: 0
Output packets: 1
Local statistics:
Input bytes : 0
Output bytes : 46
Input packets: 0
Output packets: 1
Transit statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 174, Route table: 0
Flags: Sendbcast-pkt-to-re
Policer: Input: LB-policer-ge-1/3/0.0-inet-i, Output: LB-policer-ge-1/3/0.0-inet-o
Addresses, Flags: Is-Preferred Is-Primary
Destination: 172.16.1.0/30, Local: 172.16.1.1, Broadcast: 172.16.1.3, Generation: 165
user@host> show interfaces ge-1/3/0.1 detail
Logical interface ge-1/3/0.1 (Index 81) (SNMP ifIndex 543) (Generation 151)
Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.200 ] Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 46
Input packets: 0
Output packets: 1
Local statistics:
Input bytes : 0
Output bytes : 46
Input packets: 0
Output packets: 1
Transit statistics:
Input bytes : 0 0 bps
2085
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 175, Route table: 0
Flags: Sendbcast-pkt-to-re
Policer: Input: LB-policer-ge-1/3/0.1-inet-i, Output: LB-policer-ge-1/3/0.1-inet-o
Addresses, Flags: Is-Preferred Is-Primary
Destination: 172.17.1.0/30, Local: 172.17.1.1, Broadcast: 172.17.1.3, Generation: 167
Displaying Stascs for the Policer
Purpose
Verify the number of packets evaluated by the policer.
Acon
Use the show policer operaonal mode command and oponally specify the name of the policer. The
command output displays the number of packets evaluated by each congured policer (or the specied
policer), in each direcon. For the policer LB-policer, the input and output policer names are displayed as
follows:
• LB-policer-ge-1/3/0.0-inet-i
• LB-policer-ge-1/3/0.0-inet-o
• LB-policer-ge-1/3/0.1-inet-i
• LB-policer-ge-1/3/0.1-inet-o
The -inet-i sux denotes a policer applied to logical interface input trac, while the -inet-o sux
denotes a policer applied to logical interface output trac. In this example, the policer is applied to both
input and output trac on logical interface ge-1/3/0.0 and logical interface ge-1/3/0.1.
user@host> show policer
Policers:
Name Packets
__default_arp_policer__ 0
LB-policer-ge-1/3/0.0-inet-i 0
LB-policer-ge-1/3/0.0-inet-o 0
LB-policer-ge-1/3/0.1-inet-i 0
LB-policer-ge-1/3/0.1-inet-o 0
2086
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Bandwidth Policer Overview
bandwidth-percent
interface-specic
logical-bandwidth-policer
shaping-rate (Applying to an Interface)
RELATED DOCUMENTATION
Two-Color Policer Conguraon Overview | 2038
Guidelines for Applying Trac Policers | 1938
bandwidth-percent
interface-specic (Firewall Filters)
logical-bandwidth-policer
shaping-rate (Applying to an Interface)
Prex-Specic Counng and Policing Acons
IN THIS SECTION
Prex-Specic Counng and Policing Overview | 2088
Filter-Specic Counter and Policer Set Overview | 2091
Filter-Specic Policer Overview | 2091
Example: Conguring Prex-Specic Counng and Policing | 2092
Prex-Specic Counng and Policing Conguraon Scenarios | 2102
2087
Prex-Specic Counng and Policing Overview
IN THIS SECTION
Separate Counng and Policing for Each IPv4 Address Range | 2088
Prex-Specic Acon Conguraon | 2088
Counter and Policer Set Size and Indexing | 2089
Separate Counng and Policing for Each IPv4 Address Range
Prex-specic counng and policing enables you to congure an IPv4
rewall lter
term that matches
on a source or desnaon address, applies a single-rate two-color policer as the term acon, but
associates the matched packet with a specic counter and policer instance based on the source or
desnaon in the packet header. You can implicitly create a separate counter or policer instance for a
single address or for a group of addresses.
Prex-specic counng and policing uses a
prex-specic acon
conguraon that species the name
of the policer you want to apply, whether prex-specic counng is to be enabled, and a source or
desnaon address prex range.
The prex range species between 1 and 16 sequenal set bits of an IPv4 address mask. The length of
the prex range determines the size of the counter and policer
set
, which consists of as few as 2 or as
many as 65,536 counter and policer instances. The posion of the bits of the prex range determines
the indexing of lter-matched packets into the set of instances.
NOTE: A prex-specic acon is specic to a source or desnaon
prex range
, but it is not
specic to a parcular source or desnaon
address range
, and it is not specic to a parcular
interface.
To apply a prex-specic acon to the trac at an interface, you congure a rewall lter term that
matches on source or desnaon addresses, and then you apply the rewall lter to the interface. The
ow of ltered trac is rate-limited using prex-specic counter and policer instances that are selected
per packet based on the source or desnaon address in the header of the ltered packet.
Prex-Specic Acon Conguraon
To congure a prex-specic acon, you specify the following informaon:
2088
• Prex-specic acon name—Name that can be referenced as the acon of an IPv4 standard rewall
lter term that matches packets on source or desnaon addresses.
• Policer name—Name of a single-rate two-color policer for which you want to implicitly create prex-
specic instances.
NOTE: For aggregated Ethernet interfaces, you can congure a prex-specic acon that
references a logical interface policer (also called an aggregate policer). You can reference this
type of prex-specic acon from an IPv4 standard rewall lter and then apply the lter at
the aggregate level of the interface.
• Counng opon—Opon to include if you want to enable prex-specic counters.
• Filter-specic opon—Opon to include if you want a single counter and policer set to be shared
across all terms in the rewall lter. A prex-specic acon that operates in this way is said to
operate in
lter-specic
mode. If you do not enable this opon, the prex-specic acon operates in
term-specic
mode, meaning that a separate counter and policer set is created for each lter term
that references the prex-specic acon.
• Source address prex length—Length of the address prex, from 0 through 32, to be used with a
packet matched on the source address.
• Desnaon address prex length—Length of the address prex, from 0 through 32, to be used with a
packet matched on the desnaon address.
• Subnet prex length—Length of the subnet prex, from 0 through 32, to be used with a packet
matched on either the source or desnaon address.
You must congure source and desnaon address prex lengths to be from 1 to 16 bits longer than the
subnet prex length. If you congure source or desnaon address prex lengths to be more
than 16 bits beyond the congured subnet prex length, an error occurs when you try to commit the
conguraon.
Counter and Policer Set Size and Indexing
The number of prex-specic acons (counters or policers) implicitly created for a prex-specic acon
is determined by the length of the address prex and the length of the subnet prex:
1. Size of Counter and Policer Set = 2^(
source-or-desnaon-prex-length
-
subnet-prex-length
)
Table 116 on page 2090 shows examples of counter and policer set size and indexing.
2089
Table 116: Examples of Counter and Policer Set Size and Indexing
Example Prex Lengths
Specied in the Prex-Specic
Acon
Calculaon of Counter or Policer Set Size Indexing of Instances
source-prex-length
= 32
subnet-prex-length
= 16
Size = 2^(32 -
16) = 2^16 = 65,536 instances
NOTE: This calculaon shows the largest
counter or policer set size supported.
Instance 0:
x
.
x
.0.0
Instance 1:
x
.
x
.0.1
Instance 65535:
x
.
x
.255.255
source-prex-length
= 32
subnet-prex-length
= 24
Size = 2^(32 - 24) = 2^8 = 256 instances Instance 0:
x
.
x
.
x
.0
Instance 1:
x
.
x
.
x
.1
Instance 255:
x
.
x
.
x
.255
source-prex-length
= 32
subnet-prex-length
= 25
Size = 2^(32 - 25) = 2^7 = 128 instances Instance 0:
x
.
x
.
x
.0
Instance 1:
x
.
x
.
x
.1
Instance 127:
x
.
x
.
x
.127
source-prex-length
= 24
subnet-prex-length
= 20
Size = 2^(24 - 20) = 2^4 = 16 instances Instance 0:
x
.
x
.0.
x
Instance 1:
x
.
x
.1.
x
Instance 15:
x
.
x
.15.
x
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Filter-Specic Counter and Policer Set Overview
Example: Conguring Prex-Specic Counng and Policing
2090
Prex-Specic Counng and Policing Conguraon Scenarios
prex-acon (Conguring)
prex-acon (Firewall Filter Acon)
Filter-Specic Counter and Policer Set Overview
By default, a prex-specic policer set operates in
term-specic
mode so that, for a given
rewall lter
,
the Junos OS creates a separate counter and policer set for every lter term that references the prex-
specic acon. As an opon, you can congure a prex-specic policer set to operate in
lter-specic
mode so that a single prex-specic policer set is used by all terms (within the same rewall lter) that
reference the policer.
For an IPv4 rewall lter with mulple terms that reference the same prex-specic policer set,
conguring the policer set to operate in lter-specic mode enables you to count and monitor the
acvity of the policer set at the rewall lter level.
NOTE: Term-specic mode and lter-specic mode also apply to policers. See Filter-Specic
Policer Overview.
To enable a prex-specic policer set to operate in lter-specic mode, you can include the filter-
specific statement at the following the hierarchy levels:
• [edit firewall family inet prefix-action
prefix-action-name
]
• [edit logical-systems
logical-system-name
firewall family inet prefix-action
prefix-action-name
]
You can reference lter-specic, prex-specic policer sets from IPv4 (family inet) rewall lters only.
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Prex-Specic Counng and Policing Overview
Example: Conguring Prex-Specic Counng and Policing
Prex-Specic Counng and Policing Conguraon Scenarios
Filter-Specic Policer Overview
By default, a policer operates in
term-specic
mode so that, for a given
rewall lter
, the Junos OS
creates a separate policer instance for every lter term that references the policer. As an opon, you can
congure a policer to operate in
lter-specic
mode so that a single policer instance is used by all terms
(within the same rewall lter) that reference the policer.
2091
For an IPv4 rewall lter with mulple terms that reference the same policer, conguring the policer to
operate in lter-specic mode enables you to count and monitor the acvity of the policer at the rewall
lter level.
NOTE: Term-specic mode and lter-specic mode also apply to prex-specic policer sets.
To enable a single-rate two-color policer to operate in lter-specic mode, you can include the filter-
specific statement at the following hierarchy levels:
• [edit firewall policer
policer-name
]
• [edit logical-systems
logical-system-name
firewall policer
policer-name
]
You can reference lter-specic policers from IPv4 (family inet) rewall lters only.
Example: Conguring Prex-Specic Counng and Policing
IN THIS SECTION
Requirements | 2092
Overview | 2092
Conguraon | 2094
Vericaon | 2100
This example shows how to congure prex-specic counng and policing.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 2093
2092
In this example, you congure prex-specic counng and policing based on the last octet of the source
address eld in packets matched by an IPv4 rewall lter.
The single-rate two-color policer named 1Mbps-policer rate-limits trac to a bandwidth of 1,000,000 bps
and a burst-size limit of 63,000 bytes, discarding any packets in a trac ow that exceeds the trac
limits.
Independent of the IPv4 addresses contained in any packets passed from a rewall lter, the prex-
specic acon named psa-1Mbps-per-source-24-32-256 species a set of 256 counters and policers,
numbered from 0 through 255. For each packet, the last octet of the source address eld is used to
index into the associated prex-specic counter and policer in the set:
• Packets with a source address ending with the octet 0x0000 00000 index the rst counter and
policer in the set.
• Packets with a source address ending with the octet 0x0000 0001 index the second counter and
policer in the set.
• Packets with a source address ending with the octet 0x1111 1111 index the last counter and policer
in the set.
The limit-source-one-24 rewall lter contains a single term that matches all packets from the /24 subnet
of source address 10.10.10.0, passing these packets to the prex-specic acon psa-1Mbps-per-
source-24-32-256.
Topology
In this example, because the lter term matches the /24 subnet of a single source address, each counng
and policing instance in the prex-specic set is used for only one source address.
• Packets with a source address 10.10.10.0 index the rst counter and policer in the set.
• Packets with a source address 10.10.10.1 index the second counter and policer in the set.
• Packets with a source address 10.10.10.255 index the last counter and policer in the set.
This example shows the simplest case of prex-specic acons, in which the lter term matches on one
address with a prex length that is the same as the prex length specied in the prex-specic acon
for indexing into the set of prex-specic counters and policers.
For descripons of other conguraons for prex-specic counng and policing, see Prex-Specic
Counng and Policing Conguraon Scenarios.
2093
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2094
Conguring a Policer for Prex-Specic Counng and Policing | 2095
Conguring a Prex-Specic Acon Based on the Policer | 2096
Conguring an IPv4 Filter That References the Prex-Specic Acon | 2097
Applying the Firewall Filter to IPv4 Input Trac at a Logical Interface | 2099
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall policer 1Mbps-policer if-exceeding bandwidth-limit 1m
set firewall policer 1Mbps-policer if-exceeding burst-size-limit 63k
set firewall policer 1Mbps-policer then discard
set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 policer 1Mbps-policer
set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 count
set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 subnet-prefix-length 24
set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 source-prefix-length 32
set firewall family inet filter limit-source-one-24 term one from source-address 10.10.10.0/24
set firewall family inet filter limit-source-one-24 term one then prefix-action psa-1Mbps-per-
source-24-32-256
set interfaces so-0/0/2 unit 0 family inet filter input limit-source-one-24
set interfaces so-0/0/2 unit 0 family inet address 10.39.1.1/16
2094
Conguring a Policer for Prex-Specic Counng and Policing
Step-by-Step Procedure
To congure a policer to be used for prex-specic counng and policing:
1. Enable conguraon of a single-rate two-color policer.
[edit]
user@host# edit firewall policer 1Mbps-policer
2. Dene the trac limit.
[edit firewall policer 1Mbps-policer]
user@host# set if-exceeding bandwidth-limit 1m
user@host# set if-exceeding burst-size-limit 63k
Packets in a trac ow that conforms to this limit are passed with the PLP set to low.
3. Dene the acons for nonconforming trac.
[edit firewall policer 1Mbps-policer]
user@host# set then discard
Packets in a trac ow that exceeds this limit are discarded. Other congurable acons for a single-
rate two-color policer are to set the forwarding class and to set the PLP level.
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
2095
then discard;
}
Conguring a Prex-Specic Acon Based on the Policer
Step-by-Step Procedure
To congure a prex-specic acon that references the policer and species a poron of a source
address prex:
1. Enable conguraon of a prex-specic acon.
[edit]
user@host# edit firewall family inet prefix-action psa-1Mbps-per-source-24-32-256
Prex-specic counng and policing can be dened for IPv4 trac only.
2. Reference the policer for which a prex-specic set is to be created.
[edit firewall family inet prefix-action psa-1Mbps-per-source-24-32-256]
user@host# set policer 1Mbps-policer
user@host# set count
NOTE: For aggregated Ethernet interfaces, you can congure a prex-specic acon that
references a logical interface policer (also called an aggregate policer). You can reference this
type of prex-specic acon from an IPv4 standard rewall lter and then apply the lter at
the aggregate level of the interface.
3. Specify the prex range on which IPv4 addresses are to be indexed to the counter and policer set.
[edit firewall family inet prefix-action psa-1Mbps-per-source-24-32-256]
user@host# set source-prefix-length 32
user@host# set subnet-prefix-length 24
2096
Results
Conrm the conguraon of the prex-specic acon by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
then discard;
}
family inet {
prefix-action psa-1Mbps-per-source-24-32-256 {
policer 1Mbps-policer;
subnet-prefix-length 24;
source-prefix-length 32;
}
}
Conguring an IPv4 Filter That References the Prex-Specic Acon
Step-by-Step Procedure
To congure an IPv4 standard rewall lter that references the prex-specic acon:
1. Enable conguraon of the IPv4 standard rewall lter.
[edit]
user@host# edit firewall family inet filter limit-source-one-24
Prex-specic counng and policing can be dened for IPv4 trac only.
2. Congure the lter term to match on the packet source address or desnaon address.
[edit firewall family inet filter limit-source-one-24]
user@host# set term one from source-address 10.10.10.0/24
2097
3. Congure the lter term to reference the prex-specic acon.
[edit firewall family inet filter limit-source-one-24]
user@host# set term one then prefix-action psa-1Mbps-per-source-24-32-256
You could also use the next term acon to congure all Hypertext Transfer Protocol (HTTP) trac to
each host to transmit at 500 Kbps and have the total HTTP trac limited to 1 Mbps.
Results
Conrm the conguraon of the prex-specic acon by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
then discard;
}
family inet {
prefix-action psa-1Mbps-per-source-24-32-256 {
policer 1Mbps-policer;
subnet-prefix-length 24;
source-prefix-length 32;
}
filter limit-source-one-24 {
term one {
from {
source-address {
10.10.10.0/24;
}
}
then prefix-action psa-1Mbps-per-source-24-32-256;
}
}
}
2098
Applying the Firewall Filter to IPv4 Input Trac at a Logical Interface
Step-by-Step Procedure
To apply the rewall lter to IPv4 input trac at a logical interface:
1. Enable conguraon of IPv4 on the logical interface.
[edit]
user@host# edit interfaces so-0/0/2 unit 0 family inet
2. Congure an IP address.
[edit interfaces so-0/0/2 unit 0 family inet]
user@host# set address 10.39.1.1/16
3. Apply the IPv4 standard stateless rewall lter.
[edit interfaces so-0/0/2 unit 0 family inet]
user@host# set filter input limit-source-one-24
Results
Conrm the conguraon of the prex-specic acon by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
so-0/0/2 {
unit 0 {
family inet {
filter {
input limit-source-one-24;
}
address 10.39.1.1/16;
}
2099
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying the Firewall Filters Applied to an Interface | 2100
Displaying Prex-Specic Acons Stascs for the Firewall Filter | 2101
Conrm that the conguraon is working properly.
Displaying the Firewall Filters Applied to an Interface
Purpose
Verify that the rewall lter limit-source-one-24 is applied to the IPv4 input trac at logical interface
so-0/0/2.0.
Acon
Use the show interfaces statistics operaonal mode command for logical interface so-0/0/2.0, and include
the detail opon. In the command output secon for Protocol inet, the Input Filters eld displays limit-
source-one-24, indicang that the lter is applied to IPv4 trac in the input direcon:
user@host> show interfaces statistics so-0/0/2.0 detail
Logical interface so-0/0/2.0 (Index 79) (SNMP ifIndex 510) (Generation 149)
Flags: Hardware-Down Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPP
Protocol inet, MTU: 4470, Generation: 173, Route table: 0
Flags: Sendbcast-pkt-to-re, Protocol-Down
Input Filters: limit-source-one-24
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 10.39/16, Local: 10.39.1.1, Broadcast: 10.39.255.255, Generation: 163
2100
Displaying Prex-Specic Acons Stascs for the Firewall Filter
Purpose
Verify the number of packets evaluated by the policer.
Acon
Use the show firewall prefix-action-stats filter
filter-name
prefix-action
name
operaonal mode command
to display stascs about a prex-specic acon congured on a rewall lter.
As an opon, you can use the from
set-index
to
set-index
command opon to specify the starng and
ending counter or policer to be displayed. A policer set is indexed from 0 through 65535.
The command output displays the specied lter name followed by a lisng of the number of bytes and
packets processed by each policer in the policer set.
For a term-specic policer, each policer in the set is idened as follows:
prefix-specific-action-name
-
term-name
-
set-index
For a lter-specic policer, each policer is idened in the command output as follows:
prefix-specific-action-name
-
set-index
Because the example prex-specic acon psa-1Mbps-per-source-24-32-256 is referenced by only one term of
the example lter limit-source-one-24, the example policer 1Mbps-policer is congured as term-specic. In
the show firewall prefix-action-stats command output, the policer stascs are displayed as psa-1Mbps-per-
source-24-32-256-one-0, psa-1Mbps-per-source-24-32-256-one-1, and so on through psa-1Mbps-per-source-24-32-256-
one-255.
user@host> show firewall prefix-action-stats filter limit-source-one-24 prefix-action psa-1Mbps-
per-source-24-32-256 from 0 to 9
Filter: limit-source-one-24
Counters:
Name Bytes Packets
psa-1Mbps-per-source-24-32-256-one-0 0 0
psa-1Mbps-per-source-24-32-256-one-1 0 0
psa-1Mbps-per-source-24-32-256-one-2 0 0
psa-1Mbps-per-source-24-32-256-one-3 0 0
psa-1Mbps-per-source-24-32-256-one-4 0 0
2101
psa-1Mbps-per-source-24-32-256-one-5 0 0
psa-1Mbps-per-source-24-32-256-one-6 0 0
psa-1Mbps-per-source-24-32-256-one-7 0 0
psa-1Mbps-per-source-24-32-256-one-8 0 0
psa-1Mbps-per-source-24-32-256-one-9 0 0
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Prex-Specic Counng and Policing Overview
Filter-Specic Counter and Policer Set Overview
Prex-Specic Counng and Policing Conguraon Scenarios
Prex-Specic Counng and Policing Conguraon Scenarios
IN THIS SECTION
Prex Length of the Acon and Prex Length of Addresses in Filtered Packets | 2102
Scenario 1: Firewall Filter Term Matches on Mulple Addresses | 2104
Scenario 2: Subnet Prex Is Longer Than the Prex in the Filter Match Condion | 2106
Scenario 3: SubnetThe 128th counter and policer Prex Is Shorter Than the Prex in the Firewall Filter
Match Condion | 2108
Prex Length of the Acon and Prex Length of Addresses in Filtered Packets
Table 117 on page 2102 describes the relaonship between the prex length specied in the prex-
specic acon and the prex length of the addresses matched by the rewall lter term that references
the prex-specic acon.
Table 117: Summary of
Prex-Specic Acon Scenarios
Counter and Policer Set Packet-Filtering Criteria Indexing of Instances
Prex-specic acon scenario:
Example: Conguring Prex-Specic Counng and Policing
2102
Table 117: Summary of Prex-Specic Acon Scenarios
(Connued)
Counter and Policer Set Packet-Filtering Criteria Indexing of Instances
source-prex-length
= 32
subnet-prex-length
= 24
Set size: 2^8 = 256
Instance numbers: 0 - 255
source-address
= 10.10.10.0/24 Instance 0 10.10.10.0
Instance 1: 10.10.10.1
... ...
Instance 255: 10.10.10.255
Prex-specic acon scenario:
"Scenario 1: Firewall Filter Term Matches on Mulple Addresses" on page 2104
source-prex-length
= 32
subnet-prex-length
= 24
Set size: 2^8 = 256
Instance numbers: 0 - 255
source-address
= 10.10.10.0/24
source-address
= 10.11.0.0/16
Instance 0 10.10.10.0,
10.11.
x
.0
Instance 1: 10.10.10.1,
10.11.
x
.1
... ...
Instance 255: 10.10.10.255,
10.11.
x
.255
For addresses in the /16 subnet,
x
ranges from 0 through 255.
Prex-specic acon scenario:
"Scenario 2: Subnet Prex Is Longer Than the Prex in the Filter Match Condion" on page 2106
source-prex-length
= 32
subnet-prex-length
= 25
Set size: 2^7 = 128
Instance numbers: 0 - 127
source-address
= 10.10.10.0/24 Instance 0 10.10.10.0,
10.10.10.128
Instance 1: 10.10.10.1,
10.10.10.120
2103
Table 117: Summary of Prex-Specic Acon Scenarios
(Connued)
Counter and Policer Set Packet-Filtering Criteria Indexing of Instances
... ...
Instance 127: 10.10.10.255,
10.10.10.127
Prex-specic acon scenario:
"Scenario 3: SubnetThe 128th counter and policer Prex Is Shorter Than the Prex in the Firewall Filter Match
Condion" on page 2108
source-prex-length
= 32
subnet-prex-length
= 24
Set size: 2^8 = 256
Instance numbers: 0 - 255
source-address
= 10.10.10.0/25
NOTE: Only packets with source
addresses ranging from 10.10.10.0
through 10.10.10.127 are passed to
the prex-specic acon.
Instance 0 10.10.10.0
Instance 1: 10.10.10.1
... ...
Instance 127: 10.10.10.127
Instances 128 – 255: unused
Scenario 1: Firewall Filter Term Matches on Mulple Addresses
The complete example, Example: Conguring Prex-Specic Counng and Policing, shows the simplest
case of prex-specic acons, in which a single-term
rewall lter
matches on one address with a prex
length that is the same as the subnet prex length specied in the prex-specic acon. Unlike the
example, this scenario describes a conguraon in which a single-term rewall lter matches on two
IPv4 source addresses. In addion, the addional condion matches on a source address with a prex
length that is dierent from the subnet prex length dened in the prex-specic acon. In this case,
the addional condion matches on the /16 subnet of the source address 10.11.0.0.
NOTE: Unlike packets that match the source address 10.10.10.0/24, packets that match the source
address 10.11.0.0/16 are in a many-to-one correspondence with the instances in the counter and
policer set.
2104
The lter-matched packets that are passed to the prex-specic acon index into the counter and
policer set in such a way that the counng and policing instances are shared by packets that contain
source addresses across the 10.10.10.0/24 and 10.11.0.0/16 subnets as follows:
• The rst counter and policer in the set are indexed by packets with source addresses 10.10.10.0 and
10.11.
x
.0, where
x
ranges from 0 through 255.
• The second counter and policer in the set are indexed by packets with source addresses 10.10.10.1
and 10.11.
x
.1, where
x
ranges from 0 through 255.
• The 256th (last) counter and policer in the set are indexed by packets with source addresses
10.10.10.255 and 10.11.
x
.255, where
x
ranges from 0 through 255.
The following conguraon shows the statements for conguring the single-rate two-color policer, the
prex-specic acon that references the policer, and the IPv4 standard stateless rewall lter that
references the prex-specic acon:
[edit]
firewall {
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
then discard;
}
family inet {
prefix-action psa-1Mbps-per-source-24-32-256 {
policer 1Mbps-policer;
subnet-prefix-length 24;
source-prefix-length 32;
}
filter limit-source-two-24-16 {
term one {
from {
source-address {
10.10.10.0/24;
10.11.0.0/16;
}
}
then prefix-action psa-1Mbps-per-source-24-32-256;
}
}
2105
}
}
interfaces {
so-0/0/2 {
unit 0 {
family inet {
filter {
input limit-source-two-24-16;
}
address 10.39.1.1/16;
}
}
}
}
Scenario 2: Subnet Prex Is Longer Than the Prex in the Filter Match Condion
The complete example, Example: Conguring Prex-Specic Counng and Policing, shows the simplest
case of prex-specic acons, in which the single-term rewall lter matches on one address with a
prex length that is the same as the subnet prex length specied in the prex-specic acon. Unlike
the example, this scenario describes a conguraon in which the prex-specic acon denes a subnet
prex length that is longer than the prex of the source address matched by the rewall lter. In this
case, the prex-specic acon denes a subnet-prex value of 25, while the rewall lter matches on a
source address in the /24 subnet.
NOTE: The rewall lter passes the prex-specic acon packets with source addresses that
range from 10.10.10.0 through 10.10.10.255, while the prex-specic acon species a set of only
128 counters and policers, numbered from 0 through 127.
The lter-matched packets that are passed to the prex-specic acon index into the counter and
policer set in such a way that the counng and policing instances are shared by packets that contain
either of two source addresses within the 10.10.10.0/24 subnet:
•
The rst counter and policer in the set are indexed by packets with source addresses 10.10.10.0 and
10.10.10.128.
•
The second counter and policer in the set are indexed by packets with source addresses 10.10.10.1
and 10.10.10.129.
• The 128th (last) counter and policer in the set are indexed by packets with source addresses
10.10.10.127 and 10.10.10.255.
2106
The following conguraon shows the statements for conguring the single-rate two-color policer, the
prex-specic acon that references the policer, and the IPv4 standard stateless rewall lter that
references the prex-specic acon:
[edit]
firewall {
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
then discard;
}
family inet {
prefix-action psa-1Mbps-per-source-25-32-128 {
policer 1Mbps-policer;
subnet-prefix-length 25;
source-prefix-length 32;
}
filter limit-source-one-24 {
term one {
from {
source-address {
10.10.10.0/24;
}
}
then prefix-action psa-1Mbps-per-source-25-32-128;
}
}
}
}
interfaces {
so-0/0/2 {
unit 0 {
family inet {
filter {
input limit-source-one-24;
}
address 10.39.1.1/16;
}
}
2107
}
}
Scenario 3: SubnetThe 128th counter and policer Prex Is Shorter Than the Prex in the Firewall Filter
Match Condion
The complete example, Example: Conguring Prex-Specic Counng and Policing, shows the simplest
case of prex-specic acons, in which the single-term rewall lter matches on one address with a
prex length that is the same as the subnet prex length specied in the prex-specic acon. Unlike
the example, this scenario describes a conguraon in which the prex-specic acon denes a subnet
prex length that is shorter than the prex of the source address matched by the rewall lter. In this
case, the lter term matches on the /25 subnet of the source address 10.10.10.0.
NOTE: The rewall lter passes the prex-specic acon only packets with source addresses
that range from 10.10.10.0 through 10.10.10.127, while the prex-specic acon species a set of
256 counters and policers, numbered from 0 through 255.
The matched packets that are passed to the prex-specic acon index into the lower half of the
counter and policer set only:
• The rst counter and policer in the set are indexed by packets with source address 10.10.10.0.
• The second counter and policer in the set are indexed by packets with source address 10.10.10.1 and
10.10.10.129.
• The 128th counter and policer in the set are indexed by packets with source address 10.10.10.127.
• The upper half of the set (instances numbered from 128 through 255) are not indexed by packets
passed to the prex-specic acon from this parcular rewall lter.
The following conguraon shows the statements for conguring the single-rate two-color policer, the
prex-specic acon that references the policer, and the IPv4 standard stateless rewall lter that
references the prex-specic acon:
[edit]
firewall {
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
then discard;
2108
}
family inet {
prefix-action psa-1Mbps-per-source-24-32-256 {
policer 1Mbps-policer;
subnet-prefix-length 24;
source-prefix-length 32;
}
filter limit-source-one-25 {
term one {
from {
source-address {
10.10.10.0/25;
}
}
then prefix-action psa-1Mbps-per-source-24-32-256;
}
}
}
}
interfaces {
so-0/0/2 {
unit 0 {
family inet {
filter {
input limit-source-one-25;
}
address 10.39.1.1/16;
}
}
}
}
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Prex-Specic Counng and Policing Overview
Filter-Specic Counter and Policer Set Overview
Prex-Specic Counng and Policing Conguraon Scenarios
2109
RELATED DOCUMENTATION
Two-Color Policer Conguraon Overview | 2038
Guidelines for Applying Trac Policers | 1938
Policer Overhead to Account for Rate Shaping in the Trac Manager
IN THIS SECTION
Policer Overhead to Account for Rate Shaping Overview | 2110
Example: Conguring Policer Overhead to Account for Rate Shaping | 2111
Policer Overhead to Account for Rate Shaping Overview
If you congure ingress or egress trac-shaping overhead values for an interface, the trac manager
cannot apply these values to any rate-liming also applied to the interface. To enable the router to
account for the addional Ethernet frame length when policing acons are being determined, you must
congure the ingress or egress overhead values for policers separately.
NOTE: When a policer overhead value is changed, the PIC or DPC goes oine and then comes
back online.
For Gigabit Ethernet Intelligent Queuing 2 (IQ2) and Enhanced IQ2 (IQ2E) PICs or interfaces on Dense
Port Concentrators (DPCs) in MX Series routers, you can control the rate of trac that passes through
all interfaces on the PIC or DPC by conguring a
policer overhead
. You can congure a policer ingress
overhead and a policer egress overhead, each with values from 0 through 255 bytes. The policer
overhead values are added to the length of the nal Ethernet frame when determining ingress and
egress policer acons.
SEE ALSO
egress-policer-overhead
ingress-policer-overhead
2110
Example: Conguring Policer Overhead to Account for Rate Shaping
IN THIS SECTION
Requirements | 2111
Overview | 2111
Conguraon | 2112
Vericaon | 2120
This example shows how to congure overhead values for policers when rate-shaping overhead is
congured.
Requirements
Before you begin, make sure that interface for which you are applying ingress or egress policer overhead
is hosted on one of the following:
• Gigabit Ethernet IQ2 PIC
• IQ2E PIC
• DPCs in MX Series routers
Overview
IN THIS SECTION
Topology | 2112
This example shows how to congure policer overhead values for all physical interfaces on a supported
PIC or MPC so that the rate shaping value congured on a logical interface is accounted for in any
policing on that logical interface.
2111
Topology
The router hosts a Gigabit Ethernet IQ2 PIC, installed in PIC locaon 3 of the Flexible PIC Concentrator
(FPC) in slot number 1. The physical interface on port 1 on that PIC is congured to receive trac on
logical interface 0 and send it back out on logical interface 1. Class-of-service scheduling includes
100 Mbps of trac rate-shaping overhead for the output trac. A policer egress overhead of 100 bytes
is congured on the enre PIC so that, for any policers applied to the output trac, 100 bytes are added
to the nal Ethernet frame length when determining ingress and egress policer acons.
NOTE: Trac rate-shaping and corresponding policer overhead are congured separately:
• You congure rate shaping at the [edit class-of-service interfaces
interface-name
unit
unit-
number
] hierarchy level.
• You congure policer overhead at the [edit chassis fpc
slot-number
pic
pic-number
] hierarchy
level.
When a policer overhead value is changed, the PIC or DPC goes oine and then comes back online.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2113
Conguring the Logical Interfaces | 2113
Conguring Trac Rate-Shaping on the Logical Interface That Carries Output Trac | 2115
Conguring Policer Overhead on the PIC or DPC That Hosts the Rate-Shaped Logical Interface | 2117
Applying a Policer to the Logical Interface That Carries Input Trac | 2118
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
.
To congure this example, perform the following tasks:
2112
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-1/3/1 per-unit-scheduler
set interfaces ge-1/3/1 vlan-tagging
set interfaces ge-1/3/1 unit 0 vlan-id 100
set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30
set interfaces ge-1/3/1 unit 1 vlan-id 101
set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac
00:00:11:22:33:44
set class-of-service schedulers be transmit-rate percent 5
set class-of-service schedulers ef transmit-rate percent 30
set class-of-service schedulers af transmit-rate percent 30
set class-of-service schedulers nc transmit-rate percent 35
set class-of-service scheduler-maps my-map forwarding-class best-effort scheduler be
set class-of-service scheduler-maps my-map forwarding-class expedited-forwarding scheduler ef
set class-of-service scheduler-maps my-map forwarding-class network-control scheduler nc
set class-of-service scheduler-maps my-map forwarding-class assured-forwarding scheduler af
set class-of-service interfaces ge-1/3/1 unit 1 scheduler-map my-map
set class-of-service interfaces ge-1/3/1 unit 1 shaping-rate 100m
set firewall policer 500Kbps logical-interface-policer
set firewall policer 500Kbps if-exceeding bandwidth-limit 500k
set firewall policer 500Kbps if-exceeding burst-size-limit 625k
set firewall policer 500Kbps then discard
set chassis fpc 1 pic 3 ingress-policer-overhead 100
set chassis fpc 1 pic 3 egress-policer-overhead 100
set interfaces ge-1/3/1 unit 0 family inet policer input 500Kbps
Conguring the Logical Interfaces
Step-by-Step Procedure
To congure the logical interfaces:
1. Enable conguraon of the interface
[edit]
user@host# edit interfaces ge-1/3/1
2113
2. Enable mulple queues for each logical interface (so that you can associate an output scheduler with
each logical interface).
[edit interfaces ge-1/3/1]
user@host# set per-unit scheduler
user@host# set vlan-tagging
NOTE: For Gigabit Ethernet IQ2 PICs only, use the shared-scheduler statement to enable shared
schedulers and shapers on a physical interface.
3. Congure logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1]
user@host# set unit 0 vlan-id 100
user@host# set unit 0 family inet address 10.10.10.1/30
4. Congure logical interface ge-1/3/1.1.
[edit interfaces ge-1/3/1]
user@host# set unit 1 vlan-id 101
user@host# set unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44
Results
Conrm the conguraon of the interfaces by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/1 {
per-unit-scheduler;
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 10.10.10.1/30;
2114
}
}
unit 1 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
}
}
}
}
Conguring Trac Rate-Shaping on the Logical Interface That Carries Output Trac
Step-by-Step Procedure
To congure trac rate-shaping on the logical interface that carries output trac:
1. Enable conguraon of class-of-service features.
[edit]
user@host# edit class-of-service
2. Congure packet scheduling on logical interface ge-1/3/1.0.
• Congure schedulers that specify the percentage of transmission capacity.
[edit class-of-service]
user@host# edit schedulers
[edit class-of-service schedulers]
user@host# set be transmit-rate percent 5
user@host# set ef transmit-rate percent 30
user@host# set af transmit-rate percent 30
user@host# set nc transmit-rate percent 35
A percentage of zero drops all packets in the queue. When the rate-limit opon is specied, the
transmission rate is limited to the rate-controlled amount. In contrast with the exact opon, a
scheduler with the rate-limit opon shares unused bandwidth above the rate-controlled amount.
2115
• Congure a scheduler map to associate each scheduler with a forwarding class.
[edit class-of-service]
user@host# edit scheduler-maps my-map
[edit class-of-service scheduler-maps my-map]
user@host# set forwarding-class best-effort scheduler be
user@host# set forwarding-class expedited-forwarding scheduler ef
user@host# set forwarding-class network-control scheduler nc
user@host# set forwarding-class assured-forwarding scheduler af
• Associate the scheduler map with logical interface ge-1/3/1.0.
[edit class-of-service]
user@host# edit interfaces ge-1/3/1 unit 1
[edit class-of-service interfaces ge-1/3/1 unit 1]
user@host# set scheduler-map my-map
3. Congure 100 Mbps of trac rate-shaping overhead on logical interface ge-1/3/1.1.
[edit class-of-service interfaces ge-1/3/1 unit 1]
user@host# set shaping-rate 100
Alternavely, you can congure a shaping rate for a logical interface and oversubscribe the physical
interface by including the shaping-rate statement at the [edit class-of-service traffic-control-profiles]
hierarchy level. With this conguraon approach, you can independently control the delay-buer
rate.
Results
Conrm the conguraon of the class-of-service features (including the 100 Mbp of shaping of the
egress trac) by entering the show class-of-service conguraon mode command. If the command output
does not display the intended conguraon, repeat the instrucons in this procedure to correct the
conguraon.
[edit]
user@host# show class-of-service
interfaces {
2116
ge-1/3/1 {
unit 1 {
scheduler-map my-map;
shaping-rate 100m;
}
}
}
scheduler-maps {
my-map {
forwarding-class best-effort scheduler be;
forwarding-class expedited-forwarding scheduler ef;
forwarding-class network-control scheduler nc;
forwarding-class assured-forwarding scheduler af;
}
}
schedulers {
be {
transmit-rate percent 5;
}
ef {
transmit-rate percent 30;
}
af {
transmit-rate percent 30;
}
nc {
transmit-rate percent 35;
}
}
Conguring Policer Overhead on the PIC or DPC That Hosts the Rate-Shaped Logical Interface
Step-by-Step Procedure
To congure policer overhead on the PIC or MPC that hosts the rate-shaped logical interface:
1. Enable conguraon of the supported PIC or MPC.
[edit]
user@host# set chassis fpc 1 pic 3
2117
2. Congure 100 bytes of policer overhead on the supported PIC or MPC.
[edit chassis fpc 1 pic 3]
user@host# set ingress-policer-overhead 100
user@host# set egress-policer-overhead 100
NOTE: These values are added to the length of the nal Ethernet frame when determining
ingress and egress policer acons for all physical interfaces on the PIC or MPC.
You can specify policer overhead with values from 0 through 255 bytes.
Results
Conrm the conguraon of the policer overhead on the physical interface to account for rate-shaping
by entering the show chassis conguraon mode command. If the command output does not display the
intended conguraon, repeat the instrucons in this procedure to correct the conguraon.
[edit]
user@host# show chassis
chassis {
fpc 1 {
pic 3 {
egress-policer-overhead 100;
ingress-policer-overhead 100;
}
}
}
Applying a Policer to the Logical Interface That Carries Input Trac
Step-by-Step Procedure
To apply a policer to the logical interface that carries input trac:
1. Congure the logical interface (aggregate) policer.
[edit]
user@host# edit firewall policer 500Kbps
2118
[edit firewall policer 500Kbps]
user@host# set logical-interface-policer
user@host# set if-exceeding bandwidth-limit 500k
user@host# set if-exceeding burst-size-limit 625k
user@host# set then discard
2. Apply the policer to Layer 3 input on the IPv4 logical interface.
[edit]
user@host# set interfaces ge-1/3/1 unit 0 family inet policer input 500Kbps
NOTE: The 100 Mbps policer overhead is added to the length of the nal Ethernet frame
when determining ingress and egress policer acons,
Results
Conrm the conguraon of the policer with rate-shaping overhead by entering the show firewall and
show interfaces conguraon mode commands. If the command output does not display the intended
conguraon, repeat the instrucons in this procedure to correct the conguraon.
[edit]
user@host# show firewall
policer 500Kbps {
logical-interface-policer;
if-exceeding {
bandwidth-limit 500k;
burst-size-limit 625k;
}
then discard;
}
[edit]
user@host# show interfaces
ge-1/3/1 {
per-unit-scheduler;
vlan-tagging;
unit 0 {
2119
vlan-id 100;
layer2-policer {
input-policer 500Kbps;
}
family inet {
address 10.10.10.1/30;
}
}
unit 0 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying Trac Stascs and Policers for the Logical Interface | 2120
Displaying Stascs for the Policer | 2121
Conrm that the conguraon is working properly.
Displaying Trac Stascs and Policers for the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
2120
Acon
Use the show interfaces operaonal mode command for logical interface ge-1/3/1.0, and include the detail
or extensive opon. The command output secon for Trac stascs lists the number of bytes and
packets received and transmied on the logical interface, and the Protocol inet secon contains a
Policer eld that would list the policer 500Kbps as an input or output policer as follows:
• Input: 500Kbps-ge-1/3/1.0-log_int-i
• Output: 500Kbps-ge-1/3/1.0-log_int-o
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to Input trac only.
Displaying Stascs for the Policer
Purpose
Verify the number of packets evaluated by the policer.
Acon
Use the show policer operaonal mode command and oponally specify the name of the policer. The
command output displays the number of packets evaluated by each congured policer (or the specied
policer), in each direcon. For the policer 500Kbps, the input and output policer names are displayed as
follows:
• 500Kbps-ge-1/3/1.0-log_int-i
• 500Kbps-ge-1/3/1.0-log_int-o
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to input trac only.
SEE ALSO
egress-policer-overhead
ingress-policer-overhead
2121
RELATED DOCUMENTATION
Two-Color Policer Conguraon Overview | 2038
Guidelines for Applying Trac Policers | 1938
Conguring a Policer Overhead | 2005
CLI Explorer
Three-Color Policer Conguraon Overview
Table 118 on page 2122 describes the hierarchy levels at which you can congure and apply single-rate
tricolor-marking (single-rate TCM) policers and two-rate tricolor-marking (two-rate TCM) policers to
Layer 3 trac. For informaon about applying three-color policers to Layer 2 trac, see Three-Color
Policing at Layer 2 Overview.
Table 118: Three-Color Policer Conguraon and Applicaon Overview
Policer Conguraon Layer 3 Applicaon Key Points
Single-Rate Three-Color Policer
Denes trac rate liming that you can apply to Layer 3 protocol-specic trac at a logical interface. Can be
applied as a rewall lter policer only.
Provides moderate allowances for short periods of trac that exceed the commied burst size.
2122
Table 118: Three-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
Basic single-rate TCM policer
conguraon:
[edit firewall]
three-color-policer
policer-name
{
single-rate {
(color-aware | color-
blind);
committed-information-
rate
bps
;
committed-burst-size
bytes
;
excess-burst-size
bytes
;
}
action {
loss-priority high then
discard;
}
}
Reference the policer from a rewall lter,
and apply the lter to a protocol family on a
logical interface:
[edit firewall]
family
family-name
{
filter
filter-name
{
term
term-name
{
from {
...
match-conditions
...
}
then {
three-color-policer {
single-rate
policer-
name
;
}
}
}
}
}
Apply the lter to a logical interface at the
protocol family level:
[edit interfaces]
interface-name
{
unit
unit-number
{
family
family-name
{
filter {
input
filter-name
;
output
filter-name
;
}
}
}
}
Policer conguraon:
• Include the single-rate
(color-aware | color-
blind) statement.
Firewall lter conguraon:
• Include the three-color-
policer single-rate
policer-name
acon.
Applying the rewall lter to
the logical interface:
• Include the filter (input
| output)
filter-name
statement.
Single-Rate Three-Color Physical Interface Policer
Denes trac rate liming that applies to all logical interfaces and protocol families congured on a physical
interface, even if the interfaces belong to dierent roung instances. Can be applied as a rewall lter policer only.
2123
Table 118: Three-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
Physical interface single-rate TCM
policer:
[edit firewall]
three-color-policer
policer-name
{
physical-interface-policer;
single-rate {
(color-aware | color-
blind);
committed-information-
rate
bps
;
committed-burst-size
bytes
;
excess-burst-size
bytes
;
}
action {
loss-priority high then
discard;
}
}
Reference the policer from a physical
interface lter only, and apply the lter to a
protocol family on a logical interface:
[edit firewall]
family
family-name
{
filter
filter-name
{
physical-interface-filter
term
term-name
{
from {
...
match-conditions
...
}
then {
three-color-policer {
single-rate
policer-
name
;
}
}
}
}
}
[edit interfaces]
interface-name
{
unit
number
{
family
family-name
{
filter {
input
filter-name
;
output
filter-name
;
}
}
}
}
Policer conguraon:
• Include the physical-
interface-policer
statement.
Firewall lter conguraon:
• Include the physical-
interface-filter
statement.
Applicaon:
• Include the filter (input
| output)
filter-name
statement.
Vericaon
• To verify, use the show
firewall filter
filter-
name
operaonal mode
command.
Basic Two-Rate Three-Color Policer
Denes trac rate liming that you can apply to Layer 3 protocol-specic trac at a logical interface. Can be
applied as a rewall lter policer only.
Provides moderate allowances for sustained periods of trac that exceed the commied bandwidth limit or burst
size.
2124
Table 118: Three-Color Policer Conguraon and Applicaon Overview
(Connued)
Policer Conguraon Layer 3 Applicaon Key Points
Basic two-rate TCM policer
conguraon:
[edit firewall]
three-color-policer
policer-name
{
two-rate {
(color-aware | color-
blind);
committed-information-
rate
bps
;
committed-burst-size
bytes
;
peak-information-rate
bps
;
peak-burst-size
bytes
;
}
action {
loss-priority high then
discard;
}
}
Reference the policer from a rewall lter,
and apply the lter to a protocol family on a
logical interface:
[edit firewall]
family
family-name
{
filter
filter-name
{
term
term-name
{
from {
...
match-conditions
...
}
then {
three-color-policer {
two-rate
policer-name
;
}
}
}
}
}
[edit interfaces]
interface-name
{
unit
unit-number
{
family
family-name
{
filter {
input
filter-name
;
output
filter-name
;
}
}
}
}
Policer conguraon:
• Include the two-rate
(color-aware | color-
blind) statement.
Firewall lter conguraon:
• Include the three-color-
policer two-rate
policer-
name
acon.
Applying the rewall lter to
the logical interface:
• Include the filter (input
| output)
filter-name
statement.
RELATED DOCUMENTATION
Three-Color Policer Conguraon Guidelines | 2138
Basic Single-Rate Three-Color Policers | 2142
Basic Two-Rate Three-Color Policers | 2151
2125
Two-Color and Three-Color Logical Interface Policers | 2170
Two-Color and Three-Color Physical Interface Policers | 2189
Applying Policers
IN THIS SECTION
Overview of Applying Policers | 2126
Applying Aggregate Policers | 2127
Applying Hierarchical Policers on Enhanced Intelligent Queuing PICs | 2130
Conguring Hierarchical Policers | 2133
Conguring a Single-Rate Two-Color Policer | 2134
Conguring a Single-Rate Color-Blind Policer | 2135
Conguring a Two-Rate Tricolor Marker Policer | 2136
Overview of Applying Policers
Policers allow you to perform simple trac policing on specic interfaces or Layer 2 virtual private
networks (VPNs) without conguring a rewall lter. To apply policers, include the policer statement:
policer {
arp
policer-template-name
;
input
policer-template-name
;
output
policer-template-name
;
}
You can include these statements at the following hierarchy levels:
• [edit interfaces
interface-name
unit
logical-unit-number
family
family
]
•
[edit logical-systems
logical-system-name
interfaces
interface-name
unit
logical-unit-number
family
family
]
In the family statement, the protocol family can be ccc, inet, inet6, mpls, tcc, or vpls.
In the arp statement, list the name of one policer template to be evaluated when Address Resoluon
Protocol (ARP) packets are received on the interface. By default, an ARP policer is installed that is shared
2126
among all the Ethernet interfaces on which you have congured the family inet statement. If you want
more stringent or lenient policing of ARP packets, you can congure an interface-specic policer and
apply it to the interface. You congure an ARP policer just as you would congure any other policer, at
the [edit firewall policer] hierarchy level. If you apply this policer to an interface, the default ARP packet
policer is overridden. If you delete this policer, the default policer takes eect again.
• You can congure a dierent policer on each protocol family on an interface, with one input policer
and one output policer for each family. When you apply policers, you can congure the family ccc,
inet, inet6, mpls, tcc, or vpls only, and one ARP policer for the family inet protocol only. Each me a
policer is referenced, a separate copy of the policer is installed on the packet forwarding components
for that interface.
• If you apply both policers and rewall lters to an interface, input policers are evaluated before input
rewall lters, and output policers are evaluated aer output rewall lters. In the input statement,
list the name of one policer template to be evaluated when packets are received on the interface. In
the output statement, list the name of one policer template to be evaluated when packets are
transmied on the interface.
• For subscribers terminang on MX Series routers over an Aggregated Ethernet (AE) interface that
spans mulple FPCs, it is possible for an overall subscriber rate to exceed the congured rate
because the limit congured in the policer is applied separately to each interface in the AE bundle.
Thus, for example, if you intend to have a policer on a three-member AE interface enforce a bandwidth-
limit of
600m
, you would need to congure the bandwidth-limit in the policer for
200m
to account for
the three interfaces in the AE (that is, 200 Mbps per interface, for a combined total of 600Mbps).
• If you apply the policer to the interface lo0, it is applied to packets received or transmied by the
Roung Engine.
• On T Series, M120, and M320 plaorms, if the interfaces are on the same FPC, the lters or policers
do not act on the sum of trac entering and exing the interfaces.
Applying Aggregate Policers
IN THIS SECTION
Applying Aggregate Policers | 2127
Applying Aggregate Policers
By default, if you apply a policer to mulple protocol families on the same logical interface, the policer
restricts trac for each protocol family individually. For example, a policer with a 50 Mbps bandwidth
2127
limit applied to both IPv4 and IPv6 trac would allow the interface to accept 50 Mbps of IPv4 trac
and 50 Mbps of IPv6 trac. If you apply an aggregate policer, the policer would allow the interface to
receive only 50 Mbps of IPv4 and IPv6 trac combined.
To congure an aggregate policer, include the logical-interface-policer statement at the [edit firewall
policer
policer-template-name
] hierarchy level:
[edit firewall policer
policer-template-name
]
logical-interface-policer;
For the policer to be treated as an aggregate, you must apply it to mulple protocol families on a single
logical interface by including the policer statement:
policer {
arp
policer-template-name
;
input
policer-template-name
;
output
policer-template-name
;
}
You can include these statements at the following hierarchy levels:
• [edit interfaces
interface-name
unit
logical-unit-number
family
family
]
• [edit logical-systems
logical-system-name
interfaces
interface-name
unit
logical-unit-number
family
family
]
In the family statement, the protocol family can be ccc, inet, inet6, mpls, tcc, or vpls.
The protocol families on which you do not apply the policer are not aected by the policer. For example,
if you congure a single logical interface to accept MPLS, IPv4, and IPv6 trac and you apply the logical
interface policer policer1 to only the IPv4 and IPv6 protocol families, MPLS trac is not subject to the
constraints of policer1.
If you apply policer1 to a dierent logical interface, there are two instances of the policer. This means the
Junos OS polices trac on separate logical interfaces separately, not as an aggregate, even if the same
logical-interface policer is applied to mulple logical interfaces on the same physical interface port.
Example: Applying Aggregate Policers
Congure two logical interface policers: aggregate_police1 and aggregate_police2. Apply aggregate_police1 to
IPv4 and IPv6 trac received on logical interface fe-0/0/0.0. Apply aggregate_police2 to CCC and MPLS
trac received on logical interface fe-0/0/0.0. This conguraon causes the soware to create only one
instance of aggregate_police1 and one instance of aggregate_police2.
2128
Apply aggregate_police1 to IPv4 and IPv6 trac received on another logical interface fe-0/0/0.1. This
conguraon causes the soware to create a new instance of aggregate_police1, one that applies to unit 0
and another that applies to unit 1.
[edit firewall]
policer aggregate_police1 {
logical-interface-policer;
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 500k;
}
then {
discard;
}
}
policer aggregate_police2 {
logical-interface-policer;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 200k;
}
then {
discard;
}
}
[edit interfaces fe-0/0/0]
unit 0 {
family inet {
policer {
input aggregate_police1;
}
}
family inet6 {
policer {
input aggregate_police1;
}
}
family ccc {
policer {
input aggregate_police2;
}
}
2129
family mpls {
policer {
input aggregate_police2;
}
}
}
unit 1 {
family inet {
policer {
input aggregate_police1;
}
}
family inet6 {
policer {
input aggregate_police1;
}
}
}
Applying Hierarchical Policers on Enhanced Intelligent Queuing PICs
IN THIS SECTION
Applying Hierarchical Policers on Enhanced Intelligent Queuing PICs | 2130
Applying Hierarchical Policers on Enhanced Intelligent Queuing PICs
M40e, M120, and M320 edge routers and T Series core routers with Enhanced Intelligent Queuing (IQE)
PICs support hierarchical policers in the ingress direcon and allow you to apply a hierarchical policer for
the premium and aggregate (premium plus normal) trac levels to an interface. Hierarchical policers
provide cross-funconality between the congured physical interface and the Packet Forwarding
Engine.
Before you begin, there are some general restricons that apply to hierarchical policers:
• Only one type of policer can be congured for a logical or physical interface. For example, a
hierarchical policer and a regular policer in the same direcon for the same logical interface is not
allowed.
2130
• The chaining of the policers—that is, applying policers to both a port and the logical interfaces of that
port—is not allowed.
• There is a limit of 64 policers per interface in case there is no BA classicaon, providing a single
policer per DLCI.
• Only one kind of policer can be applied on a physical or logical interface.
• The policer should be independent of BA classicaon. Without BA classicaon, all trac on an
interface will be treated either as EF or non-EF, based on the conguraon. With BA classicaon, an
interface can support up to 64 policers. Again, the interface here may be a physical interface or
logical interface (for example, DLCI).
• With BA classicaon, the miscellaneous trac (the trac
not
matching with any of the BA
classicaon DSCP/EXP bits) will be policed as non-EF trac. No separate policers will be installed
for this trac.
Hierarchical Policer Overview
Hierarchical policing uses two token buckets, one for aggregate (non-EF) trac and one for premium
(EF) trac. Which trac is EF and which is non-EF is determined by the class-of-service conguraon.
Logically, hierarchical policing is achieved by chaining two policers.
Figure 88: Hierarchical Policer
In the example in Figure 88 on page 2131, EF trac is policed by Premium Policer and non EF trac is
policed by Aggregate Policer. What that means is, for EF trac the out-of-spec acon will be the one
that is congured for Premium Policer, but the in-spec EF trac will sll consume the tokens from the
Aggregate Policer.
But EF trac will never be submied to the out-of-spec acon of the Aggregate Policer. Also, if the out-
of-spec acon of the Premium Policer is not set to Discard, those out-of-spec packets will not consume
the tokens from the Aggregate Policer. Aggregate Policer only polices the non-EF trac. As you can see,
the Aggregate Policer token bucket can go negave, if all the tokens are consumed by the non-EF trac
and then you get bursts of EF trac. But that will be for a very short me, and over a period of me it
will average out. For example:
2131
•
Premium Policer:
Bandwidth 2 Mbps, OOS Acon: Discard
•
Aggregate Policer:
Bandwidth 10 Mbps, OOS Acon: Discard
In the above case, EF trac is guaranteed 2 Mbps and the non-EF trac will get from 8 Mbps to 10
Mbps, depending on the input rate of the EF trac.
Hierarchical Policing Characteriscs
Hierarchical token bucket features include:
• Ingress trac is rst classied into EF and non-EF trac prior to applying a policer:
• Classicaon is performed by Q-tree lookup
• Channel number selects a shared token bucket policer:
• Dual token bucket policer is divided into two single bucket policers:
• Policer1—EF trac
• Policer2—non-EF trac
• Shared token bucket is used to police the trac as follows:
• Policer1 is set to EF rate (for example, 2 Mbps)
• Policer2 is set to aggregate interface policed rate (for example, 10 Mbps).
• EF trac gets applied to Policer1.
• If trac is in-spec it is allowed to pass and decrement from both Policer1 and Policer2.
• If trac is out-of-spec it can be discarded or marked with a new FC or loss priority. Policer2
will not do anything with out-of-spec EF trac.
• Non-EF trac gets applied only to Policer2.
• If trac is in-spec it is allowed to pass through and decremented Policer2.
• If trac is out-of-spec it is discarded or marked with a new FC or set with a new drop priority.
• Rate-limit the port speed to a desired rate at Layer 2
• Rate-limit the EF trac
• Rate-limit the non-EF trac
• Policing drops counted per color
2132
SEE ALSO
Class of Service User Guide (Routers and EX9200 Switches)
Conguring Hierarchical Policers
To congure a hierarchical policer, apply the policing-priority statement to the proper forwarding class
and congure a hierarchical policer for the aggregate and premium level. For more informaon about
class of service, see the Junos OS Class of Service User Guide for Roung Devices.
NOTE: Hierarchical policers can only be congured on SONET physical interfaces hosted on an
IQE PIC. Only aggregate and premium levels are supported.
CoS Conguraon of Forwarding Classes for Hierarchical Policers
[edit class-of-service forwarding-classes]
class fc1 queue-num 0 priority high policing-priority premium;
class fc2 queue-num 1 priority low policing-priority normal;
class fc3 queue-num 2 priority low policing-priority normal;
class fc4 queue-num 3 priority low policing-priority normal;
For detailed informaon on class-of-service conguraon and statements, see the Junos OS Class of
Service User Guide for Roung Devices.
Firewall Conguraon for Hierarchical Policers
[edit firewall hierarchical-policer foo]
aggregate {
if-exceeding {
bandwidth-limit 70m;
burst-size-limit 1500;
}
then {
discard;
}
premium {
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 1500;
}
then {
2133
discard;
}
}
You can apply the hierarchical policer as follows:
[edit interfaces so-0/1/0 unit 0 layer2-policer]
input-hierarchical-policer foo;
You also have the opon to apply the policer at the physical port level as follows:
[edit interfaces so-0/1/0 layer2-policer]
input-hierarchical-policer foo;
Conguring a Single-Rate Two-Color Policer
You can congure a single-rate two-color policer as follows:
[edit firewall policer foo]
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 1500;
}
then {
discard;
}
You can apply the policer as follows:
[edit interfaces so-0/1/0 unit 0 layer2-policer]
input-policer foo;
You also have the opon to apply the policer at the physical port level as follows:
[edit interfaces so-0/1/0 layer2-policer]
input-policer foo;
2134
Conguring a Single-Rate Color-Blind Policer
This secon describes single-rate color blind and color aware policers.
You can congure a single-rate color blind policer as follows:
[edit firewall three-color-policer foo]
single-rate {
color-blind;
committed-information-rate 50m;
committed-burst-size 1500;
excess-burst-size 1500;
}
You can apply the single-rate color blind policer as follows:
[edit interfaces so-0/1/0 unit 0 layer2-policer]
input-three-color foo;
You can congure a single-rate color-aware policer as follows:
[edit firewall three-color-policer bar]
single-rate {
color-aware;
committed-information-rate 50m;
committed-burst-size 1500;
excess-burst-size 1500;
}
You can apply the single-rate color-aware policer as follows:
[edit interfaces so-0/1/0 unit 0 layer2-policer]
input-three-color foo;
You also have the opon to apply the policer at the physical port level as follows:
[edit interfaces so-0/1/0 layer2-policer]
input-three-color bar;
2135
Conguring a Two-Rate Tricolor Marker Policer
Ingress policing is implemented using a two-rate tricolor marker (trTCM). This is done with a dual token
bucket (DTB) that maintains two rates, commied, and a peak. Egress stac policing also uses a token
bucket.
The token buckets perform the following ingress policing funcons:
• (1K) trTCM - Dual token bucket (red, yellow, and green marking)
• Policing is based on Layer 2 packet size:
• Aer +/- byte adjust oset
• Marking is color aware and color blind:
• Color aware needs to have the color set by q-tree lookup based on:
• ToS
• EXP
• Programmable marking acons:
• Color (red, yellow, green)
• Drop based on color and congeson prole
• Policer is selected based on the arriving channel number:
• Channel number LUT produces policer index and queue index
• Mulple channels can share the same policer (LUT produces same policer index)
• Support ingress policing and trTCM at the following levels:
• Queue
• Logical interface (i/DLCI)
• Physical interface (ifd)
• Physical port (controller ifd)
• Any combinaons of logical interface, physical interface, and port
• Support percentage of interface speed and bits per second
Rate limits may be applied to selected queues on ingress and on predened queues at egress. The token
bucket operates in color aware and color blind modes (specied by RFC 2698).
2136
Conguring a Color-Blind trTCM
[edit firewall three-color-policer foo]
two-rate {
color-blind;
committed-information-rate 50m;
committed-burst-size 1500;
peak-information-rate 100m;
peak-burst-size 3k;
}
You can apply the three-color two-rate color-blind policer as follows:
[edit interfaces so-0/1/0 unit 0 layer2-policer]
input-three-color foo;
You also have the opon to apply the policer at the physical port level as follows:
[edit interfaces so-0/1/0 layer2-policer]
input-three-color foo;
Conguring a Color-Aware trTCM
[edit firewall three-color-policer bar]
two-rate {
color-aware;
committed-information-rate 50m;
committed-burst-size 1500;
peak-information-rate 100m;
peak-burst-size 3k;
}
You can apply the three-color two-rate color-aware policer as follows:
[edit interfaces so-0/1/0 unit 0 layer2-policer]
input-three-color bar;
2137
You also have the opon to apply the policer at the physical port level as follows:
[edit interfaces so-0/1/0 layer2-policer]
input-three-color bar;
SEE ALSO
Class of Service User Guide (Routers and EX9200 Switches)
Three-Color Policer Conguraon Guidelines
IN THIS SECTION
Plaorms Supported for Three-Color Policers | 2138
Color Modes for Three-Color Policers | 2139
Naming Convenons for Three-Color Policers | 2140
Plaorms Supported for Three-Color Policers
Three-color policers are supported on the following Juniper Networks routers:
• M120 Mulservice Edge Routers
• M320 Mulservice Edge Routers and T Series Core Routers with Enhanced II Flexible PIC
Concentrators (FPCs)
• MX Series 5G Universal Roung Plaorms
• T640 Core Routers with Enhanced Scaling FPC4
• T4000 Core Routers with FPC5
On MX Series and M120 routers, you can apply three-color policers to aggregated interfaces.
The discard acon for a tricolor marking policer for a
rewall lter
is supported on the M120 routers,
M320 routers with Enhanced-III FPCs, M7i and M10i routers with the Enhanced CFEB (CFEB-E), and
2138
MX Series routers with Trio MPCs, so it is not necessary to include the logical-interface-policer statement
for them.
SEE ALSO
Three-Color Policer Conguraon Overview | 2122
Color Modes for Three-Color Policers
Naming Convenons for Three-Color Policers
Color Modes for Three-Color Policers
IN THIS SECTION
Color-Blind Mode | 2139
Color-Aware Mode | 2139
Three-color policers—both single-rate and two-rate three-color policer schemes—can operate in either
of two modes:
Color-Blind Mode
In
color-blind
mode, the three-color policer assumes that all packets examined have not been previously
marked or metered. If you congure a three-color policer to be color-blind instead of color-aware, the
policer ignores preexisng color markings that might have been set for a packet by another trac
policer congured at a previous network node.
Color-Aware Mode
In
color-aware
mode, the three-color policer assumes that all packets examined have been previously
marked or metered. In other words, the three-color policer takes into account any coloring markings that
might have been set for a packet by another trac policer congured at a previous network node. At
the node where color-aware policing is congured, any preexisng color markings are used in
determining the appropriate policing acon for the packet.
In color-aware mode, the three-color policer can increase the packet loss priority (PLP) level of a packet,
but never decrease it. For example, if a color-aware three-color policer meters a packet with a medium
PLP marking, it can raise the PLP level to high, but cannot reduce the PLP level to low.
2139
For two-rate, three-color policing, the Junos OS uses two token buckets to manage bandwidth based on
the two rates of trac. For example, two-rate policing might be congured on a node upstream in the
network. The two-rate policer has marked a packet as yellow (loss priority medium-low). The color-
aware policer takes this yellow marking into account when determining the appropriate policing acon.
In color-aware policing, the yellow packet would never receive the acon associated with either the
green packets or red packets. This way, tokens for violang packets are never taken from the metering
token buckets at the color-aware policing node.
NOTE: For a three-color policer operang in color-aware mode and when the PLP of the input
packet is medium-low, the color of the input packet to the policer is mapped to the color yellow.
In such a scenario, if the color of the input packet remains unchanged, the policer operates in the
following way:
• On a T1600 Enhanced Scaling Type 4 FPC (T1600-FPC4-ES), the PLP of the output packet
remains medium-low.
• On a T4000 Type 5 FPC (T4000-FPC5-3D), the PLP of the output packet is marked as
medium-high.
Because of this dierence, for any applicaons (such as rewrite and WRED selecon on egress
interface) that use PLP, the packets are treated dierently for the same ow depending on the
FPC type (T1600 Enhanced Scaling FPC4 (T1600-FPC4-ES) or T4000 FPC5 (T4000-FPC5-3D))
on which the policer is applied.
SEE ALSO
Three-Color Policer Conguraon Overview | 2122
Plaorms Supported for Three-Color Policers
Naming Convenons for Three-Color Policers
Naming Convenons for Three-Color Policers
Because policers can be numerous and must be applied correctly to work, a simple naming convenon
makes it easier to apply the policers properly.
We recommend that you name your policer using a convenon that idenes the basic components of
the policer:
•
Three-color policer type—Where srTCM idenes a
single-rate
three-color policer and trTCM idenes a
two-rate
three-color policer.
2140
• Three-color policer color mode—Where ca idenes a
color-aware
three-color policer and cb
idenes a
color-blind three-color policer
.
NOTE:
TCM stands for tricolor marking.
Table 119 on page 2141 describes a recommended naming convenon for policers.
Table 119: Recommended Naming Convenon for Policers
Three-Color Policer Type Naming Convenon Example Names
Single-rate three-color, color-aware
srTCM
number
-ca srTCM1-ca,
srTCM2-ca,
srTCM3-ca,
...
Single-rate three-color, color-blind
srTCM
number
-cb srTCM1-cb,
srTCM2-cb,
srTCM3-cb,
...
Two-rate three-color, color-aware
trTCM
number
-ca trTCM1-ca,
trTCM2-ca,
trTCM3-ca,
...
Two-rate three-color, color-blind
trTCM
number
-cb trTCM1-cb,
trTCM2-cb,
trTCM3-cb,
...
SEE ALSO
Three-Color Policer Conguraon Overview | 2122
Plaorms Supported for Three-Color Policers
Color Modes for Three-Color Policers
2141
RELATED DOCUMENTATION
Three-Color Policer Conguraon Overview | 2122
Guidelines for Applying Trac Policers | 1938
Basic Single-Rate Three-Color Policers
IN THIS SECTION
Single-Rate Three-Color Policer Overview | 2142
Example: Conguring a Single-Rate Three-Color Policer | 2143
Single-Rate Three-Color Policer Overview
A single-rate three-color policer denes a bandwidth limit and a maximum burst size for guaranteed
trac and a second burst size for peak trac. A single-rate three-color policer is most useful when a
service is structured according to packet length and not peak arrival rate.
Single-rate three-color policing meters a trac stream based on the following congured trac criteria:
• Commied informaon rate (CIR)—Bandwidth limit for guaranteed trac.
• Commied burst size (CBS)—Maximum packet size permied for bursts of data that exceed the CIR.
• Excess burst size (EBS)—Maximum packet size permied for peak trac.
Single-rate tricolor marking (single-rate TCM) classies trac as belonging to one of three color
categories and performs congeson-control acons on the packets based on the color marking:
• Green—Trac that conforms to
either
the bandwidth limit
or
the burst size for guaranteed trac (CIR
or CBS). For a green trac ow, single-rate marks the packets with an implicit loss priority of low and
transmits the packets.
• Yellow—Trac that exceeds
both
the bandwidth limit
and
the burst size for guaranteed trac (CIR
and CBS) but not the burst size for peak trac (EBS). For a yellow trac ow, single-rate marks the
packets with an implicit loss priority of medium-high and transmits the packets.
• Red—Trac that exceeds the burst size for peak trac (EBS), single-rate marks packets with an
implicit loss priority of high and, oponally, discards the packets.
If congeson occurs downstream, the packets with higher loss priority are more likely to be discarded.
2142
NOTE: For both single-rate and two-rate three-color policers, the only
congurable
acon is to
discard packets in a red trac ow.
The discard acon for a tricolor marking policer for a
rewall lter
is supported on the M120 routers,
M320 routers with Enhanced-III FPCs, M7i and M10i routers with the Enhanced CFEB (CFEB-E), and
MX Series routers with MPCs, so it is not necessary to include the logical-interface-policer statement for
them.
SEE ALSO
Three-Color Policer Conguraon Overview | 2122
Example: Conguring a Single-Rate Three-Color Policer
Example: Conguring a Single-Rate Three-Color Policer
IN THIS SECTION
Requirements | 2143
Overview | 2143
Conguraon | 2144
Vericaon | 2150
This example shows how to congure a single-rate three-color policer.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 2144
2143
A single-rate three-color policer meters a trac ow against a bandwidth limit and burst-size limit for
guaranteed trac, plus a second burst-size limit for excess trac. Trac that conforms to the limits for
guaranteed trac is categorized as green, and nonconforming trac falls into one of two categories:
• Nonconforming trac that does not exceed the burst size for excess trac is categorized as yellow.
• Nonconforming trac that exceeds the burst size for excess trac is categorized as red.
Each category is associated with an acon. For green trac, packets are implicitly set with a loss-priority
value of low and then transmied. For yellow trac, packets are implicitly set with a loss-priority value of
medium-high and then transmied. For red trac, packets are implicitly set with a loss-priority value of high
and then transmied. If the policer conguraon includes the oponal action statement (action loss-
priority high then discard), then packets in a red ow are discarded instead.
You can apply a three-color policer to Layer 3 trac as a rewall lter policer only. You reference the
policer from a stateless rewall lter term, and then you apply the lter to the input or output of a
logical interface at the protocol level.
Topology
In this example, you apply a color-aware, single-rate three-color policer to the input IPv4 trac at logical
interface ge-2/0/5.0. The IPv4 rewall lter term that references the policer does not apply any packet-
ltering. The lter is used only to apply the three-color policer to the interface.
You congure the policer to rate-limit trac to a bandwidth limit of 40 Mbps and a burst-size limit of
100 KB for green trac but also allow an excess burst-size limit of 200 KB for yellow trac. Only
nonconforming trac that exceeds the peak burst-size limit is categorized as red. In this example, you
congure the three-color policer acon loss-priority high then discard, which overrides the implicit
marking of red trac to a high loss priority.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2145
Conguring a Single-Rate Three-Color Policer | 2145
Conguring an IPv4 Stateless Firewall Filter That References the Policer | 2147
Applying the Filter to the Logical Interface | 2148
2144
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall three-color-policer srTCM1-ca single-rate color-aware
set firewall three-color-policer srTCM1-ca single-rate committed-information-rate 40m
set firewall three-color-policer srTCM1-ca single-rate committed-burst-size 100k
set firewall three-color-policer srTCM1-ca single-rate excess-burst-size 200k
set firewall three-color-policer srTCM1-ca action loss-priority high then discard
set firewall family inet filter filter-srtcm1ca-all term 1 then three-color-policer single-rate
srTCM1-ca
set class-of-service interfaces ge-2/0/5 unit 0 forwarding-class af
set interfaces ge-2/0/5 unit 0 family inet address 10.20.130.1/24
set interfaces ge-2/0/5 unit 0 family inet filter input filter-srtcm1ca-all
Conguring a Single-Rate Three-Color Policer
Step-by-Step Procedure
To congure a single-rate three-color policer:
1. Enable conguraon of a three-color policer.
[edit]
user@host# edit firewall three-color-policer srTCM1-ca
2. Congure the color mode of the single-rate three-color policer.
[edit firewall three-color-policer srTCM1-ca]
user@host# set single-rate color-aware
2145
3. Congure the single-rate guaranteed trac limits.
[edit firewall three-color-policer srTCM1-ca]
user@host# set single-rate committed-information-rate 40m
user@host# set single-rate committed-burst-size 100k
4. Congure the single-rate burst-size limit that is used to classify nonconforming trac.
[edit firewall three-color-policer srTCM1-ca]
user@host# set single-rate excess-burst-size 200k
5. (Oponal) Congure the acon for nonconforming trac.
[edit firewall three-color-policer srTCM1-ca]
user@host# set action loss-priority high then discard
For three-color policers, the only congurable acon is to discard packets in a red trac ow. In this
example, packets in a red trac ow have been implicitly marked with a high packet loss priority
(PLP) level because the trac ow exceeded the rate-liming dened by the single rate-limit
(specied by the committed-information-rate 40m statement) and the larger burst-size limit (specied by
the excess-burst-size 200k statement). Because the oponal action statement is included, this example
takes the more severe acon of discarding packets in a red trac ow.
Results
Conrm the conguraon of the hierarchical policer by entering the show firewall conguraon
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
three-color-policer srTCM1-ca {
action {
loss-priority high then discard;
}
single-rate {
color-aware;
committed-information-rate 40m;
committed-burst-size 100k;
excess-burst-size 200k;
2146
}
}
Conguring an IPv4 Stateless Firewall Filter That References the Policer
Step-by-Step Procedure
To congure a standard stateless rewall lter that references the policer:
1. Enable conguraon of an IPv4 standard stateless rewall lter.
[edit]
user@host# edit firewall family inet filter filter-srtcm1ca-all
2. Specify the lter term that references the policer.
[edit firewall family inet filter filter-srtcm1ca-all]
user@host# set term 1 then three-color-policer single-rate srTCM1-ca
Note that the term does not specify any match condions. The rewall lter passes all packets to the
policer.
Results
Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter filter-srtcm1ca-all {
term 1 {
then {
three-color-policer {
single-rate srTCM1-ca;
}
}
}
}
2147
}
three-color-policer srTCM1-ca {
action {
loss-priority high then discard;
}
single-rate {
color-aware;
committed-information-rate 40m;
committed-burst-size 100k;
excess-burst-size 200k;
}
}
Applying the Filter to the Logical Interface
Step-by-Step Procedure
To apply the lter to the logical interface:
1. (MX Series routers only) (Oponal) Reclassify all incoming packets on the logical interface ge-2/0/5.0
to assured forwarding, regardless of any preexisng classicaon.
[edit]
user@host# set class-of-service interfaces ge-2/0/5 unit 0 forwarding-class af
The classier name can be a congured classier or one of the default classiers.
2. Enable conguraon of the logical interface.
[edit]
user@host# edit interfaces ge-2/0/5 unit 0 family inet
3. Congure an IP address.
[edit interfaces ge-2/0/5 unit 0 family inet]
user@host# set address 10.20.130.1/24
2148
4. Reference the lter as an input lter.
[edit interfaces ge-2/0/5 unit 0 family inet]
user@host# set filter input filter-srtcm1ca-all
Results
Conrm the conguraon of the interface by entering the show class-of-service and show interfaces
conguraon mode commands. If the command output does not display the intended conguraon,
repeat the instrucons in this procedure to correct the conguraon.
[edit]
user@host# show class-of-service
interfaces {
ge-2/0/5 {
unit 0 {
forwarding-class af;
}
}
}
[edit]
user@host# show interfaces
ge-2/0/5 {
unit 0 {
family inet {
filter {
input filter-srtcm1ca-all;
}
address 10.20.130.1/24;
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
2149
Vericaon
IN THIS SECTION
Displaying the Firewall Filters Applied to the Logical Interface | 2150
Conrm that the conguraon is working properly.
Displaying the Firewall Filters Applied to the Logical Interface
Purpose
Verify that the rewall lter is applied to IPv4 input trac at the logical interface.
Acon
Use the show interfaces operaonal mode command for the logical interface ge-2/0/5.0, and specify detail
mode. The Protocol inet secon of the command output displays IPv4 informaon for the logical
interface. Within that secon, the Input Filters eld displays the name of the rewall lter applied to
IPv4 input trac at the logical interface.
user@host> show interfaces ge-2/0/5.0 detail
Logical interface ge-2/0/5.0 (Index 105) (SNMP ifIndex 556) (Generation 170)
Flags: Device-Down SNMP-Traps 0x4004000 Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
2150
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 242, Route table: 0
Flags: Sendbcast-pkt-to-re
Input Filters: filter-srtcm1ca-all
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 10.20.130/24, Local: 10.20.130.1, Broadcast: 10.20.130.255,
Generation: 171
Protocol multiservice, MTU: Unlimited, Generation: 243, Route table: 0
Policer: Input: __default_arp_policer__
SEE ALSO
Three-Color Policer Conguraon Overview | 2122
Single-Rate Three-Color Policer Overview
RELATED DOCUMENTATION
Three-Color Policer Conguraon Overview | 2122
Three-Color Policer Conguraon Guidelines | 2138
Basic Two-Rate Three-Color Policers
IN THIS SECTION
Two-Rate Three-Color Policer Overview | 2151
Example: Conguring a Two-Rate Three-Color Policer | 2153
Two-Rate Three-Color Policer Overview
A two-rate three-color policer denes two bandwidth limits (one for guaranteed trac and one for peak
trac) and two burst sizes (one for each of the bandwidth limits). A two-rate three-color policer is most
useful when a service is structured according to arrival rates and not necessarily packet length.
Two-rate three-color policing meters a trac stream based on the following congured trac criteria:
2151
• Commied informaon rate (CIR)—Bandwidth limit for guaranteed trac.
• Commied burst size (CBS)—Maximum packet size permied for bursts of data that exceed the CIR.
• Peak informaon rate (PIR)—Bandwidth limit for peak trac.
• Peak burst size (PBS)—Maximum packet size permied for bursts of data that exceed the PIR.
Two-rate tricolor marking (two-rate TCM) classies trac as belonging to one of three color categories
and performs congeson-control acons on the packets based on the color marking:
• Green—Trac that conforms to the bandwidth limit and burst size for guaranteed trac (CIR and
CBS). For a green trac ow, two-rate TCM marks the packets with an implicit loss priority of low and
transmits the packets.
• Yellow—Trac that exceeds the bandwidth limit or burst size for guaranteed trac (CIR or CBS) but
not the bandwidth limit and burst size for peak trac (PIR and PBS). For a yellow trac ow, two-
rate TCM marks packets with an implicit loss priority of medium-high and transmits the packets.
• Red—Trac that exceeds the bandwidth limit and burst size for peak trac (PIR and PBS). For a red
trac ow, two-rate TCM marks packets with an implicit loss priority of high and, oponally, discards
the packets.
If congeson occurs downstream, the packets with higher loss priority are more likely to be discarded.
NOTE: For both single-rate and two-rate three-color policers, the only
congurable
acon is to
discard packets in a red trac ow.
For a tricolor marking policer referenced by a
rewall lter
term, the discard policing acon is supported
on the following roung plaorms:
• EX Series switches
• M7i and M10i routers with the Enhanced CFEB (CFEB-E)
• M120 and M320 routers with Enhanced-III FPCs
• MX Series routers with Trio MPCs
To apply a tricolor marking policer on these roung plaorms, it is not necessary to include the logical-
interface-policer statement.
SEE ALSO
Example: Conguring a Two-Rate Three-Color Policer | 2161
2152
Example: Conguring a Two-Rate Three-Color Policer
IN THIS SECTION
Requirements | 2153
Overview | 2153
Conguraon | 2154
Vericaon | 2159
This example shows how to congure a two-rate three-color policer.
Requirements
Support for two-rate three-color policers varies according to the device. It includes SRX1400, SRX3400,
SRX3600, SRX5400, SRX5600, and SRX5800 Firewall devices running a compable version of Junos
OS.
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 2154
A two-rate three-color policer meters a trac ow against a bandwidth limit and burst-size limit for
guaranteed trac, plus a bandwidth limit and burst-size limit for peak trac. Trac that conforms to the
limits for guaranteed trac is categorized as green, and nonconforming trac falls into one of two
categories:
• Nonconforming trac that does not exceed peak trac limits is categorized as yellow.
• Nonconforming trac that exceeds peak trac limits is categorized as red.
Each category is associated with an acon. For green trac, packets are implicitly set with a loss-priority
value of low and then transmied. For yellow trac, packets are implicitly set with a loss-priority value of
medium-high
and then transmied. For red trac, packets are implicitly set with a loss-priority value of
high
2153
and then transmied. If the policer conguraon includes the oponal action statement (action loss-
priority high then discard), then packets in a red ow are discarded instead.
You can apply a three-color policer to Layer 3 trac as a rewall lter policer only. You reference the
policer from a stateless rewall lter term, and then you apply the lter to the input or output of a
logical interface at the protocol level.
Topology
In this example, you apply a color-aware, two-rate three-color policer to the input IPv4 trac at logical
interface fe-0/1/1.0. The IPv4 rewall lter term that references the policer does not apply any packet-
ltering. The lter is used only to apply the three-color policer to the interface.
You congure the policer to rate-limit trac to a bandwidth limit of 40 Mbps and a burst-size limit of
100 KB for green trac, and you congure the policer to also allow a peak bandwidth limit of 60 Mbps
and a peak burst-size limit of 200 KB for yellow trac. Only nonconforming trac that exceeds the
peak trac limits is categorized as red. In this example, you congure the three-color policer acon loss-
priority high then discard, which overrides the implicit marking of red trac to a high loss priority.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2155
Conguring a Two-Rate Three-Color Policer | 2155
Conguring an IPv4 Stateless Firewall Filter That References the Policer | 2157
Applying the Filter to a Logical Interface at the Protocol Family Level | 2158
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
.
To congure this example, perform the following tasks:
2154
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, copy and then paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from conguraon mode.
set firewall three-color-policer trTCM1-ca two-rate color-aware
set firewall three-color-policer trTCM1-ca two-rate committed-information-rate 40m
set firewall three-color-policer trTCM1-ca two-rate committed-burst-size 100k
set firewall three-color-policer trTCM1-ca two-rate peak-information-rate 60m
set firewall three-color-policer trTCM1-ca two-rate peak-burst-size 200k
set firewall three-color-policer trTCM1-ca action loss-priority high then discard
set firewall family inet filter filter-trtcm1ca-all term 1 then three-color-policer two-rate
trTCM1-ca
set interfaces ge-2/0/5 unit 0 family inet address 10.10.10.1/30
set interfaces ge-2/0/5 unit 0 family inet filter input filter-trtcm1ca-all
set class-of-service interfaces ge-2/0/5 forwarding-class af
Conguring a Two-Rate Three-Color Policer
Step-by-Step Procedure
To congure a two-rate three-color policer:
1. Enable conguraon of a three-color policer.
[edit]
user@host# set firewall three-color-policer trTCM1-ca
2. Congure the color mode of the two-rate three-color policer.
[edit firewall three-color-policer trTCM1-ca]
user@host# set two-rate color-aware
2155
3. Congure the two-rate guaranteed trac limits.
[edit firewall three-color-policer trTCM1-ca]
user@host# set two-rate committed-information-rate 40m
user@host# set two-rate committed-burst-size 100k
Trac that does not exceed both of these limits is categorized as green. Packets in a green ow are
implicitly set to low loss priority and then transmied.
4. Congure the two-rate peak trac limits.
[edit firewall three-color-policer trTCM1-ca]
user@host# set two-rate peak-information-rate 60m
user@host# set two-rate peak-burst-size 200k
Nonconforming trac that does not exceed both of these limits is categorized as yellow. Packets in a
yellow ow are implicitly set to medium-high loss priority and then transmied. Nonconforming trac
that exceeds both of these limits is categorized as red. Packets in a red ow are implicitly set to high
loss priority.
5. (Oponal) Congure the policer acon for red trac.
[edit firewall three-color-policer trTCM1-ca]
user@host# set action loss-priority high then discard
For three-color policers, the only congurable acon is to discard red packets. Red packets are
packets that have been assigned high loss priority because they exceeded the peak informaon rate
(PIR) and the peak burst size (PBS).
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
three-color-policer trTCM1-ca {
action {
loss-priority high then discard;
2156
}
two-rate {
color-aware;
committed-information-rate 40m;
committed-burst-size 100k;
peak-information-rate 60m;
peak-burst-size 200k;
}
}
Conguring an IPv4 Stateless Firewall Filter That References the Policer
Step-by-Step Procedure
To congure an IPv4 stateless rewall lter that references the policer:
1. Enable conguraon of an IPv4 standard stateless rewall lter.
[edit]
user@host# set firewall family inet filter filter-trtcm1ca-all
2. Specify the lter term that references the policer.
[edit firewall family inet filter filter-trtcm1ca-all]
user@host# set term 1 then three-color-policer two-rate trTCM1-ca
Note that the term does not specify any match condions. The rewall lter passes all packets to the
policer.
Results
Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter filter-trtcm1ca-all {
term 1 {
2157
then {
three-color-policer {
two-rate trTCM1-ca;
}
}
}
}
}
three-color-policer trTCM1-ca {
action {
loss-priority high then discard;
}
two-rate {
color-aware;
committed-information-rate 40m;
committed-burst-size 100k;
peak-information-rate 60m;
peak-burst-size 200k;
}
}
Applying the Filter to a Logical Interface at the Protocol Family Level
Step-by-Step Procedure
To apply the lter to the logical interface at the protocol family level:
1. Enable conguraon of an IPv4 rewall lter.
[edit]
user@host# edit interfaces ge-2/0/5 unit 0 family inet
2. Apply the policer to the logical interface at the protocol family level.
[edit interfaces ge-2/0/5 unit 0 family inet]
user@host# set address 10.10.10.1/30
user@host# set filter input filter-trtcm1ca-all
2158
3. (MX Series routers and EX Series switches only) (Oponal) For input policers, you can congure a
xed classier. A xed classier reclassies all incoming packets, regardless of any preexisng
classicaon.
NOTE: Plaorm support depends on the Junos OS release in your implementaon.
[edit]
user@host# set class-of-service interfaces ge-2/0/5 forwarding-class af
The classier name can be a congured classier or one of the default classiers.
Results
Conrm the conguraon of the interface by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-2/0/5 {
unit 0 {
family inet {
address 10.10.10.1/30;
filter {
input filter-trtcm1ca-all;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying the Firewall Filters Applied to the Logical Interface | 2160
2159
Conrm that the conguraon is working properly.
Displaying the Firewall Filters Applied to the Logical Interface
Purpose
Verify that the rewall lter is applied to IPv4 input trac at the logical interface.
Acon
Use the show interfaces operaonal mode command for the logical interface ge-2/0/5.0, and specify detail
mode. The Protocol inet secon of the command output displays IPv4 informaon for the logical
interface. Within that secon, the Input Filters eld displays the name of IPv4 rewall lters associated
with the logical interface.
user@host> show interfaces ge-2/0/5.0 detail
Logical interface ge-2/0/5.0 (Index 105) (SNMP ifIndex 556) (Generation 170)
Flags: Device-Down SNMP-Traps 0x4004000 Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 242, Route table: 0
Flags: Sendbcast-pkt-to-re
Input Filters: filter-trtcm1ca-all
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 10.20.130/24, Local: 10.20.130.1, Broadcast: 10.20.130.255,
Generation: 171
Protocol multiservice, MTU: Unlimited, Generation: 243, Route table: 0
Policer: Input: __default_arp_policer__
2160
SEE ALSO
Two-Rate Three-Color Policer Overview | 2151
RELATED DOCUMENTATION
Three-Color Policer Conguraon Overview | 2122
Three-Color Policer Conguraon Guidelines | 2138
Example: Conguring a Two-Rate Three-Color Policer
IN THIS SECTION
Requirements | 2161
Overview | 2161
Conguraon | 2162
Vericaon | 2167
This example shows how to congure a two-rate three-color policer.
Requirements
Support for two-rate three-color policers varies according to the device. It includes SRX1400, SRX3400,
SRX3600, SRX5400, SRX5600, and SRX5800 Firewall devices running a compable version of Junos
OS.
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 2162
2161
A two-rate three-color policer meters a trac ow against a bandwidth limit and burst-size limit for
guaranteed trac, plus a bandwidth limit and burst-size limit for peak trac. Trac that conforms to the
limits for guaranteed trac is categorized as green, and nonconforming trac falls into one of two
categories:
• Nonconforming trac that does not exceed peak trac limits is categorized as yellow.
• Nonconforming trac that exceeds peak trac limits is categorized as red.
Each category is associated with an acon. For green trac, packets are implicitly set with a loss-priority
value of low and then transmied. For yellow trac, packets are implicitly set with a loss-priority value of
medium-high and then transmied. For red trac, packets are implicitly set with a loss-priority value of high
and then transmied. If the policer conguraon includes the oponal action statement (action loss-
priority high then discard), then packets in a red ow are discarded instead.
You can apply a three-color policer to Layer 3 trac as a rewall lter policer only. You reference the
policer from a stateless rewall lter term, and then you apply the lter to the input or output of a
logical interface at the protocol level.
Topology
In this example, you apply a color-aware, two-rate three-color policer to the input IPv4 trac at logical
interface fe-0/1/1.0. The IPv4 rewall lter term that references the policer does not apply any packet-
ltering. The lter is used only to apply the three-color policer to the interface.
You congure the policer to rate-limit trac to a bandwidth limit of 40 Mbps and a burst-size limit of
100 KB for green trac, and you congure the policer to also allow a peak bandwidth limit of 60 Mbps
and a peak burst-size limit of 200 KB for yellow trac. Only nonconforming trac that exceeds the
peak trac limits is categorized as red. In this example, you congure the three-color policer acon loss-
priority high then discard, which overrides the implicit marking of red trac to a high loss priority.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2163
Conguring a Two-Rate Three-Color Policer | 2163
Conguring an IPv4 Stateless Firewall Filter That References the Policer | 2165
Applying the Filter to a Logical Interface at the Protocol Family Level | 2166
2162
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see
Using the CLI Editor in Conguraon Mode
.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, copy and then paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from conguraon mode.
set firewall three-color-policer trTCM1-ca two-rate color-aware
set firewall three-color-policer trTCM1-ca two-rate committed-information-rate 40m
set firewall three-color-policer trTCM1-ca two-rate committed-burst-size 100k
set firewall three-color-policer trTCM1-ca two-rate peak-information-rate 60m
set firewall three-color-policer trTCM1-ca two-rate peak-burst-size 200k
set firewall three-color-policer trTCM1-ca action loss-priority high then discard
set firewall family inet filter filter-trtcm1ca-all term 1 then three-color-policer two-rate
trTCM1-ca
set interfaces ge-2/0/5 unit 0 family inet address 10.10.10.1/30
set interfaces ge-2/0/5 unit 0 family inet filter input filter-trtcm1ca-all
set class-of-service interfaces ge-2/0/5 forwarding-class af
Conguring a Two-Rate Three-Color Policer
Step-by-Step Procedure
To congure a two-rate three-color policer:
1. Enable conguraon of a three-color policer.
[edit]
user@host# set firewall three-color-policer trTCM1-ca
2. Congure the color mode of the two-rate three-color policer.
[edit firewall three-color-policer trTCM1-ca]
user@host# set two-rate color-aware
2163
3. Congure the two-rate guaranteed trac limits.
[edit firewall three-color-policer trTCM1-ca]
user@host# set two-rate committed-information-rate 40m
user@host# set two-rate committed-burst-size 100k
Trac that does not exceed both of these limits is categorized as green. Packets in a green ow are
implicitly set to low loss priority and then transmied.
4. Congure the two-rate peak trac limits.
[edit firewall three-color-policer trTCM1-ca]
user@host# set two-rate peak-information-rate 60m
user@host# set two-rate peak-burst-size 200k
Nonconforming trac that does not exceed both of these limits is categorized as yellow. Packets in a
yellow ow are implicitly set to medium-high loss priority and then transmied. Nonconforming trac
that exceeds both of these limits is categorized as red. Packets in a red ow are implicitly set to high
loss priority.
5. (Oponal) Congure the policer acon for red trac.
[edit firewall three-color-policer trTCM1-ca]
user@host# set action loss-priority high then discard
For three-color policers, the only congurable acon is to discard red packets. Red packets are
packets that have been assigned high loss priority because they exceeded the peak informaon rate
(PIR) and the peak burst size (PBS).
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
three-color-policer trTCM1-ca {
action {
loss-priority high then discard;
2164
}
two-rate {
color-aware;
committed-information-rate 40m;
committed-burst-size 100k;
peak-information-rate 60m;
peak-burst-size 200k;
}
}
Conguring an IPv4 Stateless Firewall Filter That References the Policer
Step-by-Step Procedure
To congure an IPv4 stateless rewall lter that references the policer:
1. Enable conguraon of an IPv4 standard stateless rewall lter.
[edit]
user@host# set firewall family inet filter filter-trtcm1ca-all
2. Specify the lter term that references the policer.
[edit firewall family inet filter filter-trtcm1ca-all]
user@host# set term 1 then three-color-policer two-rate trTCM1-ca
Note that the term does not specify any match condions. The rewall lter passes all packets to the
policer.
Results
Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
filter filter-trtcm1ca-all {
term 1 {
2165
then {
three-color-policer {
two-rate trTCM1-ca;
}
}
}
}
}
three-color-policer trTCM1-ca {
action {
loss-priority high then discard;
}
two-rate {
color-aware;
committed-information-rate 40m;
committed-burst-size 100k;
peak-information-rate 60m;
peak-burst-size 200k;
}
}
Applying the Filter to a Logical Interface at the Protocol Family Level
Step-by-Step Procedure
To apply the lter to the logical interface at the protocol family level:
1. Enable conguraon of an IPv4 rewall lter.
[edit]
user@host# edit interfaces ge-2/0/5 unit 0 family inet
2. Apply the policer to the logical interface at the protocol family level.
[edit interfaces ge-2/0/5 unit 0 family inet]
user@host# set address 10.10.10.1/30
user@host# set filter input filter-trtcm1ca-all
2166
3. (MX Series routers and EX Series switches only) (Oponal) For input policers, you can congure a
xed classier. A xed classier reclassies all incoming packets, regardless of any preexisng
classicaon.
NOTE: Plaorm support depends on the Junos OS release in your implementaon.
[edit]
user@host# set class-of-service interfaces ge-2/0/5 forwarding-class af
The classier name can be a congured classier or one of the default classiers.
Results
Conrm the conguraon of the interface by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-2/0/5 {
unit 0 {
family inet {
address 10.10.10.1/30;
filter {
input filter-trtcm1ca-all;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying the Firewall Filters Applied to the Logical Interface | 2168
2167
Conrm that the conguraon is working properly.
Displaying the Firewall Filters Applied to the Logical Interface
Purpose
Verify that the rewall lter is applied to IPv4 input trac at the logical interface.
Acon
Use the show interfaces operaonal mode command for the logical interface ge-2/0/5.0, and specify detail
mode. The Protocol inet secon of the command output displays IPv4 informaon for the logical
interface. Within that secon, the Input Filters eld displays the name of IPv4 rewall lters associated
with the logical interface.
user@host> show interfaces ge-2/0/5.0 detail
Logical interface ge-2/0/5.0 (Index 105) (SNMP ifIndex 556) (Generation 170)
Flags: Device-Down SNMP-Traps 0x4004000 Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 242, Route table: 0
Flags: Sendbcast-pkt-to-re
Input Filters: filter-trtcm1ca-all
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 10.20.130/24, Local: 10.20.130.1, Broadcast: 10.20.130.255,
Generation: 171
Protocol multiservice, MTU: Unlimited, Generation: 243, Route table: 0
Policer: Input: __default_arp_policer__
2168
RELATED DOCUMENTATION
Two-Rate Three-Color Policer Overview | 2151
2169
CHAPTER 33
Conguring Logical and Physical Interface Trac
Policers at Layer 3
IN THIS CHAPTER
Two-Color and Three-Color Logical Interface Policers | 2170
Two-Color and Three-Color Physical Interface Policers | 2189
Two-Color and Three-Color Logical Interface Policers
IN THIS SECTION
Logical Interface (Aggregate) Policer Overview | 2170
Example: Conguring a Two-Color Logical Interface (Aggregate) Policer | 2171
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer | 2180
Logical Interface (Aggregate) Policer Overview
A
logical interface policer
—also called an
aggregate policer
—is a two-color or three-color policer that
denes trac rate liming that you can apply to input or output trac for mulple protocol families on
the same logical interface without creang mulple instances of the policer.
To congure a single-rate two-color
logical interface
policer, include the logical-interface-policer
statement at one of the following hierarchy levels:
•
[edit firewall policer
policer-name
]
• [edit logical-systems
logical-system-name
firewall policer
policer-name
]
To congure a single-rate or two-rate three-color logical interface policer, include the logical-interface-
policer statement at one of the following hierarchy levels:
2170
• [edit firewall three-color-policer
name
]
• [edit logical-systems
logical-system-name
firewall three-color-policer
name
]
NOTE: A three-color policer can be applied to Layer 2 trac as a logical interface policer only.
You cannot apply a three-color policer to Layer 2 trac as a physical interface policer (through a
rewall lter
).
You apply a logical interface policer to Layer 3 trac directly to the interface conguraon at the logical
unit level (to rate-limit all trac types, regardless of the protocol family) or at the protocol family level
(to rate-limit trac of a specic protocol family). It is OK to reference a logical interface policer from a
stateless rewall lter term and then apply the lter to a logical interface.
You can apply a logical interface policer to unicast trac only. For informaon about conguring a
stateless rewall lter for ooded trac, see “
Applying Forwarding Table Filters
” in the “Trac Sampling,
Forwarding, and Monitoring” secon of the Roung Policies, Firewall Filters, and Trac Policers User
Guide.
To display a logical interface policer on a parcular interface, issue the show interfaces policers
operaonal
mode command
.
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Three-Color Policer Conguraon Overview | 2122
Example: Conguring a Two-Color Logical Interface (Aggregate) Policer
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer
interface-specic (Firewall Filters)
logical-interface-policer
Example: Conguring a Two-Color Logical Interface (Aggregate) Policer
IN THIS SECTION
Requirements | 2172
Overview | 2172
Conguraon | 2173
2171
Vericaon | 2178
This example shows how to congure a single-rate two-color policer as a logical interface policer and
apply it to incoming IPv4 trac on a logical interface.
Requirements
Before you begin, make sure that the logical interface to which you apply the two-color logical interface
policer is hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-).
Overview
IN THIS SECTION
Topology | 2172
In this example, you congure the single-rate two-color policer policer_IFL as a logical interface policer
and apply it to incoming IPv4 trac at logical interface ge-1/3/1.0.
Topology
If the input IPv4 trac on the physical interface ge-1/3/1 exceeds the bandwidth limit equal to
90 percent of the media rate with a 300 KB burst-size limit, then the logical interface policer policer_IFL
rate-limits the input IPv4 trac on the logical interface ge-1/3/1.0. Congure the policer to mark
nonconforming trac by seng packet loss priority (PLP) levels to high and classifying packets as best-
effort.
As the incoming IPv4 trac rate on the physical interface slows and conforms to the congured limits,
Junos OS stops marking the incoming IPv4 packets at the logical interface.
2172
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2173
Conguring the Logical Interfaces | 2173
Conguring the Single-Rate Two-Color Policer as a Logical Interface Policer | 2175
Applying the Logical Interface Policer to Input IPv4 Trac at a Logical Interface | 2177
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-1/3/1 vlan-tagging
set interfaces ge-1/3/1 unit 0 vlan-id 100
set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30
set interfaces ge-1/3/1 unit 1 vlan-id 101
set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac
00:00:11:22:33:44
set firewall policer policer_IFL logical-interface-policer
set firewall policer policer_IFL if-exceeding bandwidth-percent 90
set firewall policer policer_IFL if-exceeding burst-size-limit 300k
set firewall policer policer_IFL then loss-priority high
set firewall policer policer_IFL then forwarding-class best-effort
set interfaces ge-1/3/1 unit 0 family inet policer input policer_IFL
Conguring the Logical Interfaces
Step-by-Step Procedure
To congure the logical interfaces:
2173
1. Enable conguraon of the interface.
[edit]
user@host# edit interfaces ge-1/3/1
2. Congure single tagging.
[edit interfaces ge-1/3/1]
user@host# set vlan-tagging
3. Congure logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1]
user@host# set unit 0 vlan-id 100
user@host# set unit 0 family inet address 10.10.10.1/30
4. Congure logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1]
user@host# set unit 1 vlan-id 101
user@host# set unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44
Results
Conrm the conguraon of the logical interfaces by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 10.10.10.1/30;
}
2174
}
unit 1 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
}
}
}
}
Conguring the Single-Rate Two-Color Policer as a Logical Interface Policer
Step-by-Step Procedure
To congure a single-rate two-color policer as a logical interface policer:
1. Enable conguraon of a single-rate two-color policer.
[edit]
user@host# edit firewall policer policer_IFL
2. Specify that the policer is a logical interface (aggregate) policer.
[edit firewall policer policer_IFL]
user@host# set logical-interface-policer
A logical interface policer rate-limits trac based on a percentage of the media rate of the physical
interface underlying the logical interface to which the policer is applied. The policer is applied directly
to the interface rather than referenced by a rewall lter.
3. Specify the policer trac limits.
• Specify the bandwidth limit.
• To specify the bandwidth limit as an absolute rate, from 8,000 bits per second through
50,000,000,000 bits per second, include the bandwidth-limit
bps
statement.
• To specify the bandwidth limit as a percentage of the physical port speed on the interface,
include the bandwidth-percent
percent
statement.
2175
In this example, the CLI commands and output are based on a bandwidth limit specied as a
percentage rather than as an absolute rate.
[edit firewall policer policer_IFL]
user@host# set if-exceeding bandwidth-percent 90
• Specify the burst-size limit, from 1,500 bytes through 100,000,000,000 bytes, which is the
maximum packet size to be permied for bursts of data that exceed the specied bandwidth limit.
[edit firewall policer policer_IFL]
user@host# set if-exceeding burst-size-limit 300k
4. Specify the policer acons to be taken on trac that exceeds the congured rate limits.
• To discard the packet, include the discard statement.
• To set the loss-priority value of the packet, include the loss-priority (low | medium-low | medium-high |
high) statement.
• To classify the packet to a forwarding class, include the forwarding-class (
forwarding-class
| assured-
forwarding | best-effort | expedited-forwarding | network-control) statement.
In this example, the CLI commands and output are based on both seng the packet loss priority level
and classifying the packet.
[edit firewall policer policer_IFL]
user@host# set then loss-priority high
user@host# set then forwarding-class best-effort
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
policer policer_IFL {
logical-interface-policer;
if-exceeding {
2176
bandwidth-percent 90;
burst-size-limit 300k;
}
then {
loss-priority high;
forwarding-class best-effort;
}
}
Applying the Logical Interface Policer to Input IPv4 Trac at a Logical Interface
Step-by-Step Procedure
To apply the two-color logical interface policer to input IPv4 trac a logical interface:
1. Enable conguraon of the logical interface.
[edit]
user@host# edit interfaces ge-1/3/1 unit 0
2. Apply the policer to all trac types or to a specic trac type on the logical interface.
• To apply the policer to all trac types, regardless of the protocol family, include the
policer (input | output)
policer-name
statement at the [edit interfaces
interface-name
unit
number
]
hierarchy level.
• To apply the policer to trac of a specic protocol family, include the policer (input |
output)
policer-name
statement at the [edit interfaces
interface-name
unit
unit-number
family
family-
name
] hierarchy level.
To apply the logical interface policer to incoming packets, use the policer input
policer-name
statement.
To apply the logical interface policer to outgoing packets, use the policer output
policer-name
statement.
In this example, the CLI commands and output are based on rate-liming the IPv4 input trac at
logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1 unit 0]
user@host# set family inet policer input policer_IFL
2177
Results
Conrm the conguraon of the interface by entering the show interfaces conguraon mode command.
If the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
policer input policer_IFL;
address 10.10.10.1/30;
}
}
unit 1 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying Trac Stascs and Policers for the Logical Interface | 2179
Displaying Stascs for the Policer | 2179
Conrm that the conguraon is working properly.
2178
Displaying Trac Stascs and Policers for the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show interfaces operaonal mode command for logical interface ge-1/3/1.0, and include the detail
or extensive opon. The command output secon for Trac stascs lists the number of bytes and
packets received and transmied on the logical interface. The Protocol inet subsecon contains a
Policer eld that would list the policer policer_IFL as an input or output logical interface policer as
follows:
• Input: policer_IFL-ge-1/3/1.0-log_int-i
• Output: policer_IFL-ge-1/3/1.0-log_int-o
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to input trac only.
Displaying Stascs for the Policer
Purpose
Verify the number of packets evaluated by the policer.
Acon
Use the show policer operaonal mode command and oponally specify the name of the policer. The
command output displays the number of packets evaluated by each congured policer (or the specied
policer), in each direcon. For the policer policer_IFL, the input and output policer names are displayed as
follows:
• policer_IFL-ge-1/3/1.0-log_int-i
• policer_IFL-ge-1/3/1.0-log_int-o
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to input trac only.
2179
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Logical Interface (Aggregate) Policer Overview
Example: Conguring a Three-Color Logical Interface (Aggregate) Policer
IN THIS SECTION
Requirements | 2180
Overview | 2180
Conguraon | 2181
Vericaon | 2187
This example shows how to congure a two-rate three-color color-blind policer as a logical interface
(aggregate) policer and apply the policer directly to Layer 2 input trac at a supported logical interface.
Requirements
Before you begin, make sure that the logical interface to which you apply the three-color logical
interface policer is hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) on
an MX Series router.
Overview
IN THIS SECTION
Topology | 2181
A two-rate three-color policer meters a trac ow against a bandwidth limit and burst-size limit for
guaranteed trac, plus a second set of bandwidth and burst-size limits for peak trac. Trac that
conforms to the limits for guaranteed trac is categorized as green, and nonconforming trac falls into
one of two categories:
• Nonconforming trac that does not exceed the bandwidth and burst-size limits for peak trac is
categorized as yellow.
2180
• Nonconforming trac that exceeds the bandwidth and burst-size limits for peak trac is categorized
as red.
A logical interface policer denes trac rate-liming rules that you can apply to mulple protocol
families on the same logical interface without creang mulple instances of the policer.
NOTE: You apply a logical interface policer directly to a logical interface at the logical unit level,
and not by referencing the policer in a stateless rewall lter and then applying the lter to the
logical interface at the protocol family level.
Topology
In this example, you congure the two-rate three-color policer trTCM2-cb as a color-blind logical interface
policer and apply the policer to incoming Layer 2 trac on logical interface ge-1/3/1.0.
NOTE: When using a three-color policer to rate-limit Layer 2 trac, color-aware policing can be
applied to egress trac only.
The policer denes guaranteed trac rate limits such that trac that conforms to the bandwidth limit of
40 Mbps with a 100 KB allowance for trac bursng (based on the token-bucket formula) is categorized
as green. As with any policed trac, the packets in a green ow are implicitly set to a low loss priority
and then transmied.
Nonconforming trac that falls within the peak trac limits of a 60 Mbps bandwidth limit and a 200 KB
allowance for trac bursng (based on the token-bucket formula) is categorized as yellow. The packets
in a yellow trac ow are implicitly set to a medium-high loss priority and then transmied.
Nonconforming trac that exceeds the peak trac limits are categorized as red. The packets in a red
trac ow are implicitly set to a high loss priority. In this example, the oponal policer acon for red
trac (loss-priority high then discard) is congured, so packets in a red trac ow are discarded instead
of transmied.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2182
Conguring the Logical Interfaces | 2182
2181
Conguring the Two-Rate Three-Color Policer as a Logical Interface Policer | 2184
Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface | 2186
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-1/3/1 vlan-tagging
set interfaces ge-1/3/1 unit 0 vlan-id 100
set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30
set interfaces ge-1/3/1 unit 1 vlan-id 101
set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac
00:00:11:22:33:44
set firewall three-color-policer trTCM2-cb logical-interface-policer
set firewall three-color-policer trTCM2-cb two-rate color-blind
set firewall three-color-policer trTCM2-cb two-rate committed-information-rate 40m
set firewall three-color-policer trTCM2-cb two-rate committed-burst-size 100k
set firewall three-color-policer trTCM2-cb two-rate peak-information-rate 60m
set firewall three-color-policer trTCM2-cb two-rate peak-burst-size 200k
set firewall three-color-policer trTCM2-cb action loss-priority high then discard
set interfaces ge-1/3/1 unit 0 layer2-policer input-three-color trTCM2-cb
Conguring the Logical Interfaces
Step-by-Step Procedure
To congure the logical interfaces:
2182
1. Enable conguraon of the interface.
[edit]
user@host# edit interfaces ge-1/3/1
2. Congure single tagging.
[edit interfaces ge-1/3/1]
user@host# set vlan-tagging
3. Congure logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1]
user@host# set unit 0 vlan-id 100
user@host# set unit 0 family inet address 10.10.10.1/30
4. Congure logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1]
user@host# set unit 1 vlan-id 101
user@host# set unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44
Results
Conrm the conguraon of the logical interfaces by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 10.10.10.1/30;
}
2183
}
unit 1 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
}
}
}
}
Conguring the Two-Rate Three-Color Policer as a Logical Interface Policer
Step-by-Step Procedure
To congure the two-rate three-color policer as a logical interface policer:
1. Enable conguraon of a three-color policer.
[edit]
user@host# edit firewall three-color-policer trTCM2-cb
2. Specify that the policer is a logical interface (aggregate) policer.
[edit firewall three-color-policer trTCM2-cb]
user@host# set logical-interface-policer
A logical interface policer rate-limits trac based on a percentage of the media rate of the physical
interface underlying the logical interface to which the policer is applied, and the policer is applied
directly to the interface rather than referenced by a rewall lter.
3. Specify that the policer is two-rate and color-blind.
[edit firewall three-color-policer trTCM2-cb]
user@host# set two-rate color-blind
A color-aware three-color policer takes into account any coloring markings that might have been set
for a packet by another trac policer congured at a previous network node, and any preexisng
color markings are used in determining the appropriate policing acon for the packet.
2184
Because you are applying this three-color policer applied to input at Layer 2, you must congure the
policer to be color-blind.
4. Specify the policer trac limits used to classify a green trac ow.
[edit firewall three-color-policer trTCM2-cb]
user@host# set two-rate committed-information-rate 40m
user@host# set two-rate committed-burst-size 100k
5. Specify the addional policer trac limits used to classify a yellow or red trac ow.
[edit firewall three-color-policer trTCM2-cb]
user@host# set two-rate peak-information-rate 60m
user@host# set two-rate peak-burst-size 200k
6. (Oponal) Specify the congured policer acon for packets in a red trac ow.
[edit firewall three-color-policer trTCM2-cb]
user@host# set action loss-priority high then discard
In color-aware mode, the three-color policer congured acon can increase the packet loss priority
(PLP) level of a packet, but never decrease it. For example, if a color-aware three-color policer meters
a packet with a medium PLP marking, it can raise the PLP level to high, but cannot reduce the PLP
level to low.
Results
Conrm the conguraon of the three-color policer by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
three-color-policer trTCM2-cb {
logical-interface-policer;
action {
loss-priority high then discard;
}
two-rate {
2185
color-blind;
committed-information-rate 40m;
committed-burst-size 100k;
peak-information-rate 60m;
peak-burst-size 200k;
}
}
Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface
Step-by-Step Procedure
To apply the three-color policer to the Layer 2 input at the logical interface:
1. Enable applicaon of Layer 2 logical interface policers.
[edit]
user@host# edit interfaces ge-1/3/1 unit 0
2. Apply the three-color logical interface policer to a logical interface input.
[edit interfaces ge-1/3/1 unit 0]
user@host# set layer2-policerinput-three-color trTCM2-cb
Results
Conrm the conguraon of the logical interfaces by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
ge-1/3/1 {
vlan-tagging;
unit 0 {
vlan-id 100;
layer2-policer {
input-three-color trTCM2-cb;
}
2186
family inet {
address 10.10.10.1/30;
}
}
unit 1 {
vlan-id 101;
family inet {
address 20.20.20.1/30 {
arp 20.20.20.2 mac 00:00:11:22:33:44;
}
}
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying Trac Stascs and Policers for the Logical Interface | 2187
Displaying Stascs for the Policer | 2188
Conrm that the conguraon is working properly.
Displaying Trac Stascs and Policers for the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show interfaces operaonal mode command for logical interface ge-1/3/1.0, and include the detail
or extensive opon. The command output secon for Trac stascs lists the number of bytes and
packets received and transmied on the logical interface, and the Protocol inet secon contains a
Policer eld that would list the policer trTCM2-cb as an input or output policer as follows:
2187
• Input: trTCM2-cb-ge-1/3/1.0-log_int-i
• Output: trTCM2-cb-ge-1/3/1.0-log_int-o
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to in the input direcon only.
Displaying Stascs for the Policer
Purpose
Verify the number of packets evaluated by the policer.
Acon
Use the show policer operaonal mode command and oponally specify the name of the policer. The
command output displays the number of packets evaluated by each congured policer (or the specied
policer), in each direcon. For the policer trTCM2-cb, the input and output policer names are displayed as
follows:
• trTCM2-cb-ge-1/3/1.0-log_int-i
• trTCM2-cb-e-1/3/1.0-log_int-o
The log_int-i sux denotes a logical interface policer applied to input trac, while the log_int-o sux
denotes a logical interface policer applied to output trac. In this example, the logical interface policer is
applied to input trac only.
SEE ALSO
Logical Interface (Aggregate) Policer Overview
Example: Conguring a Two-Color Logical Interface (Aggregate) Policer
Three-Color Policing at Layer 2 Overview
layer2-policer (EX)
logical-interface-policer
three-color-policer (Conguring)
RELATED DOCUMENTATION
Two-Color Policer Conguraon Overview | 2038
2188
Three-Color Policer Conguraon Overview | 2122
Guidelines for Applying Trac Policers | 1938
Two-Color and Three-Color Physical Interface Policers
IN THIS SECTION
Physical Interface Policer Overview | 2189
Example: Conguring a Physical Interface Policer for Aggregate Trac at a Physical Interface | 2191
Physical Interface Policer Overview
A
physical interface policer
is a two-color or three-color policer that denes trac rate liming that you
can apply to input or output trac for all the logical interfaces and protocol families congured on a
physical interface, even if the logical interfaces belong to dierent roung instances. This feature is
useful when you want to perform aggregate policing for dierent protocol families and dierent logical
interfaces on the same physical interface.
For example, suppose that a provider edge (PE) router has numerous logical interfaces, each
corresponding to a dierent customer, congured on the same link to a customer edge (CE) device. Now
suppose that a customer wants to apply one set of aggregated rate limits for certain types of trac on a
single physical interface. To accomplish this, you could apply a single physical interface policer to the
physical interface, which rate-limits all the logical interfaces congured on the interface and all the
roung instances to which those interfaces belong.
To congure a single-rate two-color physical interface policer, include the physical-interface-policer
statement at one of the following hierarchy levels:
• [edit firewall policer
policer-name
]
•
[edit logical-system
logical-system-name
firewall policer
policer-name
]
• [edit routing-instances
routing-instance-name
firewall policer
policer-name
]
•
[edit logical-systems
logical-system-name
routing-instances
routing-instance-name
firewall policer
policer-
name
]
To congure a single-rate or two-rate three-color physical interface policer, include the physical-interface-
policer statement at one of the following hierarchy levels:
2189
• [edit firewall three-color-policer
policer-name
]
• [edit logical-system
logical-system-name
firewall three-color-policer
policer-name
]
• [edit routing-instances
routing-instance-name
firewall three-color-policer
policer-name
]
• [edit logical-systems
logical-system-name
routing-instances
routing-instance-name
firewall three-color-policer
policer-name
]
You apply a physical interface policer to Layer 3 trac by referencing the policer from a stateless
rewall
lter
term and then applying the lter to a
logical interface
. You cannot apply a physical interface to
Layer 3 trac directly to the interface conguraon.
To reference a single-rate two-color policer from a stateless rewall lter term, use the policer
nonterminang acon. To reference a single-rate or two-rate three-color policer from a stateless rewall
lter term, use the three-color-policer nonterminang acon.
The following requirements apply to a stateless rewall lter that references a physical interface policer:
• You must congure the rewall lter for a specic, supported protocol family: ipv4, ipv6, mpls, vpls, or
circuit cross-connect (ccc), but not for family any.
• You must congure the rewall lter as a
physical interface lter
by including the physical-interface-
filter statement at the [edit firewall family
family-name
filter
filter-name
] hierarchy level.
• A rewall lter that is dened as a physical interface lter can reference a physical interface policer
only.
• A rewall lter that is dened on the global (non-logical) system cannot be used in a logical system
for interface-specic lter instances. More specically, you cannot use a template for a physical-
interface-lter that was created on the global system with a lter aachment that was created on the
logical system. Both the template and the aachment must reside on the logical system for ltering
to work correctly. This is because, for logical systems, lter instance naming is derived from the
physical interface, but the same is not true for interface-specic lter instances.
• A rewall lter that is dened as a physical interface lter cannot reference a policer congured with
the interface-specific statement.
• You cannot congure a rewall lter as both a physical interface lter and as a logical interface lter
that also includes the interface-specific statement.
SEE ALSO
Two-Color Policer Conguraon Overview | 2038
Three-Color Policer Conguraon Overview | 2122
2190
Example: Conguring a Physical Interface Policer for Aggregate Trac at a Physical Interface | 1941
physical-interface-lter
physical-interface-policer
Example: Conguring a Physical Interface Policer for Aggregate Trac at a Physical
Interface
IN THIS SECTION
Requirements | 2191
Overview | 2191
Conguraon | 2192
Vericaon | 2198
This example shows how to congure a single-rate two-color policer as a physical interface policer.
Requirements
No special conguraon beyond device inializaon is required before conguring this example.
Overview
IN THIS SECTION
Topology | 2192
A
physical interface policer
species rate-liming for aggregate trac, which encompasses all protocol
families and logical interfaces congured on a physical interface, even if the interfaces belong to
dierent roung instances.
You can apply a physical interface policer to Layer 3 input or output trac only by referencing the
policer from a stateless rewall lter that is congured for specic a specic protocol family (not for
family any) and congured as a physical interface lter. You congure the lter terms with match
condions that select the types of packets you want to rate-limit, and you specify the physical interface
policer as the acon to apply to matched packets.
2191
NOTE: Physical interface policers/lters are not supported for list lters.
Topology
The physical interface policer in this example, shared-policer-A, rate-limits to 10,000,000 bps and permits
a maximum burst of trac of 500,000 bytes. You congure the policer to discard packets in
nonconforming ows, but you could instead congure the policer to re-mark nonconforming trac with
a forwarding class, a packet loss priority (PLP) level, or both.
To be able to use the policer to rate-limit IPv4 trac, you reference the policer from an IPv4 physical
interface lter. For this example, you congure the lter to pass the policer IPv4 packets that meet
either of the following match terms:
• Packets received through TCP and with the IP precedence elds critical-ecp (0xa0), immediate (0x40),
or priority (0x20)
• Packets received through TCP and with the IP precedence elds internet-control (0xc0) or
routine (0x00)
You could also reference the policer from physical interface lters for other protocol families.
Conguraon
IN THIS SECTION
CLI Quick Conguraon | 2193
Conguring the Logical Interfaces on the Physical Interface | 2193
Conguring a Physical Interface Policer | 2194
Conguring an IPv4 Physical Interface Filter | 2195
Applying the IPv4 Physical interface Filter to Reference the Physical Interface Policers | 2197
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the CLI, see "Use the CLI Editor in Conguraon Mode" on page 1892.
To congure this example, perform the following tasks:
2192
CLI Quick Conguraon
To quickly congure this example, copy the following conguraon commands into a text le, remove
any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set interfaces so-1/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces so-1/0/0 unit 0 family vpls
set interfaces so-1/0/0 unit 1 family mpls
set firewall policer shared-policer-A physical-interface-policer
set firewall policer shared-policer-A if-exceeding bandwidth-limit 100m burst-size-limit 500k
set firewall policer shared-policer-A then discard
set firewall family inet filter ipv4-filter physical-interface-filter
set firewall family inet filter ipv4-filter term tcp-police-1 from precedence [ critical-ecp
immediate priority ]
set firewall family inet filter ipv4-filter term tcp-police-1 from protocol tcp
set firewall family inet filter ipv4-filter term tcp-police-1 then policer shared-policer-A
set firewall family inet filter ipv4-filter term tcp-police-2 from precedence [ internet-control
routine ]
set firewall family inet filter ipv4-filter term tcp-police-2 from protocol tcp
set firewall family inet filter ipv4-filter term tcp-police-2 then policer shared-policer-A
set interfaces so-1/0/0 unit 0 family inet filter input ipv4-filter
Conguring the Logical Interfaces on the Physical Interface
Step-by-Step Procedure
To congure the logical interfaces on the physical interface:
1. Enable conguraon of logical interfaces.
[edit]
user@host# edit interfaces so-1/0/0
2. Congure protocol families on logical unit 0.
[edit interfaces so-1/0/0]
user@host# set unit 0 family inet address 192.168.1.1/24
user@host# set unit 0 family vpls
2193
3. Congure protocol families on logical unit 1.
[edit interfaces so-1/0/0]
user@host# set unit 1 family mpls
Results
Conrm the conguraon of the rewall lter by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
so-1/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
family vpls;
}
unit 1 {
family mpls;
}
}
Conguring a Physical Interface Policer
Step-by-Step Procedure
To congure a physical interface policer:
1. Enable conguraon of the two-color policer.
[edit]
user@host# edit firewall policer shared-policer-A
2194
2. Congure the type of two-color policer.
[edit firewall policer shared-policer-A]
user@host# set physical-interface-policer
3. Congure the trac limits and the acon for packets in a nonconforming trac ow.
[edit firewall policer shared-policer-A]
user@host# set if-exceeding bandwidth-limit 100m burst-size-limit 500k
user@host# set then discard
For a physical interface lter, the acons you can congure for packets in a nonconforming trac
ow are to discard the packets, assign a forwarding class, assign a PLP value, or assign both a
forwarding class and a PLP value.
Results
Conrm the conguraon of the policer by entering the show firewall conguraon mode command. If
the command output does not display the intended conguraon, repeat the instrucons in this
procedure to correct the conguraon.
[edit]
user@host# show firewall
policer shared-policer-A {
physical-interface-policer;
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 500k;
}
then discard;
}
Conguring an IPv4 Physical Interface Filter
Step-by-Step Procedure
To congure a physical interface policer as the acon for terms in an IPv4 physical interface policer:
2195
1. Congure a standard stateless rewall lter under a specic protocol family.
[edit]
user@host# edit firewall family inet filter ipv4-filter
You cannot congure a physical interface rewall lter for family any.
2. Congure the lter as a physical interface lter so that you can apply the physical interface policer as
an acon.
[edit firewall family inet filter ipv4-filter]
user@host# set physical-interface-filter
3. Congure the rst term to match IPv4 packets received through TCP with the IP precedence elds
critical-ecp, immediate, or priority and to apply the physical interface policer as a lter acon.
[edit firewall family inet filter ipv4-filter]
user@host# set term tcp-police-1 from precedence [ critical-ecp immediate priority ]
user@host# set term tcp-police-1 from protocol tcp
user@host# set term tcp-police-1 then policer shared-policer-A
4. Congure the rst term to match IPv4 packets received through TCP with the IP precedence elds
internet-control or routine and to apply the physical interface policer as a lter acon.
[edit firewall family inet filter ipv4-filter]
user@host# set term tcp-police-2 from precedence [ internet-control routine ]
user@host# set term tcp-police-2 from protocol tcp
user@host# set term tcp-police-2 then policer shared-policer-A
Results
Conrm the conguraon of the rewall lter by entering the show firewall conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show firewall
family inet {
2196
filter ipv4-filter {
physical-interface-filter;
term tcp-police-1 {
from {
precedence [ critical-ecp immediate priority ];
protocol tcp;
}
then policer shared-policer-A;
}
term tcp-police-2 {
from {
precedence [ internet-control routine ];
protocol tcp;
}
then policer shared-policer-A;
}
}
}
policer shared-policer-A {
physical-interface-policer;
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 500k;
}
then discard;
}
Applying the IPv4 Physical interface Filter to Reference the Physical Interface Policers
Step-by-Step Procedure
To apply the physical interface lter so it references the physical interface policers:
1. Enable conguraon of IPv4 on the logical interface.
[edit]
user@host# edit interfaces so-1/0/0 unit 0 family inet
2197
2. Apply the IPv4 physical interface lter in the input direcon.
[edit interfaces so-1/0/0 unit 0 family inet]
user@host# set filter input ipv4-filter
Results
Conrm the conguraon of the rewall lter by entering the show interfaces conguraon mode
command. If the command output does not display the intended conguraon, repeat the instrucons in
this procedure to correct the conguraon.
[edit]
user@host# show interfaces
so-1/0/0 {
unit 0 {
family inet {
filter {
input ipv4-filter;
}
address 192.168.1.1/24;
}
family vpls;
}
unit 1 {
family mpls;
}
}
If you are done conguring the device, enter commit from conguraon mode.
Vericaon
IN THIS SECTION
Displaying the Firewall Filters Applied to an Interface | 2199
Displaying the Number of Packets Processed by the Policer at the Logical Interface | 2199
2198
Conrm that the conguraon is working properly.
Displaying the Firewall Filters Applied to an Interface
Purpose
Verify that the rewall lter ipv4-filter is applied to the IPv4 input trac at logical interface so-1/0/0.0.
Acon
Use the show interfaces statistics operaonal mode command for logical interface so-1/0/0.0, and include
the detail opon. In the Protocol inet secon of the command output, the Input Filters eld shows that
the rewall lter ipv4-filter is applied in the input direcon.
user@host> show interfaces statistics so-1/0/0 detail
Logical interface so-1/0/0.0 (Index 79) (SNMP ifIndex 510) (Generation 149)
Flags: Hardware-Down Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPP
Protocol inet, MTU: 4470, Generation: 173, Route table: 0
Flags: Sendbcast-pkt-to-re, Protocol-Down
Input Filters: ipv4-filter
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 10.39/16, Local: 10.39.1.1, Broadcast: 10.39.255.255, Generation: 163
Displaying the Number of Packets Processed by the Policer at the Logical Interface
Purpose
Verify the trac ow through the logical interface and that the policer is evaluated when packets are
received on the logical interface.
Acon
Use the show firewall operaonal mode command for the lter you applied to the logical interface.
user@host> show firewall filter ipv4-filter
Filter: ipv4-filter
Policers:
Name Packets
2199
shared-policer-A-tcp-police-1 32863
shared-policer-A-tcp-police-2 3870
The command output displays the name of policer (shared-policer-A), the name of the lter term (police-1)
under which the policer acon is specied, and the number of packets that matched the lter term. This
is only the number of out-of-specicaon (out-of-spec) packet counts, not all packets policed by the
policer.
SEE ALSO
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Fields | 986
Firewall Filter Match Condions Based on Address Classes | 996
Two-Color Policer Conguraon Overview | 2038
Physical Interface Policer Overview
RELATED DOCUMENTATION
Firewall Filter Match Condions Based on Numbers or Text Aliases | 978
Firewall Filter Match Condions Based on Bit-Field Values | 980
Firewall Filter Match Condions Based on Address Fields | 986
Firewall Filter Match Condions Based on Address Classes | 996
Two-Color Policer Conguraon Overview | 2038
Three-Color Policer Conguraon Overview | 2122
Guidelines for Applying Trac Policers | 1938
physical-interface-lter
physical-interface-policer
2200
CHAPTER 34
Conguring Policers on Switches
IN THIS CHAPTER
Overview of Policers | 2202
Trac Policer Types | 2210
Understanding the Use of Policers in Firewall Filters | 2214
Understanding Tricolor Marking Architecture | 2219
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Conguring Tricolor Marking Policers | 2222
Understanding Policers with Link Aggregaon Groups | 2225
Understanding Color-Blind Mode for Single-Rate Tricolor Marking | 2226
Understanding Color-Aware Mode for Single-Rate Tricolor Marking | 2226
Understanding Color-Blind Mode for Two-Rate Tricolor Marking | 2229
Understanding Color-Aware Mode for Two-Rate Tricolor Marking | 2229
Example: Using Two-Color Policers and Prex Lists | 2232
Example: Using Policers to Manage Oversubscripon | 2236
Assigning Forwarding Classes and Loss Priority | 2238
Conguring Color-Blind Egress Policers for Medium-Low PLP | 2241
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
Verifying That Two-Color Policers Are Operaonal | 2245
Verifying That Three-Color Policers Are Operaonal | 2246
Troubleshoong Policer Conguraon | 2247
Troubleshoong Policer Conguraon | 2251
2201
Overview of Policers
IN THIS SECTION
Policer Overview | 2202
Policer Types | 2205
Policer Acons | 2206
Policer Colors | 2207
Filter-Specic Policers | 2207
Suggested Naming Convenon for Policers | 2207
Policer Counters | 2208
Policer Algorithms | 2208
How Many Policers Are Supported? | 2209
Policers Can Limit Egress Firewall Filters | 2209
A switch polices trac by liming the input or output transmission rate of a class of trac according to
user-dened criteria. Policing (or rate-liming) trac allows you to control the maximum rate of trac
sent or received on an interface and to provide mulple priority levels or classes of service.
Policing is also an important component of rewall lters. You can achieve policing by including policers
in
rewall lter
conguraons.
Policer Overview
You use policers to apply limits to trac ow and set consequences for packets that exceed these limits
—usually applying a higher loss priority—so that if packets encounter downstream congeson, they can
be discarded rst. Policers apply only to unicast packets.
Policers provide two funcons: metering and marking. A policer meters (measures) each packet against
trac rates and burst sizes that you congure. It then passes the packet and the metering result to the
marker, which assigns a packet loss priority that corresponds to the metering result. Figure 89 on page
2204 illustrates this process.
NOTE: A policer restricts trac at the congured transmission rate per PFE. In QFX10016,
QFX10002, QFX10002-60C, and QFX10008 switches, when aggregated ethernet (AE) interface
2202
bundles span mulple PFEs, the overall transmission rate of the policer for the subscriber could
exceed the congured transmission rate of the policer (depending on the number of PFEs
involved).
As an example:
• Policer with bandwidth-limit 100 mbps congured on an AE interface that has member links
xe-1/0/0 (fpc1-pfe0) and xe-1/0/30 (fpc1-pfe1) . Here, the two member links belong to
FPC1, but are on dierent PFEs. When the policer is applied to the AE interface, this will
result in a total bandwidth of 200 Mbps as policer is congured for two PFEs.
• Policer with bandwidth-limit 100 mbps congured on an AE interface that has member links
xe-1/0/0 (fpc1-pfe0), et-2/0/1 (fpc2-pfe1) and xe-2/0/18:0 (fpc2-pfe2) . Here, one member
link belongs to FPC1 and PFE0 on this FPC. Thes rest two member links belong to FPC2, but
dierent PFEs. When the policer is applied to the AE interface, this will result in a total
bandwidth of 300 Mbps as policer is congured for three PFEs.
• Policer with bandwidth-limit 100 mbps congured on an AE interface that has member links
xe-1/0/0 and xe-1/0/1 on a single PFE (fpc1-pfe0) . Here, the member links belong to FPC1
and to the same PFE. When the policer is applied to the AE interface, this will result in a total
bandwidth of 100 Mbps as policer is congured on a per PFE basis.
2203
Figure 89: Flow of Tricolor Marking Policer Operaon
2204
Aer you name and congure a policer, you can use it by specifying it as an acon in one or more
rewall lters.
Policer Types
A switch supports three types of policers:
• Single-rate two-color marker—A two-color policer (or “policer” when used without qualicaon)
meters the trac stream and classies packets into two categories of packet loss priority (PLP)
according to a congured bandwidth and burst-size limit. You can mark packets that exceed the
bandwidth and burst-size limit with a specied PLP or simply discard them.
You can specify this type of policer in an ingress or egress rewall.
NOTE: A two-color policer is most useful for metering trac at the port (physical interface)
level.
• Single-rate three-color marker—This type of policer is dened in RFC 2697,
A Single Rate Three Color
Marker
, as part of an assured forwarding (AF) per-hop-behavior (PHB) classicaon system for a
Dierenated Services (DiServ) environment. This type of policer meters trac based on one rate—
the congured commied informaon rate (CIR) as well as the commied burst size (CBS) and the
excess burst size (EBS). The CIR species the average rate at which bits are admied to the switch.
The CBS species the usual burst size in bytes and the EBS species the maximum burst size in
bytes. The EBS must be greater than or equal to the CBS, and neither can be 0.
You can specify this type of policer in an ingress or egress rewall.
NOTE: A single-rate three-color marker (TCM) is most useful when a service is structured
according to packet length and not peak arrival rate.
• Two-rate three-color marker—This type of policer is dened in RFC 2698,
A Two Rate Three Color
Marker
, as part of an assured forwarding per-hop-behavior classicaon system for a Dierenated
Services environment. This type of policer meters trac based on two rates—the CIR and peak
informaon rate (PIR) along with their associated burst sizes, the CBS and peak burst size (PBS). The
PIR species the maximum rate at which bits are admied to the network and must be greater than
or equal to the CIR.
You can specify this type of policer in an ingress or egress rewall.
2205
NOTE: A two-rate three-color policer is most useful when a service is structured according to
arrival rates and not necessarily packet length.
See Table 120 on page 2206 for informaon about how metering results are applied for each of these
policer types.
Policer Acons
Policer acons are implicit or explicit and vary by policer type.
Implicit
means that Junos OS assigns the
loss priority automacally. Table 120 on page 2206 describes the policer acons.
Table 120: Policer Acons
Policer Marking Implicit Acon Congurable Acon
Single-rate two-color Green (conforming) Assign low loss priority None
Red (nonconforming) None Discard
Single-rate three-color Green (conforming) Assign low loss priority None
Yellow (above the CIR and
CBS)
Assign medium-high loss
priority
None
Red (above the EBS) Assign high loss priority Discard
Two-rate three-color Green (conforming) Assign low loss priority None
Yellow (above the CIR and
CBS)
Assign medium-high loss
priority
None
Red (above the PIR and
PBS)
Assign high loss priority Discard
2206
NOTE: If you specify a policer in an egress
rewall lter
, the only supported acon is discard.
Policer Colors
Single-rate and two-rate three-color policers can operate in two modes:
• Color-blind—In color-blind mode, the three-color policer assumes that all packets examined have not
been previously marked or metered. In other words, the three-color policer is “blind” to any previous
coloring a packet might have had.
• Color-aware—In color-aware mode, the three-color policer assumes that all packets examined have
been previously marked or metered. In other words, the three-color policer is “aware” of the previous
coloring a packet might have had. In color-aware mode, the three-color policer can increase the PLP
of a packet but cannot decrease it. For example, if a color-aware three-color policer meters a packet
with a medium PLP marking, it can raise the PLP level to high but cannot reduce the PLP level to low.
Filter-Specic Policers
You can congure policers to be lter-specic, which means that Junos OS creates only one policer
instance regardless of how many mes the policer is referenced. When you do this on some QFX
switches, rate liming is applied in aggregate, so if you congure a policer to discard trac that exceeds
1 Gbps and reference that policer in three dierent terms, the total bandwidth allowed by the lter is
1 Gbps. However, the behavior of a lter-specic policer is aected by how the rewall lter terms that
reference the policer are stored in TCAM. If you create a lter-specic policer and reference it in
mulple rewall lter terms, the policer allows more trac than expected if the terms are stored in
dierent TCAM slices. For example, if you congure a policer to discard trac that exceeds 1 Gbps and
reference that policer in three dierent terms that are stored in three separate memory slices, the total
bandwidth allowed by the lter is 3 Gbps, not 1 Gbps. (This behavior does not occur in QFX10000
switches.)
To prevent this unexpected behavior from occurring, use the informaon about TCAM slices presented
in "Planning the Number of Firewall Filters to Create" on page 1725 to organize your conguraon le
so that all the rewall lter terms that reference a given lter-specic policer are stored in the same
TCAM slice.
Suggested Naming Convenon for Policers
We recommend that you use the naming convenon
policertypeTCM#-color type
when conguring three-
color policers and
policer#
when conguring two-color policers. TCM stands for three-color marker.
Because policers can be numerous and must be applied correctly to work, a simple naming convenon
2207
makes it easier to apply the policers properly. For example, the rst single-rate, color-aware three-color
policer congured would be named srTCM1-ca. The second two-rate, color-blind three-color congured
would be named trTCM2-cb. The elements of this naming convenon are explained below:
• sr (single-rate)
• tr (two-rate)
• TCM (tricolor marking)
• 1 or 2 (number of marker)
• ca (color-aware)
• cb (color-blind)
Policer Counters
On some QFX switches, each policer that you congure includes an implicit counter that counts the
number of packets that exceed the rate limits that are specied for the policer. If you use the same
policer in mulple terms—either within the same lter or in dierent lters—the implicit counter counts
all the packets that are policed in all of these terms and provides the total amount. (This does not apply
to QFX10000 switches.) If you want to obtain separate packet counts for each term on an aected
switch, use these opons:
• Congure a unique policer for each term.
• Congure only one policer, but use a unique, explicit counter in each term.
Policer Algorithms
Policing uses the
token-bucket algorithm
, which enforces a limit on average bandwidth while allowing
bursts up to a specied maximum value. It oers more exibility than the
leaky bucket algorithm
in
allowing a certain amount of bursty trac before it starts discarding packets.
NOTE: In an environment of light bursty trac, QFX5200 might not replicate all mulcast
packets to two or more downstream interfaces. This occurs only at a line rate burst—if trac is
consistent, the issue does not occur. In addion, the issue occurs only when packet size increases
beyond 6k in a one gigabit trac ow.
2208
How Many Policers Are Supported?
QFX10000 switches support 8K policers (all policer types). QFX5100 and QFX5200 switches support
1535 ingress policers and 1024 egress policers (assuming one policer per rewall lter term). QFX5110
switches support 6144 ingress policers and 1024 egress policers (assuming one policer per rewall lter
term).
QFX3500 and QFX3600 standalone switches and QFabric Node devices support the following numbers
of policers (assuming one policer per rewall lter term):
• Two-color policers used in ingress rewall lters: 767
• Three-color policers used in ingress rewall lters: 767
• Two-color policers used in egress rewall lters: 1022
• Three-color policers used in egress rewall lters: 512
Policers Can Limit Egress Firewall Filters
On some switches, the number of egress policers you congure can aect the total number of allowed
egress rewall lters. Every policer has two implicit counters that take up two entries in a 1024-entry
TCAM. These are used for counters, including counters that are congured as acon modiers in rewall
lter terms. (Policers consume two entries because one is used for green packets and one is used for
nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any
more egress rewall lters that have terms with counters. For example, if you congure and commit 512
egress policers (two-color, three-color, or a combinaon of both policer types), all of the memory entries
for counters get used up. If later in your conguraon le you insert addional egress rewall lters with
terms that also include counters,
none
of the terms in those lters are commied because there is no
available memory space for the counters.
Here are some addional examples:
• Assume that you congure egress lters that include a total of 512 policers and no counters. Later in
your conguraon le you include another egress lter with 10 terms, 1 of which has a counter
acon modier. None of the terms in this lter are commied because there is not enough TCAM
space for the counter.
• Assume that you congure egress lters that include a total of 500 policers, so 1000 TCAM entries
are occupied. Later in your conguraon le you include the following two egress lters:
• Filter A with 20 terms and 20 counters. All the terms in this lter are commied because there is
enough TCAM space for all the counters.
2209
• Filter B comes aer Filter A and has ve terms and ve counters.
None
of the terms in this lter
are commied because there is not enough memory space for
all
the counters. (Five TCAM
entries are required but only four are available.)
You can prevent this problem by ensuring that egress rewall lter terms with counter acons are placed
earlier in your conguraon le than terms that include policers. In this circumstance, Junos OS commits
policers even if there is not enough TCAM space for the implicit counters. For example, assume the
following:
• You have 1024 egress rewall lter terms with counter acons.
• Later in your conguraon le you have an egress lter with 10 terms. None of the terms have
counters but one has a policer acon modier.
You can successfully commit the lter with 10 terms even though there is not enough TCAM space for
the implicit counters of the policer. The policer is commied without the counters.
RELATED DOCUMENTATION
Understanding Color-Blind Mode for Single-Rate Tricolor Marking | 2226
Understanding Color-Blind Mode for Two-Rate Tricolor Marking | 2229
Understanding Color-Aware Mode for Single-Rate Tricolor Marking | 2226
Understanding Color-Aware Mode for Two-Rate Tricolor Marking | 2229
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
Trac Policer Types
IN THIS SECTION
Single-Rate Two-Color Policers | 2211
Three-Color Policers | 2211
Two-Color and Three-Color Policer Opons | 2212
2210
Single-Rate Two-Color Policers
You can use a single-rate two-color policer, or “policer” when used without qualicaon, to rate-limit a
trac ow to an average bits-per-second arrival rate (specied by the single specied bandwidth limit)
while allowing bursts of trac for short periods (controlled by the single specied burst-size limit). This
type of policer categorizes a trac ow as either green (conforming) or red (nonconforming). Packets in
a green ow are implicitly set to a low loss priority and then transmied. Packets in a red ow are
handled according to acons specied in the policer conguraon. Packets in a red ow can be marked
—set to a specied forwarding class, set to a specied loss priority, or both—or they can be discarded.
A single-rate two-color policer is most useful for metering trac at the port (physical interface) level.
Basic Single-Rate Two-Color Policer
You can apply a basic single-rate two-color policer to Layer 3 trac in either of two ways: as an
interface policer or as a rewall lter policer. You can apply the policer as an
interface policer
, meaning
that you apply the policer directly to a logical interface at the protocol family level. If you want to apply
the policer to selected packets only, you can apply the policer as a
rewall lter policer
, meaning that
you reference the policer in a stateless rewall lter term and then apply the lter to a logical interface
at the protocol family level.
Bandwidth Policer
A bandwidth policer is simply a single-rate two-color policer that is dened using a bandwidth limit
specied as a percentage value rather than as an absolute number of bits per second. When you apply
the policer (as an interface policer or as a rewall lter policer) to a logical interface at the protocol
family level, the eecve bandwidth limit is calculated based on either the physical interface media rate
or the logical interface congured shaping rate.
Logical Bandwidth Policer
A logical bandwidth policer is a bandwidth policer for which the eecve bandwidth limit is calculated
based on the logical interface congured shaping rate. You can apply the policer as a rewall lter
policer only, and the rewall lter must be congured as an interface-specic lter. When you apply an
interface-specic lter to mulple logical interfaces on supported roung plaorms, any count or policer
acons act on the trac stream entering or exing each individual interface, regardless of the sum of
trac on the mulple interfaces.
Three-Color Policers
The Junos OS supports two types of three-color policers: single-rate and two-rate. The main dierence
between a single-rate and a two-rate policer is that the single-rate policer allows bursts of trac for
2211
short periods, while the two-rate policer allows more sustained bursts of trac. Single-rate policing is
implemented using a single token-bucket model, so that periods of relavely low trac must occur
between trac bursts to allow the token bucket to rell. Two-rate policing is implemented using a dual
token-bucket model, which allows bursts of trac for longer periods.
Single-Rate Three-Color Policers
The single-rate three-color type of policer is dened in RFC 2697,
A Single Rate Three Color Marker
.
You use this type of policer to rate-limit a trac ow to a single rate and three trac categories (green,
yellow, and red). A single-rate three-color policer denes a
commied
bandwidth limit and burst-size
limit plus an
excess
burst-size limit. Trac that conforms to the commied trac limits is categorized as
green (conforming). Trac that conforms to the bandwidth limit while allowing bursts of trac as
controlled by the excess burst-size limit is categorized as yellow. All other trac is categorized as red.
A single-rate three-color policer is most useful when a service is structured according to packet length,
not peak arrival rate.
Two-Rate Three-Color Policers
The two-rate three-color type of policer is dened in RFC 2698,
A Two Rate Three Color Marker
. You
use this type of policer to rate-limit a trac ow to two rates and three trac categories (green, yellow,
and red). A two-rate three-color policer denes a
commied
bandwidth limit and burst-size limit plus a
peak
bandwidth limit and burst-size limit. Trac that conforms to the commied trac limits is
categorized as green (conforming). Trac that exceeds the commied trac limits but remains below
the peak trac limits is categorized as yellow. Trac that exceeds the peak trac limits is categorized as
red.
A two-rate three-color policer is most useful when a service is structured according to arrival rates and
not necessarily packet length.
Two-Color and Three-Color Policer Opons
Both two-color and three-color policers can be congured with the following opons:
Logical Interface (Aggregate) Policers
A logical interface policer can be a two-color policer, not a three-color policer. When you apply a logical
inteface policer to mulple protocol families on the same logical interface, mulple instances of the
policer are created, meaning that trac for each protocol family is policed separately. You apply a logical
interface policer directly to a logical interface conguraon (and not by referencing the policer in a
stateless rewall lter and then applying the lter to the logical interface).
2212
• You can apply the policer at the interface logical unit level to rate-limit all trac types, regardless of
the protocol family.
When applied in this manner, the logical interface policer will be used by all trac types (inet, intet6,
etc.) and across all layers (layer 2, layer 3) no maer where the policer is aached on the logical
interface.
• You can also apply the policer at the logical interface protocol family level, to rate-limit trac for a
specic protocol family.
You can apply a logical interface policer to unicast trac only. For informaon about conguring a
stateless rewall lter for ooded trac, see “
Applying Forwarding Table Filters
” in the “Trac Sampling,
Forwarding, and Monitoring” secon of the Roung Policies, Firewall Filters, and Trac Policers User
Guide.
Physical Interface Policers
A physical interface policer can be a two-color or three-color policer. When you apply physical interface
policer, to dierent protocol families on the same logical interface, the protocol families share the same
policer instance. This means that rate liming is performed aggregately for the protocol families for
which the policer is applied. This feature enables you to use a single policer instance to perform
aggregate policing for dierent protocol families on the same physical interface. If you want a policer
instance to be associated with a protocol family, the corresponding physical interface lter needs to be
applied to that protocol family. The policer is not automacally applied to all protocol families congured
on the physical interface.
In contrast, with logical interface policers there are mulple separate policer instances.
Policers Applied to Layer 2 Trac
In addion to hierarchical policing, you can also apply single-rate two-color policers and three-color
policers (both single-rate and two-rate) to Layer 2 input or output trac. You must congure the two-
color or three-color policer as a logical interface policer and reference the policer in the interface
conguraon at the logical unit level, and not at the protocol level. You cannot apply a two-color or
three-color policer to Layer 2 trac as a stateless rewall lter acon.
Muleld Classicaon
Like behavior aggregate (BA) classicaon, which is somemes referred to as class-of-service (CoS) value
trac classicaon, muleld classicaon is a method of classifying incoming trac by associang
each packet with a forwarding class, a packet loss priority level, or both. The CoS scheduling
conguraon assigns packets to output queues based on forwarding class. The CoS random early
detecon (RED) process uses the drop probability conguraon, output queue fullness percentage, and
packet loss priority to drop packets as needed to control congeson at the output stage.
2213
BA classicaon and muleld classicaon use dierent elds of a packet to perform trac
classicaon. BA classicaon is based on a
CoS value
in the IP packet header. Muleld classicaon
can be based on
mulple elds
in the IP packet header, including CoS values. Muleld classicaon is
used instead of BA classicaon when you need to classify packets based on informaon in the packet
other than the CoS values only. Muleld classicaon is congured using a stateless rewall lter term
that matches on any packet header elds and associates matched packets with a forwarding class, a loss
priority, or both. The forwarding class or loss priority can be set by a rewall lter acon or by a policer
referenced as a rewall lter acon.
RELATED DOCUMENTATION
Controlling Network Access Using Trac Policing Overview | 1920
Order of Policer and Firewall Filter Operaons | 1930
Two-Color Policer Conguraon Overview | 2038
Three-Color Policer Conguraon Overview | 2122
Two-Color Policing at Layer 2 Overview
Three-Color Policing at Layer 2 Overview
Understanding the Use of Policers in Firewall Filters
IN THIS SECTION
Policers Overview | 2215
Policer Types | 2215
Policer Acons | 2216
Policer Levels | 2217
Color Modes | 2217
Naming Convenons for Policers | 2218
Policing, or rate liming, is an important component of rewall lters that lets you control the amount of
trac that enters an interface on Juniper Networks EX Series Ethernet Switches. You can achieve
policing by including policers in
rewall lter
conguraons.
2214
Policers Overview
You can use policers to specify rate limits on trac. A rewall lter congured with a policer permits
only trac within a specied set of rate limits, thereby providing protecon from denial-of-service (DoS)
aacks. Trac that exceeds the rate limits specied by the policer is either discarded immediately or is
marked as lower priority than trac that is within the rate limits. The switch discards the lower-priority
trac when there is trac congeson.
A policer applies two types of rate limits on trac:
• Bandwidth—The number of bits per second permied, on average.
• Maximum burst size—The maximum size permied for bursts of data that exceed the given
bandwidth limit.
Policing uses an algorithm to enforce a limit on average bandwidth while allowing bursts up to a
specied maximum value. You can dene specic classes of trac on an interface and apply a set of rate
limits to each class. Aer you name and congure a policer, it is stored as a template. You can then use
the policer in a rewall lter conguraon.
On all EX Series switches except Juniper Networks EX8200 Ethernet Switches, each policer that you
congure includes an implicit counter that counts the number of packets that exceed the rate limit
specied for the policer. Each EX8200 switch contains three global management counters. You must
assign ingress policers to these global management counters to obtain policer stascs. You can assign
any number of ingress policers to each global management counter. The policer stascs for each global
management counter are the aggregate of the policer stascs for all policers associated with that
global management counter.
To get lter-specic packet counts, you must congure a dierent policer for each rewall lter. Policers
give term-specic counts by default.
Policer Types
Switches support three types of policers:
• Single-rate two-color—A two-color policer (somemes called simply “policer”) meters the trac
stream and classies packets into two categories of packet loss priority (PLP) according to a
congured bandwidth and burst-size limit. You can mark packets that exceed the bandwidth and
burst-size limit or simply discard them. A two-color policer is most useful for metering trac at the
port (physical interface) level.
• Single-rate three-color—This type of policer is dened in RFC 2697, A
Single Rate Three Color
Marker
, as part of an assured forwarding (AF) per-hop-behavior (PHB) classicaon system for a
Dierenated Services (DiServ) environment. This type of policer meters trac based on the
congured commied informaon rate (CIR), commied burst size (CBS), and the excess burst size
2215
(EBS). Trac is marked as belonging to one of three categories (green, yellow, or red) based on
whether the packets are arriving at rates that are below the CBS (green), exceed the CBS but not the
EBS (yellow), or exceed the EBS (red). A single-rate three-color policer is most useful when a service
is structured according to packet size and not according to peak arrival rate.
• Two-rate three-color—This type of policer is dened in RFC 2698, A
Two Rate Three Color Marker
, as
part of an assured forwarding (AF) per-hop-behavior (PHB) classicaon system for a Dierenated
Services (DiServ) environment. This type of policer meters trac based on the congured CIR and
the peak informaon rate (PIR), along with their associated burst sizes; the CBS, and the peak burst
size (PBS). Trac is marked as belonging to one of three categories (green, yellow, or red) based on
packets are arriving at rates that are below the CIR (green), exceed the CIR but not the PIR (yellow),
or exceed the PIR (red). A two-rate three-color policer is most useful when a service is structured
according to arrival rates and not to packet size.
Policer Acons
Policer acons can be implicit or explicit and vary by policer type. The term implicit means that Junos
OS assigns a loss-priority value automacally; explicit means that you congure the acon. Table 121 on
page 2216 lists policer acons.
Table 121: Policer
Acons
Policer Marking Implicit Acon Congurable Acon
Single-rate two-
color
Green (Conforming) Assign low loss priority None
Red (Nonconforming) None Assign low or high loss
priority, assign a
forwarding class, or
discard
Yellow Not supported Not supported
Single-rate three-
color
Green (Conforming) Assign low loss priority None
Red (Above the EBS) Assign high loss priority Discard
2216
Table 121: Policer Acons
(Connued)
Policer Marking Implicit Acon Congurable Acon
Yellow (Exceeds the CBS but
not the EBS)
Assign high loss priority
NOTE: Not supported on
EX8200 switches
None
NOTE: Not supported on
EX8200 switches
Two-rate three-color Green (Conforming) Assign low loss priority None
Red (Above the PIR) Assign high loss priority Discard
Yellow (Exceeds the CIR but
not the PIR)
Assign high loss priority
NOTE: Not supported on
EX8200 switches
None
NOTE: Not supported on
EX8200 switches
NOTE: You cannot apply a policer with an acon of forwarding-class to an output rewall lter.
NOTE: Beginning with Junos OS Release 17.1, on EX4300 switches, you can congure the
policer acon loss-priority to be low, medium-low, medium-high, or high.
Policer Levels
You can congure policers at the queue level,
logical interface
level, or Layer 2 (MAC) level. Only a single
policer is applied to a packet at the egress queue. The search for policers occurs in this order:
• Queue level
• Logical interface level
• Layer 2 (MAC) level
Color Modes
Tricolor marking (TCM) policers are not bound by a green-yellow-red coloring convenon. Packets are
marked with low or high PLP bit conguraons based on color. Therefore, both three-color policer types
2217
(single-rate and two-rate) extend the funconality of class-of-service (CoS) trac policing by providing
three levels of drop precedence (loss priority) instead of the two normally available in policers. Both
single-rate and two-rate three-color policer types can operate in two modes:
• Color-blind—In color-blind mode, the three-color policer operates without reference to whether the
examined packets have been previously marked or metered. In other words, the three-color policer is
blind
to any previous coloring a packet might have had.
• Color-aware—In color-aware mode, the three-color policer operates with reference to any previous
marking or metering of the examined packets. In other words, the three-color policer is
aware
of the
previous coloring a packet might have had. In color-aware mode, the three-color policer can increase
the PLP of a packet but can never decrease it. For example, if a color-aware three-color policer
meters a packet with a low PLP marking, it can raise the PLP level to high. But it cannot reduce a high
PLP level to low.
Naming Convenons for Policers
We recommend you use the naming convenon
rate-TCMnumber-colortype
when conguring three-
color policers. TCM stands for tricolor marking. Because policers can be numerous and must be applied
correctly to work, observing a simple naming convenon makes it easier to apply the policers properly.
For example, if you congure a single-rate, three-color, color-aware policer, name it srTCM1-ca. If you
congure a two-rate, three-color, color-blind policer, name it trTCM2-cb.
Change History Table
Feature support is determined by the plaorm and release you are using. Use Feature Explorer to
determine if a feature is supported on your plaorm.
Release
Descripon
17.1
Beginning with Junos OS Release 17.1, on EX4300 switches, you can congure the policer acon loss-
priority to be low, medium-low, medium-high, or high.
RELATED DOCUMENTATION
Firewall Filters for EX Series Switches Overview | 1539
Understanding Tricolor Marking Architecture | 2219
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
2218
Understanding Tricolor Marking Architecture
Tricolor marking (TCM) policers provide two funcons: metering and marking. A policer meters each
packet and passes the packet and the metering result to the marker.
The meter operates in two modes. In the color-blind mode, the meter treats the packet stream as
uncolored. Any preset loss priories are ignored. In the color-aware mode, the meter inspects the packet
loss priority (PLP) eld, which has been set by an upstream device as high or low; in other words, the
PLP eld has already been set by a behavior aggregate (BA) or muleld (MF) classier. The marker
changes the PLP of each incoming IP packet according to the results of the meter.
Single-rate TCM is so called because trac is policed according to one rate—the commied burst rate
(CBR)—and two burst sizes: the commied burst size (CBS) and the excess burst size (EBS). The
congured informaon rate (CIR) species the average rate at which bits are admied to the network.
The CBS species the usual burst size in bytes and the EBS species the maximum burst size in bytes for
packets that are admied to the network. The EBS is greater than or equal to the CBS, and neither can
be 0. As each packet enters the network, its bytes are counted. Packets that do not exceed the CBS are
marked low PLP. Packets that exceed the peak informaon rate (PIR) are marked high PLP.
Two-rate TCM is so called because trac is policed according to two rates: the CIR and the PIR. The PIR
is greater than or equal to the CIR. The CIR species the average rate at which bits are admied to the
network, and the PIR species the maximum rate at which bits are admied to the network. As each
packet enters the network, its bits are counted. Bits in packets that do not exceed the CIR have their
packets marked low PLP. Bits in packets that exceed the PIR have their packets marked high PLP.
RELATED DOCUMENTATION
Understanding the Use of Policers in Firewall Filters | 2214
Conguring Tricolor Marking Policers | 2222
Conguring Policers to Control Trac Rates (CLI Procedure)
IN THIS SECTION
Conguring Policers | 2220
Specifying Policers in a Firewall Filter Conguraon | 2222
Applying a Firewall Filter That Is Congured with a Policer | 2222
2219
You can congure policers to rate limit trac on EX Series switches. Aer you congure a policer, you
can include it in an ingress rewall lter conguraon.
When you congure a rewall lter, you can specify a policer acon for any term or terms within the
lter. All trac that matches a term that contains a policer acon goes through the policer that the term
references. Each policer that you congure includes an implicit counter. To get term-specic packet
counts, you must congure a separate policer for each lter term that requires policing.
NOTE: On all EX Series switches except EX8200 switches, each policer that you congure
includes an implicit counter. To ensure term-specic packet counts, congure a policer for each
term in the lter that requires policing. For EX8200 switches, congure a policer and associate it
with a global management counter using the
counter
opon.
The following policer limits apply on a switch:
• A maximum of 512 policers can be congured for port rewall lters.
• A maximum of 512 policers can be congured for VLAN and Layer 3 rewall lters.
If the number of policers in the rewall lter conguraon exceeds these limits, the switch returns the
following message when you commit the conguraon:
Cannot assign policers: Max policer limit reached
This topic includes these tasks:
Conguring Policers
To congure a policer:
1. Specify the name of the policer:
[edit firewall]
user@switch# set policer policer-one
The policer name can include leers, numbers, and hyphens (-) and can contain up to 64 characters.
2. Specify the lter-specic statement to congure a policer to act as a lter-specic policer; else
proceed to step 3:
[edit firewall]
user@switch# set policer policer-one filter-specific
2220
If you do not specify the filter-specific statement, the policer acts as a term-specic policer by
default.
3. Congure rate liming for the policer:
a. Specify the bandwidth limit in bits per second (bps) to control the trac rate on an interface:
[edit firewall policer policer-one]
user@switch# set if-exceeding bandwidth-limit 300k
The range for the bandwidth limit is 1k through 102.3g bps.
b. Specify the burst-size limit (the maximum allowed burst size in bytes) to control the amount of
trac bursng:
[edit firewall policer policer-one]
user@switch# set if-exceeding burst-size-limit 500k
To determine the value for the burst-size limit, mulply the bandwidth of the interface on which
the lter is applied by the amount of me to allow a burst of trac at that bandwidth to occur:
burst size = (bandwidth) * (allowable me for burst trac)
The range for the burst-size limit is 1 through 2,147,450,880 bytes.
4. Specify the policer acon discard to discard packets that exceed the rate limits:
[edit firewall policer]
user@switch# set policer-one then (Policer Action) discard
Discard is the only supported policer acon.
5. On EX8200 switches, you must assign a global management counter to the policer to obtain policer
stascs:
[edit firewall policer]
user@switch# set policer-one counter counter-id 0
In this sample statement, the global management counter ID is 0. You can assign any number of
policers to the global management counter. The policer stascs displayed for each counter are the
collecve stascs of all policers assigned to that counter.
2221
Specifying Policers in a Firewall Filter Conguraon
To reference a policer for a single rewall, congure a lter term that includes the policer acon:
[edit firewall family ethernet-switching]
user@switch# set filter limit-hosts term term-one from source-address 192.0.2.0/28
users@witch# set filter limit-hosts term term-one then policer policer-one
Applying a Firewall Filter That Is Congured with a Policer
A rewall lter that is congured with one or more policer acons, like any other rewall lter, must be
applied to a port, VLAN, or Layer 3 interface. For informaon about applying rewall lters, see the
secons on applying rewall lters in "Conguring Firewall Filters (CLI Procedure)" on page 1642.
RELATED DOCUMENTATION
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Conguring Firewall Filters (CLI Procedure) | 1642
Verifying That Policers Are Operaonal | 1703
Understanding the Use of Policers in Firewall Filters | 2214
Conguring Tricolor Marking Policers
IN THIS SECTION
Conguring a Tricolor Marking Policer | 2223
Applying Tricolor Marking Policers to Firewall Filters | 2224
You can rate-limit trac on EX Series switches by conguring a policer and specifying it as an acon
modier for a term in a rewall lter. By default, if you specify the same policer in mulple terms, Junos
OS creates a separate policer instance for each term and applies rate liming separately for each
instance. For example, if you congure a policer to discard trac that exceeds 1 Gbps and reference that
policer in three dierent terms, each policer instance enforces a 1-Gbps limit. In this case, the total
bandwidth allowed by the lter is 3 Gbps.
2222
You can also congure a policer to be lter-specic, which means that Junos OS creates only one policer
instance regardless of how many mes the policer is referenced. When you do this, rate liming is
applied in aggregate, so if you congure a policer to discard trac that exceeds 1 Gbps and reference
that policer in three dierent terms, the total bandwidth allowed by the lter is 1 Gbps.
This topic describes how to congure single-rate and two-rate tricolor marking (TCM) policers, also
known as single-rate and two-rate three-color policers. If you want to congure a single-rate two-color
policer (also known just as a "policer"), see "Conguring Policers to Control Trac Rates (CLI Procedure)"
on page 2219.
Conguring a Tricolor Marking Policer
A tricolor marking policer polices trac on the basis of metering rates, including the congured
informaon rate (CIR), the peak informaon rate (PIR), their associated burst sizes, and any policing
acons congured for the trac. With tri-color marking, you can congure trac policing according to
two separate modes—color-blind and color-aware. In color-blind mode, the current packet loss priority
(PLP) value is ignored. In color-aware mode, the current PLP values are considered by the policer, and
the policer can increase those values but cannot decrease them.
To congure a tricolor marking (TCM) policer:
1. Specify the name of the policer and (oponally) whether to automacally discard packets with high
loss priority (PLP):
[edit firewall]
user@switch# set three-color-policer
policer-name
user@switch# set three-color-policer
policer-name
action loss-priority high then discard
2. Specify the policer as either single-rate or two-rate and as color-aware or color-blind:
[edit firewall three-color-policer
policer-name
]
user@switch# set
rate
mode
For example:
[edit firewall three-color-policer srTCm-1a]
user@switch# set single-rate color-aware
[edit firewall three-color-policer trTCM2-cb]
user@switch# set two-rate color-blind
2223
3. For a single-rate TCM policer, congure the CIR, commied burst size (CBS), and excess burst size
(EBS):
[edit firewall three-color-policer
policer-name
single-rate]
user@switch# set committed-information-rate
bps
user@switch# set committed-burst-size
bytes
user@switch# set excess-burst-size
bytes
4. For a two-rate TCM policer, congure the CIR, CBS, PIR, and peak burst size (PBS):
[edit firewall three-color-policer
policer-name
single-rate]
user@switch# set committed-information-rate
bps
user@switch# set committed-burst-size
bytes
user@switch# set peak-information-rate
bps
user@switch# set peak-burst-size
bytes
Applying Tricolor Marking Policers to Firewall Filters
To rate-limit trac by applying a tricolor marking (TCM) policer to a rewall lter:
[edit firewall family
family
filter
filter-name
term
term-name
then]
user@switch# set three-color-policer
rate
stTCM1-ca
For example:
[edit firewall family inet filter test1 term term1 then]
user@switch# set three-color-policer single-rate policer1
You must include either the single-rate statement or the two-rate statement in the reference to the policer
in the rewall lter conguraon, and this statement must match the congured TCM policer.
Otherwise, an error message appears in the conguraon lisng.
For example, if you congure srTCM1-ca as a single-rate TCM policer and try to apply it as a two-rate
policer, the following message appears:
[edit firewall]
user@switch# show three-color-policer srTCM1-ca
single-rate {
color-aware;
. . .
2224
}
user@switch# show filter TESTER
term A {
then {
three-color-policer {
##
## Warning: Referenced two-rate policer does not exist
##
two-rate srTCM;
}
}
}
RELATED DOCUMENTATION
Understanding Tricolor Marking Architecture | 2219
Understanding the Use of Policers in Firewall Filters | 2214
Understanding Policers with Link Aggregaon Groups
If you apply a policer to a link aggregaon group (LAG) on a standalone switch or QFabric node, the
policer applies to all the interfaces in the LAG in aggregate. For example, if you congure a policer to
rate-limit at 1 Gbps and apply the policer (by using a
rewall lter
) to a LAG that has two member
interfaces on a single switch or node, the total allowed throughput for both members is 1 Gbps.
If you apply a policer to a LAG that has members on dierent nodes in a QFabric network Node group or
redundant server Node group, the congured rate applies to the interface on each node. For example, if
you congure a policer to rate-limit at 1 Gbps and apply the policer to a LAG that has one member on
server node A and one member on server node B, the allowed throughput for each member is 1 Gbps,
for a total allowed throughput of 2 Gbps.
RELATED DOCUMENTATION
Overview of Policers | 2202
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
2225
Understanding Color-Blind Mode for Single-Rate Tricolor Marking
With the color-blind mode of single-rate tricolor marking, all packets are evaluated against the CBS. If a
packet exceeds the CBS, it is evaluated against the EBS. In color-blind mode, the policer supports three
loss priories only: low, medium-high, and high.
Packets that exceed the CBS but are below the EBS are marked yellow (medium-high). Packets that
exceed the EBS are marked red (high), as shown in Table 122 on page 2226.
Table 122: Color-Blind Mode TCM Color-to-PLP Mapping
Color PLP Meaning
Green low Conforming.
Yellow medium-high Packet exceeds the CIR and CBS but does not exceed the EBS.
Red high Packet exceeds the EBS.
RELATED DOCUMENTATION
Overview of Policers | 2202
Conguring Color-Blind Egress Policers for Medium-Low PLP | 2241
Understanding Color-Aware Mode for Single-Rate Tricolor Marking
IN THIS SECTION
Summary of PLP Changes | 2227
In color-aware mode, the treatment the packet receives depends on its classicaon. Marking can
increase a preassigned PLP but cannot decrease it.
2226
Summary of PLP Changes
Table 123 on page 2227 shows how a packet’s incoming priority can be modied with single-rate
marking.
Table 123: Color-Aware Mode Single-Rate PLP Mapping
Incoming PLP Packet Metered Against Possible Cases Outgoing PLP
low CIR, CBS, and EBS Conforming low
Packet exceeds the CIR and CBS but does
not exceed the EBS.
medium-high
Packet exceeds the EBS. high
medium-low EBS only Packet does not exceed the EBS. medium-low
Packet exceeds the EBS. high
medium-high EBS only Packet does not exceed the EBS. medium-high
Packet exceeds the EBS. high
high Not metered by the policer. All cases. high
The following secons describe single-rate color-aware PLP mapping in more detail.
Eect on Green Packets (Low PLP)
Packets belonging to the green class have already been marked by a classier with low PLP. The marking
policer can leave the PLP unchanged or increase it to medium-high or high, so these packets are
therefore metered against both the CBS and the EBS. For example, if a behavior aggregate or muleld
classier marks a packet with low PLP and the two-rate TCM policer is in color-aware mode, the output
loss priority is as follows:
• If the rate of trac ow is less than the CIR, packets remain marked as low PLP.
• If bursts exceed the CBS but not the EBS, some of the packets are marked as medium-high PLP, and
some of the packets remain marked as low PLP.
2227
• If bursts exceed the EBS, some of the packets are marked as high PLP, and some of the packets
remain marked as low PLP.
Eect on Yellow Packets (Medium PLP)
Packets belonging to the yellow class have already been marked by a classier with medium-low or
medium-high PLP. The marking policer can leave the PLP unchanged or increase it to high, so these
packets are therefore metered against the EBS only. For example, if a behavior aggregate or muleld
classier marks a packet with medium-low PLP and the two-rate TCM policer is in color-aware mode,
the output loss priority is as follows:
• If the rate of trac ow is less than the CBS, the packets remain marked as medium-low PLP.
• If the rate of trac ow is greater than the CBS but less than the EBS, the packets remain marked as
medium-low PLP.
• If the rate of trac ow is greater than the EBS, some of the packets are marked as high PLP and
some remain marked as medium-low PLP.
If a BA or muleld classier marks a packet with medium-high PLP and the two-rate TCM policer is in
color-aware mode, the policer assigns output loss priority as follows:
• If the rate of trac ow is less than the CBS, the packets remain marked as medium-high PLP.
• If the rate of trac ow is greater than the CBS but less than the EBS, the packets remain marked as
medium-high PLP.
• If the rate of trac ow is greater than the EBS, some of the packets are marked as high PLP and
some remain marked as medium-high PLP.
Eect on Red Packets (High PLP)
Packets belonging to the red class have already been marked by a classier with high PLP. Because the
policer cannot decrease the PLP, it does not change it, and these packets are not metered against the
CBS or the EBS.
RELATED DOCUMENTATION
Overview of Policers | 2202
Conguring Color-Blind Egress Policers for Medium-Low PLP | 2241
2228
Understanding Color-Blind Mode for Two-Rate Tricolor Marking
With the color-blind mode of two-rate tricolor marking, all packets are evaluated against the commied
informaon rate (CIR). If a packet exceeds the CIR, it is evaluated against the peak informaon rate (PIR).
Packets that exceed the CIR but are below the PIR are marked yellow (medium-high). Packets that
exceed the PIR are marked red (high).
Table 124: Color-Blind Mode TCM Color-to-PLP Mapping
Color PLP Meaning
Green low Packet does not exceed the CIR.
Yellow medium-high Packet exceeds the CIR but does not exceed the PIR.
Red high Packet exceeds the PIR.
RELATED DOCUMENTATION
Overview of Policers | 2202
Conguring Color-Blind Egress Policers for Medium-Low PLP | 2241
Understanding Color-Aware Mode for Two-Rate Tricolor Marking
IN THIS SECTION
Summary of PLP Changes | 2230
Eect on Green Packets (Low PLP) | 2230
Eect on Yellow Packets (Medium PLP) | 2231
Eect on Red Packets (High PLP) | 2231
2229
In color-aware mode, the treatment the packet receives depends on its classicaon. Marking can
increase the preassigned PLP but cannot decrease it
Summary of PLP Changes
Table 125 on page 2230 shows how a packet’s incoming priority can be modied with two-rate marking.
Table 125: Color-Aware Mode Two-Rate PLP Mapping
Incoming PLP Packet Metered Against Possible Cases Outgoing PLP
low CIR and PIR Packet does not exceed the CIR. low
Packet exceeds the CIR but not the PIR. medium-high
Packet exceeds the PIR. high
medium-low PIR only Packet does not exceed the PIR. medium-low
Packet exceeds the PIR. high
medium-high PIR only Packet does not exceed the PIR. medium-high
Packet exceeds the PIR. high
high Not metered by the policer. All cases. high
The following secons describe color-aware two-rate PLP mapping in more detail.
Eect on Green Packets (Low PLP)
Packets belonging to the green class have already been marked by a classier with low PLP. The marking
policer can leave the packet’s PLP unchanged or increase the PLP to medium-high or high. These
packets are therefore metered against both the CIR and the PIR. For example, if a behavior aggregate or
muleld classier marks a packet with low PLP and the two-rate TCM policer is in color-aware mode,
the output loss priority is as follows:
• If the rate of trac ow is less than the CIR, the packets remain marked as low PLP.
2230
• If the rate of trac ow is greater than the CIR but less than the PIR, some of the packets are
marked as medium-high PLP and some of the packets remain marked as low PLP.
• If the rate of trac ow is greater than the PIR, some of the packets are marked as high PLP and
some of the packets remain marked as low PLP.
Eect on Yellow Packets (Medium PLP)
Packets belonging to the yellow class have already been marked by a classier with medium-low or
medium-high PLP. The marking policer can leave the PLP unchanged or increase it to high. These
packets are therefore metered against the PIR only. For example, if a behavior aggregate (BA) or
muleld classier marks a packet with medium-low PLP and the two-rate TCM policer is in color-aware
mode, the policer assigns output loss priority as follows:
• If the rate of trac ow is less than the CIR, the packets remain marked as medium-low PLP.
• If the rate of trac ow is greater than the CIR but less than the PIR, the packets remain marked as
medium-low PLP.
• If the rate of trac ow is greater than the PIR, some of the packets are marked as high PLP and
some of the packets remain marked as medium-low PLP.
If a BA or muleld classier marks a packet with medium-high PLP and the two-rate TCM policer is in
color-aware mode, the policer assigns output loss priority as follows:
• If the rate of trac ow is less than the CIR, the packets remain marked as medium-high PLP.
• If the rate of trac ow is greater than the CIR but less than the PIR, the packets remain marked as
medium-high PLP.
• If the rate of trac ow is greater than the PIR, some of the packets are marked as high PLP and
some of the packets remain marked as medium-high PLP.
Eect on Red Packets (High PLP)
Packets belonging to the red class have already been marked by a classier with high PLP. Because the
policer cannot decrease the PLP, it does not change it, and these packets are not metered against the
CIR or the PIR.
RELATED DOCUMENTATION
Overview of Policers | 2202
Conguring Color-Blind Egress Policers for Medium-Low PLP | 2241
2231
Example: Using Two-Color Policers and Prex Lists
If you provide specic amounts of bandwidth to internal or external customers, you can use policing to
make sure that customers do not consume more bandwidth than they should receive. For example, you
might connect many customers to one 10-Gbps interface and want to ensure that none of them congest
the interface by using more bandwidth than they have been alloed.
You could accomplish this by creang a two-color policer similar to the following for each customer:
firewall {
policer Limit-Customer-1 {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 150m;
}
then discard;
}
Creang a policer for each customer is clearly not a scalable soluon, however. As an alternave, you
can create prex lists that group classes of customers and then create policers for each prex list. For
example, you could create prex lists such as Class-A-Customer-Prexes, Class-B-Customer-Prexes,
and Class-C-Customer-Prexes (at the [edit policy-options] hierarchy level) and create the following
corresponding policers:
firewall {
policer Class-A {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 150m;
}
then discard;
}
policer Class-B {
if-exceeding {
bandwidth-limit 75m;
burst-size-limit 100m;
}
then discard;
}
policer Class-C {
if-exceeding {
2232
bandwidth-limit 50m;
burst-size-limit 75m;
}
then discard;
}
}
You must create lter terms that specify the prex lists in their from statements and the corresponding
policers in their then statements similar to the following:
firewall
family inet {
filter Class-A-Customers {
term term-1 {
from {
destination-prefix-list {
Class-A-Customer-Prefixes;
}
}
then policer Class-A;
}
}
filter Class-B-Customers {
term term-1 {
from {
destination-prefix-list {
Class-B-Customer-Prefixes;
}
}
then policer Class-B;
}
}
filter Class-C-Customers {
term term-1 {
from {
destination-prefix-list {
Class-C-Customer-Prefixes;
}
}
then policer Class-C;
}
2233
}
}
Here are the steps to create this rewall conguraon:
1. Create the rst policer:
[edit firewall]
user@switch# set policer Class-A if-exceeding bandwidth-limit 100m burst-size-limit 150m
user@switch# set policer Class-A then discard
2. Create the second policer:
[edit firewall]
user@switch# set policer Class-B if-exceeding bandwidth-limit 75m burst-size-limit 100m
user@switch# set policer Class-B then discard
3. Create the third policer:
[edit firewall]
user@switch# set policer Class-C if-exceeding bandwidth-limit 50m burst-size-limit 75m
user@switch# set policer Class-C then discard
4. Create a lter for class A customers:
[edit firewall]
user@switch# edit family inet filter Class-A-Customers
5. Congure the lter to send packets matching the Class-A-Customer-Prexes prex list to the Class-
A policer:
[edit firewall family inet filter Class-A-Customers]
user@switch# set term term-1 from source-prefix-list Class-A-Customers
user@switch# set term term-1 then policer Class-A
2234
6. Create a lter for class B customers:
[edit firewall]
user@switch# edit family inet filter Class-B-Customers
7. Congure the lter to send packets matching the Class-B-Customer-Prexes prex list to the Class-
B policer:
[edit firewall family inet filter Class-B-Customers]
user@switch# set term term-1 from source-prefix-list Class-B-Customers
user@switch# set term term-1 then policer Class-B
8. Create a lter for class C customers:
[edit firewall]
user@switch# edit family inet filter Class-C-Customers
9. Congure the lter to send packets matching the Class-C-Customer-Prexes prex list to the Class-
C policer:
[edit firewall family inet filter Class-C-Customers]
user@switch# set term term-1 from source-prefix-list Class-C-Customers
user@switch# set term term-1 then policer Class-C
10. Apply the lters you created to the appropriate interfaces in the output direcon.
NOTE: Note that the implicit deny statement in this lter will block trac from any source that
does not match one of the prex lists. If you want the lter to allow this trac, you must include
an explicit term for this purpose.
RELATED DOCUMENTATION
Overview of Policers | 2202
prex-list
2235
Example: Using Policers to Manage Oversubscripon
You might want to use a policer when an interface is oversubscribed and you want to control what will
happen if congeson occurs. For example, you might have servers connected to a switch as listed in
Table 126 on page 2236.
Table 126: Servers Connected to Switch
Server Type Connecon IP Address
Network applicaon server 1-gigabit interface 10.0.0.1
Authencaon server 1-gigabit interface 10.0.0.2
Database server 10-gigabit interface 10.0.0.3
In this example, users access services provided by the network applicaon server, which requests
informaon from the database server as appropriate. When it receives a request from a user, the
network applicaon server rst contacts the authencaon server to verify the user’s credenals. When
a user is authencated and the network applicaon server provides the requested service, all the
packets sent from the database server to the applicaon server must transit the 1-Gigabit Ethernet
interface connected to the applicaon server twice—once on ingress to the applicaon server and again
on egress to the user.
The sequence of events for a user session is as follows:
1. A user connects to the applicaon server and requests a service.
2. The applicaon server requests the user’s credenals and relays them to the authencaon server.
3. If the authencaon server veries the credenals, the applicaon server iniates the requested
service.
4. The applicaon server requests the les necessary to meet the user’s request from the database
server.
5. The database server sends the requested les to the applicaon server.
6. The applicaon server includes the requested les in its response to the user.
Trac from the database server to the applicaon server might congest the 1-gigabit interface to which
that the applicaon server is connected. This congeson might prevent the server from responding to
2236
requests from users and creang new sessions for them. You can use policing to make sure that this
does not occur.
To create this rewall conguraon, perform the following steps on the database server:
1. Create a policer to drop trac from the database server to the applicaon server if it exceeds certain
limits:
[edit firewall]
user@switch# set policer Database-Egress-Policer if-exceeding bandwidth-limit 400 burst-size-
limit 500m
user@switch# set policer Database-Egress-Policer then discard
2. Create a lter to examine trac from the database server to the applicaon server:
[edit firewall]
user@switch# edit family inet filter Database-Egress-Filter
3. Congure the lter to apply the policer to trac egressing the database server and desned for the
applicaon server:
[edit firewall family inet filter Database-Egress-Filter]
user@switch# set term term-1 from destination-address 10.0.0.1
user@switch# set term term-1 then policer Database-Egress-Policer
4. If required, congure a term to allow trac from the database server to other desnaons (otherwise
the trac will be dropped by the implicit deny statement):
[edit firewall family inet filter Database-Egress-Filter]
user@switch# set term term-2 then accept
Note that oming a from statement causes the term to match all packets, which is the desired
behavior.
5. Install the egress lter as an output lter on the database server interface that is connected the
applicaon server:
[edit interfaces]
user@switch# set xe-0/0/3 unit 0 family inet filter output Database-Egress-Filter
2237
Here is how the nal conguraon would appear:
firewall {
policer Database-Egress-Policer {
if-exceeding {
bandwidth-limit 400;
burst-size-limit 500m;
}
then discard;
}
family inet {
filter Database-Egress-Filter {
term term-1 {
from {
destination-address {
10.0.0.1/24;
}
}
then policer Database-Egress-Policer;
}
term term-2 { # If required, include this term so that traffic from the database
server to other destinations is allowed.
then accept;
}
}
}
]
RELATED DOCUMENTATION
Overview of Policers | 2202
Assigning Forwarding Classes and Loss Priority
You can congure rewall lters to assign packet loss priority (PLP) and forwarding classes so that if
congeson occurs, the marked packets can be dropped according to the priority you set. The valid
match condions are one or more of the six packet header elds: desnaon address, source address, IP
protocol, source port, desnaon port, and DSCP. In other words, you can set the forwarding class and
2238
the PLP for each packet entering or an interface with a specic desnaon address, source address, IP
protocol, source port, desnaon port, or DSCP.
NOTE: Junos OS assigns forwarding classes and PLP on ingress only. Do not use a lter that
assigns forwarding classes or PLP as an egress lter.
When tricolor marking is enabled, a switch supports four PLP designaons: low, medium-low, medium-
high, and high. You can also specify any of the forwarding classes listed in Table 127 on page 2239
Table 127: Unicast Forwarding Classes
Unicast Forwarding Class For CoS Trac Type
be Best-eort trac
no-loss Guaranteed delivery for TCP trac
fcoe Guaranteed delivery for Fibre Channel over Ethernet (FCoE) trac
nc Network-control trac
To assign forwarding classes in rewall lters:
1. Congure the family address type and lter name:
[edit]
user@switch# edit firewall family ethernet-switching filter ingress-filter
2. Congure the terms of the lter as appropriate, including the forwarding-class and loss-priority
acon modiers. For example, each of the following terms in the lter examines various packet
header elds and assigns the appropriate forwarding class and packet loss priority:
• The term corp-trac matches all IPv4 packets with a 10.1.1.0/24 source address and assigns the
packets to forwarding class no-loss with a loss priority of low:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term corp-traffic from source-address 10.1.1.0/24;
user@switch# set term corp-traffic then forwarding-class no-loss
user@switch# set term corp-traffic then loss-priority low
2239
• The term data-trac matches all IPv4 packets with a 10.1.2.0/24 source address and assigns the
packets to forwarding class be (best eort) with a loss priority of medium-high:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term data-traffic from source-address 10.1.2.0/24;
user@switch# set term data-traffic then forwarding-class be
user@switch# set term data-traffic then loss-priority medium-high
• Because the loss of network-generated packets can jeopardize proper network operaon, the
delay of these packets is preferable to discarding these packets. The term network-trac assigns
the packets with an IP precedence of net-control to forwarding class nc (network control) with a
loss priority of low:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term network-traffic from precedence net-control
user@switch# set term network-traffic then forwarding-class nc
user@switch# set term network-traffic then loss-priority low
• The last term accept-trac matches any packets that did not match on any of the preceding
terms and assigns the packets to forwarding class be with a loss priority of high:
[edit firewall family ethernet-switching filter ingress-filter]
user@switch# set term accept-traffic then forwarding-class be
user@switch# set term accept-traffic then loss-priority high
3. Apply the lter ingress-lter to a port, VLAN, or Layer 3 interface. For informaon about applying the
lter, see "Conguring Firewall Filters" on page 1829. (Assigning forwarding classes and PLP is
supported only on ingress lters.)
RELATED DOCUMENTATION
Monitoring Firewall Filter Trac | 829
Overview of Policers | 2202
Understanding CoS Classiers
Understanding CoS Forwarding Classes
2240
Conguring Color-Blind Egress Policers for Medium-Low PLP
If you use color-blind mode and want to congure an egress policer that marks packets to have medium-
low PLP, you must congure a single-rate two-color policer at the [edit firewall policer
policer-name
]
hierarchy level, because color-blind mode does not support medium-low priority. For example:
1. Specify the name of the policer, the bandwidth limit in bits per second (bps) to control the trac rate
on an interface, and the maximum allowed burst size to control the amount of trac bursng:
[edit]
user@switch# set firewall policer
policer-name
if-exceeding bandwidth-limit
bytes
burst-size-
limit
bytes
2. Specify medium-low loss priority for matching packets:
[edit]
user@switch# set firewall policer
policer-name
then loss-priority medium-low;
3. Apply the lter to a port, VLAN, or Layer 3 interface.
RELATED DOCUMENTATION
Overview of Policers | 2202
Understanding Color-Blind Mode for Single-Rate Tricolor Marking | 2226
Understanding Color-Blind Mode for Two-Rate Tricolor Marking | 2229
Conguring Firewall Filters | 1829
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
Conguring Two-Color and Three-Color Policers to Control Trac Rates
IN THIS SECTION
Conguring Two-Color Policers | 2242
Conguring Three-Color Policers | 2243
2241
Specifying Policers in a Firewall Filter Conguraon | 2244
Applying a Firewall Filter That Includes a Policer | 2244
You can rate-limit trac by conguring a policer and specifying it as an acon modier for a term in a
rewall lter. By default, if you specify the same policer in mulple terms, Junos OS creates a separate
policer instance for each term and applies rate liming separately for each instance. For example, if you
congure a policer to discard trac that exceeds 1 Gbps and reference that policer in three dierent
terms, each policer instance enforces a 1-Gbps limit. In this case, the total bandwidth allowed by the
lter is 3 Gbps.
You can also congure a policer to be lter-specic, which means that Junos OS creates only one policer
instance regardless of how many mes the policer is referenced. When you do this, rate liming is
applied in aggregate, so if you congure a policer to discard trac that exceeds 1 Gbps and reference
that policer in three dierent terms, the total bandwidth allowed by the lter is 1 Gbps.
NOTE: You can include two-color policer acons on ingress rewall lters only. You can include
three-color policer acons on ingress and egress lters.
Conguring Two-Color Policers
To congure a two-color policer:
1. Specify the name of the policer, the bandwidth limit to control the trac rate on an interface, and
the maximum allowed burst size to control the amount of trac bursng:
[edit firewall]
user@switch# set policer
policer-name
<filter-specific> if-exceeding bandwidth-limit
bps
burst-size-limit
bytes
The policer name can contain leers, numbers, and hyphens (-) and can have as many as 64
characters.
The range for the bandwidth limit is 32000 (32k) through 102,300,000,000 (102300m) bps.
To determine the value for the burst-size limit, mulply the bandwidth of the interface on which the
lter is applied by the amount of me to allow a burst of trac at that bandwidth to occur and divide
the result by 8:
maximum burst size = (interface bandwidth) X (allowable me for burst) / (8 bits/byte)
2242
The range for the burst-size limit is 1 through 2,147,450,880 bytes.
2. Specify the policer acon to discard or assign a loss priority to packets that exceed the rate limits:
[edit firewall policer
policer-name
]
user@switch# set then (discard | loss-priority low | loss-priority high)
Conguring Three-Color Policers
To congure a three-color policer:
1. Specify the name of the policer and (oponally) whether to automacally discard packets with high
loss priority (PLP):
[edit firewall]
user@switch# set three-color-policer
policer-name
user@switch# set three-color-policer
policer-name
action loss-priority high then discard
2. Specify whether the three-color policer should be single-rate or two-rate and whether it should be
color-aware or color-blind:
[edit firewall three-color-policer
policer-name
]
user@switch# set (single-rate | two-rate) (color-aware | color-blind)
3. For single-rate three-color policers, congure the CIR, CBS, and EBS:
[edit firewall three-color-policer
policer-name
single-rate]
user@switch# set committed-information-rate
bps
user@switch# set committed-burst-size
bytes
user@switch# set excess-burst-size
bytes
4. For two-rate three-color policers, congure the CIR, CBS, PIR, and PBS:
[edit firewall three-color-policer
policer-name
single-rate]
user@switch# set committed-information-rate
bps
user@switch# set committed-burst-size
bytes
user@switch# set peak-information-rate
bps
user@switch# set peak-burst-size
bytes
2243
Specifying Policers in a Firewall Filter Conguraon
To use a two-color policer, congure a lter term that includes the acon policer:
[edit firewall family
family-name
]
user@switch# set filter
filter-name
term
name
then
name
For example, the following commands apply a two-color policer to all packets sent from 192.0.2.0/24.
[edit firewall family
family-name
]
user@switch# set filter limit—hosts term term1 from source-address 192.0.2.0/24
user@switch# set filter limit—hosts term term1 then policer policer1
To use a three-color policer, congure a lter term that includes the acon three-color-policer:
[edit firewall family
name
]
user@switch# set filter
name
term
name
from
match-condition
user@switch# set filter
name
term
name
then three-color-policer (single-rate | two-rate)
name
For example, the following commands apply a single-rate three-color policer to all packets received or
sent by interface ge-0/0/6 (depending on whether the lter is an ingress or egress lter).
[edit firewall family
name
]
user@switch# set filter srTCM term term-one from interface ge-0/0/6
user@switch# set filter srTCM term term-one then three-color-policer single-rate srTCM1-ca
You must specify whether the three-color policer is single-rate or two-rate, and this must match the
policer itself. Otherwise, the conguraon lisng includes an error message indicang that the three-
color policer you referenced in the lter does not exist.
Applying a Firewall Filter That Includes a Policer
A rewall lter that includes one or more policer acon modiers must be applied to a port, VLAN, or
Layer 3 interface like any other lter. For informaon about applying rewall lters, see "Conguring
Firewall Filters" on page 1829.
NOTE: You can include two-color policer acons on ingress rewall lters only. You can include
three-color policer acons on ingress and egress lters.
2244
RELATED DOCUMENTATION
Conguring Firewall Filters | 1829
Overview of Policers | 2202
Verifying That Two-Color Policers Are Operaonal | 2245
Verifying That Three-Color Policers Are Operaonal | 2246
Conguring Color-Blind Egress Policers for Medium-Low PLP | 2241
Verifying That Two-Color Policers Are Operaonal
IN THIS SECTION
Purpose | 2245
Acon | 2245
Meaning | 2246
Purpose
Verify that two-color policers in rewall lter conguraons are working properly.
Acon
Use the show firewall policer operaonal mode command to verify that the policers are working properly:
user@switch> show firewall policer
Filter: egress-vlan-watch-employee
Filter: ingress-port-filter
Filter: ingress-port-limit-tcp-icmp
Policers:
Name Packets
icmp-connection-policer 10
tcp-connection-policer 539
Filter: ingress-vlan-rogue-block
Filter: ingress-vlan-limit-guest
2245
Meaning
The show firewall policer command displays the names of all rewall lters and policers that are
congured. For each policer that is specied in a lter conguraon, the output eld shows the current
packet count for all packets that exceed the specied rate limits.
RELATED DOCUMENTATION
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
Conguring Firewall Filters | 1829
Monitoring Firewall Filter Trac | 829
Verifying That Three-Color Policers Are Operaonal
IN THIS SECTION
Purpose | 2246
Acon | 2246
Meaning | 2247
Purpose
Verify that three-color policers in rewall lter conguraons are working properly.
Acon
Use the following operaonal mode commands to verify that a three-color policer is working properly:
•
show class-of-service forwarding-table classifiers
• show interfaces
interface-name
extensive
•
show interfaces queue
interface-name
2246
Meaning
RELATED DOCUMENTATION
Overview of Policers | 2202
Conguring Two-Color and Three-Color Policers to Control Trac Rates | 2241
Troubleshoong Policer Conguraon
IN THIS SECTION
Incomplete Count of Packet Drops | 2247
Counter Reset When Eding Filter | 2248
Invalid Stascs for Policer | 2249
Policers Can Limit Egress Filters | 2249
Incomplete Count of Packet Drops
IN THIS SECTION
Problem | 2247
Soluon | 2248
Problem
Descripon
Under certain circumstances, Junos OS might display a misleading number of packets dropped by an
ingress policer.
2247
If packets are dropped because of ingress admission control, policer stascs might not show the
number of packet drops you would expect by calculang the dierence between ingress and egress
packet counts. This might happen if you apply an ingress policer to mulple interfaces, and the
aggregate ingress rate of those interfaces exceeds the line rate of a common egress interface. In this
case, packets might be dropped from the ingress buer. These drops are not included in the count of
packets dropped by the policer, which causes policer stascs to underreport the total number of drops.
Soluon
This is expected behavior.
Counter Reset When Eding Filter
IN THIS SECTION
Problem | 2248
Soluon | 2248
Problem
Descripon
If you edit a rewall lter term, the value of any counter associated with any term in the same lter is set
to 0, including the implicit counter for any policer referenced by the lter. Consider the following
examples:
• Assume that your lter has term1, term2, and term3, and each term has a counter that has already
counted matching packets. If you edit any of the terms in any way, the counters for all the terms are
reset to 0.
• Assume that your lter has term1 and term2. Also assume that term2 has a policer acon modier and
the implicit counter of the policer has already counted 1000 matching packets. If you edit term1 or
term2 in any way, the counter for the policer referenced by term2 is reset to 0.
Soluon
This is expected behavior.
2248
Invalid Stascs for Policer
IN THIS SECTION
Problem | 2249
Soluon | 2249
Problem
Descripon
If you apply a single-rate two-color policer in more than 128 terms in a rewall lter, the output of the
show firewall command displays incorrect data for the policer.
Soluon
This is expected behavior.
Policers Can Limit Egress Filters
IN THIS SECTION
Problem | 2249
Soluon | 2250
Problem
Descripon
On some switches, the number of egress policers you congure can aect the total number of allowed
egress rewall lters. Every policer has two implicit counters that take up two entries in a 1024-entry
TCAM. These are used for counters, including counters that are congured as acon modiers in rewall
lter terms. (Policers consume two entries because one is used for green packets and one is used for
nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any
more egress rewall lters that have terms with counters. For example, if you congure and commit 512
egress policers (two-color, three-color, or a combinaon of both policer types), all of the memory entries
2249
for counters get used up. If later in your conguraon le you insert addional egress rewall lters with
terms that also include counters,
none
of the terms in those lters are commied because there is no
available memory space for the counters.
Here are some addional examples:
• Assume that you congure egress lters that include a total of 512 policers and no counters. Later in
your conguraon le you include another egress lter with 10 terms, 1 of which has a counter
acon modier. None of the terms in this lter are commied because there is not enough TCAM
space for the counter.
• Assume that you congure egress lters that include a total of 500 policers, so 1000 TCAM entries
are occupied. Later in your conguraon le you include the following two egress lters:
• Filter A with 20 terms and 20 counters. All the terms in this lter are commied because there is
enough TCAM space for all the counters.
• Filter B comes aer Filter A and has ve terms and ve counters.
None
of the terms in this lter
are commied because there is not enough memory space for
all
the counters. (Five TCAM
entries are required but only four are available.)
Soluon
You can prevent this problem by ensuring that egress rewall lter terms with counter acons are placed
earlier in your conguraon le than terms that include policers. In this circumstance, Junos OS commits
policers even if there is not enough TCAM space for the implicit counters. For example, assume the
following:
• You have 1024 egress rewall lter terms with counter acons.
• Later in your conguraon le you have an egress lter with 10 terms. None of the terms have
counters but one has a policer acon modier.
You can successfully commit the lter with 10 terms even though there is not enough TCAM space for
the implicit counters of the policer. The policer is commied without the counters.
SEE ALSO
Overview of Policers | 2202
Example: Using Policers to Manage Oversubscripon | 2236
Example: Using Filter-Based Forwarding to Route Applicaon Trac to a Security Device | 1689
Example: Using Two-Color Policers and Prex Lists | 2232
2250
Troubleshoong Policer Conguraon
IN THIS SECTION
Incomplete Count of Packet Drops | 2251
Counter Reset When Eding Filter | 2252
Invalid Stascs for Policer | 2252
Egress Policers on QFX3500 Devices Might Allow More Throughput Than Is Congured | 2253
Filter-Specic Egress Policers on QFX3500 Devices Might Allow More Throughput Than Is
Congured | 2254
Policers Can Limit Egress Filters | 2255
Incomplete Count of Packet Drops
IN THIS SECTION
Problem | 2251
Soluon | 2252
Problem
Descripon
Under certain circumstances, Junos OS might display a misleading number of packets dropped by an
ingress policer.
If packets are dropped because of ingress admission control, policer stascs might not show the
number of packet drops you would expect by calculang the dierence between ingress and egress
packet counts. This might happen if you apply an ingress policer to mulple interfaces, and the
aggregate ingress rate of those interfaces exceeds the line rate of a common egress interface. In this
case, packets might be dropped from the ingress buer. These drops are not included in the count of
packets dropped by the policer, which causes policer stascs to underreport the total number of drops.
2251
Soluon
This is expected behavior.
Counter Reset When Eding Filter
IN THIS SECTION
Problem | 2252
Soluon | 2252
Problem
Descripon
If you edit a rewall lter term, the value of any counter associated with any term in the same lter is set
to 0, including the implicit counter for any policer referenced by the lter. Consider the following
examples:
• Assume that your lter has term1, term2, and term3, and each term has a counter that has already
counted matching packets. If you edit any of the terms in any way, the counters for all the terms are
reset to 0.
• Assume that your lter has term1 and term2. Also assume that term2 has a policer acon modier and
the implicit counter of the policer has already counted 1000 matching packets. If you edit term1 or
term2 in any way, the counter for the policer referenced by term2 is reset to 0.
Soluon
This is expected behavior.
Invalid Stascs for Policer
IN THIS SECTION
Problem | 2253
Soluon | 2253
2252
Problem
Descripon
If you apply a single-rate two-color policer in more than 128 terms in a rewall lter, the output of the
show firewall command displays incorrect data for the policer.
Soluon
This is expected behavior.
Egress Policers on QFX3500 Devices Might Allow More Throughput Than Is
Congured
IN THIS SECTION
Problem | 2253
Soluon | 2254
Problem
Descripon
If you congure a policer to rate-limit throughput and apply it on egress to mulple interfaces on a
QFX3500 switch or Node, the measured aggregate policed rate might be twice the congured rate,
depending on which interfaces you apply the policer to. The doubling of the policed rate occurs if you
apply a policer to mulple interfaces and
both
of the following are true:
• There is at least one policed interface in the range xe-0/0/0 to xe-0/0/23 or the range xe-0/1/1 to
xe-0/1/7.
• There is at least one policed interface in the range xe-0/0/24 to xe-0/0/47 or the range xe-0/1/8 to
xe-0/1/15.
For example, if you congure a policer to rate-limit trac at 1 Gbps and apply the policer (by using a
rewall lter) to xe-0/0/0 and xe-0/0/24 in the output direcon, each interface is rate-limited at 1
Gbps, for a total allowed throughput of 2 Gbps. The same behavior occurs if you apply the policer to
xe-0/1/1 and xe-0/0/24—each interface is rate-limited at 1 Gbps.
2253
If you apply the same policer on egress to mulple interfaces in these groups, each
group
is rate-limited
at 1 Gbps. For example, if you apply the policer to xe-0/0/0 through xe-0/0/4 (ve interfaces) and
xe-0/0/24 through xe-0/0/33 (ten interfaces), each group is rate-limited at 1 Gbps, for a total allowed
throughput of 2 Gbps.
Here is another example: If you apply the policer to xe-0/0/0 through xe-0/0/4 and xe-0/1/1 through
xe-0/1/5 (a total of ten interfaces), that group is rate-limited at 1 Gbps in aggregate. If you also apply the
policer to xe-0/0/24, that one interface is rate-limited at 1 Gbps while the other ten are sll rate-limited
at 1 Gbps in aggregate.
Interfaces xe-0/1/1 through xe-0/1/15 are physically located on the QSFP+ uplink ports, according to
the following scheme:
• xe-0/1/1 through xe-0/1/3 are on Q0.
• xe-0/1/4 through xe-0/1/7 are on Q1.
• xe-0/1/8 through xe-0/1/11 are on Q2.
• xe-0/1/2 through xe-0/1/15 are on Q3.
The doubling of the policed rate occurs only if the policer is applied in the output direcon. If you
congure a policer as described above but apply it in the input direcon, the total allowed throughput
for all interfaces is 1 Gbps.
Soluon
This is expected behavior.
Filter-Specic Egress Policers on QFX3500 Devices Might Allow More Throughput
Than Is Congured
IN THIS SECTION
Problem | 2255
Soluon | 2255
2254
Problem
Descripon
You can congure policers to be lter-specic. This means that Junos OS creates only one policer
instance no maer how many mes the policer is referenced. When you do this, rate liming is applied
in aggregate, so if you congure a policer to discard trac that exceeds 1 Gbps and reference that
policer in three dierent terms, the total bandwidth allowed by the lter is 1 Gbps. However, the
behavior of a lter-specic policer is aected by how the rewall lter terms that reference the policer
are stored in ternary content addressable memory (TCAM). If you create a lter-specic policer and
reference it in mulple rewall lter terms, the policer allows more trac than expected if the terms are
stored in dierent TCAM slices. For example, if you congure a policer to discard trac that exceeds
1 Gbps and reference that policer in three dierent terms that are stored in three separate memory
slices, the total bandwidth allowed by the lter is 3 Gbps, not 1 Gbps.
Soluon
To prevent this unexpected behavior, use the informaon about TCAM slices presented in Planning the
Number of Firewall Filters to Create to organize your conguraon le so that all the rewall lter terms
that reference a given lter-specic policer are stored in the same TCAM slice.
Policers Can Limit Egress Filters
IN THIS SECTION
Problem | 2255
Soluon | 2256
Problem
Descripon
On some switches, the number of egress policers you congure can aect the total number of allowed
egress rewall lters. Every policer has two implicit counters that take up two entries in a 1024-entry
TCAM. These are used for counters, including counters that are congured as acon modiers in rewall
lter terms. (Policers consume two entries because one is used for green packets and one is used for
nongreen packets regardless of policer type.) If the TCAM becomes full, you are unable to commit any
more egress rewall lters that have terms with counters. For example, if you congure and commit 512
egress policers (two-color, three-color, or a combinaon of both policer types), all of the memory entries
2255
for counters get used up. If later in your conguraon le you insert addional egress rewall lters with
terms that also include counters,
none
of the terms in those lters are commied because there is no
available memory space for the counters.
Here are some addional examples:
• Assume that you congure egress lters that include a total of 512 policers and no counters. Later in
your conguraon le you include another egress lter with 10 terms, 1 of which has a counter
acon modier. None of the terms in this lter are commied because there is not enough TCAM
space for the counter.
• Assume that you congure egress lters that include a total of 500 policers, so 1000 TCAM entries
are occupied. Later in your conguraon le you include the following two egress lters:
• Filter A with 20 terms and 20 counters. All the terms in this lter are commied because there is
enough TCAM space for all the counters.
• Filter B comes aer Filter A and has ve terms and ve counters.
None
of the terms in this lter
are commied because there is not enough memory space for
all
the counters. (Five TCAM
entries are required but only four are available.)
Soluon
You can prevent this problem by ensuring that egress rewall lter terms with counter acons are placed
earlier in your conguraon le than terms that include policers. In this circumstance, Junos OS commits
policers even if there is not enough TCAM space for the implicit counters. For example, assume the
following:
• You have 1024 egress rewall lter terms with counter acons.
• Later in your conguraon le you have an egress lter with 10 terms. None of the terms have
counters but one has a policer acon modier.
You can successfully commit the lter with 10 terms even though there is not enough TCAM space for
the implicit counters of the policer. The policer is commied without the counters.
SEE ALSO
Overview of Policers
Example: Using Policers to Manage Oversubscripon
Example: Using Two-Color Policers and Prex Lists
2256
4
PART
Conguraon Statements and
Operaonal Commands
Firewall Filter Conguraon Statements Supported by Junos OS for EX Series
Switches | 2258
gtp-header | 2263
gtp-teid | 2265
per-logical-interface-rewall | 2267
Junos CLI Reference Overview | 2269
Firewall Filter Conguraon Statements Supported
by Junos OS for EX Series Switches
You congure rewall lters to lter packets based on their components and to perform an acon on
packets that match the lter.
Table 128 on page 2258 lists the opons that are supported for the rewall statement in Junos OS for
EX Series switches.
Table 128: Supported Opons for Firewall Filter Statements
Statement and Opon Descripon
family
family-name
{
}
The
family-name
opon species the version or type of
addressing protocol:
• any—Filter packets based on protocol-independent
match condions.
• ethernet-switching—Filter Layer 2 (Ethernet)
packets and Layer 3 (IP) packets
• inet—Filter IPv4 packets
• inet6—Filter IPv6 packets
filter
filter-name
{
}
The
lter-name
opon idenes the lter. The name
can contain leers, numbers, and hyphens (-) and can
be up to 64 characters long. To include spaces in the
name, enclose the name in quotaon marks (" " ).
interface-specific
The interface-specific statement congures unique
names for individual rewall counters specic to each
interface.
term
term-name
{
}
The
term-name
opon idenes the term. The name
can contain leers, numbers, and hyphens (-) and can
be up to 64 characters long. To include spaces in the
name, enclose the enre name in quotaon marks (" " ).
Each term name must be unique within a lter.
2258
Table 128: Supported Opons for Firewall Filter Statements
(Connued)
Statement and Opon Descripon
from {
match-
conditions;
}
The from statement is oponal. If you omit it, all
packets are considered to match.
then {
action
;
action-
modifiers
;
}
For informaon about the
acon
and
acon-modiers
opons, see "Firewall Filter Match Condions, Acons,
and Acon Modiers for EX Series Switches" on page
1558.
policer
policer-name
{
}
The
policer-name
opon idenes the policer. The
name can contain leers, numbers, and hyphens (-) and
can be up to 64 characters long. To include spaces in
the name, enclose the name in quotaon marks (" " ).
filter-specific
The filter-specific statement congures policers and
counters for a specic lter name.
2259
Table 128: Supported Opons for Firewall Filter Statements
(Connued)
Statement and Opon Descripon
if-exceeding {
bandwidth-limit
bps
burst-size-limit
bytes
}
The bandwidth-limit
bps
opon species the trac
rate in bits per second (bps).
You can specify
bps
as a decimal value or as a decimal
number followed by one of the following
abbreviaons:
• k (thousand)
• m (million)
•
g (billion, which is also called a thousand million)
Range: 1000 (1k) through 102,300,000,000 (102.3g)
bps
The burst-size-limit
bytes
opon species the
maximum allowed burst size to control the amount of
trac bursng. To determine the value for the burst-
size limit, you can mulply the bandwidth of the
interface on which the lter is applied by the amount
of me (in seconds) to allow a burst of trac at that
bandwidth to occur:
burst size = bandwidth * allowable me for burst trac
You can specify a decimal value or a decimal number
followed by k (thousand) or m (million).
Range: 1 through 2,147,450,880 bytes
then {
policer-
action
}
Use the
policer-acon
opon to specify discard to
discard trac that exceeds the rate limits.
Junos OS for EX Series switches does not support some of the rewall lter statements that are
supported by other Junos OS packages. Table 129 on page 2261 shows the rewall lter statements
that are not supported by Junos OS for EX Series switches.
2260
Table 129: Firewall Filter Statements That Are Not Supported by Junos OS for EX Series Switches
Statements Not Supported Statement Hierarchy Level
• interface-set
interface-set-name
{
}
• load-balance-group
group-name
{
}
• three-color-policer
name
{
}
• logical-interface-policer;
• single-rate {
}
• two-rate {
}
[edit firewall]
2261
Table 129: Firewall Filter Statements That Are Not Supported by Junos OS for EX Series Switches
(Connued)
Statements Not Supported Statement Hierarchy Level
• prefix-action
name
{
}
• prefix-policer {
}
• service-filter
filter-name
{
}
• simple-filter
simple-filter-name
{
}
[edit firewall family
family-name
]
• accounting-profile
name
;
[edit firewall family
family-name
filter
filter-name
]
• logical-bandwidth-policer;
• logical-interface-policer;
[edit firewall policer
policer-name
]
bandwidth-percent
number
; [edit firewall policer
policer-name
if-exceeding]
RELATED DOCUMENTATION
Firewall Filter Match Condions, Acons, and Acon Modiers for EX Series Switches | 1558
2262
Example: Conguring Firewall Filters for Port, VLAN, and Router Trac on EX Series Switches |
1654
Conguring Firewall Filters (CLI Procedure) | 1642
Conguring Policers to Control Trac Rates (CLI Procedure) | 2219
Firewall Filters for EX Series Switches Overview | 1539
gtp-header
IN THIS SECTION
Syntax | 2263
Hierarchy Level | 2263
Descripon | 2264
Required Privilege Level | 2264
Release Informaon | 2265
Syntax
gtp-header
Hierarchy Level
[edit firewall family family-name filter filter-name from]
2263
Descripon
Include the match condions for the GTP packet. An example is as below:
firewall {
family inet /inet6 {
filter gtp_filter {
from {
protocol udp;
port 2123;
gtp-header {
gtp-teid <TEID value/list/range>;
ipv4/ipv6 {
source-address <32bit for v4 and 128 bit for v6>;
source-prefix-list <prefix-list>;
destination-address <32bit for v4 and 128 bit for v6>;
destination-prefix-list <prefix-list>;
Protocol/next-header <8 bit>;
Protocol/next-header-except <8 bit>;
source-port <16 bit>;
source-port-except <16 bit>;
destination-port <16 bit>;
destination-port-except <16 bit>;
}
}
then {
count gtp;
}
Required Privilege Level
• rewall—To view this statement in the conguraon.
• rewall-control—To add this statement to the conguraon.
2264
Release Informaon
Statement introduced in Junos 22.2R1
gtp-teid
IN THIS SECTION
Syntax | 2265
Hierarchy Level | 2265
Descripon | 2266
Opons | 2266
Required Privilege Level | 2266
Release Informaon | 2266
Syntax
gtp-teid
list
;
Hierarchy Level
[edit firewall family family-name filter filter-name from gtp-header]
2265
Descripon
Specify the teid value or list of values in the GTP-C packet header. The rewall lter will aempt to
match on the provided teid value or list of values.
Opons
gtp-teid
list
• list - gtp-teid is integer and will take a list of values from 0 to 4294967295. As an example, in the
following conguraon statement, gtp-teid is supplied a list of two values.
set firewall family inet filter ft term 1 from gtp-header gtp-teid [100 200]
In the following conguraon statement, gtp-teid is supplied a single value.
set firewall family inet filter ft term 1 from gtp-header gtp-teid 105
Required Privilege Level
• rewall—To view this statement in the conguraon.
• rewall-control—To add this statement to the conguraon.
Release Informaon
Statement introduced in Junos 22.2R1
2266
per-logical-interface-rewall
IN THIS SECTION
Syntax | 2267
Hierarchy Level | 2267
Descripon | 2267
Caveats | 2268
Required Privilege Level | 2269
Release Informaon | 2269
Syntax
per-logical-interface-firewall
Hierarchy Level
[edit chassis]
Descripon
Enables per logical interface rewall ltering in the ingress direcon. When enabled, the same set of
match condions and acons that are used for port rewall lters can be used for rewall lters on
logical interfaces. The following example depicts the creaon of a rewall lter and it being
subsequently applied to a logical interface, aer the enabling of the per-logical-interface-firewall seng.
firewall {
family ethernet-switching {
2267
filter <filter-name> {
term <rule-name> {
from {
source-mac-address {
<mac-address>;
}
}
then {
count <count>;
policer <policer>;
}
}
}
}
policer <policer-name> {
if-exceeding {
bandwidth-limit <bandwidth-limit>;
burst-size-limit <burst-size-limit>;
}
then discard;
}
}
interfaces {
<interface-name> {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit <interface-unit-number> {
vlan-id <vlan-id>;
family ethernet-switching {
filter {
input <filter-name>;
}
}
}
}
Caveats
• per-logical-interface-firewall is not supported on enterprise style logical interfaces.
2268
• Per logical interface rewall ltering with mix of services provider and enterprise logical interfaces is
not supported.
• per-logical-interface-firewall scope is limited to non-VxLAN interfaces.
• With per-logical-interface-firewall, IPv6 address in lters across is of an ifd should be exclusive.
• Interface specic knob is not recommended with IPv6 address match.
• IFLs belongs to dierent vlans cannot have the same lter with IPv6 address match.
Required Privilege Level
interface
Release Informaon
Statement introduced in Junos OS Release 22.2R1 (QFX5110, QFX5120-32C, QFX5120-48T,
QFX5120-48Y, QFX5120-48YM, QFX5200, and QFX5210)
Junos CLI Reference Overview
We've consolidated all Junos CLI commands and conguraon statements in one place. Learn about the
syntax and opons that make up the statements and commands and understand the contexts in which
you’ll use these CLI elements in your network conguraons and operaons.
• Junos CLI Reference
Click the links to access Junos OS and Junos OS Evolved conguraon statement and command
summary topics.
• Conguraon Statements
• Operaonal Commands
2269
5
PART
Troubleshoong
Knowledge Base | 2271
CHAPTER 35
Knowledge Base
2271