Broadband Subscriber Services Feature Guide

Junos® OS
Broadband Subscriber Services Feature Guide
Release
14.2
Published: 2015-02-02
Copyright © 2015, Juniper Networks, Inc.

Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective 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 publication without notice.
®
Junos OS Broadband Subscriber Services Feature Guide
14.2
Copyright © 2015, Juniper Networks, Inc.
All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of
that EULA.
ii Copyright © 2015, Juniper Networks, Inc.

Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
Part 1 Configuring Dynamic Class of Service

Chapter 1 CoS for Subscriber Access and Interfaces Overview . . . . . . . . . . . . . . . . . . . . 3
CoS for Subscriber Access Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Guidelines for Configuring Dynamic CoS for Subscriber Access . . . . . . . . . . . . . . . 4
Configuration Guidelines for Hierarchical CoS and Per-Unit Scheduling . . . . . 4
Configuration Guidelines for Dynamic Scheduling and Queuing . . . . . . . . . . . 5
Configuration Guidelines for Dynamic Classifiers and Rewrite Rules . . . . . . . . 5
CoS for Aggregated Ethernet Subscriber Interfaces Overview . . . . . . . . . . . . . . . . . 8
CoS for PPPoE Subscriber Interfaces Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2 Configuring Scheduling and Shaping for Subscriber Access . . . . . . . . . . . . . 11
Configuring Traffic Scheduling and Shaping for Subscriber Access . . . . . . . . . . . . 11
Configuring Static Traffic Shaping and Scheduling Parameters in a Dynamic
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Configuring Dynamic Traffic Shaping and Scheduling Parameters in a
Dynamic Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Configuring Schedulers in a Dynamic Profile for Subscriber Access . . . . . . . . . . . . 13
Configuring Static Schedulers in a Dynamic Profile . . . . . . . . . . . . . . . . . . . . . 14
Configuring Dynamic Schedulers with Variables in a Dynamic Profile . . . . . . 15
Configuring a Combination of Static and Dynamic Scheduler Parameters
in a Scheduler Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Configuring Scheduler and Scheduler Map Sharing . . . . . . . . . . . . . . . . . . . . . . . . 19
Example: Providing Unique Rate Configurations for Schedulers in a Dynamic
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Example: Configuring Aggregate Scheduling of Queues for Residential
Subscribers on Static IP Demux Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Verifying the Scheduling and Shaping Configuration for Subscriber Access . . . . . 23
Copyright © 2015, Juniper Networks, Inc. iii

Chapter 3 Managing Different Types of Service Traffic for a Household Using

Hierarchical Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Understanding Two-Level and Three-Level Hierarchical CoS for Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Two-Level Hierarchical Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Three-Level Hierarchical Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Interface Hierarchy Versus CoS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . 29
Hardware Requirements for Dynamic Hierarchical CoS . . . . . . . . . . . . . . . . . . . . . 31
Configuring Static Hierarchical Scheduling in a Dynamic Profile . . . . . . . . . . . . . . 32
Configuring Dynamic Hierarchical Scheduling in a Dynamic Profile . . . . . . . . . . . 33
Configuring Hierarchical CoS for a Subscriber Interface of Aggregated Ethernet
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Configuring Hierarchical CoS on a Static PPPoE Subscriber Interface . . . . . . . . . 36
Example: Maintaining a Constant Traffic Flow by Configuring a Static VLAN
Interface with a Dynamic Profile for Subscriber Access . . . . . . . . . . . . . . . . . 37
Example: Configuring Dynamic Hierarchical Scheduling for Subscribers . . . . . . . 48
Example: Configuring Hierarchical Scheduling for a Static PPPoE Subscriber
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Example: Configuring Hierarchical Scheduling for an Underlying Static PPPoE
Subscriber Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Example: Configuring Hierarchical Scheduling for an Interface Set of Static
PPPoE Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Chapter 4 Configuring Hierarchical CoS Scheduling on MPLS Ethernet Pseudowire
Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Hierarchical CoS on MPLS Pseudowire Subscriber Interfaces Overview . . . . . . . . 63
CoS Two-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
CoS Three-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Three-Level Scheduling Hierarchy: Pseudowire Logical Interfaces over a
Transport Logical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Three-Level Scheduling Hierarchy : Pseudowire Service Logical Interfaces
over a Pseudowire Service Interface Set . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Three-Level Scheduling Hierarchy Combined Deployment Scenario . . . . . . 68
CoS Configuration Overview for MPLS Pseudowire Subscriber Interfaces . . . . . . 69
Configuring CoS Two-Level Hierarchical Scheduling for MPLS Pseudowire
Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Configuring CoS Three-Level Hierarchical Scheduling for MPLS Pseudowire
Subscriber Interfaces (Logical Interfaces over a Transport Logical
Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Configuring CoS Three-Level Hierarchical Scheduling for MPLS Pseudowire
Subscriber Interfaces (Logical Interfaces over a Pseudowire Interface
Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Chapter 5 Allocating Dedicated Queues for Each Logical Interface Using Per-Unit
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Hardware Requirements for Dynamic Per-Unit Scheduling . . . . . . . . . . . . . . . . . . 77
Configuring Per-Unit Scheduling in a Dynamic Profile . . . . . . . . . . . . . . . . . . . . . . 78
Example: Configuring Per-Unit Scheduling for Subscriber Access . . . . . . . . . . . . 80
iv Copyright © 2015, Juniper Networks, Inc.

Table of Contents
Chapter 6 Configuring Dedicated Queue Scaling with Hierarchical CoS or Per-Unit

Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Dedicated Queue Scaling for CoS Configurations on MIC and MPC Interfaces
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Queue Scaling for MIC and MPC Combinations . . . . . . . . . . . . . . . . . . . . . . . 89
Distribution of Queues on 30-Gigabit Ethernet Queuing MPCs . . . . . . . . . . . 90
Distribution of Queues on 60-Gigabit Ethernet Queuing MPCs . . . . . . . . . . . 91
Determining Maximum Egress Queues and Subscriber Interfaces per
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Managing Remaining Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Managing Dedicated and Remaining Queues for Dynamic CoS Configurations
on MIC and MPC Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Configuring the Maximum Number of Queues for MIC and MPC
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Configuring Remaining Common Queues on MIC and MPC Interfaces . . . . . 94
Verifying the Number of Dedicated Queues Configured on MIC and MPC
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Chapter 7 Preventing Bandwidth Contention on Subscriber Interfaces Using
Hierarchical CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Hierarchical CoS Shaping-Rate Adjustments Overview . . . . . . . . . . . . . . . . . . . . . 97
Types of Shaping-Rate Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Levels of Shaping-Rate Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Shaping Rate Adjustments for Subscriber Local Loops Overview . . . . . . . . . . . . . 99
Guidelines for Configuring Shaping-Rate Adjustments for Subscriber Local
Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Configuring the Minimum Adjusted Shaping Rate on Scheduler Nodes for
Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Configuring a Static Minimum Adjusted Shaping Rate on Scheduler
Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Configuring a Dynamic Minimum Adjusted Shaping Rate on Scheduler
Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Configuring Shaping-Rate Adjustments on Queues . . . . . . . . . . . . . . . . . . . . . . . 102
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Configuring a Static Shaping-Rate Adjustment for Queues . . . . . . . . . . . . . 103
Configuring a Dynamic Shaping-Rate Adjustment for Queues . . . . . . . . . . . 103
Enabling Shaping-Rate Adjustments for Subscriber Local Loops . . . . . . . . . . . . 104
Configuring Static Logical Interface Sets to Serve as CoS Hierarchical
Scheduler Nodes for Subscriber Loops . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Configuring the Logical Interfaces That Compose the Static Logical Interface
Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Configuring Hierarchical CoS on the Static Logical Interface Sets That Serve
as Hierarchical Scheduler Nodes for Subscriber Local Loops . . . . . . . . 106
Copyright © 2015, Juniper Networks, Inc. v

Configuring ANCP Functionality That Supports and Drives Shaping-Rate

Adjustments for Subscriber Local Loops . . . . . . . . . . . . . . . . . . . . . . . . 108
Disabling Shaping-Rate Adjustments for Subscriber Local Loops . . . . . . . . . . . 109
Disabling Hierarchical Bandwidth Adjustment for Subscriber Interfaces with
Reverse-OIF Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Example: Configuring Hierarchical CoS Shaping-Rate Adjustments for Subscriber
Local Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Verifying the Configuration of Shaping-Rate Adjustments for Subscriber Local
Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Verifying the Configuration of ANCP for Shaping-Rate Adjustments . . . . . . . . . . 114
Chapter 8 Shaping Downstream Traffic Based on Frames or Cells . . . . . . . . . . . . . . . . 115
Bandwidth Management for Downstream Traffic in Edge Networks
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Effective Shaping Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Shaping Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Byte Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Relationship with Other CoS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Configuring Dynamic Shaping Parameters to Account for Overhead in
Downstream Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Example: Configuring Dynamic Shaping Parameters to Account for Overhead
in Downstream Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Managing Traffic with Different Encapsulations . . . . . . . . . . . . . . . . . . . . . . . 119
Managing Downstream Cell-Based Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Configuring Static Shaping Parameters to Account for Overhead in Downstream
Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Example: Configuring Static Shaping Parameters to Account for Overhead in
Downstream Traffic Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Managing Traffic with Different Encapsulations . . . . . . . . . . . . . . . . . . . . . . . 123
Managing Downstream Cell-Based Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Setting Shaping Rate and Overhead Accounting Based on PPPoE Vendor-Specific
Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
CLI Interaction with PPPoE Vendor-Specific Tags . . . . . . . . . . . . . . . . . . . . . 125
RADIUS Interaction with PPPoE Vendor-Specific Tags . . . . . . . . . . . . . . . . . 125
ANCP Interaction with PPPoE Vendor-Specific Tags . . . . . . . . . . . . . . . . . . . 126
Multicast QoS Adjustment Interaction with PPPoE Vendor-Specific
Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Shaping Rate Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Configuring the Shaping Rate and Overhead Accounting Based on PPPoE
Vendor-Specific Tags on Dynamic Subscriber Interfaces . . . . . . . . . . . . . . . . 127
Reporting the Effective Shaping Rate for Subscribers . . . . . . . . . . . . . . . . . . . . . . 127
Verifying the Effective Shaping Rate Reporting Configuration . . . . . . . . . . . . . . . 128
Chapter 9 Applying CoS to Households or Individual Subscribers Using ACI-Based
Dynamic VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Agent Circuit Identifier-Based Dynamic VLANs Bandwidth Management
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
CoS Shaping Rate Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
CoS Overhead Accounting Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
vi Copyright © 2015, Juniper Networks, Inc.

Table of Contents
Dynamic Profiles and Adjustment of CoS Shaping Rate and Overhead

Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Guidelines for Configuring Adjustment of CoS Shaping Rate and Overhead
Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Restrictions for Configuring Adjustment of CoS Shaping Rate and Overhead
Accounting for Dynamic ACI Interface Sets . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Adjusting the CoS Shaping Rate and Overhead Accounting Parameters for Agent
Circuit Identifier-Based Dynamic VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Chapter 10 Managing Excess Bandwidth Distribution and Traffic Bursts . . . . . . . . . . . 135
Excess Bandwidth Distribution on MIC and MPC Interfaces Overview . . . . . . . . . 135
Traffic Burst Management on MIC and MPC Interfaces Overview . . . . . . . . . . . . 136
Guidelines for Configuring the Burst Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
How the System Calculates the Burst Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Managing Excess Bandwidth Distribution for Dynamic CoS on MIC and MPC
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 11 Configuring Targeted Distribution of Demux Subscribers on Aggregated
Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Distribution of Demux Subscribers in an Aggregated Ethernet Interface . . . . . . . 141
Distribution Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Sample Targeted Distribution Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Redundancy and Redistribution Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 142
Considerations and Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Providing Accurate Scheduling for a Demux Subscriber Interface of Aggregated
Ethernet Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Configuring the Distribution Type for Demux Subscribers on Aggregated Ethernet
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Configuring Link and Module Redundancy for Demux Subscribers in an
Aggregated Ethernet Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Configuring Rebalancing of Demux Subscribers in an Aggregated Ethernet
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Configuring Periodic Rebalancing of Subscribers in an Aggregated Ethernet
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Configuring Manual Rebalancing of Subscribers on an Aggregated Ethernet
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Example: Separating Targeted Multicast Traffic for Demux Subscribers on
Aggregated Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Verifying the Distribution of Demux Subscribers in an Aggregated Ethernet
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Configuring the Distribution Type for PPPoE Subscribers on Aggregated Ethernet
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Verifying the Distribution of PPPoE Subscribers in an Aggregated Ethernet
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Copyright © 2015, Juniper Networks, Inc. vii

Chapter 12 Applying CoS Using Parameters Received from RADIUS . . . . . . . . . . . . . . 159

Subscriber Interfaces That Provide Initial CoS Parameters Dynamically Obtained
from RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Dynamic Configuration of Initial CoS in Access Profiles . . . . . . . . . . . . . . . . 160
Predefined Variables for Dynamic Configuration of Initial Traffic
Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Predefined Variables for Dynamic Configuration of Initial Scheduling and
Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Changing CoS Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Types of CoS Variables Used in a Service Profile . . . . . . . . . . . . . . . . . . . . . . 163
Static and Dynamic CoS Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Scenarios for Static and Dynamic Configuration of CoS Parameters . . . . . . 164
CoS Traffic Shaping Attributes for Dynamic Interface Sets and Member
Subscriber Sessions Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Supported Network Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Traffic-Control Profiles in Subscriber Interface Dynamic Profiles . . . . . . . . . 166
CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets and
Member Subscriber Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Guidelines for Configuring CoS Traffic Shaping Attributes for Dynamic Interface
Sets and Member Subscriber Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring Initial CoS Parameters Dynamically Obtained from RADIUS . . . . . . 169
Configuring Static Default Values for Traffic Scheduling and Shaping . . . . . . . . . 170
Applying CoS Traffic-Shaping Attributes to Dynamic Interface Sets and Member
Subscriber Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets . . . . . . . . . 174
Example: Configuring Initial CoS Parameters Dynamically Obtained from
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Chapter 13 Modifying a Subscriber’s Shaping Characteristics After a Subscriber is
Instantiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
CoS Adjustment Control Profiles Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Applications and Associated Algorithms in Adjustment Control Profiles . . . 184
Configuring CoS Adjustment Control Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Verifying the CoS Adjustment Control Profile Configuration . . . . . . . . . . . . . . . . 185
Chapter 14 Configuring Dynamic CoS for L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
CoS for L2TP LAC Subscriber Interfaces Overview . . . . . . . . . . . . . . . . . . . . . . . . 187
Traffic from LAC to LNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
LAC Tunnels: Traffic from LNS to LAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
CoS for L2TP LNS Inline Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Guidelines for Applying CoS to the LNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Hardware Requirements for Inline Services on the LNS . . . . . . . . . . . . . . . . 190
Configuring Dynamic CoS for an L2TP LAC Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 190
Configuring Dynamic CoS for an L2TP LNS Inline Service . . . . . . . . . . . . . . . . . . 192
viii Copyright © 2015, Juniper Networks, Inc.

Table of Contents
Chapter 15 Applying CoS to Groups of Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . 195

CoS for Interface Sets of Subscribers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Guidelines for Configuring Dynamic Interface Sets in a Subscriber Access
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Configuring an Interface Set of Subscribers in a Dynamic Profile . . . . . . . . . . . . 198
Example: Configuring a Dynamic Interface Set of VLAN Subscribers . . . . . . . . . 198
Example: Configuring a Dynamic Service VLAN Interface Set of Subscribers in
a Dynamic Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Chapter 16 Applying CoS to Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Applying Minimal Shaping and Scheduling to Remaining Subscriber Traffic . . . 218
Applying a Rewrite Rule Definition to a Subscriber Interface in a Dynamic
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Applying a Classifier to a Subscriber Interface in a Dynamic Profile . . . . . . . . . . 220
Applying CoS Attributes to VLANs Using Agent-Circuit-Identifiers . . . . . . . . . . . 221
Part 2 Configuring Dynamic Filters and Policers

Chapter 17 Dynamic Firewall Filters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Understanding Dynamic Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Defining Dynamic Filter Processing Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Chapter 18 Configuring Static Firewall Filters That Are Dynamically Applied . . . . . . . 231
Classic Filters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Classic Filter Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Classic Filter Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Classic Filter Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Guidelines for Creating and Applying Classic Filters for Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Basic Classic Filter Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Examples: Configuring Static Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Chapter 19 Streamlining Processing of Chains of Static Filters . . . . . . . . . . . . . . . . . . . 239
Configuring Firewall Filter Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Example: Bypassing Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Chapter 20 Dynamically Attaching Static or Fast Update Filters to an Interface . . . . 245
Dynamically Attaching Statically Created Filters for a Specific Interface Family
Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Dynamically Attaching Statically Created Filters for Any Interface Type . . . . . . . 246
Chapter 21 Configuring Filters That Are Created Dynamically . . . . . . . . . . . . . . . . . . . . 249
Parameterized Filters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Unique Identifiers for Firewall Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Configuring Unique Identifiers for Parameterized Filters . . . . . . . . . . . . . . . . . . . 252
Sample Dynamic-Profile Configuration for Parameterized Filters . . . . . . . . . . . . 253
Dynamic Profile After UID Substitutions for Parameterized Filters . . . . . . . . . . . 255
Multiple Parameterized Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Parameterized Filter Processing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Copyright © 2015, Juniper Networks, Inc. ix

Parameterized Filters Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . 258

Subscriber IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Interaction with Static Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Interface-Specific Dynamic Service Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Service Session Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Filter Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Guidelines for Creating and Applying Parameterized Filters for Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
IPv4 Parameterized Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
IPv6 Parameterized Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Parameterized Filter Actions and Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Parameterized Filter Policer Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Interface-Shared Filters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Example: Implementing a Filter for Households That Use ACI-Based VLANs . . 263
Example: Dynamic-Profile Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Example: Firewall Dynamic Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Chapter 22 Using Ascend Data Filters to Implement Firewalls Based on RADIUS
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Ascend-Data-Filter Policies for Subscriber Management Overview . . . . . . . . . . 267
Filter Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Use of Multiple Sessions with Ascend-Data-Filters on an Interface . . . . . . 268
Optional ADF Filter Requirement for Some Subscribers . . . . . . . . . . . . . . . 269
Ascend-Data-Filter Attribute Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Dynamically Applying Ascend-Data-Filter Policies to Subscriber Sessions . . . . . 272
Example: Configuring Dynamic Ascend-Data-Filter Support for Subscriber
Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Example: Configuring Static Ascend-Data-Filter Support for Subscriber
Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Verifying and Managing Dynamic Ascend-Data-Filter Policy Configuration . . . . 281
Chapter 23 Configuring Fast Update Filters to Provide More Efficient Processing Over
Classic Static Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Fast Update Filters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Fast Update Filter Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Fast Update Filter Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Fast Update Filter Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Guidelines for Creating and Applying Fast Update Filters . . . . . . . . . . . . . . . 286
Basic Fast Update Filter Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Configuring Fast Update Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Example: Configuring Fast Update Filters for Subscriber Access . . . . . . . . . . . . 289
Match Conditions and Actions in Fast Update Filters . . . . . . . . . . . . . . . . . . . . . 290
Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Adding Terms Only Once . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Configuring the Match Order for Fast Update Filters . . . . . . . . . . . . . . . . . . . . . . . 291
Fast Update Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Fast Update Filter Actions and Action Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Configuring Terms for Fast Update Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Configuring Filters to Permit Expected Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
x Copyright © 2015, Juniper Networks, Inc.

Table of Contents
Avoiding Conflicts When Terms Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

How the Router Evaluates Terms in a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Using Implied Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Conflict Caused by Overlapping Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Associating Fast Update Filters with Interfaces in a Dynamic Profile . . . . . . . . . 300
Chapter 24 Defending Against DoS and DDoS Attacks Using Unicast RPF and Fail
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Unicast RPF in Dynamic Profiles for Subscriber Interfaces . . . . . . . . . . . . . . . . . 303
Configuring Unicast RPF in Dynamic Profiles for Subscriber Interfaces . . . . . . . 304
Configuring Unicast RPF and Fail Filters in Dynamic Profiles for Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Configuring a Fail Filter for Unicast RPF in Dynamic Profiles for Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Example: Configuring Unicast RPF in a Dynamic Profile on MX Series Routers . . 305
Chapter 25 Improving Scaling and Performance of Filters on Static Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Firewall Filters and Enhanced Network Services Mode Overview . . . . . . . . . . . . . 311
Configuring a Filter for Use with Enhanced Network Services Mode . . . . . . . . . . 313
Chapter 26 Configuring Dynamic Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Dynamic Service Sets Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Associating Service Sets with Interfaces in a Dynamic Profile . . . . . . . . . . . . . . . 315
Verifying and Managing Service Sets Information . . . . . . . . . . . . . . . . . . . . . . . . . 316
Chapter 27 Configuring Rate-Limiting Premium and Non-Premium Traffic on an
Interface Using Hierarchical Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Methods for Regulating Traffic by Applying Hierarchical Policers . . . . . . . . . . . . . 317
Hierarchical Policer Applied as Filter Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Example: Configuring Hierarchical Policers to Limit Rates of Services in a Static
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Chapter 28 Monitoring and Managing Firewalls for Subscriber Access . . . . . . . . . . . . 333
Verifying and Managing Firewall Filter Configuration . . . . . . . . . . . . . . . . . . . . . . 333
Enhanced Policer Statistics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Part 3 Configuring Dynamic Multicast

Chapter 29 Configuring Dynamic IGMP to Support IP Multicasting for Subscribers . . 337
Dynamic IGMP Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Subscriber Management IGMP Model Overview . . . . . . . . . . . . . . . . . . . . . . . . . 337
Configuring Dynamic DHCP Client Access to a Multicast Network . . . . . . . . . . . 338
Example: IGMP Dynamic Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Chapter 30 Configuring Dynamic MLD to Enable Subscribers to Access Multicast
Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Dynamic MLD Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Copyright © 2015, Juniper Networks, Inc. xi

Part 4 Configuring HTTP Redirect

Chapter 31 Configuring HTTP Redirect Services to Provide Authentication and
Authorization Services for Redirected Subscribers . . . . . . . . . . . . . . . . . . . 347
Redirecting HTTP Requests Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Remote HTTP Redirect Server Operation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Local HTTP Redirect Server Operation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Configuring HTTP Redirect Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Example: Walled Garden as a Service Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Example: Walled Garden as an HTTP Service Rule . . . . . . . . . . . . . . . . . . . . . . . 356
Example: Configuring an HTTP Service and Attaching It to a Static Interface . . 356
Example: HTTP Service Attached to a Dynamic Interface . . . . . . . . . . . . . . . . . . 364
Example: Configuring Destination Address Rewrite for HTTP Redirect . . . . . . . 366
Example: Configuring Redundant Multiservice . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Chapter 32 Monitoring and Managing HTTP Redirect Services . . . . . . . . . . . . . . . . . . . . 371
Verifying HTTP Redirect Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Part 5 Configuring Subscriber Secure Policy

Chapter 33 Configuring Subscriber Secure Policy Traffic Mirroring . . . . . . . . . . . . . . . . 375
Subscriber Secure Policy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Subscriber Secure Policy for Subscribers on VLANs . . . . . . . . . . . . . . . . . . . 375
Traffic Filtering For DTCP-Initiated Subscriber Secure Policy Mirrored
Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Mirroring-Related Event Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Subscriber Secure Policy Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . 376
Configuring Support for Subscriber Secure Policy Mirroring . . . . . . . . . . . . . . . . 376
Chapter 34 Configuring Subscriber Secure Policy and L2TP LAC and LNS
Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Subscriber Secure Policy and L2TP LAC Subscribers . . . . . . . . . . . . . . . . . . . . . . 379
Subscriber Secure Policy and L2TP LNS Subscribers . . . . . . . . . . . . . . . . . . . . . . 379
Chapter 35 Configuring RADIUS-Initiated Subscriber Secure Policy Traffic
Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
RADIUS-Initiated Subscriber Secure Policy Overview . . . . . . . . . . . . . . . . . . . . . . 381
Configuring RADIUS-Initiated Subscriber Secure Policy Mirroring Overview . . . . 382
Guidelines for Configuring Subscriber Secure Policy Mirroring . . . . . . . . . . . . . . 383
Configuring RADIUS Server Support for Subscriber Secure Policy Mirroring . . . . 383
Subscriber Secure Policy Traffic Mirroring Architecture Using RADIUS . . . . . . . . 384
RADIUS-Initiated Traffic Mirroring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
RADIUS-Initiated Traffic Mirroring Process at Subscriber Login . . . . . . . . . . . . . 388
RADIUS-Initiated Traffic Mirroring Process for Logged-In Subscribers . . . . . . . . 389
Configuring Tunnel Interfaces for Subscriber Secure Policy Mirroring . . . . . . . . . 390
RADIUS Attributes Used for Subscriber Secure Policy . . . . . . . . . . . . . . . . . . . . . 392
Triggering Subscriber Secure Policy for Subscribers on Dynamic
Authenticated VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Terminating RADIUS-Initiated Subscriber Traffic Mirroring . . . . . . . . . . . . . . . . . 393
xii Copyright © 2015, Juniper Networks, Inc.

Table of Contents
Chapter 36 Configuring Subscriber Secure Policy Support for IPv4 Multicast

Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Subscriber Secure Policy Support for IPv4 Multicast Traffic . . . . . . . . . . . . . . . . 395
Triggering the Mirroring of IPv4 Multicast Traffic . . . . . . . . . . . . . . . . . . . . . . 395
Enabling Subscriber Secure Policy Mirroring for IPv4 Multicast Traffic . . . . . . . . 396
Chapter 37 Configuring DTCP-Initiated Subscriber Secure Policy Traffic Mirroring . . 397
DTCP-Initiated Subscriber Secure Policy Overview . . . . . . . . . . . . . . . . . . . . . . . 397
Configuring DTCP-Initiated Subscriber Secure Policy Mirroring Overview . . . . . 398
Example: Configuring Traffic That Is Mirrored Using DTCP-Initiated Subscriber
Secure Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Subscriber Secure Policy Traffic Mirroring Architecture Using DTCP . . . . . . . . . 400
DTCP-Initiated Traffic Mirroring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
DTCP-Initiated Traffic Mirroring Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
DTCP Messages Used for Subscriber Secure Policy . . . . . . . . . . . . . . . . . . . . . . . 405
DTCP Traffic Mirroring Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Triggering Subscriber Secure Policy for Subscribers on Dynamic
Authenticated VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Order in Which Trigger Attributes Are Processed . . . . . . . . . . . . . . . . . . . . . 408
Terminating DTCP-Initiated Subscriber Traffic Mirroring Sessions . . . . . . . . . . . 408
Chapter 38 Configuring Intercept-Related Information for Subscriber Secure
Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Intercept-Related Events Transmitted to the Mediation Device . . . . . . . . . . . . . 409
SNMP Traps for Subscriber Secure Policy LAES Compliance . . . . . . . . . . . . . . . 409
Configuring SNMPv3 Traps for Subscriber Secure Policy Mirroring . . . . . . . . . . . . 411
Example: SNMPv3 Traps Configuration for Subscriber Secure Policy
Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Chapter 39 Configuring the Mediation Device for Subscriber Secure Policy . . . . . . . . . 413
Using the Packet Header to Track Subscribers on the Mediation Device . . . . . . . 413
Format of the Mirror Header Values Used to Track Subscribers and
Subscriber Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
4-Byte Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
8-Byte Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Packet Header for Mirrored Traffic Sent to Mediation Device . . . . . . . . . . . . . . . . 418
Configuring the Mediation Device as a User on the Router . . . . . . . . . . . . . . . . . 420
Configuring the Mediation Device to Provision Traffic Mirroring . . . . . . . . . . . . . . 421
Configuring a DTCP-over-SSH Connection to the Mediation Device . . . . . . . . . . 421
Chapter 40 Monitoring and Managing DTCP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Example: Using DTCP Messages to Trigger, Verify, and Disable Traffic Mirroring
for Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Creating DTCP ADD Messages to Trigger Traffic Mirroring . . . . . . . . . . . . . . 423
Creating DTCP ENABLE Messages to Trigger Traffic Mirroring . . . . . . . . . . . 425
Creating DTCP DISABLE Messages to Trigger Traffic Mirroring . . . . . . . . . . . 425
Using LIST Messages to Verify That Subscriber Traffic Is Being Mirrored . . . 425
Using DELETE Messages to Remove Traffic Mirroring Triggers . . . . . . . . . . . 426
Copyright © 2015, Juniper Networks, Inc. xiii

Verifying That Traffic Mirroring Was Stopped on the Subscriber

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
ADD DTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
DELETE DTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
DISABLE DTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
ENABLE DTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
LIST DTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Part 6 Troubleshooting
Chapter 41 Contacting Juniper Networks Technical Support . . . . . . . . . . . . . . . . . . . . . 439
Collecting Subscriber Access Logs Before Contacting Juniper Networks Technical
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Chapter 42 CoS System Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
COSD_AGGR_CONFIG_INVALID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
COSD_CHASSIS_SCHED_MAP_INVALID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
COSD_CLASSIFIER_NO_SUPPORT_LSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
COSD_CLASS_8021P_UNSUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
COSD_CLASS_NO_SUPPORT_IFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
COSD_CLASS_NO_SUPPORT_L3_IFL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
COSD_CONF_OPEN_FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
COSD_DB_OPEN_FAILED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
COSD_EXACT_RATE_UNSUPP_INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
COSD_EXACT_RATE_UNSUPP_SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
COSD_EXP_RW_L2_IFL_NOT_SUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
COSD_FRAGMENTATION_MAP_CONFLICT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
COSD_HIGH_PRIO_QUEUES_INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
COSD_HIGH_PRIO_QUEUES_SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
COSD_IFD_OUTPUT_SHAPING_RATE_ERR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
COSD_IFD_SHAPER_ERR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
COSD_INTERFACE_NO_MEDIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
COSD_L2TP_COS_NOT_CONFIGURED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
COSD_L2TP_COS_NOT_SUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
COSD_L2TP_SHAPING_NOT_CONFIGURED . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
COSD_LARGE_DELAY_BUFFER_INVALID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
COSD_MALLOC_FAILED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
COSD_MAX_FORWARDING_CLASSES_ABC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
COSD_MPLS_DSCP_CLASS_NO_SUPPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
COSD_MULTILINK_CLASS_CONFLICT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
COSD_NULL_INPUT_ARGUMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
COSD_OUT_OF_DEDICATED_QUEUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
COSD_RATE_LIMIT_INVALID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
COSD_RATE_LIMIT_NOT_SUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
COSD_REWRITE_RULE_LIMIT_EXCEEDED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
COSD_RL_IFL_NEEDS_SHAPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
COSD_SCHEDULER_MAP_CONFLICT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
COSD_SCHED_AVG_CONST_UNSUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . 454
COSD_SCHED_MAP_GROUP_CONFLICT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
COSD_SHAPER_GROUP_CONFLICT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
xiv Copyright © 2015, Juniper Networks, Inc.

Table of Contents
COSD_STREAM_IFD_CREATE_FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
COSD_TIMER_ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
COSD_TRICOLOR_ALWAYS_ON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
COSD_TRICOLOR_NOT_SUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
COSD_TX_QUEUE_RATES_TOO_HIGH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
COSD_UNKNOWN_CLASSIFIER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
COSD_UNKNOWN_REWRITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
COSD_UNKNOWN_TRAFFIC_CLASS_MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
COSD_UNKNOWN_TRANSLATION_TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Part 7 Configuration Statements and Operational Commands

Chapter 43 Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
[edit class-of-service] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
[edit dynamic-profiles] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
[edit services captive-portal-content-delivery] Hierarchy Level . . . . . . . . . . . . . 478
[edit services radius-flow-tap] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . 479
accounting (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
accounting (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
adf (Dynamic Firewalls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
adjustment-control-profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
adjust-minimum (Dynamic Shaping and Scheduling) . . . . . . . . . . . . . . . . . . . . 484
adjust-percent (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
aggregate (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
ancp (Adjustment Control Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
application (Adjustment Control Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
application (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
apply-groups (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
apply-groups-except (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . 489
authentication (Login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
authentication-order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
authentication-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
bandwidth (Tunnel Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
bandwidth-limit (Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
bandwidth-percent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
buffer-size (Dynamic Scheduling) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
burst-size-limit (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
burst-size-limit (Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
bytes (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
captive-portal-content-delivery (Captive Portal Content Delivery) . . . . . . . . . . 504
cell-mode (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
class (Assigning a Class to an Individual User) . . . . . . . . . . . . . . . . . . . . . . . . . . 506
class (Defining Login Classes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
class-of-service (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
classifiers (Dynamic CoS Application) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
color-aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
color-blind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
committed-burst-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Copyright © 2015, Juniper Networks, Inc. xv

committed-information-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
connection-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
delay-buffer-rate (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
destination-address (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . 517
destination-address (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . 517
destination-prefix-list (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . 518
destination-port (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
disable (Dynamic IGMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
disable (Dynamic MLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
drop-policy (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
drop-profile (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
drop-profile-map (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
dscp (Dynamic Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
dscp (Dynamic Rewrite Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
dscp (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
dscp-ipv6 (Dynamic Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
dscp-ipv6 (Dynamic Rewrite Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
dynamic-class-of-service-options (Dynamic Traffic Shaping) . . . . . . . . . . . . . . 526
dynamic-profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
effective-shaping-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
enhanced-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
enhanced-mode-override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
enhanced-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
excess-burst-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
excess-priority (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
excess-rate (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
excess-rate (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
excess-rate-high (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
excess-rate-low (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
exclude (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
fail-filter (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
family (Dynamic Firewalls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
family (Dynamic Standard Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
fast-update-filter (Dynamic Firewalls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
filter (Configuring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
filter (Dynamic Firewalls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
filter (Dynamic Interface Unit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
filter-specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
firewall (Dynamic Firewalls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
flow-tap-dtcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
forwarding-class (Dynamic Scheduler Maps) . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
forwarding-class (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
fpc (MX Series 3D Universal Edge Routers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
frame-mode (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
from (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
from (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
group (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
group (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
group-count (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
xvi Copyright © 2015, Juniper Networks, Inc.

Table of Contents
group-increment (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

group-limit (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
group-limit (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
group-policy (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
group-policy (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
guaranteed-rate (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
hierarchical-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
hierarchical-scheduler (Subscriber Interfaces on MX Series Routers) . . . . . . . . . 573
ieee-802.1 (Dynamic Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
ieee-802.1 (Dynamic Rewrite Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
if-exceeding (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
if-exceeding (Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
igmp (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
immediate-leave (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
immediate-leave (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
inet (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
inet-precedence (Dynamic Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
inet-precedence (Dynamic Rewrite Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
inet6 (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
input (Dynamic Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
interface (Dynamic IGMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
interface (Dynamic Interface Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
interface (Dynamic MLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
interface (Dynamic Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
interface-set (Dynamic CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
interface-shared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
interface-specific (Dynamic Firewalls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
interfaces (Dynamic CoS Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
interfaces (Static and Dynamic Subscribers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
interfaces (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
logical-bandwidth-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
logical-interface-fpc-redundancy (Aggregated Ethernet Subscriber
Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
logical-interface-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
loss-priority (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
loss-priority high then discard (Three-Color Policer) . . . . . . . . . . . . . . . . . . . . . . 601
match-direction (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . 602
max-queues-per-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
match-order (Dynamic Firewalls) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
mld (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
multicast (Dynamic Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
multicast-interception (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . 606
no-accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
no-qos-adjust (Dynamic Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
oif-map (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
oif-map (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
output (Dynamic Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
output-traffic-control-profile (Dynamic CoS Definition) . . . . . . . . . . . . . . . . . . . 610
Copyright © 2015, Juniper Networks, Inc. xvii

overhead-accounting (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . 611

passive (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
passive (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
peak-burst-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
peak-information-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
physical-interface-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
policer (Configuring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
policy (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
policy-options (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
post-service-filter (Dynamic Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
pppoe-tags (Adjustment Control Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
premium (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
priority (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
profile (Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
promiscuous-mode (Protocols IGMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
protocol (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
protocol (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
radius (Access Profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
radius-coa (Adjustment Control Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
radius-flow-tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
radius-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
rate-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
rebalance-periodic (Aggregated Ethernet Subscriber Interfaces) . . . . . . . . . . . 639
rewrite-rules (Dynamic CoS Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
routing-options (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
rpf-check (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
rule (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
rule-set (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
scheduler (Dynamic Scheduler Maps) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
scheduler-map (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
scheduler-maps (Dynamic CoS Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
schedulers (Dynamic CoS Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
service (Dynamic Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
service-filter (Dynamic Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
service-set (Dynamic Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
services (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
shaping-rate (Dynamic Traffic Shaping and Scheduling) . . . . . . . . . . . . . . . . . . 652
shared-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
single-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
source (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
source (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
source-address (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
source-count (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
source-increment (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
source-ipv4-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
source-port (Subscriber Secure Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
xviii Copyright © 2015, Juniper Networks, Inc.

Table of Contents
ssm-map (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

ssm-map (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
static (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
static (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
subscriber-leave-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
targeted-distribution (Dynamic Demux Interfaces over Aggregated
Ethernet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
targeted-distribution (Static Interfaces over Aggregated Ethernet) . . . . . . . . . . 664
term (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
term (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
then (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
three-color-policer (Configuring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
traceoptions (Captive Portal Content Delivery) . . . . . . . . . . . . . . . . . . . . . . . . . . 672
traffic-control-profiles (Dynamic CoS Definition) . . . . . . . . . . . . . . . . . . . . . . . . 674
transmit-rate (Dynamic Schedulers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
tunnel-services (Chassis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
two-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
uid (Dynamic Profiles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
uid-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
unit (Dynamic Profiles Standard Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
unit (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
user (Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
vendor-specific-tags (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . 684
version (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
version (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
vlan-tag (Dynamic Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
vlan-tag (Dynamic Rewrite Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Chapter 44 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
clear firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
clear igmp membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
clear igmp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
clear mld membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
clear mld statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
clear services captive-portal-content-delivery statistics . . . . . . . . . . . . . . . . . . 700
request interface rebalance (Aggregated Ethernet for Subscriber
Management) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
show class-of-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
show class-of-service adjustment-control-profile . . . . . . . . . . . . . . . . . . . . . . . 704
show class-of-service interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
show class-of-service interface-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
show class-of-service scheduler-hierarchy interface . . . . . . . . . . . . . . . . . . . . . . 736
show class-of-service scheduler-hierarchy interface-set . . . . . . . . . . . . . . . . . . 738
show class-of-service scheduler-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
show class-of-service traffic-control-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
show firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
show firewall log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
show firewall templates-in-use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
show igmp group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Copyright © 2015, Juniper Networks, Inc. xix

show igmp interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762

show igmp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
show interfaces targeting (Aggregated Ethernet for Subscriber
Management) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
show mld group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
show mld interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
show mld statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
show services captive-portal-content-delivery . . . . . . . . . . . . . . . . . . . . . . . . . . 782
show services service-sets summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
show subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
show subscribers summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Part 8 Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
xx Copyright © 2015, Juniper Networks, Inc.

List of Figures
Figure 1: Two-Level Hierarchical Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2: Three-Level Hierarchical Scheduling: Logical Interfaces at Level 3 with
Underlying Logical Interfaces at Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 3: Three-Level Hierarchical Scheduling: Logical Interfaces at Level 2 with
Interface Sets at Level 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 4: Logical Interfaces at Level 2 and Interface Sets at Level 3 . . . . . . . . . . . 29
Figure 5: Logical Interfaces at Level 3 and Underlying Logical Interfaces at Level
2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 6: VLAN Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 7: MPLS Pseudowire Subscriber Interface Two-Level Scheduler
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 8: Three-Level Scheduling Hierarchy Case 1: Pseudowire Service Logical
Interfaces over a Transport Logical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 9: Three-Level Scheduling Hierarchy Case 2: Pseudowire Service Logical
Interfaces over a Pseudowire Service Interface Set . . . . . . . . . . . . . . . . . . . . 68
Figure 10: Three-Level Hierarchical Scheduling for MPLS Pseudowire Subscriber
Interfaces—Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 11: Distribution of Queues on the 30-Gigabit Ethernet Queuing MPC with
One MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 12: Distribution of Queues on the 30-Gigabit Ethernet Queuing MPC with
Two MICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 13: Distribution of Queues on the 60-Gigabit Ethernet Enhanced Queuing
MPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Chapter 7 Preventing Bandwidth Contention on Subscriber Interfaces Using
Hierarchical CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 14: Scheduler Node and Queues with Adjusted Shaping Rates . . . . . . . . . 98
Figure 15: Queue with Adjusted Shaping Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 16: Sample Network Topology for Downstream Traffic . . . . . . . . . . . . . . . . 119
Figure 17: Sample Network Topology for Downstream Traffic . . . . . . . . . . . . . . . . 123
Copyright © 2015, Juniper Networks, Inc. xxi

Chapter 10 Managing Excess Bandwidth Distribution and Traffic Bursts . . . . . . . . . . . 135

Figure 18: Sample Burst Shaping Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 11 Configuring Targeted Distribution of Demux Subscribers on Aggregated
Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Figure 19: Targeted Subscriber Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Figure 20: Multicast Traffic Separation Using OIF Mapping . . . . . . . . . . . . . . . . . 148
Figure 21: CoS Configuration for L2TP LAC Topology . . . . . . . . . . . . . . . . . . . . . . 187
Figure 22: Processing of CoS Parameters in an L2TP LNS Inline Service . . . . . . . 190

Chapter 19 Streamlining Processing of Chains of Static Filters . . . . . . . . . . . . . . . . . . . 239
Figure 23: Logical Flow Example for Filter Bypass Processing . . . . . . . . . . . . . . . 241
Figure 24: Hierarchical Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Figure 25: RADIUS-Initiated Subscriber Secure Policy Architecture . . . . . . . . . . 384
Figure 26: RADIUS-Initiated Traffic Mirroring Interfaces . . . . . . . . . . . . . . . . . . . 386
Figure 27: RADIUS-Initiated Subscriber Secure Policy Model at Login . . . . . . . . 388
Figure 28: RADIUS-Initiated Subscriber Secure Policy Model After Login . . . . . . 389
Figure 29: DTCP-Initiated Subscriber Secure Policy Architecture . . . . . . . . . . . . 401
Figure 30: DTCP-Initiated Traffic Mirroring Interfaces . . . . . . . . . . . . . . . . . . . . . 402
Figure 31: DTCP-Initiated Subscriber Secure Policy Model . . . . . . . . . . . . . . . . . 404
Figure 32: Mirrored Packet Header and Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Figure 33: 4-Byte Format of VSA 26-59 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Figure 34: 8-Byte Format of VSA 26-59 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Figure 35: Mirrored Packet Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
xxii Copyright © 2015, Juniper Networks, Inc.

List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix

Chapter 1 CoS for Subscriber Access and Interfaces Overview . . . . . . . . . . . . . . . . . . . . 3
Table 3: IP Demux Classification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Table 4: IP Demux Rewrite Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Table 5: L2TP Classification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 6: L2TP LAC Rewrite Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 7: Two-Level Hierarchical Scheduling–Interface Hierarchy Versus
Scheduling Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 8: Three-Level Hierarchical Scheduling–Interface Hierarchy Versus CoS
Scheduling Node Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 9: Hardware Required for Dynamic Hierarchical CoS Configurations . . . . . . 31
Table 10: Initial Scheduler Map and Shaping Values at Subscriber Login . . . . . . . 50
Table 11: Initial CoS Values for the Voice Scheduler at Subscriber Login . . . . . . . . 50
Table 12: Initial CoS Values for the Data Scheduler at Subscriber Login . . . . . . . . 50
Table 13: Upgraded CoS Values for the Video Service . . . . . . . . . . . . . . . . . . . . . . 53
Table 14: Upgraded CoS Values for the Video Scheduler . . . . . . . . . . . . . . . . . . . . 53
Table 15: Initial CoS Values for the Expedited Forwarding Scheduler at Subscriber
Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 16: Initial CoS Values for the Best Effort Scheduler at Subscriber Login . . . 54
Table 17: Scheduler per Logical Interface Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 55
Table 18: Scheduler per Underlying Interface Mapping . . . . . . . . . . . . . . . . . . . . . 58
Table 19: Scheduler per Logical Interface with Interface Set Mapping . . . . . . . . . 60
Scheduling Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 21: Three-Level Hierarchical Scheduling–Interface Hierarchy Versus CoS
Scheduling Node Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 5 Allocating Dedicated Queues for Each Logical Interface Using Per-Unit
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Table 22: Hardware Required for Per-Unit Scheduling Dynamic CoS
Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Copyright © 2015, Juniper Networks, Inc. xxiii


Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 23: Dedicated Queues for MIC and MPC Interfaces . . . . . . . . . . . . . . . . . . . 89
Table 24: Initial Shaping Values at Subscriber Login For Traffic With Different
Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Table 25: Initial Shaping Values at Subscriber Login For Downstream Cell-Based
Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Chapter 9 Applying CoS to Households or Individual Subscribers Using ACI-Based
Dynamic VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Table 26: CoS Adjustment in Dynamic Profiles for ACI Interface Sets and
ACI-Based Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Chapter 12 Applying CoS Using Parameters Received from RADIUS . . . . . . . . . . . . . . 159
Table 27: CoS Predefined Variables for Scheduler Map and Traffic Shaping . . . . 160
Table 28: CoS Predefined Variables for Scheduling and Queuing . . . . . . . . . . . . . 161
Table 29: CoS Services and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Table 30: Junos OS CoS Traffic Shaping Predefined Variables for Dynamic
Interface Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Chapter 13 Modifying a Subscriber’s Shaping Characteristics After a Subscriber is
Instantiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Table 31: Adjustment Control Profile Applications and Algorithms . . . . . . . . . . . 183
Table 32: Ingress LAC Tunnel Classifier Options . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Table 33: Sample Result for the Classifier and Rewrite Rules for a VLAN
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Table 34: Hardware Requirements for L2TP LNS Inline Services . . . . . . . . . . . . . 190

Chapter 22 Using Ascend Data Filters to Implement Firewalls Based on RADIUS
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Table 35: Ascend-Data-Filter Attribute Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Table 36: Ascend-Data-Filter Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Chapter 23 Configuring Fast Update Filters to Provide More Efficient Processing Over
Classic Static Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Table 37: Fast Update Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Table 38: Fast Update Filter Actions and Action Modifiers . . . . . . . . . . . . . . . . . . 293
Chapter 25 Improving Scaling and Performance of Filters on Static Subscriber
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Table 39: Enhanced Network Services Mode and Firewall Filter Use Case
Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Table 40: Hierarchical Policer Configuration and Application Summary . . . . . . . 322
xxiv Copyright © 2015, Juniper Networks, Inc.

List of Tables

Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Table 41: RADIUS-Initiated Subscriber Secure Policy Functions and
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Table 42: RADIUS-Initiated Traffic Mirroring Interfaces . . . . . . . . . . . . . . . . . . . . 387
Table 43: RADIUS-Based Mirroring Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Table 44: RADIUS Attributes Used in CoA Messages to Identify Subscribers for
Traffic Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Table 45: DTCP-Initiated Subscriber Secure Policy Functions and
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Table 46: DTCP-Initiated Traffic Mirroring Interfaces . . . . . . . . . . . . . . . . . . . . . . 403
Table 47: DTCP Mirroring Triggers for Use in ADD Messages . . . . . . . . . . . . . . . . 405
Chapter 38 Configuring Intercept-Related Information for Subscriber Secure
Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Table 48: Subscriber Secure Policy SNMPv3 Traps for LAES Messages . . . . . . . 410
Table 49: Mirrored Packet Header and Payload Field Descriptions For the
Mediation Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Table 50: Packet Header Field Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Part 7 Configuration Statements and Operational Commands

Chapter 43 Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Table 51: Bandwidth Limits and Token Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Chapter 44 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Table 52: show class-of-service adjustment-control-profile Output Fields . . . . 704
Table 53: show class-of-service interface Output Fields . . . . . . . . . . . . . . . . . . . 707
Table 54: show class-of-service interface-set Output Fields . . . . . . . . . . . . . . . . 734
Table 55: show class-of-service scheduler-hierarchy interface Output Fields . . 736
Table 56: show class-of-service scheduler-hierarchy interface-set Output
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Table 57: show class-of-service scheduler-map Output Fields . . . . . . . . . . . . . . 740
Table 58: show class-of-service traffic-control-profile Output Fields . . . . . . . . . 742
Table 59: show firewall Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Table 60: show firewall log Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Table 61: show firewall templates-in-use Output Fields . . . . . . . . . . . . . . . . . . . 756
Table 62: show igmp group Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Table 63: show igmp interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Table 64: show igmp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Table 65: show interfaces targeting Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 769
Table 66: show mld group Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Table 67: show mld interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Table 68: show mld statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Table 69: show services service-sets summary Output Fields . . . . . . . . . . . . . . 784
Copyright © 2015, Juniper Networks, Inc. xxv

Table 70: show subscribers Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

Table 71: show subscribers summary Output Fields . . . . . . . . . . . . . . . . . . . . . . 805
xxvi Copyright © 2015, Juniper Networks, Inc.

About the Documentation
• Documentation and Release Notes on page xxvii

• Supported Platforms on page xxvii
• Using the Examples in This Manual on page xxvii
• Documentation Conventions on page xxix
• Documentation Feedback on page xxxi
• Requesting Technical Support on page xxxi
Documentation and Release Notes

®
To obtain the most current version of all Juniper Networks technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.
Supported Platforms
For the features described in this document, the following platforms are supported:
• MX Series
Using the Examples in This Manual
If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. The example does not become
active until you commit the candidate configuration.
If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. In this case, use the load merge command.
Copyright © 2015, Juniper Networks, Inc. xxvii

If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.
Merging a Full Example

To merge a full example, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.
For example, copy the following configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}
2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command:
[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
Merging a Snippet
To merge a snippet, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.
For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.
commit {
file ex-script-snippet.xsl; }
2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:
xxviii Copyright © 2015, Juniper Networks, Inc.

[edit]
user@host# edit system scripts
[edit system scripts]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:
[edit system scripts]

user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete
For more information about the load command, see the CLI User Guide.
Documentation Conventions
Table 1 on page xxix defines notice icons used in this guide.
Table 1: Notice Icons

Icon Meaning Description
Informational note Indicates important features or instructions.
Caution Indicates a situation that might result in loss of data or hardware damage.
Warning Alerts you to the risk of personal injury or death.
Laser warning Alerts you to the risk of personal injury from a laser.
Tip Indicates helpful information.
Best practice Alerts you to a recommended use or implementation.
Table 2 on page xxix defines the text and syntax conventions used in this guide.
Table 2: Text and Syntax Conventions

Convention Description Examples
Bold text like this Represents text that you type. To enter configuration mode, type the
configure command:
user@host> configure
Copyright © 2015, Juniper Networks, Inc. xxix

Table 2: Text and Syntax Conventions (continued)

Fixed-width text like this Represents output that appears on the user@host> show chassis alarms
terminal screen.
No alarms currently active
Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.
• Junos OS CLI User Guide
• Identifies RFC and Internet draft titles.
• RFC 1997, BGP Communities Attribute
Italic text like this Represents variables (options for which Configure the machine’s domain name:
you substitute a value) in commands or
configuration statements. [edit]
root@# set system domain-name
domain-name
Text like this Represents names of configuration • To configure a stub area, include the
statements, commands, files, and stub statement at the [edit protocols
directories; configuration hierarchy levels; ospf area area-id] hierarchy level.
or labels on routing platform • The console port is labeled CONSOLE.
components.
< > (angle brackets) Encloses optional keywords or variables. stub <default-metric metric>;
| (pipe symbol) Indicates a choice between the mutually broadcast | multicast

exclusive keywords or variables on either
side of the symbol. The set of choices is (string1 | string2 | string3)
often enclosed in parentheses for clarity.
# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS only
same line as the configuration statement
to which it applies.
[ ] (square brackets) Encloses a variable for which you can community name members [
substitute one or more values. community-ids ]
Indention and braces ( { } ) Identifies a level in the configuration [edit]

hierarchy. routing-options {
static {
route default {
; (semicolon) Identifies a leaf statement at a
nexthop address;
configuration hierarchy level.
retain;
}
}
}
GUI Conventions
Bold text like this Represents graphical user interface (GUI) • In the Logical Interfaces box, select
items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.
xxx Copyright © 2015, Juniper Networks, Inc.

Table 2: Text and Syntax Conventions (continued)

> (bold right angle bracket) Separates levels in a hierarchy of menu In the configuration editor hierarchy,
selections. select Protocols>Ospf.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can

improve the documentation. You can provide feedback by using either of the following
methods:
• Online feedback rating system—On any page at the Juniper Networks Technical
Documentation site at http://www.juniper.net/techpubs/index.html, simply click the
stars to rate the content, and use the pop-up form to provide us with information about
your experience. Alternately, you can use the online feedback form at
https://www.juniper.net/cgi-bin/docbugreport/.
• E-mail—Send your comments to techpubs-comments@juniper.net. Include the document

or topic name, URL or page number, and software version (if applicable).
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
or are covered under warranty, and need post-sales technical support, you can access
our tools and resources online or open a case with JTAC.
• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.
• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.
• JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:
• Find CSC offerings: http://www.juniper.net/customers/support/
• Search for known bugs: http://www2.juniper.net/kb/
• Find product documentation: http://www.juniper.net/techpubs/
• Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
Copyright © 2015, Juniper Networks, Inc. xxxi

• Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/
• Search technical bulletins for relevant hardware and software notifications:

http://kb.juniper.net/InfoCenter/
• Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/
• Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.
• Use the Case Management tool in the CSC at http://www.juniper.net/cm/.
• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, see

http://www.juniper.net/support/requesting-support.html.
xxxii Copyright © 2015, Juniper Networks, Inc.

PART 1
Configuring Dynamic Class of Service

• CoS for Subscriber Access and Interfaces Overview on page 3
• Configuring Scheduling and Shaping for Subscriber Access on page 11
• Managing Different Types of Service Traffic for a Household Using Hierarchical
Scheduling on page 25
• Configuring Hierarchical CoS Scheduling on MPLS Ethernet Pseudowire Subscriber
Interfaces on page 63
• Allocating Dedicated Queues for Each Logical Interface Using Per-Unit
• Configuring Dedicated Queue Scaling with Hierarchical CoS or Per-Unit
• Preventing Bandwidth Contention on Subscriber Interfaces Using Hierarchical
CoS on page 97
• Shaping Downstream Traffic Based on Frames or Cells on page 115
• Applying CoS to Households or Individual Subscribers Using ACI-Based Dynamic
VLANs on page 129
• Managing Excess Bandwidth Distribution and Traffic Bursts on page 135
• Configuring Targeted Distribution of Demux Subscribers on Aggregated Ethernet
• Applying CoS Using Parameters Received from RADIUS on page 159
• Modifying a Subscriber’s Shaping Characteristics After a Subscriber is
Instantiated on page 183
• Configuring Dynamic CoS for L2TP on page 187
• Applying CoS to Groups of Subscriber Interfaces on page 195
• Applying CoS to Subscriber Interfaces on page 217
Copyright © 2015, Juniper Networks, Inc. 1

2 Copyright © 2015, Juniper Networks, Inc.

CHAPTER 1
CoS for Subscriber Access and Interfaces

Overview
• CoS for Subscriber Access Overview on page 3

• Guidelines for Configuring Dynamic CoS for Subscriber Access on page 4
• CoS for Aggregated Ethernet Subscriber Interfaces Overview on page 8
• CoS for PPPoE Subscriber Interfaces Overview on page 9
CoS for Subscriber Access Overview
This topic describes class-of-service (CoS) functionality for dynamic subscriber access.
Junos CoS enables you to divide traffic into classes and offer various levels of throughput
and packet loss when congestion occurs. This functionality allows packet loss to happen
according to rules that you configure. The Junos CoS features provide a set of mechanisms
that you can use to provide differentiated services when best-effort traffic delivery is
insufficient.
In a subscriber access environment, service providers want to provide video, voice, and
data services over the same network for subscribers. Subscriber traffic is delivered from
the access network, through a router, through a switched Ethernet network, to an Ethernet
digital subscriber line access multiplexer (DSLAM). The DSLAM forwards the subscriber’s
traffic to the residential gateway over a digital subscriber line (DSL). An MX Series router
that is installed in a subscriber access network as an edge router can perform subscriber
management functions that include subscriber identification and per-subscriber CoS.
In a subscriber access network, a subscriber is an authenticated user—a user that has

logged in to the access network at a subscriber interface and then been verified by the
configured authentication server and subsequently granted initial CoS services.
Subscribers can be identified statically or dynamically. In this network, subscribers are
mapped to VLANs, demux, or PPPoE interfaces.
You can configure the router to provide hierarchical scheduling or per-unit scheduling for
subscribers:
• Hierarchical CoS enables you to apply traffic scheduling and queuing parameters
(which can include a delay-buffer bandwidth) and packet transmission scheduling
parameters (which can include buffer management parameters) to an individual

subscriber interface rather than to all interfaces configured on the port. Hierarchical
CoS enables you to dynamically modify queues when subscribers require services.
• Per-unit scheduling enables one set of output queues for each logical interface
configured under the physical interface. In per-unit scheduling configurations, each
Layer 3 scheduler node is allocated a dedicated set of queues.
Because the interface sets corresponding to VLANs using agent-circuit-identifier

information are created dynamically, you can apply CoS attributes, such as shaping, at
the household level. You must set and define the CoS policy for the agent-circuit-identifier
virtual VLAN interface set using the dynamic profile for the agent-circuit-identifier interface
set (not the subscriber profile). CoS on dynamic VLANs includes support for level 3 or
level 2 scheduler nodes for a dynamic interface set. You can also configure a traffic-control
profile and a remaining traffic-control profile for a dynamic interface set. CoS on dynamic
VLANs enables you to configure a dynamic scheduler map for a traffic-control profile
that is used by a dynamic interface set. In this case, the dynamic scheduler map must
use the unique ID format.
Related • Understanding Two-Level and Three-Level Hierarchical CoS for Subscriber Interfaces
Documentation on page 25
• Configuring Static Hierarchical Scheduling in a Dynamic Profile on page 32
• Configuring Dynamic Hierarchical Scheduling in a Dynamic Profile on page 33
• Configuring Per-Unit Scheduling in a Dynamic Profile on page 78
Guidelines for Configuring Dynamic CoS for Subscriber Access
This topic describes the guidelines for configuring dynamic CoS in a subscriber access
environment.
Configuration Guidelines for Hierarchical CoS and Per-Unit Scheduling

You can configure dynamic CoS with one of the following scheduling configurations:
• For hierarchical scheduling configurations, you must enable hierarchical scheduling in

the static CLI for the interface referenced in the dynamic profile. If not, the dynamic
profile fails.
• For per-unit scheduling configurations, you must enable per-unit scheduling in the
static CLI for the interface referenced in the dynamic profile. If not, the dynamic profile
fails and schedulers are not attached to the interface.
Junos software supports either per-unit scheduling or hierarchical scheduling on an

interface. You cannot run both types of scheduling at the same time. If CoS is active on
an interface, and you change the type of scheduling configured on the interface, all traffic
is dropped upon egress from the interface.

Chapter 1: CoS for Subscriber Access and Interfaces Overview
Configuration Guidelines for Dynamic Scheduling and Queuing

When configuring scheduling and queuing for subscriber access, consider the following
guidelines:
• To improve CoS performance in IPv4, IPv6, and dual-stack networks that use a DHCP
access model, we recommend that you use the aggregate-clients replace statement
rather than the aggregate-clients merge statement.
• You configure the traffic scheduling and shaping parameters in a traffic-control profile
within the dynamic profile. You can configure the scheduler map and schedulers in a
dynamic profile or in the [edit class-of-service] hierarchy. You must statically configure
the remaining CoS parameters, such as hierarchical scheduling, classifiers, drop profiles,
and forwarding classes, in the [edit class-of-service] hierarchy.
• You can configure only one traffic-control-profile under a dynamic profile.
• You must define the output-traffic-control-profile that binds the traffic-control profile
to the interface within the same dynamic profile as the interface.
• We recommend that you provide different names for the schedulers defined in dynamic
profiles that are used for access and services. For example, if there are two dynamic
profiles, voice-profile and video-profile, provide unique names for the schedulers
defined under those profiles.
• You must use a service dynamic profile with a different profile name for each RADIUS
CoA request over the same logical interface.
• When you configure scheduler and scheduler map sharing in client profiles, schedulers
and scheduler maps must use the unique ID format. If the client profile uses the unique
ID format and you want to have either scheduler or scheduler map sharing for service
activation, you must configure the service profile in unique ID format.
Configuration Guidelines for Dynamic Classifiers and Rewrite Rules

When you configure classifiers and rewrite rules for subscriber access, consider the
following guidelines:
• To apply classifiers and rewrite rules to a subscriber interface in a dynamic profile, you
must configure the rewrite rule and classifier definitions in the static [edit
class-of-service] hierarchy and reference them in the dynamic profile.
• If a static classifier or a rewrite rule definition that is referenced by a dynamic

subscriber interface does not exist, the configuration is invalid and the subscriber
cannot log in.
• If a network administrator changes the static classifiers and rewrite rules definitions
that are referenced in a dynamic profile with an active subscriber interface logged
in, the changes are applied to the active subscriber interface immediately.
• If a network administrator deletes a classifier or a rewrite rule definition that is

referenced by an active dynamic subscriber interface, the system removes the
classifier or rewrite rule binding from the interface. The classifier is replaced by the
default classifier. If the network administrator adds the removed classifier or rewrite

rule to the configuration while the dynamic interface is active, the addition does not
take effect until the subscriber logs out and then logs in again.
• IP demux interfaces can only instantiate Layer 3 rules (both rewrite rules and classifiers).
• An IP demux subscriber interface can implicitly inherit a classifier from the underlying
interface. If an IP demux interface is created without a classifier and a Layer 2 classifier
is attached to the underlying interface, the IP demux interface also inherits the Layer
2 classifier. The show class-of-service interface interface-name command does not
display this attachment.
Table 3 on page 6 lists the classification rule configuration for an IP demux subscriber
interface with a VLAN underlying interface.
Table 3: IP Demux Classification Rules

VLAN Underlying Interface IP Demux Interface Resulting Classifier
Classifier Configuration Classifier Configuration Configuration
Layer 2 — VLAN Layer 2
Layer 2 Layer 3 Demux Layer 3
Layer 3 — Default
• An IP demux subscriber interface explicitly inherits Layer 2 rewrite rules from the
underlying interface if a Layer 2 rewrite rule is present. The show class-of-service
interface interface-name command displays the attachment.
Table 4 on page 6 lists the rewrite rule configuration for an IP demux subscriber
interface with a VLAN underlying interface.
Table 4: IP Demux Rewrite Rules

IP Demux Interface
VLAN Underlying Interface Rewrite Rule Resulting Rewrite Rule
Rewrite Rule Configuration Configuration Configuration
Layer 2 — VLAN Layer 2
Layer 2 Layer 3 VLAN Layer 2 and demux Layer 3
Layer 3 — Default
• An L2TP subscriber interface can implicitly inherit a classifier from the underlying
interface.
Table 5 on page 7 lists the classification rule configuration for an L2TP LAC
subscriber interface with a VLAN underlying interface.

Table 5: L2TP Classification Rules

VLAN Underlying Interface L2TP LAC Classifier Resulting Classifier
Classifier Configuration Configuration Configuration
Layer 2 or Fixed Layer 2 or Fixed VLAN Layer 2 or Fixed
Layer 2 or Fixed Layer 3 Demux/PPPoE Layer 3
Layer 3 Layer 2 or Fixed VLAN Layer 2 or Fixed
Layer 3 Layer 3 Demux/PPPoE Layer 3
• An L2TP LAC subscriber interface explicitly inherits Layer 2 rewrite rules from the
underlying interface if a Layer 2 rewrite rule is present. Table 6 on page 7 lists the
rewrite rule configuration for an L2TP LAC subscriber interface with a VLAN underlying
interface.
Table 6: L2TP LAC Rewrite Rules

VLAN Underlying
Interface Rewrite Rule L2TP Interface Rewrite Resulting Rewrite Rule
Configuration Rule Configuration Configuration
Layer 2 Layer 2 VLAN Layer 2
Layer 2 Layer 3 VLAN Layer 2 and demux/PPPoE

Layer 3
Layer 3 Layer 2 VLAN Layer 2 and demux/PPPoE

Layer 3
Layer 3 Layer 3 Demux/PPPoE Layer 3
Related • CoS for Subscriber Access Overview on page 3

Documentation
• Understanding Two-Level and Three-Level Hierarchical CoS for Subscriber Interfaces
on page 25
• Configuring Static CoS for an L2TP LNS Inline Service

CoS for Aggregated Ethernet Subscriber Interfaces Overview
You can apply static or dynamic hierarchical CoS to a scheduler node at the aggregated
Ethernet logical interface, its underlying physical interface, or an interface set.
When you configure CoS for aggregated Ethernet interfaces, consider the following
guidelines:
• Configure the aggregated Ethernet logical interface over two physical interfaces capable
of performing hierarchical scheduling.
• For VLAN subscriber interfaces over aggregated Ethernet, you must enable link
protection on the aggregated Ethernet interface for hierarchical CoS to operate.
• Link protection is not required for IP or demux subscriber interfaces over aggregated
Ethernet. We recommend that you enable targeted distribution on the demux interface
to provide accurate hierarchical scheduling for these links.
• Keep the following guidelines in mind when configuring interface sets of aggregated
Ethernet interfaces:
• Sets of aggregated Ethernet interfaces are supported on MPC/MIC interfaces on MX

Series routers only.
• The supported logical interfaces for aggregated Ethernet in an interface set include
VLAN demux interfaces, IP demux interfaces, and PPPoE logical interfaces over
VLAN demux interfaces.
• The link membership list and scheduler mode of the interface set are inherited from
the underlying aggregated Ethernet interface over which the interface set is
configured.
• When an aggregated Ethernet interface operates in link protection mode, or if the

scheduler mode is configured to replicate member links, the scheduling parameters
of the interface set are copied to each of the member links.
• If the scheduler mode of the aggregated Ethernet interface is set to scale member
links, the scheduling parameters are scaled based on the number of active member
links and applied to each of the aggregated interface member links.
• Configuring Hierarchical CoS for a Subscriber Interface of Aggregated Ethernet Links

on page 35
• Configuring an Interface Set of Subscribers in a Dynamic Profile on page 198
• Static or Dynamic Demux Subscriber Interfaces over Aggregated Ethernet Overview
• Static and Dynamic VLAN Subscriber Interfaces over Aggregated Ethernet Overview
• Distribution of Demux Subscribers in an Aggregated Ethernet Interface on page 141

CoS for PPPoE Subscriber Interfaces Overview
You can configure CoS functionality for static and dynamic PPPoE subscriber interfaces
configured on Gigabit Ethernet Intelligent Queuing 2 (IQ2) and Ethernet Enhanced IQ2
(IQ2E) PICs on the M120 and M320 routers, and on MPCs on the MX Series 3D Universal
Edge Router.
For all supported hardware platforms, you can attach an output traffic-control profile
that contains basic shaping and scheduling properties directly to a PPPoE interface. In
this type of scenario, you can use each PPPoE interface to represent a household and
shape all of the household traffic to an aggregate rate. Each forwarding class is mapped
to a queue, and represents one type of services provided to a household customer.
Both the IQ2E PIC and MPC Q line cards support hierarchical scheduling functionality
that is not available on the IQ2 PIC. To shape customer or DSLAM traffic at different
levels of the PPPoE interface hierarchy, you can attach traffic-control profiles to interface
sets that contain PPPoE members.
MPCs support subscriber interfaces with PPPoE encapsulation over aggregated Ethernet
interfaces. These PPPoE subscriber interfaces are configured over VLAN demux interfaces,
which are also configured over Aggregated Ethernet interfaces.
You can configure 802.3ad link aggregation group (LAG) stateful port and dense port
concentrator (DPC) redundancy. This provides targeted distribution of non-replicated
(stacked) PPPoE or IP demux links over VLAN demux links, which in turn are over an
aggregated Ethernet (AE) logical interface. Service providers with PPPoE or IP demux
interfaces for CoS configurations can provide DPC and port redundancy to subscribers.
NOTE: For static PPPoE underlying logical interfaces, use PPPoE interface
sets.
• Configuring Hierarchical CoS on a Static PPPoE Subscriber Interface on page 36
• CoS on Enhanced IQ2 PICs Overview


CHAPTER 2
Configuring Scheduling and Shaping for

Subscriber Access
• Configuring Traffic Scheduling and Shaping for Subscriber Access on page 11

• Configuring Schedulers in a Dynamic Profile for Subscriber Access on page 13
• Configuring Scheduler and Scheduler Map Sharing on page 19
• Example: Providing Unique Rate Configurations for Schedulers in a Dynamic
Profile on page 21
• Example: Configuring Aggregate Scheduling of Queues for Residential Subscribers on
Static IP Demux Interfaces on page 21
• Verifying the Scheduling and Shaping Configuration for Subscriber Access on page 23
Configuring Traffic Scheduling and Shaping for Subscriber Access
You use traffic-control profiles to configure traffic shaping and scheduling properties.
You can choose to configure static values or dynamic variables for the shaping parameters.
The values for the dynamic variables are obtained from RADIUS when a subscriber logs
in or when a subscriber changes services.
You cannot configure a traffic-control profile that contains a combination of static and
dynamic parameters.
This topic includes the following tasks:
• Configuring Static Traffic Shaping and Scheduling Parameters in a Dynamic

Profile on page 11
• Configuring Dynamic Traffic Shaping and Scheduling Parameters in a Dynamic
Profile on page 12
Configuring Static Traffic Shaping and Scheduling Parameters in a Dynamic Profile

To configure static traffic shaping and scheduling parameters in a traffic-control profile:
1. Create the traffic-control profile and assign a name.
[edit dynamic-profiles business-profile class-of-service]

user@host# edit traffic-control-profiles profile-name

2. Apply a static scheduler map that has been configured in the [edit class-of-service]
hierarchy.
[edit dynamic-profiles business-profile class-of-service traffic-control-profiles

profile-name]
user@host# set scheduler-map map-name
3. Configure the shaping rate to be used in the dynamic profile.

profile-name]
user@host# set shaping-rate (rate <burst-size bytes>
4. Configure the guaranteed rate to be used in the dynamic profile.

profile-name]
user@host# set guaranteed-rate (rate <burst-size bytes>
5. Configure the delay-buffer rate.
If you do not include this statement, the delay-buffer rate is based on the guaranteed
rate if one is configured, or on the shaping rate if no guaranteed rate is configured.

profile-name]
user@host# set delay-buffer-rate (percent percentage | rate)
Configuring Dynamic Traffic Shaping and Scheduling Parameters in a Dynamic Profile

You can configure variables for the traffic shaping and scheduling parameters. The values
for the parameters are dynamically obtained by RADIUS when a subscriber logs in or
changes a service.
To configure dynamic traffic-control profiles in a dynamic profile:
1. Create the traffic-control profile.
[edit dynamic-profiles business-profile class-of-service]

2. Reference a dynamic scheduler map.
The scheduler map is dynamically configured in the [edit dynamic-profiles profile-name

class-of-service scheduler-maps] hierarchy.

profile-name]
user@host# set scheduler-map $junos-cos-scheduler-map
3. Configure the shaping rate variable.

profile-name]
user@host# set shaping-rate $junos-cos-shaping-rate <burst-size bytes>
4. Configure the guaranteed rate variable.

profile-name]

Chapter 2: Configuring Scheduling and Shaping for Subscriber Access
user@host# set guaranteed-rate $junos-cos-guaranteed-rate <burst-size [ bytes |

$junos-cos-guaranteed-rate-burst]>
5. Configure a variable for the delay-buffer rate.
If you do not include this statement, the delay-buffer rate is based on the guaranteed
rate if one is configured, or the shaping rate if no guaranteed rate is configured.

profile-name]
user@host# set delay-buffer-rate $junos-cos-delay-buffer-rate
Related • For hardware requirements and configuration guidelines, see Guidelines for Configuring
Documentation Dynamic CoS for Subscriber Access on page 4
• Example: Maintaining a Constant Traffic Flow by Configuring a Static VLAN Interface

with a Dynamic Profile for Subscriber Access on page 37
• Example: Configuring Dynamic Hierarchical Scheduling for Subscribers on page 48
Configuring Schedulers in a Dynamic Profile for Subscriber Access
You use schedulers to define the parameters of output queues. These properties include
the amount of interface bandwidth assigned to the queue, the size of the memory buffer
allocated for storing packets, the priority of the queue, and the tail drop profiles associated
with the queue.
You can configure up to four schedulers in a dynamic profile.
Within a dynamic profile, you can choose to define schedulers with static values, dynamic
variables, or a combination of static values and dynamic variables. The dynamic variables
enable RADIUS to provide the value for the scheduler parameter when the subscriber
logs in.
• Configuring Static Schedulers in a Dynamic Profile on page 14

• Configuring Dynamic Schedulers with Variables in a Dynamic Profile on page 15
• Configuring a Combination of Static and Dynamic Scheduler Parameters in a Scheduler
Definition on page 16

Configuring Static Schedulers in a Dynamic Profile

This topic describes how to configure schedulers with static values in a dynamic profile
for subscriber access.
To configure static scheduling and queuing in a dynamic profile:
1. Configure the scheduler and queuing parameters.
a. Specify the scheduler for which you want to configure parameters.
[edit dynamic-profiles profile-name class-of-service]

user@host# edit schedulers scheduler-name
b. Configure the buffer size.
[edit dynamic-profiles profile-name class-of-service schedulers scheduler-name]

user@host# set buffer-size remainder
c. Configure the drop-profile map and drop profile.

user@host# set drop-profile-map loss-priority any protocol any drop-profile d3
d. Configure the priority.

user@host# set priority low
e. Configure the transmit rate.

user@host# set transmit-rate percent 40
f. Configure the excess rate.

user@host# set excess-rate percent 90
g. (Optional) Configure the priority value for the excess-rate.

user@host# set excess-priority high
2. Associate the scheduler with a scheduler map.
a. Configure the scheduler map name.

user@host# set scheduler-maps data-smap
b. Configure the forwarding class.
[edit dynamic-profiles profile-name class-of-service scheduler-maps map-name]

user@host# set forwarding-class be
c. Configure the scheduler.
[edit dynamic-profiles profile-name class-of-service scheduler-maps map-name

forwarding-class forwarding-class-name]

user@host# set scheduler be_sch
Configuring Dynamic Schedulers with Variables in a Dynamic Profile

You can configure variables for the dynamic scheduler parameters. These values are
dynamically obtained by RADIUS when a subscriber logs in or changes a service using a
RADIUS change of authorization (CoA) message.
To configure dynamic scheduling and queuing in a dynamic profile:
1. Configure the scheduler and queuing parameters.
a. Specify the scheduler name using a variable.

user@host# edit schedulers $junos-cos-scheduler
b. Configure the variable for the buffer size.
[edit dynamic-profiles profile-name class-of-service schedulers]

user@host# set buffer-size (percent $junos-cos-scheduler-bs | temporal
$junos-cos-scheduler-bs)
c. Configure the variables for the drop-profile maps and the drop profile.

user@host# set drop-profile-map loss-priority low protocol any drop-profile
$junos-cos-scheduler-low
user@host# set drop-profile-map loss-priority medium-low protocol any
drop-profile $junos-cos-scheduler-medium-low
user@host# set drop-profile-map loss-priority medium-high protocol any
drop-profile $junos-cos-scheduler-medium-high
user@host# set drop-profile-map loss-priority high protocol any drop-profile
$junos-cos-scheduler-high
user@host# set drop-profile-map loss-priority any protocol any drop-profile
$junos-cos-scheduler-any
d. Configure the variable for the priority.

user@host# set priority $junos-cos-scheduler-pri
e. Configure the variable for the transmit rate.

user@host# set transmit-rate $junos-cos-scheduler-tx
f. Configure the variable for the excess rate.

user@host# set excess-rate percent $junos-cos-scheduler-excess-rate
g. Configure the variable for the priority of the excess-rate.

user@host# set excess-priority $junos-cos-scheduler-excess-priority


user@host# edit scheduler-maps scheduler-map-name
[edit dynamic-profiles profile-name class-of-service scheduler-maps

scheduler-map-name]

scheduler-map-name]
user@host# set scheduler $junos-cos-scheduler
Configuring a Combination of Static and Dynamic Scheduler Parameters in a Scheduler Definition

Within a dynamic profile, you can choose to configure one dynamic scheduler definition,
or combine static and dynamic scheduler parameters in many static scheduler definitions.
Combining static and dynamic scheduler parameters enables you to provide subscribers
with unique rate configurations that the RADIUS definitions for predefined variables do
not allow.
To configure a scheduler definition that contains static and dynamic scheduling and
queuing parameters:
1. Configure the scheduler definition.
a. Specify the scheduler name.
NOTE: To configure a static scheduler that contains both static and

dynamic parameters, you must specify a unique scheduler name, not
the $junos-cos-scheduler variable.

user@host# edit schedulers scheduler-name
b. Configure the buffer size.
Do either of the following:
• Configure a static value.

user@host# set buffer-size (percent percentage | remainder | temporal
(microseconds)
• Configure a variable.

user@host# set buffer-size (percent $junos-cos-scheduler-bs | temporal

$junos-cos-scheduler-bs)
c. Configure the drop-profile maps, the drop profile, and the priority.
• Configure static values.

user@host# set drop-profile-map loss-priority any protocol any drop-profile d3

• Configure variables.

user@host# set drop-profile-map loss-priority low protocol any drop-profile
$junos-cos-scheduler-low
user@host# set drop-profile-map loss-priority medium-low protocol any
drop-profile $junos-cos-scheduler-medium-low
user@host# set drop-profile-map loss-priority medium-high protocol any
drop-profile $junos-cos-scheduler-medium-high
user@host# set drop-profile-map loss-priority high protocol any drop-profile
$junos-cos-scheduler-high
user@host# set drop-profile-map loss-priority any protocol any drop-profile
$junos-cos-scheduler-any
d. Configure the priority.


user@host# set excess-priority $junos-cos-scheduler-excess-priority
e. Configure the transmit rate.

user@host# set transmit-rate

user@host# set transmit-rate $junos-cos-scheduler-tx
f. Configure the excess rate.



user@host# set excess-rate percent $junos-cos-scheduler-excess-rate
g. Configure the priority for the excess-rate.


user@host# set excess-priority percent $junos-cos-scheduler-excess-priority

user@host# edit scheduler-maps scheduler-map-name

scheduler-map-name]

scheduler-map-name]
user@host# set scheduler $junos-cos-scheduler
• Changing CoS Services Overview on page 163

Configuring Scheduler and Scheduler Map Sharing
The system generates unique identifiers (IDs) in dynamic profiles created for services.
The generated unique IDs enable you to identify and configure separate parameter values
with the same variable name. When applied to CoS, you can configure scheduler and
scheduler map sharing. In client-access profiles, schedulers and scheduler maps must
use the unique ID format. If the client-access profile uses the unique ID format and you
want to have either scheduler or scheduler map sharing for service activation, you must
configure the service profile in unique ID format. Generating unique IDs based on
schedulers and scheduler maps eliminates duplication and improves router performance
and scalability. You can configure scheduler and scheduler map sharing by including the
variables for CoS in the client access or service dynamic profile. All scheduler maps and
schedulers must be in the unique ID format.
Before you configure variables for the client access or service dynamic profile:
• Create a basic dynamic profile.
See Configuring a Basic Dynamic Profile.
To configure variables for the client access or service dynamic profile:
1. Configure the variables for the dynamic client access profile.
[edit dynamic-profiles client-profile variables]

user@host# set smap_data uid
user@host# set data_sched uid
2. Configure the CoS parameters for the variables in the scheduler profile.
[edit dynamic-profiles client-profile class-of-service]

user@host# edit schedulers “$data_sched”
3. Configure the CoS parameters for the variables in the scheduler maps profile.
[edit dynamic-profiles client-profile class-of-service]

user@host# edit scheduler-maps “$smap_data”
user@host# edit forwarding-class be scheduler “$data_sched”
For example, you can configure scheduler maps and schedulers for a client access profile:
dynamic-profiles {
cos-para {
variables {
data_smap uid;
data_video_smap uid;
voice_smap uid;
data_sched uid;
video_sched uid;
voice_sched uid;
}
…

class-of-service {
traffic-control-profiles {
tcp1 {
scheduler-map "$junos-cos-scheduler-map";
shaping-rate "$junos-cos-shaping-rate";
guaranteed-rate 10m;
delay-buffer-rate "$junos-cos-delay-buffer-rate";
}
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-underlying-interface-unit" {
output-traffic-control-profile tcp1;
}
}
}
scheduler-maps {
"$data_smap" {
forwarding-class be scheduler "$data_sched";
}
"$data_video_smap" {
forwarding-class be scheduler "$data_sched";
forwarding-class af scheduler "$video_sched";
}
“$voice_smap” {
forwarding-class ef scheduler “$voice_sched”;
}
}
schedulers {
"$data_sched" {
transmit-rate "$junos-cos-scheduler-tx";
inactive: buffer-size percent "$junos-cos-scheduler-bs";
priority "$junos-cos-scheduler-pri";
}
"$video_sched" {
inactive: buffer-size percent "$junos-cos-scheduler-bs";
}
“$voice_sched” {
transmit-rate percent 10;
buffer-size remainder;;
priority low;
}
}
}
}
}
Related • Access Profiles and Service Profiles Overview

Documentation

Example: Providing Unique Rate Configurations for Schedulers in a Dynamic Profile
Combining static and dynamic schedulers in a dynamic profile enables you to provide
subscribers with services that have unique scheduler definitions.
In this example, the network administrator configures the data service with a transmit-rate
that is rate controlled using the $junos-cos-scheduler-tx predefined variable. RADIUS
dynamically supplies the percentage value for the transmission rate that is specified in
the RADIUS VSA to the data scheduler when the subscriber logs in.
For the best-effort service, the network administrator assigns the remaining transmission
rate that is available.
schedulers {
data-scheduler {
transmit-rate percent rate-limit $junos-cos-scheduler-tx;
buffer-size percent $junos-cos-scheduler-bs;
priority $junos-cos-scheduler-pri;
drop-profile-map loss-priority low protocol any drop-profile d0;
drop-profile-map loss-priority medium-low protocol any drop-profile d1;
drop-profile-map loss-priority medium-high protocol any drop-profile d2;
drop-profile-map loss-priority high protocol any drop-profile d3;
drop-profile-map loss-priority any protocol any drop-profile all;
}
best-effort-scheduler {
transmit-rate remainder;
priority medium-high;
drop-profile-map loss-priority low protocol any drop-profile
$junos-cos-scheduler-dropfile-low;
drop-profile-map loss-priority medium-high protocol any drop-profile
$junos-cos-scheduler-dropfile-medium-high;
drop-profile-map loss-priority any protocol any drop-profile
$junos-cos-scheduler-dropfile-any;
}
Related • Configuring a Combination of Static and Dynamic Scheduler Parameters in a Scheduler

Documentation Definition on page 16
Example: Configuring Aggregate Scheduling of Queues for Residential Subscribers on

Static IP Demux Interfaces
In this example, scheduling is configured for a residential subscriber. Each forwarding

class represents a multiplay service (voice, video, and data), and is equivalent to a queue.
An interface set of IP demux interfaces represents a DSLAM, and provides shaping of

subscribers services to a DSLAM aggregate rate.
[edit]
interfaces {

interface-set demux-set {
interface demux0 {
unit 0;
unit 1;
}
}
ge-2/0/1 {
vlan-tagging;
unit 1 {
per-session-scheduler;
vlan-id 1;
demux-source inet;
family inet {
address 4.4.4.4/24;
}
}
}
demux0 {
unit 0 {
demux-options {
underlying-interface ge-2/0/1.1;
}
family inet {
address 1.1.1.1/24;
demux-source {
1.1.1.0/24;
}
}
}
unit 1 {
demux-options {
}
family inet {
address 1.1.2.1/24;
demux-source {
1.1.2.0/24;
}
}
}
}
}
class-of-service {
T1 {
scheduler-map m1;
shaping-rate 5m;
}
T2 {
shaping-rate 60m;
}
}
interfaces {
interface-set demux-set {
output-traffic-control-profile T2;
}

demux0 {
unit 0 {
}
unit 1 {
}
}
}
scheduler-maps {
m1 {
forwarding-class best-effort scheduler s0;
forwarding-class expedited-forwarding scheduler s1;
forwarding-class assured-forwarding scheduler s2;
forwarding-class network-control scheduler s3;
}
}
schedulers {
s0 {
buffer-size percent 10;
}
s1 {
}
s2 {
}
s3 {
}
}
}
Verifying the Scheduling and Shaping Configuration for Subscriber Access

Purpose View the class-of-service (CoS) configurations that are referenced in a dynamic profile
Action • To display the entire CoS configuration, including static and dynamic parameters:
user@host> show class-of-service
• To display the CoS configuration for a subscriber interface:
user@host> show class-of-service interface
• To display traffic shaping and scheduling profiles:
user@host> show class-of-service traffic-control-profile
• To display the mapping of schedulers to forwarding classes and a summary of scheduler

parameters for each entry:
user@host> show class-of-service scheduler-map


CHAPTER 3
Managing Different Types of Service

Traffic for a Household Using Hierarchical
Scheduling
• Understanding Two-Level and Three-Level Hierarchical CoS for Subscriber

• Hardware Requirements for Dynamic Hierarchical CoS on page 31
• Configuring Hierarchical CoS for a Subscriber Interface of Aggregated Ethernet
Links on page 35
• Example: Configuring Hierarchical Scheduling for a Static PPPoE Subscriber
Interface on page 55
• Example: Configuring Hierarchical Scheduling for an Underlying Static PPPoE Subscriber
• Example: Configuring Hierarchical Scheduling for an Interface Set of Static PPPoE
Subscriber Interfaces on page 60
Understanding Two-Level and Three-Level Hierarchical CoS for Subscriber Interfaces
Hierarchical CoS enables you to apply traffic scheduling and queuing parameters and
packet transmission scheduling parameters to an individual subscriber interface rather
than to all interfaces configured on a port. Hierarchical CoS enables you to dynamically
modify queues when subscribers require services.
Hierarchical CoS is supported on MX Series routers with either EQ DPCs or MPC-Q/MICs

installed.
Interfaces support a four-level CoS scheduling hierarchy that, when fully configured,
consists of the physical interface (level 1), an interface set or underlying interface (level

2), one or more logical interfaces (level 3), and one or more queues (level 4). Although
all CoS scheduling hierarchies are four-level, level 1 is always the physical interface and
level 4 is always the queue. Hierarchical scheduling configurations consist of the type of
interfaces you configure; for example, a logical interface or an interface set and where
those interfaces reside in the scheduling hierarchy, either level 2 or level 3. Because many
hierarchical scheduling configurations are possible, we use the terms two-level hierarchical
scheduling and three-level hierarchical scheduling in this discussion.
Two-Level Hierarchical Scheduling

Two-level hierarchical scheduling limits the number of hierarchical levels in the scheduling
hierarchy to two (level 2 and level 3) as shown in Figure 1 on page 26. In this configuration,
interface sets are not configured and only the logical interfaces have traffic-control
profiles.
Figure 1: Two-Level Hierarchical Scheduling

Logical interface (unit) Interface set Physical interface
Level 3 Level 2 node
Level 3 Level 2 node Level 1 node
g017446
In a two-level scheduling hierarchy, all logical interfaces and interface sets share a single
level 2 node; no hierarchical relationship is formed.
You control two-level hierarchical scheduling by including the maximum-hierarchy-levels

option under the [edit interfaces interface-name hierarchical-scheduler] statement:
• When the maximum-hierarchy-levels option is not set, interface sets can be at either
level 2 or level 3, depending on whether the member logical interfaces within the
interface set have a traffic-control profile.
• If any member logical interface has a traffic-control profile, then the interface set is
always a level 2 CoS scheduler node.
• If no member logical interface has a traffic-control profile, the interface set is always
a level 3 CoS scheduler node.
• If the maximum-hierarchy-levels option is set, then the interface set can only be at level
3; it cannot be at level 2. In this case, if you configure a level 2 interface set, you generate
Packet Forwarding Engine errors.
Table 7 on page 27 summarizes the interface hierarchy and the CoS scheduler node levels
for two-level hierarchical scheduling.

Chapter 3: Managing Different Types of Service Traffic for a Household Using Hierarchical Scheduling

Scheduling Nodes
Level 1 Level 2 Level 3 Level 4
Physical interface – Logical interfaces One or more queues
Physical interface – Interface set One or more queues
Physical interface – Logical interfaces One or more queues
To configure two-level hierarchical scheduling, include the hierarchical-scheduler

statement at the [edit interfaces interface-name] hierarchy level. You can optionally
include the maximum-hierarchy-levels option. If you choose to set this option, the only
supported value is 2.
[edit interfaces]
xe-2/0/0 {
hierarchical-scheduler {
maximum-hierarchy-levels 2;
}
}
Three-Level Hierarchical Scheduling

Three-level hierarchical scheduling is supported only on MX Series routers running
MPC/MIC interfaces. Three-level hierarchical scheduling has up to eight class of service
queues. You can configure many different three-level scheduling hierarchies, depending
on the location of the interface set and the use of underlying interfaces. In all variations,
the physical interface is a level 1 CoS scheduler node and the queues reside at level 4.
NOTE: Three-level hierarchical scheduling is supported only on subscriber

interfaces and interface sets running over aggregated Ethernet interfaces on
MPC/MIC interfaces in MX Series routers.
When you use three-level hierarchical scheduling, interface sets can reside at either level
2 or level 3. You can also configure an underlying logic interface at level 2 and a logical
interface at level 3. Table 8 on page 27 summarizes the most common cases of the
interface hierarchy and the CoS scheduler node levels for three-level hierarchical
scheduling.
Table 8: Three-Level Hierarchical Scheduling–Interface Hierarchy Versus

CoS Scheduling Node Levels
Physical interface Interface set Logical interfaces One or more queues
Physical interface Logical interface Interface set One or more queues


CoS Scheduling Node Levels (continued)
Physical interface Underlying logical Logical interfaces One or more queues

interface
In three-level hierarchical scheduling, the CoS scheduler nodes at level 1, level 2, and
level 3 form a hierarchical relationship; this differs from two-level hierarchical scheduling
where no hierarchical relationship is formed.
With a three-level hierarchical scheduling, logical interfaces can reside at level 2, or they
can reside at level 3, if the logical interface at level 2 is an underlying logical interface.
This is shown in Figure 2 on page 28.
Figure 2: Three-Level Hierarchical Scheduling: Logical Interfaces at Level

3 with Underlying Logical Interfaces at Level 2
Logical interface Underlying logical interface Physical interface
(unit) (unit)
g041450
Level 3
Another possible configuration for three-level hierarchical scheduling is shown in

Figure 3 on page 28. In this configuration, the logical interfaces are located at level 2 and
the interface sets are located at level 3.
Figure 3: Three-Level Hierarchical Scheduling: Logical Interfaces at Level

2 with Interface Sets at Level 3
Interface set (unit) Logical interface (unit) Physical interface

g041449
Level 3

To configure three-level hierarchical scheduling, include the implicit-hierarchy option at

the [edit interfaces interface-name hierarchical-scheduler] hierarchy level.
[edit interfaces]
xe-2/0/0 {
hierarchical-scheduler {
implicit-hierarchy;
}
}
Interface Hierarchy Versus CoS Hierarchy
An interface hierarchy and a CoS scheduling hierarchy are distinctly different. Interface
hierarchy refers to the relationship between the various interfaces; for example, the
relationship between logical interfaces and an interface set, the relationship between a
logical interface and an underlying logical interface, or the relationship between the
physical interface and logical interface. CoS scheduling hierarchy refers to the hierarchical
relationship between the CoS scheduler nodes. In two-level hierarchical scheduling, no
hierarchy is formed between the CoS scheduler nodes; all logical interfaces and interface
sets share a single level 2 scheduler node. However, when you use the implicit-hierarchy
option for three-level hierarchical scheduling, the CoS scheduler nodes form a scheduling
hierarchy.
Figure 4 on page 29 and Figure 5 on page 30 provide two scenarios for this discussion.
Figure 4 on page 29 shows an interface hierarchy where a Gigabit Ethernet interface
(GE-1/0/0) is the physical interface. Two logical interfaces (GE-1/0/0.100 and
GE-1/0/0.101) are configured on the physical interface:
• Logical interface GE-1/0/0.100 is a member of a PPPoE interface set and a Demux

interface set.
• Logical interface GE-1/0/0.101 is a member of a demux interface set.
Figure 4: Logical Interfaces at Level 2 and Interface Sets at Level 3

PPPoE PPPoE DHCP
subscriber queues subscriber queues subscriber queues
L4
TCP TCP
Pppoe- Demux- Ppp-Demux-
Logical Interface Logical Interface Logical Interface Set Logical Interface Set
L3
Sets Set (home) (demux-and pppoe)
L2 Logical Interfaces TCP GE-1/0/0.100 GE-1/0/0.101 TCP
Physical Interface
g041435
L1 GE-1/0/0
of Logical Tunnel

Each interface set has a dedicated queue. The CoS scheduler nodes at level 1 (physical
interface), level 2 (underlying logical interfaces), and level 3 (interface sets) form a
scheduling hierarchy.
To configure this scenario, you must include the implicit-hierarchy option under the
hierarchical-scheduler statement on physical interface GE-1/0/0 and configure and apply
traffic-control profiles on each interface set and underlying logical interface.
Figure 5 on page 30 shows an interface hierarchy where Gigabit Ethernet interface

GE-1/0/0 is the physical interface. Three logical interfaces are configured:
• Two logical interfaces (Pp0.100 and Demux0.100) reside on the underlying logical
interface GE-1/0/0.100.
• A third logical interface (Pp0.101) resides on the underlying logical interface

GE-1/0/0.101.
Figure 5: Logical Interfaces at Level 3 and Underlying Logical Interfaces

at Level 2
PPPoE Demux DHCP
subscriber queues subscriber queues subscriber queues
L4
Demux0
L3 Logical Interfaces Pp0.100 TCP TCP Pp0.101
100
Underlying logical
L2 TCP GE-1/0/0.100 GE-1/0/0.101 TCP
interfaces
Physical Interface
g041436
L1 GE-1/0/0
of Logical Tunnel
Each logical interface has a dedicated queue. The CoS scheduler nodes at level 1 (physical
interface), level 2 (underlying logical interfaces), and level 3 (logical interfaces) form a
scheduling hierarchy.
To configure this scenario, you must include the implicit-hierarchy option under the
hierarchical-scheduler statement on physical interface GE-1/0/0 and configure and apply
traffic-control profiles on each logical interface and underlying logical interface.
You can configure many different three-level scheduling hierarchies; Figure 4 on page 29
and Figure 5 on page 30 present just two possible scenarios. Table 8 on page 27
summarizes the possible interface locations and CoS scheduler nodes.
Related • Hardware Requirements for Dynamic Hierarchical CoS on page 31

Documentation
• Configuring Hierarchical Schedulers for CoS

on page 35

• CoS Three-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber Interfaces

on page 66
• hierarchical-scheduler (Subscriber Interfaces on MX Series Routers) on page 573
Hardware Requirements for Dynamic Hierarchical CoS
Table 9 on page 31 lists the hardware requirements based on subscriber interface type
for hierarchical scheduling in dynamic CoS configurations.
Table 9: Hardware Required for Dynamic Hierarchical CoS Configurations

EQ DPCs on MX Series MPC Q/MIC Modules on MX
Dynamic CoS Configuration Subscriber Interface Type Routers Series Routers
Hierarchical CoS Static and dynamic VLANs Yes Yes
Static and dynamic VLANs Yes Yes

over aggregated Ethernet
Static or dynamic IP demux Yes Yes

interfaces
Static or dynamic IP demux Yes Yes

interfaces over aggregated
Ethernet
Static or dynamic VLAN No Yes

demux interfaces
Static or dynamic VLAN No Yes

demux interfaces over
aggregated Ethernet
Static PPPoE interfaces No Yes
Dynamic PPPoE interfaces No Yes
Static or dynamic PPPoE No Yes

interfaces over aggregated
Ethernet
L2TP LAC tunnel over PPP No Yes
L2TP LNS inline service over No Yes

PPP

Configuring Static Hierarchical Scheduling in a Dynamic Profile
You configure static scheduling and queuing in a dynamic profile for subscriber access.
To configure CoS in a dynamic profile for subscriber access using static scheduling and
queuing parameters:
1. Configure the static CoS parameters in the [edit class-of-service] hierarchy.
a. Enable the hierarchical scheduler for the interface.
See “Understanding Two-Level and Three-Level Hierarchical CoS for Subscriber

Interfaces” on page 25.
b. Configure the scheduler map and schedulers.
When you configure static scheduling and queuing in a dynamic profile, you
reference the scheduler map in the dynamic profile.
See Configuring Schedulers.
c. Configure the drop profiles.
See Configuring RED Drop Profiles.
d. Configure the forwarding classes.
See Configuring Forwarding Classes.
e. Configure the rewrite-rules and classifier definitions.
See Configuring Rewrite Rules and Defining Classifiers.
See Junos OS CoS Components for information about configuring the remaining CoS
parameters.
2. Configure a static or dynamic subscriber interface that can be referenced in the

dynamic profile.
3. Configure CoS parameters in a dynamic profile.
a. Configure the dynamic profile.
b. Configure traffic shaping and scheduling parameters in the dynamic profile using
a traffic-control profile. Reference the scheduler map you configured in the static
[edit class-of-service] hierarchy.
See “Configuring Static Traffic Shaping and Scheduling Parameters in a Dynamic

Profile” on page 11.
c. Apply CoS parameters to a subscriber interface by referencing an interface in the

dynamic profile.

See “Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic

4. To configure default values for subscribers on login, and enable subscribers to replace
other CoS parameters when replacing services, configure variables in the dynamic
profile.
See “Configuring Static Default Values for Traffic Scheduling and Shaping” on page 170.
Related • Guidelines for Configuring Dynamic CoS for Subscriber Access on page 4
Documentation

Configuring Dynamic Hierarchical Scheduling in a Dynamic Profile
To configure dynamic scheduling or subscriber access using dynamic scheduling and

queuing parameters:
a. Enable the hierarchical scheduler for the interface.
See “Understanding Two-Level and Three-Level Hierarchical CoS for Subscriber

Interfaces” on page 25 and hierarchical-scheduler.
b. Configure the drop profiles.
c. Configure the forwarding classes.
d. Configure the rewrite-rules and classifier definitions.
parameters.

dynamic profile.
a traffic-control profile.
See “Configuring Traffic Scheduling and Shaping for Subscriber Access” on page 11.

c. Configure the schedulers and scheduler map in the dynamic profile.
You can configure the schedulers using dynamic variables or a combination of both
static values and dynamic variables.
See “Configuring Schedulers in a Dynamic Profile for Subscriber Access” on page 13.
d. Apply CoS parameters to a subscriber interface by referencing an interface in the

dynamic profile.
• For traffic shaping and scheduling, see “Applying Traffic Shaping and Scheduling
to a Subscriber Interface in a Dynamic Profile” on page 217.
• For rewrite-rules, see “Applying a Rewrite Rule Definition to a Subscriber Interface

in a Dynamic Profile” on page 219.
• For classifiers, see “Applying a Classifier to a Subscriber Interface in a Dynamic

4. (Optional) Configure variables in access and service profiles to enable RADIUS to

activate subscriber and upgrade services through CoA.
NOTE: Do not instantiate a CoA request using a service dynamic profile

that is already in use on the same logical interface.
a. Configure user-defined CoS variables in a dynamic profile.
See “Configuring Static Default Values for Traffic Scheduling and Shaping” on
page 170
b. (Optional) Enable multiple clients for the same subscriber (logical interface) to
aggregate attributes by configuring the aggregate-clients option for the dynamic
profile attached to a DHCP subscriber interface.
See Attaching Dynamic Profiles to DHCP Subscriber Interfaces or DHCP Client

Interfaces.
Because you have configured the scheduler map in the dynamic profile, queues
are merged when subscribers change services. Other CoS parameters are replaced.
When multiple subscribers are enabled on a DHCP subscriber interface, and the
dynamic profile referenced by DHCP does not have the replace keyword configured,
the system does not replace the parameters. Instead, it combines the values of
the parameters to their maximum scalar value.

Configuring Hierarchical CoS for a Subscriber Interface of Aggregated Ethernet Links
You can enable hierarchical CoS on a subscriber interface with an underlying aggregated
Ethernet interface.
Before you begin, configure the subscriber interface with aggregated Ethernet.
• To configure a VLAN interface over aggregated Ethernet with link protection, see
Configuring a Static or Dynamic VLAN Subscriber Interface over Aggregated Ethernet
and Configuring Link Protection for Aggregated Ethernet Interfaces.
• To configure a demux subscriber interface:
For static and dynamic IP demux interfaces, see Configuring a Static or Dynamic IP
Demux Subscriber Interface over Aggregated Ethernet.
For static and dynamic VLAN demux interfaces, see Configuring a Static or Dynamic
VLAN Demux Subscriber Interface over Aggregated Ethernet.
BEST PRACTICE: Link protection is not required for IP or demux subscriber

interfaces. We recommend that you enable targeted distribution on the
demux interface to provide accurate hierarchical scheduling for these links.
See “Providing Accurate Scheduling for a Demux Subscriber Interface of
Aggregated Ethernet Links” on page 144.
To configure hierarchical CoS on the link aggregation (LAG) bundle:
1. Specify that you want to access the LAG bundle.
user@host# edit interfaces aex
2. Configure the link aggregation (LAG) bundle with hierarchical scheduler mode.
[edit interfaces aex]

user@host# set hierarchical-scheduler
You can then attach static or dynamic traffic shaping and scheduling parameters at the
aggregated Ethernet logical interface or its underlying physical interface. See:
• Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic Profile

on page 217
Documentation

on page 25

Configuring Hierarchical CoS on a Static PPPoE Subscriber Interface
You can configure hierarchical CoS on a static PPPoE subscriber interface.
Before you begin:
• Configure the static PPPoE subscriber interface.
See Configuring PPPoE.
To configure hierarchical CoS on a static PPPoE subscriber interface:
1. Specify the PPPoE interface that you want to configure.
user@host# edit interfaces pppoe-interface-name
2. Configure the hierarchical scheduler for the interface.
[edit interfaces interface-name]

3. (Optional) Group the PPPoE interfaces in an interface set.
[edit]
user@host# edit interfaces interface-set interface-set-name
You can now configure static traffic and scheduling parameters for each traffic-control
profile, and attach each traffic-control profile to the PPPoE interface or the PPPoE
interface set. For more information, see Using the CLI to Modify Traffic-Control Profiles
That Are Currently Applied to Subscribers.
• CoS for PPPoE Subscriber Interfaces Overview on page 9
• Example: Configuring Hierarchical Scheduling for a Static PPPoE Subscriber Interface

on page 55
• Example: Configuring Hierarchical Scheduling for an Underlying Static PPPoE Subscriber

• Example: Configuring Hierarchical Scheduling for an Interface Set of Static PPPoE

Subscriber Interfaces on page 60

on page 25

Example: Maintaining a Constant Traffic Flow by Configuring a Static VLAN Interface

with a Dynamic Profile for Subscriber Access
This example shows how to configure a static VLAN interface with a dynamic profile
using static schedulers and CoS parameters for subscriber access to maintain a constant
traffic flow. The CoS parameters configure a best-effort data service for subscribers.
• Requirements on page 37
• Overview on page 37
• Configuration on page 38
• Verification on page 47
Requirements
Before you begin, be sure that your environment meets the following requirements:
• The interface is hosted on an MX Series router.
• For hierarchical scheduling configurations, hierarchical scheduling is enabled in the

static CLI for the interface referenced in the dynamic profile. If not, the dynamic profile
fails.
• Only one traffic-control-profile is configured under a dynamic profile.
• The output-traffic-control-profile that binds the traffic-control profile to the interface

is defined within the same dynamic profile as the interface.
Overview
In a dynamic profile, you can configure VLAN subscriber interfaces over the following
statically created logical interface types:
• GE—Gigabit Ethernet
• XE—10-Gigabit Ethernet
• AE—Aggregated Ethernet
Topology
We recommend that you configure each subscriber on a statically created VLAN.
Figure 6 on page 38 shows an example of subscriber interfaces on an individual VLAN.

Figure 6: VLAN Subscriber Interfaces
You can further separate VLANs on subscriber interfaces by configuring a VLAN interface
as the underlying interface for a set of IP demux interfaces.
Configuration
To configure a static VLAN interface with a dynamic profile for subscriber access, perform
these tasks:
• Configuring a Subscriber Interface with a Static VLAN on page 39

• Associating the Dynamic Profile with a Statically Created Interface on page 40
• Configuring the Firewall Filter on page 41
• Configuring Static Schedulers in a Dynamic Profile on page 43
• Associating the Scheduler with a Scheduler Map on page 44
• Configuring and Applying Static Traffic Shaping and Scheduling Parameters in a
Dynamic Profile on page 45
CLI Quick To quickly configure this example, copy the following configuration commands into a
Configuration text file, remove any line breaks, and then paste the commands into the CLI at the [edit]
hierarchy level.
set interfaces ge-2/2/0

set interfaces ge-2/2/0 hierarchical-scheduler
set interfaces ge-2/2/0 vlan-tagging
set interfaces ge-2/2/0 vlan-tagging unit 100 vlan-id 100
set interfaces ge-2/2/0 vlan-tagging unit 100 vlan-id 100 family inet
set interfaces ge-2/2/0 vlan-tagging unit 100 vlan-id 100 family inet unnumbered-address
lo0.0 preferred-source-address 100.0.0.1
set dynamic-profiles data-service
set dynamic-profiles data-service interfaces $junos-interface-ifd-name
set dynamic-profiles data-service interfaces $junos-interface-ifd-name unit
$junos-underlying-interface-unit
set dynamic-profiles data-service interfaces $junos-interface-ifd-name unit
$junos-underlying-interface-unit family inet
set dynamic-profiles data-service firewall family inet filter filter EF_limit_G=768K
set dynamic-profiles data-service firewall family inet filter filter EF_limit_G=768K term
EF
default
EF from forwarding-class EF
EF then policer POL_EF_G=768K

default then accept
set dynamic-profiles data-service class-of-service schedulers be-scheduler
set dynamic-profiles data-service class-of-service schedulers be-scheduler buffer-size
remainder
drop-profile-map loss-priority any protocol any
drop-profile-map loss-priority any protocol any drop-profile drop3
set dynamic-profiles data-service class-of-service schedulers be-scheduler priority low
user@host# set dynamic-profiles data-service class-of-service schedulers be-scheduler
transmit-rate percent 40
set dynamic-profiles data-service class-of-service schedulers be-scheduler excess-rate
percent 90
set dynamic-profiles data-service class-of-service schedulers be-scheduler excess-priority
high
set dynamic-profiles data-service class-of-service scheduler-maps data-service-map
forwarding-class best-effort
forwarding-class best-effort scheduler be-scheduler
set dynamic-profiles data-service class-of-service traffic-control-profiles tcp-data-service
scheduler-map data-service-map
shaping-rate 50k
guaranteed-rate 10k
delay-buffer-rate 10k
set dynamic-profiles data-service class-of-service interfaces $junos-interface-ifd-name
unit $junos-underlying-interface-unit output-traffic-control-profile tcp-data-service
Configuring a Subscriber Interface with a Static VLAN
Step-by-Step After you configure a static VLAN interface, you can reference it in a dynamic profile.
Procedure
1. Configure the static VLAN interface.
[edit]
user@host# set interfaces ge-2/2/0
2. Enable hierarchical scheduling for the interface.
[edit interfaces ge-2/2/0]

3. Enable VLAN tagging.

user@host# set vlan-tagging
4. Configure the unit and assign a VLAN ID.
[edit interfaces ge-2/2/0 vlan-tagging]

user@host# set unit 100 vlan-id 100
5. Define the family address type (inet for IPv4) for the VLAN interface.

[edit interfaces ge-2/2/0 vlan-tagging unit 100 vlan-id 100]

user@host# set family inet
6. Enable the physical interface to borrow an IP address from the loopback interface
by setting an unnumbered interface address. Configure a secondary IP address on
the loopback interface, lo0.0, and configure it as the preferred source address.
[edit interfaces ge-2/2/0 vlan-tagging unit 100 vlan-id 100 family inet]
user@host# set unnumbered-address lo0.0 preferred-source-address 100.0.0.1
Results Confirm the configuration of the static VLAN interface by entering the show interfaces
configuration command. If the command output does not display the intended
configuration, repeat the instructions in this procedure to correct the configuration.
[edit]
user@host# show interfaces
interfaces {
ge-2/2/0 {
hierarchical-scheduler;
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
unnumbered-address lo0.0 preferred-source-address 100.0.0.1;
}
}
}
}
Associating the Dynamic Profile with a Statically Created Interface
Step-by-Step A dynamic profile is a set of characteristics, defined in a type of template, that you can
Procedure use to provide dynamic subscriber access and services for broadband applications. When
configuring the interface at the [dynamic-profiles profile-name interfaces] hierarchy level
for a dynamic profile, you use variables to specify the interface name and the logical unit
value. When a DHCP subscriber sends a DHCP request to the interface, the dynamic
profile replaces the interface name variable and logical unit name variable with the actual
interface name and logical unit number of the interface that received the DHCP request.
NOTE: Configuration of the interface name variable and logical interface

name variable at the [edit dynamic-profiles profile-name interfaces] hierarchy
level is required for a dynamic profile to function.
1. Create the new dynamic profile for data services for subscribers.
[edit]
user@host# set dynamic-profiles data-service
2. Define the interface-name variable statement with the internal

$junos-interface-ifd-name variable used by the router to match the interface name
of the receiving interface.

[edit dynamic-profiles data-service]

user@host# set interfaces $junos-interface-ifd-name
3. Define the unit statement with the internal variable.
• When referencing an existing interface, specify the

$junos-underlying-interface-unit variable used by the router to match the unit
value of the receiving interface.
• When creating dynamic interfaces, specify the $junos-interface-unit variable

used by the router to generate a unit value for the interface.
[edit dynamic-profiles data-service interfaces $junos-interface-ifd-name]

user@host# set unit $junos-underlying-interface-unit
or
[edit dynamic-profiles data-service interfaces $junos-interface-ifd-name]

user@host# set unit $junos-interface-unit
4. Define the family address type (inet for IPv4) for the $junos-interface-unit variable.
[edit dynamic-profiles data-service interfaces $junos-interface-ifd-name unit

$junos-underlying-interface-unit]
Results Confirm the configuration of the dynamic profile by entering the show dynamic-profiles
[edit]
user@host# show dynamic-profiles
dynamic-profiles {
data-service {
interfaces {
$junos-interface-ifd-name {
unit $junos-underlying-interface-unit {
family inet;
}
}
}
}
}
Configuring the Firewall Filter
Step-by-Step To configure a static VLAN interface with a dynamic profile for subscriber access, you
Procedure can configure a firewall filter to provide enhanced security by blocking packets based on
various match criteria, such as subjecting traffic to a policer for rate limiting, assigning
the traffic to a class-of-service (CoS) forwarding class for later queuing and packet
rewrite operations, or directing traffic to a specific routing instance.
1. Configure the family address type (inet for IPv4) for the firewall filter and specify
the filter name.
We recommend that you name the filter something that indicates the filter’s purpose.
In this example, we use the bandwidth limit settings.

[edit dynamic-profiles data-service]

user@host# set firewall family inet filter EF_limit_G=768K
2. Specify the term names for the filter. Make each term name unique and represent
what its function is. The first term matches traffic that has been classified into the
Expedited Forwarding (EF) class, and the second term matches all non-EF traffic.
[edit dynamic-profiles data-service firewall family inet filter EF_limit_G=768K]

user@host# set term EF
user@host# set term default
3. In each firewall filter term, specify the conditions used to match components of a
packet. Configure the first term to match all traffic classified as EF class.
[edit dynamic-profiles data-service firewall family inet filter EF_limit_G=768K term

EF]
user@host# set from forwarding-class EF
4. Specify the actions to take when the packet matches the condition in the first term.
Send the EF traffic to the policer named POL_EF_G=768K.

EF]
user@host# set then policer POL_EF_G=768K
5. Specify the action to take when the packet matches the condition in the second
term. All non-EF packet traffic is accepted.

default]
user@host# set then accept
Results Confirm the configuration by entering the show dynamic-profiles data-service firewall
[edit]
user@host# show dynamic-profiles data-service firewall
family inet {
filter EF_limit_G=768K {
term EF {
from {
forwarding-class EF;
}
then policer POL_EF_G=768K;
}
term default {
then accept;
}
}
}

Configuring Static Schedulers in a Dynamic Profile
Step-by-Step You can configure static scheduling and queuing parameters in a dynamic profile for
Procedure subscriber access. Schedulers are part of the basic class-of-service (CoS) infrastructure.
You must define at least one scheduler per forwarding class. Schedulers indicate a
forwarding class’s priority, transmit weight, and buffer size, as well as various shaping
and rate control mechanisms.
1. Specify the best-effort scheduler for which you want to configure parameters.
[edit dynamic-profiles data-service class-of-service]

user@host# set schedulers be-scheduler
NOTE: Set schedulers to the name of the scheduler to be configured or

to the Junos OS predefined variable ($junos-cos-scheduler) used for
dynamic subscriber interfaces. The predefined variable is replaced with
the scheduler name obtained from the RADIUS server when a subscriber
authenticates over the interface to which the dynamic profile is attached.
2. (Optional) Configure the buffer size to use the remaining buffer available.
This parameter allows you to specify an explicit buffer size, either as a percent of
interface speed or as a function of time (specified in microseconds).
[edit dynamic-profiles data-service class-of-service schedulers be-scheduler]

3. (Optional) Configure the drop-profile map to associate one or more drop profiles
with a queue.
The default random early detection (RED) drop profile is used when no explicit drop
profile mapping is specified. Specify a packet-loss priority (PLP) level of any, and
for the specified scheduler to accept any protocol type.

user@host# set drop-profile-map loss-priority any protocol any
4. (Optional) Configure the drop profile to map a fill level (fullness of a queue) to a
drop probability (probability that a packet is dropped).
[edit dynamic-profiles data-service class-of-service schedulers be-scheduler

drop-profile-map loss-priority any protocol any]
user@host# set drop-profile drop3
You enable RED by applying a drop profile to a scheduler.
5. (Optional) Configure the queue’s scheduler priority to a specific level (low) for
guaranteed rate traffic.

6. (Optional) Configure the queue’s transmit weight [in bits per second (bps)] or as
a percentage of transmission capacity.


The transmit rate guarantees the rate for the queue, assuming no priority-based
starvation occurs. When you do not specify a transmit weight, or when the transmit
rate is reached, the queue can only send excess-rate traffic because that queue’s
priority is demoted to the excess region. A percentage of zero (0) drops all packets
in the queue.
7. (Optional) Configure the queue’s weight as either a percentage, or a proportion, for

any unused bandwidth traffic to share.

Behavior varies based on interface mode, explicit configuration, and whether any
other queues have explicit weight configured. By default, excess bandwidth between
the guaranteed and shaped rate is shared equally among queues.
8. (Optional) Configure the priority of how excess bandwidth traffic is sent on a

scheduler in a dynamic profile.

To prevent the queue from sending any excess rate traffic, set to none.
Results Confirm the configuration of the scheduler with static values in the dynamic profile by
entering the show dynamic-profiles data-service class-of-service configuration command.
If the command output does not display the intended configuration, repeat the instructions
in this procedure to correct the configuration.
[edit]
user@host# show dynamic-profiles data-service class-of-service
class-of-service {
schedulers {
be-scheduler {
buffer-size remainder;
drop-profile-map loss-priority any protocol any drop-profile drop3;
priority low;
excess-rate percent 90;
excess-priority high;
}
}
}
Associating the Scheduler with a Scheduler Map
Step-by-Step After you define your schedulers, you must link them to a set of queues on a logical
Procedure interface using a scheduler map. Applying a scheduler map to an interface places the
related set of schedulers and drop profiles into effect.
1. Configure the scheduler map name.

user@host# set scheduler-maps data-service-map
2. Configure a forwarding class to associate a scheduler with a scheduler map.
[edit dynamic-profiles data-service class-of-service scheduler-maps

data-service-map]
user@host# set forwarding-class best-effort
3. Associate the scheduler you previously defined (be-scheduler) with the scheduler
map.
[edit dynamic-profiles data-service class-of-service scheduler-maps

data-service-map forwarding-class best-effort]
user@host# set scheduler be-scheduler
Results Confirm the configuration of the scheduler map by entering the show dynamic-profiles
data-service class-of-service scheduler-maps configuration command. If the command
output does not display the intended configuration, repeat the instructions in this
procedure to correct the configuration.
[edit]
user@host# show dynamic-profiles data-service class-of-service scheduler-maps
scheduler-maps {
data-service-map {
forwarding-class best-effort scheduler be-scheduler;
}
}
Configuring and Applying Static Traffic Shaping and Scheduling Parameters in a

Dynamic Profile
Step-by-Step Configure static traffic shaping and scheduling parameters in a traffic-control profile. A
Procedure traffic-control profile is a generic class-of-service (CoS) container that you can apply at
all points of a CoS hierarchy to affect the committed information rate (CIR), peak
information rate (PIR), and excess bandwidth handling. You can specify the traffic-control
profile at the port, logical interface, or logical interface-set level. The traffic-control profile
also references the scheduler map.
1. Create the traffic-control profile and assign it a name.

user@host# edit traffic-control-profiles tcp-data-service
2. Apply the static scheduler map, data-service-map, that you previously configured.
[edit dynamic-profiles data-service class-of-service traffic-control-profiles

tcp-data-service]
user@host# set scheduler-map data-service-map
3. Configure the shaping rate [in bits per second (bps)] to use for the scheduler in the
dynamic profile.

tcp-data-service]
user@host# set shaping-rate 50k

The shaping rate places a maximum limit on a queue’s transmit capacity. By default,
the shaping rate is equal to the interface speed/shaping rate enabling the queue
to send a the full rate of the interface.
4. Configure the guaranteed rate [in bits per second (bps)] to use for the scheduler
in the dynamic profile.

tcp-data-service]
user@host# set guaranteed-rate 10k
The guaranteed rate is the minimum bandwidth the queue can receive; if excess
physical interface bandwidth is available for use, the logical interface can receive
more than the guaranteed rate provisioned for the interface, depending on how you
choose to manage excess bandwidth and the interface’s mode of PIR compared
to CIR/PIR.
5. Configure the delay-buffer rate [in bits per second (bps)] based on the delay-buffer
calculation.

tcp-data-service]
user@host# set delay-buffer-rate 10k
The delay buffer rate setting at one level of the hierarchy becomes the reference
bandwidth used at the next higher level, and the sum of the reference bandwidth
cannot exceed the value used at a lower level. If you do not include this statement,
the delay-buffer rate is based on the guaranteed rate if one is configured, or on the
shaping rate if no guaranteed rate is configured.
6. After you configure the traffic shaping and scheduling CoS parameters in a dynamic
profile, you apply them to an interface. The output traffic-control profile enables
you to provide traffic scheduling to the interface.
Configure the interface name and logical interface using a variable, and apply the
output traffic-control profile to the interface. Specify the previously defined
traffic-control profile, tcp-data-service.

user@host# set interfaces $junos-interface-ifd-name unit
$junos-underlying-interface-unit output-traffic-control-profile tcp-data-service
Results Confirm the configuration and application of the static traffic shaping and scheduling
parameters by entering the show dynamic-profiles configuration command. If the
command output does not display the intended configuration, repeat the instructions in
this procedure to correct the configuration.
[edit]
dynamic-profiles {
data-service {
class-of-service {
interfaces {
output-traffic-control-profile tcp-data-service;

}
}
}
tcp-data-service {
scheduler-map data-service-map;
shaping-rate 50k;
guaranteed-rate 10k;
delay-buffer-rate 10k;
}
}
}
}
}
Verification
Confirm that the configuration is working properly.
• Verifying Traffic Shaping and Scheduling Profiles for Subscriber Access on page 47
• Verifying the Mapping of Schedulers for Subscriber Access on page 47
Verifying Traffic Shaping and Scheduling Profiles for Subscriber Access
Purpose View the class-of-service (CoS) configurations that are referenced in a dynamic profile
Action user@host> show class-of-service traffic-control-profile

Traffic control profile: tcp-data-service, Index: 57625
Shaping rate: 50000
Scheduler map: data-service-map
Delay Buffer rate: 10000
Guaranteed rate: 10000
Meaning The Shaping rate, Delay Buffer rate, and Guaranteed rate fields indicate rates of 50,000
bps, 10,000 bps, and 10,000 bps, respectively, for the traffic-control profile.
Verifying the Mapping of Schedulers for Subscriber Access
Purpose Display the mapping of schedulers to forwarding classes and a summary of scheduler
parameters for each entry.

Action user@host> show class-of-service scheduler-map

Scheduler map: data-service-map, Index: 84
Scheduler: be-scheduler, Index: 8721, Forwarding class: best-effort

Transmit rate: 40 percent, Rate Limit: none, Maximum buffer delay: 39 ms,
Priority: low
Drop profiles:
Loss priority Protocol Index Name
Any Any 8724 drop3
Meaning The Scheduler map field indicates the parameters are for the best-effort scheduler. The
Transmit rate field shows 40 percent; the Rate Limit field indicates no limit; and the Drop
profiles fields are for drop3.

Documentation

on page 25
Example: Configuring Dynamic Hierarchical Scheduling for Subscribers
In this example, subscribers are provided with a data and voice service defined in an
access profile when they initially log in. The RADIUS administrator supplies the initial
values on the RADIUS server, and the service activation is performed at subscriber login.
After the initial login, the subscriber adds an assured forwarding service that is not defined
in the original access profile. A service profile is used to configure the schedulers and a
RADIUS CoA activates the service. The queues defined for the schedulers in the initial
scheduler map and the new scheduler map are merged.
In addition, the values for the initial data and voice service are upgraded by the RADIUS
administrator through a separate RADIUS CoA message.
To configure the initial service and enable the activation through a RADIUS CoA:
1. Configure the access profile for the service activation.
a. Configure the VLAN interface for the access profile.
[edit]
dynamic-profiles access-profile {
interfaces {
family inet;
}
}
}
}

b. Configure the class of service parameters in the access profile. In this example,
you configure Junos OS predefined variables that provide the initial scheduler name
and scheduler parameters obtained from the RADIUS authentication server when
the subscriber logs in.
Include the configurations for the interfaces, schedulers, and the scheduler maps.
[edit]
dynamic-profiles access-profile {
class-of-service {
tcp1 {
scheduler-map $junos-cos-scheduler-map;
shaping-rate $junos-cos-shaping-rate;
guaranteed-rate $junos-cos-guaranteed-rate;
delay-buffer-rate $junos-cos-delay-buffer-rate;
}
}
interfaces {
classifiers {
ieee-802.1 l2_classifier;
}
rewrite-rules {
ieee-802.1 l2_rewrite;
}
}
}
}
schedulers {
$junos-cos-scheduler {
priority $junos-cos-scheduler-pri;
transmit-rate percent $junos-cos-scheduler-tx;
drop-profile-map loss-priority low protocol any $junos-cos-scheduler-low;
drop-profile-map loss-priority medium-low protocol any
$junos-cos-scheduler-medium-low;
drop-profile-map loss-priority medium-high protocol any
$junos-cos-scheduler-medium-high;
drop-profile-map loss-priority high protocol any $junos-cos-scheduler-high;
}
}
scheduler-maps {
data_voice_smap {
forwarding-class be scheduler be_sch;
forwarding-class ef scheduler ef_sch;
}
}
}
}
Table 10 on page 50 lists the initial values defined by the RADIUS administrator for
the scheduler map and shaping rates.

Table 10: Initial Scheduler Map and Shaping Values at Subscriber Login
Predefined Variable RADIUS Tag Value
$junos-cos-scheduler-map T01 data_voice_smap
$junos-cos-shaping-rate T02 6m
$junos-cos-guaranteed-rate T03 4m
$junos-cos-delay-buffer-rate T04 4m
the voice (expedited forwarding) scheduler.
Table 11: Initial CoS Values for the Voice Scheduler at Subscriber Login
Predefined Variable Tag Value
$junos-cos-scheduler — ef_sch
$junos-cos-scheduler-tx T01 10
$junos-cos-scheduler-bs T02 10
$junos-cos-scheduler-pri T03 medium-high
$junos-cos-scheduler-dropfile-low T04 d3
$junos-cos-scheduler-dropfile-medium-low T05 d2
$junos-cos-scheduler-dropfile-medium-high T06 d1
$junos-cos-scheduler-dropfile-high T07 d0
the data (best effort) scheduler.
Table 12: Initial CoS Values for the Data Scheduler at Subscriber Login
$junos-cos-scheduler — be_sch
$junos-cos-scheduler-pri T03 low

Table 12: Initial CoS Values for the Data Scheduler at Subscriber
Login (continued)
2. Configure the classifiers, drop profiles, forwarding classes, and rewrite rules in the
static [edit class-of-service] hierarchy.
[edit]
class-of-service {
classifiers {
dscp dscp_classifier {
forwarding-class be {
loss-priority low code-points 000000;
}
forwarding-class af {
loss-priority medium-low code-points 000001;
}
}
ieee-802.1 l2_classifier {
}
forwarding-class ef {
}
}
}
}
drop-profiles {
d0 {
fill-level 25 drop-probability 100;
}
d1 {
}
d2 {
}
d3 {
}

}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
interfaces {
ge-1/2/9 {
shaping-rate 100m;
}
}
rewrite-rules {
ieee-802.1 l2_rewrite {
loss-priority medium-low code-point 000;
}
}
}
dscp l2_rewrite {
}
}
}
}
}
3. Configure the service profile enable RADIUS to activate the video service after login.
The video service corresponds to assured forwarding PHB.
In this example, you configure Junos OS predefined variables that provide the initial
scheduler name and scheduler parameters obtained from the RADIUS authentication
server when the subscriber logs in.
[edit]
dynamic-profiles service-af {
variables {
af_fc default-value video;
af_sch default-value af_sch;
sch-drop-any default-value all;
sch-pri-2 default-value strict-high;
sch-bs-2 default-value 40;
sch-tx-2 default-value 3m;
smap default-value any
}
class-of-service {
scheduler-maps {

"$smap" {
forwarding-class “$af_fc” scheduler “$af_sch”;
}
}
schedulers {
"$af_sch" {
transmit-rate percent "$sch-tx-2";
buffer-size percent "$sch-bs-2";
priority "$sch-pri-2";
drop-profile-map loss-priority any protocol any drop-profile “$sch-drop-any”;
}
}
}
}
After the three services are activated, subscribers receive upgraded values for the data
and voice service when RADIUS sends a change of authorization (CoA). In this case, the
CoS parameters are replaced, because multiple subscribers were not enabled on the
logical interface.
Table 13 on page 53 lists the upgraded values defined by the RADIUS administrator.
Table 13: Upgraded CoS Values for the Video Service

Variable RADIUS Tag Value
junos-cos-scheduler-map T01 data_voice_smap
junos-cos-shaping-rate T02 14m
junos-cos-guaranteed-rate T03 13m
junos-cos-delay-buffer-rate T04 12m
Table 14 on page 53 lists the values defined by the RADIUS administrator for the video
(assured forwarding) scheduler.
Table 14: Upgraded CoS Values for the Video Scheduler

$junos-cos-scheduler — af_sch
$junos-cos-scheduler-pri T03 medium

Table 14: Upgraded CoS Values for the Video Scheduler (continued)
Table 15 on page 54 lists the values defined by the RADIUS administrator for the expedited
forwarding scheduler in the CoA message. The values are the same as the initial service.
Table 15: Initial CoS Values for the Expedited Forwarding Scheduler at
Subscriber Login
$junos-cos-scheduler — ef_sch
$junos-cos-scheduler-pri T03 medium-high
Table 16 on page 54 lists the values defined by the RADIUS administrator for the best
effort scheduler in the CoA message. The values are the same as the initial service.
Table 16: Initial CoS Values for the Best Effort Scheduler at Subscriber
Login
$junos-cos-scheduler — be_sch
$junos-cos-scheduler-pri T03 low

Table 16: Initial CoS Values for the Best Effort Scheduler at Subscriber
Login (continued)
Related • Changing CoS Services Overview on page 163

Documentation

on page 25
Example: Configuring Hierarchical Scheduling for a Static PPPoE Subscriber Interface
In this example, the network administrator defines hierarchical queuing and scheduler
parameters by configuring traffic-control profile and binding it directly to a PPPoE
subscriber interface.
This configuration is supported on the IQ2E PIC.
To use this configuration in a broadband access network, each forwarding class can
represent one type of services provided to a household customer and is mapped to a
queue. Each PPPoE interface represents a household and provides shaping of all
household traffic to an aggregate rate. All of the PPPoE interfaces on the physical
interfaces are shaped to the underlying physical interface rate.
Table 17 on page 55 lists the scheduler and queue mapping for this configuration.
Table 17: Scheduler per Logical Interface Mapping

Level Type Mapping
4 Queue PPPoE interface
3 Scheduler PPPoE interface
2 Scheduler —
1 Scheduler Underlying physical interface
interfaces {
ge-3/0/3 {
vlan-tagging;
unit 0 {
encapsulation ppp-over-ether;
vlan-id 100;
}

}
pp0 {
unit 0 {
pppoe-options {
server;
}
family inet {
address 120.20.20.20/32 {
destination 120.20.20.21;
}
}
}
unit 1 {
pppoe-options {
server;
}
family inet {
address 130.30.30.30/32 {
}
}
}
unit 2 {
pppoe-options {
server;
}
family inet {
address 140.40.40.40/32 {
}
}
}
}
}
class-of-service {
tcp {
scheduler-map data_smap;
shaping-rate 50k;
}
}
interfaces {
pp0 {
unit 0 {
output-traffic-control-profile tcp;
}
unit 1 {
unit 2 {
}
}

}
queue 0 be;
queue 1 ef;
queue 3 nc;
queue 2 af;
}
scheduler-maps {
data_smap {
}
voice_data_smap {
}
vid_data_smap {
}
}
schedulers {
be_sch {
priority low;
}
ef_sch {
priority low;
}
af_sch {
priority low;
}
nc_sch {
priority low;
}
}
Related • CoS for PPPoE Subscriber Interfaces Overview on page 9

Documentation
Example: Configuring Hierarchical Scheduling for an Underlying Static PPPoE Subscriber

Interface
In this example, the network administrator defines hierarchical queues and scheduler
parameters by configuring a traffic-control profile and binding it directly to a PPPoE
subscriber interface. The network administrator then configures the traffic-control profile
on the underlying interface where a group of PPPoE interfaces reside.

To use this configuration in a broadband access network, each forwarding class represents
one type of services provided to a household customer and is mapped to a queue. Each
PPPoE interface represents a household and provides shaping of all household traffic
to an aggregate rate. The underlying logical interface where a group of PPPoE interfaces
resides represents a DSLAM and provides shaping to the DSLAM rate.
Table 18: Scheduler per Underlying Interface Mapping

Level Type Mapping
2 Scheduler Underlying logical interface
1 Scheduler Underlying interface
interfaces {
ge-3/0/3 {
vlan-tagging;
unit 0 {
vlan-id 100;
}
unit 1 {
vlan-id 101;
}
}
pp0 {
unit 0 {
pppoe-options {
server;
}
family inet {
address 120.20.20.20/32 {
}
}
}
unit 1 {
pppoe-options {
server;
}
family inet {
address 130.30.30.30/32 {
}

}
}
unit 2 {
pppoe-options {
server;
}
family inet {
address 140.40.40.40/32 {
}
}
}
}
}
class-of-service {
tcp1 {
shaping-rate 50k;
}
tcp2 {
shaping-rate 50m;
}
}
interfaces {
pp0 {
unit 0 {
}
unit 1 {
}
unit 2 {
}
}
ge-3/0/3 {
unit 0 {
}
}
}
...
}

Documentation

on page 25

Example: Configuring Hierarchical Scheduling for an Interface Set of Static PPPoE

Subscriber Interfaces
In this example, the network administrator defines hierarchical queues and scheduler
parameters by configuring traffic-control profile and binding it directly to a PPPoE
subscriber interface. The network administrator then configures the traffic-control profile
on a set of PPPoE interfaces.
To use this configuration in a broadband access network, each forwarding class represents
one type of services provided to a household customer and is mapped to a queue. Each
PPPoE interface represents a household and provides shaping of all household traffic
to an aggregate rate. In addition, the PPPoE interface-set configuration provides shaping
of traffic for a group of PPPoE interface on a DSLAM to a DSLAM aggregate rate.
Table 19: Scheduler per Logical Interface with Interface Set Mapping
Level Type Mapping
2 Scheduler Set of PPPoE interfaces
1 Scheduler Underlying physical interface
interfaces {
interface-set iflset1 {
interface pp0 {
unit 0;
unit 1;
unit 2;
}
}
pp0 {
unit 0 {
pppoe-options {
server;
}
family inet {
address 120.20.20.20/32 {
}
}
}
unit 1 {
pppoe-options {

server;
}
family inet {
address 130.30.30.30/32 {
}
}
}
unit 2 {
pppoe-options {
server;
}
family inet {
address 140.40.40.40/32 {
}
}
}
}
ge-3/0/3 {
vlan-tagging;
unit 0 {
vlan-id 100;
}
unit 1 {
vlan-id 101;
}
unit 2 {
vlan-id 102;
}
}
}
class-of-service {
tcp1 {
shaping-rate 50k;
}
tcp2 {
shaping-rate 50m;
}
}
interfaces {
pp0 {
unit 0 {
}
unit 1 {

}
unit 2 {
}
interface-set iflset1 {
}
...
}

Documentation

on page 25

CHAPTER 4
Configuring Hierarchical CoS Scheduling

on MPLS Ethernet Pseudowire Subscriber
Interfaces
• Hierarchical CoS on MPLS Pseudowire Subscriber Interfaces Overview on page 63

• CoS Two-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber
• CoS Three-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber
• CoS Configuration Overview for MPLS Pseudowire Subscriber Interfaces on page 69
• Configuring CoS Two-Level Hierarchical Scheduling for MPLS Pseudowire Subscriber
• Configuring CoS Three-Level Hierarchical Scheduling for MPLS Pseudowire Subscriber
Interfaces (Logical Interfaces over a Transport Logical Interface) on page 72
Interfaces (Logical Interfaces over a Pseudowire Interface Set) on page 74
Hierarchical CoS on MPLS Pseudowire Subscriber Interfaces Overview
Junos OS supports two aspects of CoS for MPLS pseudowire subscriber interfaces. You
can apply CoS rewrite rules and behavior aggregate (BA) classifiers to MPLS pseudowire
subscriber interfaces. In addition, CoS performs egress hierarchical shaping towards the
subscriber on MPLS pseudowire subscriber interfaces.
Hierarchical CoS enables you to apply traffic scheduling and queuing parameters and
packet transmission scheduling parameters to an individual subscriber interface rather
than to all interfaces configured on the port. Hierarchical CoS is supported on MX Series
routers with either EQ DPCs or MPC/MICs installed.
On Juniper Networks MX Series routers, MPC/MIC and EQ DPC interfaces support a

four-level CoS scheduling hierarchy that, when fully configured, consists of the physical
interface (level 1), the interface set or the underlying interface (level 2), one or more
logical interfaces (level 3), and one or more queues (level 4). Although all CoS scheduling
hierarchies are four-level, level 1 is always the physical interface and level 4 is always the
queue. Hierarchical scheduling configurations consist of the type of interfaces you

configure; for example, a logical interface or an interface set and where those interfaces
reside in the scheduling hierarchy, either level 2 or level 3. Because many hierarchical
scheduling configurations are possible, we use the terms two-level hierarchical scheduling
and three-level hierarchical scheduling in this discussion.
Related • Pseudowire Subscriber Logical Interfaces Overview

Documentation
• Configuring a Pseudowire Subscriber Logical Interface

on page 25
• CoS Two-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber Interfaces

on page 64

on page 66
CoS Two-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber Interfaces
Two-level hierarchical scheduling limits the number of hierarchical levels in the scheduling
hierarchy to two. In a two-level scheduling hierarchy, all logical interfaces and interface
sets share a single level 2 node.Table 20 on page 64 summarizes the interface hierarchy
and the CoS scheduler node levels for two-level hierarchical scheduling.

Scheduling Nodes
Physical interface – Pseudowire transport logical One or more queues

interface
Physical interface – Interface set One or more queues
Physical interface – Pseudowire service logical One or more queues

interface
You use the two-level hierarchical scheduling when you have many pseudowires but you
do not require shaping specific to the subscriber logical interface. For example, when
your configuration is one subscriber per pseudowire interface.
Figure 7 on page 65 shows a two-level hierarchical scheduling configuration for the MPLS
pseudowires. In this configuration, level 1 is the physical interface used for the logical
tunnel anchor node. All of the pseudowire transport interfaces share a single level 2 node.
The level 3 nodes are the pseudowire transport logical interfaces (ps0.0, ps1.0, and
ps2.0). In this configuration, interface sets are not configured and only the logical
interfaces have traffic control profiles.

Chapter 4: Configuring Hierarchical CoS Scheduling on MPLS Ethernet Pseudowire Subscriber Interfaces
Figure 7: MPLS Pseudowire Subscriber Interface Two-Level Scheduler

Configuration
Queues Queues Queues
L4
Pseudowire ps0.0 ps1.0 ps2.0

L3
Logical Interfaces
TCP
L2 Dummy
L1 Logical Tunnel
g041325
Physical Interface
Two-level hierarchical scheduling has up to eight class of service queues. For this
configuration, include the maximum-hierarchy-levels 2 option under the [edit interfaces
interface-name hierarchical-scheduler] statement at the physical interface for the anchor
logical tunnel.
NOTE: You cannot configure shaping policies on both the pseudowire logical
interfaces and the subscriber logical interfaces over the same pseudowire.
If a traffic-control profile is configured on a pseudowire logical interface, and
CoS policies are configured on the subscriber logical interface over another
pseudowire, all of the logical interfaces are at level 3 and act as peers.

Documentation

on page 25

on page 66


CoS Three-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber Interfaces
In three-level hierarchical scheduling, the CoS scheduler nodes at level 1, level 2, and
level 3 form a scheduling hierarchy. You can configure many different three-level
scheduling hierarchies, depending on the location of the interface set and the use of
underlying interfaces. In all variations, the physical interface on which the logical tunnel
resides is a level 1 CoS scheduler node and the queues reside at level 4. Three-level
scheduling hierarchies can have up to eight class of service queues.
Table 21 on page 66summarizes the most common three-level hierarchical scheduling
configurations and shows the interface hierarchy and CoS scheduler nodes.

CoS Scheduling Node Levels
Physical interface Pseudowire interface set Pseudowire service One or more

logical interfaces queues
Physical interface Pseudowire transport Pseudowire interface set One or more

logical interface queues
Physical interface Pseudowire transport Pseudowire service One or more

logical interface logical interfaces queues
Three-Level Scheduling Hierarchy: Pseudowire Logical Interfaces over a Transport Logical

Interface
Figure 8 on page 67 shows an MPLS pseudowire three-level scheduling hierarchy that
includes two pseudowire service logical interfaces over a pseudowire transport logical
interface. This variation uses the following scheduler nodes:
• Level 4—Forwarding class-based queues
• Level 3—Pseudowire service logical interfaces (ps0.1 and ps0.2) for subscriber sessions
• Level 2—Pseudowire transport logical interface (ps0.0)
• Level 1—Common/shared physical interface of the logical tunnel anchor point
You apply the traffic-control profiles at the pseudowire transport logical interfaces (level
2) and the pseudowire service logical interfaces (level 3).

Figure 8: Three-Level Scheduling Hierarchy Case 1: Pseudowire Service

Logical Interfaces over a Transport Logical Interface
Queues Queues
L4
Pseudowire ps0.1 ps0.2

L3
Logical Interfaces
TCP
Pseudowire
L2 Transport ps0.0 TCP
Logical Interface
L1 Logical Tunnel
g041326
Physical Interface
Three-Level Scheduling Hierarchy : Pseudowire Service Logical Interfaces over a Pseudowire

Service Interface Set
Figure 9 on page 68 shows another variation of MPLS pseudowire three-level hierarchical
scheduling that includes two pseudowire service logical interfaces over a pseudowire
service interface set. This variation uses the following CoS scheduler nodes:
• Level 3—Pseudowire service logical interfaces (ps0.1 and ps0.2)
• Level 2—Pseudowire service interface set
You apply the traffic-control profile at the pseudowire service interfaces (level 3) and
at the interface set (level 2). This variation is most useful for subscriber edge deployments.

Figure 9: Three-Level Scheduling Hierarchy Case 2: Pseudowire Service

Logical Interfaces over a Pseudowire Service Interface Set
Queues Queues
L4
Pseudowire ps0.1 ps0.2

L3
Logical Interface
TCP
Interface Set of Pseudowire

L2 Pseudowire Logical Interface TCP
Logical Interfaces Set
Logical Tunnel
L1
g041327
Physical Interface
Three-Level Scheduling Hierarchy Combined Deployment Scenario

Figure 10 on page 68 shows a deployment scenario that combines the three-level
hierarchical scheduling scenarios in Figure 8 on page 67 and Figure 9 on page 68.
Figure 10: Three-Level Hierarchical Scheduling for MPLS Pseudowire

Subscriber Interfaces—Deployment Scenario
Queues Queues Queues Queues
L4
TCP TCP
ps0.1 ps0.2 ps1.1 ps1.2
L3
Pseudowire service Pseudowire service Pseudowire service Pseudowire service
interface interface interface interface
ps1.0
L2 Interface set Pseudowire transport
interface
L1 Physical interface
g041406
for logical tunnel
This variation uses the following CoS scheduler nodes:
• Level 3—Pseudowire service logical interfaces (ps0.1, ps0.2, ps1.1, and ps1.2)

• Level 2—Service interface set for pseudowire service interfaces (ps0.1 and ps0.2) and
transport logical interface (ps1.0) for the pseudowire service logical interfaces (ps1.1
and ps1.2)
You apply the traffic-control profiles to the interfaces at both level 2 and level 3, as well
as the interface set at level 2.

Documentation

on page 25


CoS Configuration Overview for MPLS Pseudowire Subscriber Interfaces
CoS supports two-level and three-level hierarchies for MPLS pseudowire subscriber
interfaces.
To configure two-level scheduling, include the maximum-hierarchy-levels 2 option under

the [edit interfaces interface-name hierarchical-scheduler] statement on the physical
interface of the logical tunnel anchor point.
To configure three-level hierarchical scheduling, include the implicit-hierarchy option

under the [edit interfaces interface-name hierarchical-scheduler] statement on the physical
interface of the logical tunnel anchor point. Use the following guidelines for configuring
the implicit-hierarchy option:
• If an output traffic-control profile is configured on the pseudowire transport interface

and on a pseudowire service interface, the two interfaces form a scheduling hierarchy.
The pseudowire transport interface resides in a level 2 scheduler node and the
pseudowire service interface resides in a level 3 scheduler node.
• If an output traffic-control profile is configured on the pseudowire services interface

but not on a pseudowire transport interface, the pseudowire services interface resides
in a level 3 scheduler node.
• If an output traffic-control profile is only configured on the pseudowire transport

interface and not on the pseudowire services interface, the pseudowire transport
interface resides in a level 3 scheduler node and all pseudowire traffic uses this node.

If the implicit-hierarchy option is not set on the logical tunnel anchor point, logical
interfaces behave normally with the hierarchical-scheduler mode configured with or
without the hierarchical-scheduler maximum-hierarchy-levels option under the [edit
interfaces interface-name hierarchical-scheduler] statement. In this case, when you apply
a traffic-control profile to the pseudowire and service logical interfaces, they both reside
in level 3 scheduler nodes and do not form a scheduling hierarchy, which might not be
the desirable behavior. In business edge, where only the pseudowire logical interfaces
need to be shaped, applying the traffic-control profile at just the transport logical interface
may be sufficient.
When configuring the logical tunnel physical interface for the maximum hierarchy level,
all pseudowire logical interfaces operating on the physical interface use the same hierarchy
model. If you want to mix two-level and three-level scheduling hierarchies, you can group
the pseudowires together by hierarchy levels and share the same logical tunnel anchor
point or you can use three-level scheduling for all pseudowires over the anchor point.
To specify rewrite rules and classifiers on pseudowire interfaces, reference the pseudowire
device under the [edit class-of-service interfaces] hierarchy level and specify the rewrite
rules and classifiers for the pseudowire interfaces.
To control all pseudowire traffic using the same logical tunnel interface, apply CoS policies
at the physical interface for the anchor logical tunnel.

Documentation

on page 25



Configuring CoS Two-Level Hierarchical Scheduling for MPLS Pseudowire Subscriber

Interfaces
Before configuring CoS parameters for MPLS pseudowire subscriber interfaces, you must
first complete these tasks:
1. Configure the pseudowire logical interfaces. See Configuring a Pseudowire Subscriber

Logical Interface.
2. Configure the pseudowire device count. See Configuring the Maximum Number of
Pseudowire Logical Interface Devices Supported on the Router.

3. Configure the pseudowire device including the logical tunnel anchor point. See
Configuring a Pseudowire Subscriber Logical Interface Device.
4. Configure the pseudowire transport logical interface. See Configuring the Transport
Logical Interface for a Pseudowire Subscriber Logical Interface.
5. Configure the pseudowire signaling (either Layer 2 circuit signaling or Layer 2 VPN
signaling). See Configuring Layer 2 Circuit Signaling for Pseudowire Subscriber Logical
Interfaces or Configuring Layer 2 VPN Signaling for Pseudowire Subscriber Logical
Interfaces.
6. Configure the pseudowire logical interfaces. See Configuring the Service Logical Interface
for a Pseudowire Subscriber Logical Interface.
To configure CoS policies on MPLS pseudowire subscriber interfaces using two-level

scheduling:
1. Configure the hierarchical scheduler for the physical interface used for the logical
tunnel (anchor point). For two-level scheduling the hierarchical scheduler must be
set to maximum-scheduler levels 2.
[edit]
user@host#edit interfaces ps ps-anchor-device-name
user@host#set hierarchical-scheduler maximum-hierarchy-levels 2
2. Specify the traffic-control profile to use on the pseudowire logical interface.
[edit class-of-service]
user@host#edit interfaces ps ps-device-name
user@host#edit unit logical-unit-number
user@host#set output-traffic-control-profile profile-name
3. Configure the rewrite rule.
The available rewrite rule types for pseudowire interfaces are dscp and inet-precedence.
user@host#edit rewrite-rules (dscp | inet-precedence) rewrite-name
user@host#edit forwarding-class class-name
user@host#set loss-priority class-name code-point (alias | bits)
4. Configure the classifier.
The available classifier types for pseudowire interfaces are dscp and inet-precedence.
user@host#edit classifiers (dscp | inet-precedence) classifier-name
user@host#set loss-priority class-name code-points [aliases] [bit-patterns]
5. Apply the rewrite rule and classifier to the pseudowire interface.
For the interface_name parameter, specify the pseudowire device name.
[edit class-of-service interfaces interface_name unit logical-unit-number]

user@host#set rewrite-rule (dscp | inet-precedence) (rewrite-name | default) protocol

protocol-types
user@host#set classifiers (dscp | inet-precedence) (classifier-name | default)
Related • CoS on Ethernet Pseudowires in Universal Edge Networks Overview

Documentation
• Mapping CoS Component Inputs to Outputs

on page 25
• CoS Two-Level Hierarchical Scheduling on MPLS Pseudowire Subscriber Interfaces

on page 64

on page 66
Configuring CoS Three-Level Hierarchical Scheduling for MPLS Pseudowire Subscriber

Interfaces (Logical Interfaces over a Transport Logical Interface)
Before configuring CoS three-level scheduling on pseudowire logical interfaces over a

transport logical interface, you must first complete these tasks:

Logical Interface.
Interfaces.

Three-level scheduling on pseudowire logical interfaces over a transport logical interface

requires you to apply the traffic-control profiles at both the pseudowire logical interface
and the pseudowire transport logical interface. To configure CoS policies on three-level
scheduling on pseudowire logical interfaces over a transport logical interface:
tunnel (anchor point). For three-level scheduling the hierarchical scheduler must be
set to implicit-hierarchy.
[edit]
user@host#edit interfaces ps-anchor-device-name
user@host#set hierarchical-scheduler implicit-hierarchy
2. Specify the traffic-control profile to use on the pseudowire logical interface.
3. Specify the traffic-control profile to use on the pseudowire transport logical interface.
6. Apply the rewrite rule and classifier to the pseudowire interfaces.
For the interface_name parameter, specify the pseudowire device name.

protocol-types


Documentation

on page 25

on page 66

Configuring CoS Three-Level Hierarchical Scheduling for MPLS Pseudowire Subscriber

Interfaces (Logical Interfaces over a Pseudowire Interface Set)
Before configuring three-level scheduling on pseudowire logical interfaces over a

pseudowire logical interface set, you must first complete the following tasks:

Logical Interface.
Interfaces.
Three-level scheduling on pseudowire logical interfaces over a pseudowire logical interface

set requires you to apply the traffic-control profiles at both the pseudowire logical
interface and the pseudowire logical interface-set. To configure CoS policies on MPLS
pseudowire subscriber interfaces using three-level implicit hierarchical scheduling:
tunnel (anchor point). For three-level scheduling the hierarchical scheduler must be
set to implicit-hierarchy.
[edit]
user@host#edit interfaces ps-anchor-device-name

user@host#set hierarchical-scheduler implicit-hierarchy
2. Specify the traffic-control profile to use on the pseudowire logical interfaces.
3. Define a pseudowire logical interface set and configure the traffic-control profile used
for the interface set.
user@host#edit interfaces
user@host#edit interface-set interface-set-name
user@host#edit output-traffic-control-profile profile-name
4. Group the pseudowire logical interfaces in the pseudowire logical interface set.
[edit ]
user@host#edit interfaces
user@host#edit interface ps ps-device-name
7. Apply the rewrite rule and classifier to the pseudowire interfaces.
For the interface_name parameter, specify the ps device name.

protocol-types

Documentation


on page 25

on page 66


CHAPTER 5
Allocating Dedicated Queues for Each

Logical Interface Using Per-Unit
Scheduling
• Hardware Requirements for Dynamic Per-Unit Scheduling on page 77

• Example: Configuring Per-Unit Scheduling for Subscriber Access on page 80
Hardware Requirements for Dynamic Per-Unit Scheduling
Table 22 on page 77 lists the hardware requirements based on subscriber interface type
for per-unit scheduling in dynamic CoS configurations.
Table 22: Hardware Required for Per-Unit Scheduling Dynamic CoS Configurations
Subscriber Interface EQ DPCs on MX MPC/MIC Modules IQ2 PICs on M120 and IQ2E PICs on M120
Type Series Routers on MX Series Routers M320 Routers and M320 Routers
Static and dynamic Yes Yes No No

VLANs
Static and dynamic No No No No

VLANs over
aggregated Ethernet
Static or dynamic IP Yes No No No

demux interfaces
Static or dynamic IP No No No No
demux interfaces over
aggregated Ethernet
Static or dynamic No No No No
VLAN demux
interfaces

Table 22: Hardware Required for Per-Unit Scheduling Dynamic CoS Configurations (continued)
Subscriber Interface EQ DPCs on MX MPC/MIC Modules IQ2 PICs on M120 and IQ2E PICs on M120
Type Series Routers on MX Series Routers M320 Routers and M320 Routers
VLAN demux
interfaces over
aggregated Ethernet
Static PPPoE No Yes Yes Yes

interfaces
Dynamic PPPoE No No Yes Yes

interfaces
PPPoE interfaces over
aggregated Ethernet
L2TP LAC tunnel over No No No No

PPP
L2TP LNS inline service No No No No

over PPP
Documentation
Configuring Per-Unit Scheduling in a Dynamic Profile
Per-unit scheduling enables one set of output queues for each logical interface configured
under the physical interface. In per-unit scheduling configurations, each Layer 3 scheduler
node is allocated a dedicated set of queues.
If you do not explicitly configure CoS parameters, a default traffic profile with queues is
attached to the logical interface.
To configure per-unit scheduling and queuing for subscriber access:
a. Enable the per-unit scheduler for the physical interface.

user@host# set per-unit-scheduler
b. Configure the drop profiles.
c. Configure the forwarding classes.

Chapter 5: Allocating Dedicated Queues for Each Logical Interface Using Per-Unit Scheduling
d. Configure the rewrite-rules and classifier definitions.
parameters.

dynamic profile.
a traffic-control profile.
See “Configuring Traffic Scheduling and Shaping for Subscriber Access” on page 11.
c. Configure the schedulers and scheduler map in the dynamic profile.
You can configure the schedulers using dynamic variables or a combination of both
static values and dynamic variables.
See “Configuring Schedulers in a Dynamic Profile for Subscriber Access” on page 13.
d. Apply CoS parameters to a subscriber interface by referencing an interface in the

dynamic profile.
• For traffic shaping and scheduling, see “Applying Traffic Shaping and Scheduling
to a Subscriber Interface in a Dynamic Profile” on page 217.
• For rewrite rules, see “Applying a Rewrite Rule Definition to a Subscriber Interface
in a Dynamic Profile” on page 219.
• For classifiers, see “Applying a Classifier to a Subscriber Interface in a Dynamic

4. (Optional) Configure variables in access and service profiles to enable RADIUS to

activate subscriber and upgrade services through CoA.
NOTE: Do not instantiate a CoA request using a service dynamic profile

that is already in use on the same logical interface.
Because you have configured the scheduler map in the dynamic profile, queues are
merged when subscribers change services. Other CoS parameters are replaced.
When multiple subscribers are enabled on a DHCP subscriber interface, and the
dynamic profile referenced by DHCP does not have the replace keyword configured,

the system does not replace the parameters. Instead, it combines the values of the
parameters to their maximum scalar value.
a. Configure CoS variables in a dynamic profile.
See “Configuring Static Default Values for Traffic Scheduling and Shaping” on
page 170
b. (Optional) Enable multiple clients for the same subscriber (logical interface) to
aggregate attributes by configuring the aggregate-clients option for the dynamic
profile attached to a DHCP subscriber interface.
See Attaching Dynamic Profiles to DHCP Subscriber Interfaces or DHCP Client

Interfaces.

Documentation
• Example: Configuring Per-Unit Scheduling for Subscriber Access on page 80
Example: Configuring Per-Unit Scheduling for Subscriber Access
In this example, a network administrator sets up a subscriber access configuration with

per-unit scheduling.
1. The administrator configures the static VLAN interfaces and enables per-unit
scheduling for the interfaces.
[edit]
interfaces {
ge-1/1/0 {
per-unit-scheduler;
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
}
}
unit 200 {
vlan-id 200;
family inet {
}
}
}
ge-1/1/1 {
per-unit-scheduler;
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {

}
}
unit 200 {
vlan-id 200;
family inet {
}
}
}
ge-1/0/1 {
unit 0 {
family inet {
address 3.1.1.1/24;
}
}
}
ge-1/1/2 {
description "wfce14 eth1 soso ge-1/1/2";
vlan-tagging;
gigether-options {
no-auto-negotiation;
}
unit 100 {
vlan-id 100;
family inet {
address 121.0.0.1/24;
}
}
}
}
2. The administrator configures static CoS parameters, including forwarding classes

and classifiers, to be referenced in the dynamic profiles.
[edit]
class-of-service {
classifiers {
inet-precedence 8q-inet {
}
}
}
forwarding-class nc {
}
forwarding-class voice {
}
forwarding-class video {
}

forwarding-class game {
}
forwarding-class data {
}
}
inet-precedence 4q-inet {
loss-priority low code-points [ 000 001 ];
}
}
}
}
}
inet-precedence 8q-drop-inet {
}
}
loss-priority medium-high code-points 010;
}
loss-priority high code-points 011;
}
forwarding-class voice {
}
forwarding-class video {
}
forwarding-class game {
loss-priority medium-high code-points 110;
}
forwarding-class data {
loss-priority high code-points 111;
}
}
inet-precedence 4q-drop-inet {
}
loss-priority medium-low code-points [ 010 011 ];
}
loss-priority medium-high code-points [ 100 101 ];

}
loss-priority high code-points [ 110 111 ];
}
}
}
drop-profiles {
d0 {
}
d1 {
}
d2 {
}
d3 {
}
all {
}
}
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
queue 4 voice;
queue 5 video;
queue 6 game;
queue 7 data;
}
interfaces {
ge-1/0/1 {
unit 0 {
classifiers {
inet-precedence 8q-drop-low-high-inet;
}
}
}
}
traceoptions {
flag all;
flag asynch;
flag route-socket;
}
}
3. The administrator configures the access and service dynamic profiles to receive CoS
parameters for the subscriber interfaces through RADIUS.

[edit]
dynamic-profiles {
subscriber {
interfaces {
family inet;
}
}
}
class-of-service {
zero {
scheduler-map "$junos-cos-scheduler-map";
guaranteed-rate "$junos-cos-guaranteed-rate";
}
}
interfaces {
output-traffic-control-profile zero;
}
}
}
scheduler-maps {
be_smap {
}
all_smap {
forwarding-class af scheduler af_sch;
forwarding-class nc scheduler nc_sch;
forwarding-class video scheduler video_sch;
forwarding-class data scheduler data_sch;
}
be_ef_smap {
}
af_smap {
}
be_ef_af_nc_smap {
}
voice_video_game_data_smap {
forwarding-class voice scheduler voice_sch;
forwarding-class game scheduler game_sch;

}
}
schedulers {
"$junos-cos-scheduler" {
transmit-rate percent "$junos-cos-scheduler-tx";
buffer-size percent "$junos-cos-scheduler-bs";
"$junos-cos-scheduler-dropfile-low";
drop-profile-map loss-priority medium-low protocol any drop-profile
"$junos-cos-scheduler-dropfile-medium-low";
"$junos-cos-scheduler-dropfile-medium-high";
drop-profile-map loss-priority high protocol any drop-profile
"$junos-cos-scheduler-dropfile-high";
}
}
}
}
service {
variables {
fc_1 default-value be;
sch_1 default-value be_sch;
sch-tx_1 default-value 20000000;
sch-bs_1 default-value 10;
sch-pri_1 default-value high;
sch-drop-low_1 default-value d3;
sch-drop-med-low_1 default-value d2;
sch-drop-med-high_1 default-value d1;
sch-drop-high_1 default-value d0;
sch-drop-any_1 default-value d3;
fc_2 default-value af;
sch_2 default-value af_sch;
fc_3 default-value voice;
sch_3 default-value voice_sch;
fc_4 default-value game;
sch_4 default-value game_sch;


scheduler-map default-value all_smap;
}
class-of-service {
scheduler-maps {
"$scheduler-map" {
forwarding-class "$fc_1" scheduler "$sch_1";
}
}
schedulers {
"$sch_1" {
transmit-rate "$sch-tx_1";
buffer-size percent "$sch-bs_1";
priority "$sch-pri_1";
"$sch-drop-low_1";
"$sch-drop-med-low_1";
"$sch-drop-med-high_1";
"$sch-drop-high_1";
}
"$sch_2" {
transmit-rate percent "$sch-tx_2";
"$sch-drop-low_2";
"$sch-drop-high_2";
}
"$sch_3" {
transmit-rate "$sch-tx_3";
"$sch-drop-low_3";
"$sch-drop-high_3";
}

"$sch_4" {
"$sch-drop-low_4";
"$sch-drop-high_4";
}
}
}
}
service_2 {
variables {
fc_1 default-value be;
sch_1 default-value be_sch;
scheduler-map default-value all_smap;
}
class-of-service {
scheduler-maps {
"$scheduler-map" {
}
}
schedulers {
"$sch_1" {
"$sch-drop-low_1";
"$sch-drop-high_1";
}
}
}
}
}

4. The network administrator configures DHCP and RADIUS to grant access and services
to the interfaces referenced by the subscriber dynamic profile.
[edit]
forwarding-options {
dhcp-relay {
traceoptions {
file size 1g;
flag all;
}
dynamic-profile subscriber aggregate-clients replace;
server-group {
subscriber-server {
3.1.1.2;
}
}
active-server-group subscriber-server;
group relay-0 {
authentication {
password pwd0;
username-include {
user-prefix user0;
mac-address;
}
}
interface ge-1/1/0.100;
}
}
}
radius-server {
121.0.0.11 secret "$9$mPF/u0Icrv1RvL7V4oik.Pz3/CtOIE"; ## SECRET-DATA
}
profile subscriber-profile {
authentication-order radius;
radius {
authentication-server 121.0.0.11;
accounting-server 121.0.0.11;
}
radius-server {
121.0.0.11 secret "$9$.mz6pu1hyKBIK8xdg4jHqmQF69A01R"; ## SECRET-DATA
}
accounting {
order radius;
statistics time;
}
}
Related • Configuring Per-Unit Scheduling in a Dynamic Profile on page 78

Documentation

CHAPTER 6
Configuring Dedicated Queue Scaling with

Hierarchical CoS or Per-Unit Scheduling
• Dedicated Queue Scaling for CoS Configurations on MIC and MPC Interfaces
Overview on page 89
• Managing Dedicated and Remaining Queues for Dynamic CoS Configurations on MIC
and MPC Interfaces on page 93
• Verifying the Number of Dedicated Queues Configured on MIC and MPC
Dedicated Queue Scaling for CoS Configurations on MIC and MPC Interfaces Overview
The 30-Gigabit Ethernet Queuing and 60-Gigabit Ethernet Queuing and Enhanced
Queuing Ethernet Modular Port Concentrators (MPCs) provide a set of dedicated queues
for subscriber interfaces configured with hierarchical scheduling or per-unit scheduling.
The dedicated queues offered on these MPCs enable service providers to reduce costs
through different scaling configurations. For example, the 60-Gigabit Ethernet Enhanced
Queuing MPC enables service providers to reduce the cost per subscriber by allowing
many subscriber interfaces to be created with four or eight queues. Alternatively, the
30-Gigabit Ethernet and 60-Gigabit Ethernet Queuing MPCs enable service providers to
reduce hardware costs, but allow fewer subscriber interfaces to be created with four or
eight queues.
This topic describes the overall queue, scheduler node, and logical interface scaling for
subscriber interfaces created on these MIC and MPC combinations.
Queue Scaling for MIC and MPC Combinations

Table 23 on page 89 lists the number of dedicated queues and number of subscribers
supported per MPC.
Table 23: Dedicated Queues for MIC and MPC Interfaces

Dedicated Egress Supported Subscriber Logical Interfaces with Logical Interfaces with
MPC Queues Interfaces 4 Queues 8 Queues
30-Gigabit 64,000 16,000 16,000 (8000 per PIC) 8000 (4000 per PIC)
Ethernet Queuing
MPC

Table 23: Dedicated Queues for MIC and MPC Interfaces (continued)
Dedicated Egress Supported Subscriber Logical Interfaces with Logical Interfaces with
MPC Queues Interfaces 4 Queues 8 Queues
60-Gigabit 128,000 32,000 32,000 (8000 per PIC) 16,000 (4000 per PIC)
Ethernet Queuing
MPC
60-Gigabit 512,000 64,000 64,000 (16,000 per 64,000 (16,000 per

Ethernet Enhanced PIC) PIC)
Queuing MPC
MPCs vary in the number of Packet Forwarding Engines on board. MPC1s, such as the
30-Gigabit Ethernet MPC, have one Packet Forwarding Engine. MPC2s, such as the
60-Gigabit Ethernet MPC, have two Packet Forwarding Engines. Each Packet Forwarding
Engine has two schedulers that share the management of the queues.
A scheduler maps to one-half of a MIC; in CLI configuration statements, that one-half of

a MIC corresponds to PIC 0, 1, 2, or 3. MIC ports are partitioned equally across the PICs.
A two-port MIC has one port per PIC. A four-port MIC has two ports per PIC.
Each interface-set uses eight queues from total available egress queues.
Distribution of Queues on 30-Gigabit Ethernet Queuing MPCs

On 30-Gigabit Ethernet Queuing MPCs, each scheduler maps to different PICs. When
only one MIC is installed, scheduler 0 maps to PIC 0 and scheduler 1 maps to PIC 1 on the
MIC. When two MICs are installed, scheduler 0 can additionally distribute queues to PIC
2 on MIC 1, and scheduler 1 can additionally distribute queues to PIC 3 on MIC 1. However,
the distribution of queues to the MICs is not hard-partitioned for 30-Gigabit Ethernet
Queuing MPCs or other MPC1s. Distribution depends instead on how you allocate the
queues to the PICs.
Figure 11 on page 91 shows the queue distribution on a 30-Gigabit Ethernet Queuing MPC
with only one MIC installed. All 64,000 egress queues on the MPC are available to the
single Packet Forwarding Engine. On the Packet Forwarding Engine, half of these queues
(32,000) are managed by each scheduler. Scheduler 0 contributes all of its 32,000
queues to PIC 0. Scheduler 1 contributes all of its 32,000 queues to PIC 1.

Chapter 6: Configuring Dedicated Queue Scaling with Hierarchical CoS or Per-Unit Scheduling
Figure 11: Distribution of Queues on the 30-Gigabit Ethernet Queuing MPC

with One MIC
MX-MPC1-3D-Q
64,000 egress queues
PFE 1
64,000 queues
Scheduler 0 Scheduler 1
32,000 queues 32,000 queues
PIC 0 PIC 1
g017871
MIC 0
Figure 12 on page 91 shows the queue distribution on the same MPC with two MICs
installed. In this case, each scheduler can supply two PICS, one on each MIC. Because
the distribution of the queues across the MICs is not hard-partitioned, you can allocate
from 0 to 32,000 queues from each scheduler’s pool across the scheduler’s associated
PICs. For example, you can allocate 32,000 queues from Scheduler 0 to PIC 0, 4000
queues from Scheduler 1 to PIC 1, and 28,000 queues from Scheduler 1 to PIC 3.
Alternatively, you can allocate the queues evenly across the PICs, or allocate them in
other combinations with the limitation of 32,000 queues per PIC and 32,000 queues per
port.
Figure 12: Distribution of Queues on the 30-Gigabit Ethernet Queuing MPC with Two MICs
MX-MPC1-3D-Q
PFE 1
64,000 queues
Scheduler 0 Scheduler 1
PIC 0 PIC 1 PIC 2 PIC 3

32,000 queues 32,000 queues 32,000 queues 32,000 queues
shared with PIC 2 shared with PIC 3 shared with PIC 0 shared with PIC 1
g017503
MIC 0 MIC 1
Distribution of Queues on 60-Gigabit Ethernet Queuing MPCs

On 60-Gigabit Ethernet Queuing and Enhanced Queuing Ethernet MPCs, each scheduler
maps to a single PIC: PIC 0 or PIC 1 on MIC 0 and PIC 2 or PIC 3 on MIC 1. The distribution
of the queues is hard-partitioned for these MPCs and other MPC2s; the only difference
in distribution is in the total number of queues available.

For example, Figure 13 on page 92 shows how queues are distributed on a 60-Gigabit
Ethernet Enhanced Queuing MPC. Of the 512,000 egress queues on the MPC, half
(256,000) are available to each of the two Packet Forwarding Engines. On each Packet
Forwarding Engine, half of these queues (128,000) are managed by each scheduler. The
complete scheduler complement (128,000) is available to only one PIC in a MIC. Thus
the total number of queues available depends on the number of MICs installed. The MPC
must have 2 MICs to achieve the maximum of 512,000 queues. With a single MIC, the
MPC can achieve only 256,000 queues.
Figure 13: Distribution of Queues on the 60-Gigabit Ethernet Enhanced Queuing MPC
MX-MPC2-3D-EQ
PFE 1 PFE 2
Scheduler 1 Scheduler 2 Scheduler 1 Scheduler 2

PIC 0 PIC 1 PIC 2 PIC 3

g017499
MIC 0 MIC 1
Determining Maximum Egress Queues and Subscriber Interfaces per Port

The number of MICs installed in an MPC and the number of ports per MIC do not affect
the maximum number of queues available on a given port. These factors affect only how
you are able to allocate queues (and, therefore, subscribers) for your network.
For example, a 30-Gigabit Ethernet Queuing MPC supports a maximum of 16,000

subscriber interfaces and has a maximum of 32,000 queues available per PIC. On this
card, you can allocate up to 32,000 queues to a single port in each PIC. If you dedicate
4 queues per subscriber interface, you can accommodate a maximum of 8000 subscriber
interfaces on a single port, and therefore need at least two ports to reach the maximum
16,000 subscriber interfaces. If you dedicate 8 queues per subscriber interface, you can
accommodate a maximum of 4000 subscriber interfaces on a single port, and you need
4 ports for the maximum of 16,000 subscriber interfaces.
The 60-Gigabit Ethernet Enhanced Queuing MPC supports a maximum of 64,000

subscriber interfaces and has a maximum of 128,000 queues per PIC. You can allocate
up to 128,000 queues to a single port in each PIC. However, if you dedicate 4 queues per
subscriber interface, you can accommodate a maximum of only 16,000 subscriber
interfaces on a single MPC port—not 32,000—because the 60-Gigabit Ethernet Enhanced
Queuing MPC is limited to 16,000 subscriber interfaces per PIC. If you dedicate 8 queues
per subscriber interface, you can also accommodate a maximum of 16,000 subscriber
interfaces on a single MPC port. In either case, you need at least 4 ports to reach the
maximum of 64,000 subscriber interfaces.

Managing Remaining Queues

When the number of available dedicated queues on the MPC drops below 10 percent,
an SNMP trap is generated to notify you .
When the maximum number of dedicated queues on the MPCs is reached, a system log
message, COSD_OUT_OF_DEDICATED_QUEUES, is generated. The system does not provide
subsequent subscriber interfaces with a dedicated set of queues. For per-unit scheduling
configurations, there are no configurable queues remaining on the MPC.
For hierarchical scheduling configurations, remaining queues are available when the
maximum number of dedicated queues is reached on the MPC. Traffic from these logical
interfaces are considered unclassified and attached to a common set of queues that are
shared by all subsequent logical interfaces. These common queues are the default port
queues that are created for every port. You can configure a traffic-control profile and
attach that to the interface to provide CoS parameters for the remaining queues.
For example, when the 30-Gigabit Ethernet Queuing MPC is configured with 32,000
subscriber interfaces with four queues per subscriber, the MPC can support 16,000
subscribers with a dedicated set of queues. You can provide CoS shaping and scheduling
parameters to the remaining queues for those subscriber interfaces by attaching a special
traffic-control profile to the interface.
These subscriber interfaces remain with this traffic-control profile, even if dedicated
queues become available.
Related • For information about managing dedicated queues in a static CoS configuration, see
Documentation Managing Dedicated and Remaining Queues for Static CoS Configurations on MIC and
MPC Interfaces
• For information about managing dedicated queues in a dynamic subscriber access

configuration, see Managing Dedicated and Remaining Queues for Dynamic CoS
Configurations on MIC and MPC Interfaces on page 93
• Understanding Hierarchical Scheduling for MIC and MPC Interfaces
• COSD System Log Messages on page ?
Managing Dedicated and Remaining Queues for Dynamic CoS Configurations on MIC
and MPC Interfaces
This topic describes how to manage dedicated and remaining queues for static and
dynamic subscriber interfaces configured in dynamic profiles.
You manage queues at the chassis and physical port level in the static configuration
hierarchies, then configure dynamic scheduling and shaping parameters for the subscriber
interfaces in the dynamic profile.
• Configuring the Maximum Number of Queues for MIC and MPC Interfaces on page 94
• Configuring Remaining Common Queues on MIC and MPC Interfaces on page 94

Configuring the Maximum Number of Queues for MIC and MPC Interfaces
30-Gigabit Ethernet Queuing MPCs and 60-Gigabit Ethernet Queuing and Enhanced
Queuing MPCs support a dedicated number of queues when configured for hierarchical
scheduling and per-unit scheduling configurations.
To scale the number of subscriber interfaces per queue, you can modify the number of
queues supported on the MIC.
To configure the number of queues:
1. Specify that you want to configure the MIC.
user@host# edit chassis fpc slot-number pic pic-number
2. Configure the number of queues.
[edit chassis fpc slot-number pic pic-number]

user@host# setmax-queues-per-interface (8 | 4)
Configuring Remaining Common Queues on MIC and MPC Interfaces

30-Gigabit Ethernet Queuing MPCs and 60-Gigabit Ethernet Queuing and Enhanced
Queuing MPCs support a dedicated set of queues when configured with hierarchical
scheduling.
When the number of dedicated queues is reached on the module, there can be queues
remaining. Traffic from these logical interfaces are considered unclassified and attached
to a common set of queues that are shared by all subsequent logical interfaces.
You can configure traffic shaping and scheduling resources for the remaining queues by
attaching a special traffic-control profile to the interface. This feature enables you to
provide the same shaping and scheduling to remaining queues as the dedicated queues.
To configure the remaining queues on a MIC or MPC interface:
1. Configure CoS parameters in a traffic-control profile.

3. Attach the traffic control profiles for the dedicated and remaining queues to the port
on which you enabled hierarchical scheduling.
To provide the same shaping and scheduling parameters to dedicated and remaining
queues, reference the same traffic-control profile.
a. Attach the traffic-control profile for the dedicated queues on the interface.
[edit class-of-service interfaces interface-name]

user@host# set output-traffic-control-profile profile-name

b. Attach the traffic-control profile for the remaining queues on the interface.

user@host# set output-traffic-control-profile-remaining profile-name
Related • Verifying the Number of Dedicated Queues Configured on MIC and MPC Interfaces on
Documentation page 95
• Dedicated Queue Scaling for CoS Configurations on MIC and MPC Interfaces Overview
on page 89
Verifying the Number of Dedicated Queues Configured on MIC and MPC Interfaces
Purpose Display the number of dedicated queue resources that are configured for the logical
interfaces on a port.
Action user@host#show class-of-service interface ge-1/1/0

Physical interface: ge-1/1/0, Index: 166
Queues supported: 4, Queues in use: 4
Total non-default queues created: 4
Scheduler map: <default>, Index: 2
Chassis scheduler map: <default-chassis>, Index: 4
Logical interface: ge-1/1/0.100, Index: 72, Dedicated Queues: no

Shaping rate: 32000
Object Name Type Index
Scheduler-map <remaining> 0
Classifier ipprec-compatibility ip 13
Logical interface: ge-1/1/0.101, Index: 73, Dedicated Queues: no

Shaping rate: 32000
Scheduler-map <remaining> 0
Logical interface: ge-1/1/0.102, Index: 74, Dedicated Queues: yes

Shaping rate: 32000
Traffic-control-profile <control_tc_prof> Output 45866
Related • Managing Dedicated and Remaining Queues for Static CoS Configurations on MIC and
Documentation MPC Interfaces
• Managing Dedicated and Remaining Queues for Dynamic CoS Configurations on MIC
and MPC Interfaces on page 93


CHAPTER 7
Preventing Bandwidth Contention on

Subscriber Interfaces Using Hierarchical
CoS
• Hierarchical CoS Shaping-Rate Adjustments Overview on page 97

• Shaping Rate Adjustments for Subscriber Local Loops Overview on page 99
• Guidelines for Configuring Shaping-Rate Adjustments for Subscriber Local
Loops on page 100
• Configuring the Minimum Adjusted Shaping Rate on Scheduler Nodes for
Subscribers on page 101
• Configuring Shaping-Rate Adjustments on Queues on page 102
• Enabling Shaping-Rate Adjustments for Subscriber Local Loops on page 104
• Disabling Shaping-Rate Adjustments for Subscriber Local Loops on page 109
• Disabling Hierarchical Bandwidth Adjustment for Subscriber Interfaces with Reverse-OIF
Mapping on page 110
• Example: Configuring Hierarchical CoS Shaping-Rate Adjustments for Subscriber Local
Loops on page 110
• Verifying the Configuration of Shaping-Rate Adjustments for Subscriber Local
Loops on page 113
• Verifying the Configuration of ANCP for Shaping-Rate Adjustments on page 114
Hierarchical CoS Shaping-Rate Adjustments Overview
This overview describes how MX Series 3D Universal Edge Routers installed in a subscriber
access network can adjust hierarchical class-of-service (CoS) parameters to prevent
bandwidth contention at subscriber interfaces.
Hierarchical CoS is supported only for subscriber interfaces on EQ DPC or MPC interfaces
operating in hierarchical scheduler mode.
The characteristics of voice, data, and video applications vary widely in their requirements
for traffic throughput, bandwidth management, delay and jitter tolerance, and buffer
depth. To prevent bandwidth contention at subscriber interfaces, you can configure
applications such as ANCP and Multicast to perform real-time adjustments to the shaping

rate configured for subscriber interfaces for residential gateways. Enabling shaping-rate
adjustments on the router can prevent bandwidth contention at the interface from causing
degradation of the subscriber’s voice, data, or video services.
Depending on the application, shaping-rate adjustments are supported on Enhanced

Queueing (EQ) DPCs on MX Series routers and MPC/MIC modules on MX Series routers.
Types of Shaping-Rate Adjustments

The ANCP application supports absolute adjustments to a specific shaping-rate value.
You can configure ANCP to communicate the subscriber local loop speed to the MX
Series router, which in turn throttles traffic destined to the associated subscriber interface
so that it matches the subscriber local loop speed. ANCP acquires subscriber line rate
information from DSLAMs and then communicates this data transmission rate for use
with CoS.
The OIF mapping and reverse OIF mapping multicast applications support delta
adjustments that increase or decrease the current shaping rate by a certain value. The
system adjusts traffic destined to the subscriber using reverse OIF mapping enabled on
a specified multicast interface. Reverse OIF mapping is used to determine the subscriber
VLAN interface and the multicast traffic bandwidth on the interface.
Levels of Shaping-Rate Adjustments

Both absolute and delta adjustments are made to a subscriber’s aggregate shaping rate
on a level 3 scheduler node.
Adjustments that occur on the scheduler node can also impact the shaping rates for all
queues. This adjustment can be undesirable for service providers who want to provide
a premium level of service on specific queues.
For delta-based adjustments by multicast applications, you can control the distribution
of shaping rates among queues by assigning the percentage of adjustment allowed for
each queue. In addition, you can set a minimum adjusted shaping rate for each queue.
Figure 14 on page 98 shows a sample multicast network with shaping rates adjusted at
the scheduler node level. The shaping rate is reduced by 4 Mbps (from 41 Mbps to 37
Mbps) at the scheduler node for subscriber interface 1, which reduces the rates of both
the best effort and video on demand (VoD) service queues.
Figure 14: Scheduler Node and Queues with Adjusted Shaping Rates
Queues Level 3 (Logical interface) Level 2 Level 1 (Gigabit Ethernet port)
BE: Shaping rate 5M Shaping rate: 37M

Subscriber interface 1
VoD: Shaping rate 38M
BE: Shaping rate 5M

Subscriber interface 2 Scheduler node GE port
g017580
IPTV Multicast VLAN

4 Mbps of multicast destined to subscriber interface 1

Chapter 7: Preventing Bandwidth Contention on Subscriber Interfaces Using Hierarchical CoS
Figure 15 on page 99 shows the same network with queue-based adjustments enabled
for the best-effort queue on subscriber 1. The shaping rate of the best-effort queue is
reduced by 4 Mbps (from 5 Mbps to 1 Mbps). The VoD service queue is not affected.
Figure 15: Queue with Adjusted Shaping Rate

Queues Level 3 (Logical interface) Level 2 Level 1 (Gigabit Ethernet port)
BE: Shaping rate 1M Shaping rate: 41M

Subscriber interface 1
BE: Shaping rate 5M

Subscriber interface 2 Scheduler node GE port
g017576
IPTV Multicast VLAN
4 Mbps of multicast destined to subscriber interface 1
Related • Configuring the Minimum Adjusted Shaping Rate on Scheduler Nodes for Subscribers
• Disabling Hierarchical Bandwidth Adjustment for Subscriber Interfaces with Reverse-OIF

Mapping on page 110

Loops on page 110
Shaping Rate Adjustments for Subscriber Local Loops Overview
This overview describes how an MX Series 3D Universal Edge Router installed as an edge
router can adjust hierarchical CoS policy for subscriber interfaces for subscriber local
loops. You can configure the router to throttle the traffic sent to subscriber local loops
so that the traffic does not exceed the current data transmission rate of those lines. This
feature ensures that changes to subscriber local loop speeds do not cause bandwidth
contention at the subscriber’s residential gateway.
In a typical subscriber access network, traffic destined to a subscriber is delivered from

the access network, through an edge router, to a DSLAM. The DSLAM multiplexes
subscriber traffic through a DSL, also known as a local loop, to the subscriber’s residential
gateway. When line noise or cross talk in a subcarrier causes the error rate on a DSL to
exceed a certain threshold, the DSLAM can adapt itself by lowering the data transmission
rate to that carrier device. A lower data transmission rate is less susceptible to induced
errors.
You can configure an MX Series router to adjust the configured shaping rates on scheduler
nodes for subscriber interfaces that represent subscriber local loops. Whenever a DSLAM
resynchronizes a subscriber local loop speed, the router adjusts the configured shaping
rate for that line so that the aggregate egress traffic to those subscribers is shaped to
the local loop speed before the traffic reaches the DSLAM. Unless the maximum amount
of bandwidth allocated to the subscriber interface on the router is throttled to the local
loop speed, bandwidth contention can occur at the subscriber’s residential gateway,
which can cause the DSLAM to drop packets. This type of shaping-rate adjustment

requires the topology discovery and traffic-monitoring features of the Access Node
Control Protocol (ANCP).
You can enable ANCP to communicate the subscriber local loop speed to CoS, which in
turn throttles traffic destined to the associated subscriber interface so that it matches
the subscriber local loop speed. The ANCP agent acquires unadjusted (net) subscriber
line rate information from DSLAMs and then communicates this data transmission rate
for use with CoS. You can also configure percentage and byte adjustments that the ANCP
agent can make to the received net data rate for frame-mode DSL types before
communicating the adjusted rate and overhead to CoS.
Related • Hierarchical CoS Shaping-Rate Adjustments Overview on page 97

Documentation
• Guidelines for Configuring Shaping-Rate Adjustments for Subscriber Local Loops on
page 100

Loops on page 110
• For more information about the ANCP protocol, see the ANCP and the ANCP Agent
Overview.
Guidelines for Configuring Shaping-Rate Adjustments for Subscriber Local Loops
These guidelines apply to configuring an MX Series 3D Universal Edge Router installed

as an edge router to adjust the configured shaping rates on scheduler nodes for subscriber
interfaces that represent subscriber local loops. This shaping-rate feature uses the
topology discovery and traffic-monitoring features of ANCP.
When you enhance hierarchical CoS policy by configuring ANCP-driven shaping-rate

adjustments, consider the following guidelines:
• Shaping-rate adjustments are supported on EQ DPCs and MPCs on MX Series routers.
• Shaping-rate adjustments are supported only for subscriber local loops that terminate
at DSLAMs that you have configured as ANCP neighbors of the MX Series router.
• Shaping-rate adjustments are supported only for scheduler nodes for which you have
configured an initial shaping rate by including the shaping-rate statement in a
traffic-control profile applied to the scheduler node. Specify the initial shaping rate as
a peak rate, in bits per second (bps), and not as a percentage. Other methods of
configuring a shaping rate are not supported with this feature.
• Shaping-rate adjustments are supported only for scheduler nodes that are static logical
interface sets that you have configured to operate at Level 3 of the scheduler hierarchy
on the router. If an interface set is configured with a logical interface (such as unit 0)
and queue, then the interface set is an internal scheduler node (as opposed to a root
node or a leaf node) at Level 2 of the hierarchy. However, if there are no traffic-control

profiles are configured on logical interfaces in an interface set, then the interface set
is an internal scheduler node at Level 3 of the hierarchy.
• Shaping-rate adjustments are supported only for subscriber interfaces over physical
interfaces that you have configured to operate in hierarchical scheduler mode. Only
ports on EQ DPCs in MX Series routers support hierarchical scheduler mode.
• After shaping-rate adjustments are enabled and the router has performed shaping-rate
adjustments on a scheduler node, you can configure a new shaping rate by including
the shaping-rate statement in a traffic-control profile and then applying that profile to
that scheduler node. However, this new shaping-rate value does not immediately result
in shaping traffic at the new rate. The scheduler node continues to be shaped at rate
set by ANCP. Only when the ANCP shaping-rate adjustment feature is disabled is the
scheduler node shaped at the newly configured shaping-rate.
• The Layer 2 Tunneling Protocol (L2TP) is often used to carry traffic securely between
an L2TP Network Server (LNS) and an L2TP Access Concentrator (LAC). The QoS
adjustment feature supports the shaping overhead options that you can use to add a
specified number of bytes to the actual packet length when determining shaped session
packet length. ANCP shaping-rate adjustments are not supported for ingress traffic,
only for egress traffic. To configure the number of bytes to add to the packet at the
egress side of the tunnel, include the egress-shaping-overhead and mode statements
at the [edit chassis fpc slot-number pic pic-number traffic-manager] hierarchy level. Use
the shaping overhead options if you need to account for encapsulation overhead.
For more information about the ANCP protocol, see the ANCP and the ANCP Agent
Overview.

Documentation

Loops on page 110
Configuring the Minimum Adjusted Shaping Rate on Scheduler Nodes for Subscribers

• Configuring a Static Minimum Adjusted Shaping Rate on Scheduler Nodes on page 102
• Configuring a Dynamic Minimum Adjusted Shaping Rate on Scheduler Nodes on page 102
Overview
Absolute adjustments and delta adjustments are performed at the scheduler node level.
You can configure a minimum adjusted shaping rate at the scheduler node level using
static or dynamic CoS parameters.

This feature is supported for adjustments performed by the ANCP and multicast
applications on both EQ DPCs and MPC/MIC modules on MX Series routers.
BEST PRACTICE: For multicast traffic, you can configure a minimum adjusted
shaping rate at the queue level. We recommend that you configure the
minimum adjusted value at the scheduler node or the queue, but not both.
When you configure a minimum adjusted value for a node and for a scheduler
that is referenced by a scheduler map in the same traffic-control-profile, the
system uses the minimum value from the scheduler.
This feature is supported for adjustments performed by the ANCP and multicast
applications on both EQ DPCs and MPC/MIC modules on MX Series routers.
Configuring a Static Minimum Adjusted Shaping Rate on Scheduler Nodes

To apply a minimum adjusted shaping rate for a scheduler node:
• Configure the adjust-minimum statement for the static traffic-control profile.
[edit class-of-service traffic-control-profiles profile-name]

user@host# set adjust-minimum rate
Configuring a Dynamic Minimum Adjusted Shaping Rate on Scheduler Nodes

To apply a minimum adjusted shaping rate for a scheduler node:
• Configure the adjust-minimum statement for the dynamic traffic-control profile.
[edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name]

Related • Verifying the Scheduling and Shaping Configuration for Subscriber Access on page 23
Documentation
Configuring Shaping-Rate Adjustments on Queues

• Configuring a Static Shaping-Rate Adjustment for Queues on page 103
• Configuring a Dynamic Shaping-Rate Adjustment for Queues on page 103
Overview
By default, the multicast application adjusts the shaping rates at the scheduler node
level. This adjustment also impacts the shaping rates for all queues, which can be
undesirable for service providers who want to provide a premium level of service on
specific queues.

For multicast applications, you can control the distribution of shaping rates among queues
by assigning the percentage of adjustment allowed for each queue. In addition, you can
set a minimum adjusted shaping rate for each queue.
This feature is supported for adjustments performed by the multicast application on

MPC/MIC modules on MX Series routers.
BEST PRACTICE: We recommend that you configure the minimum adjusted

value at the scheduler node or the queue, but not both.
When you configure a minimum adjusted value for a node and for a scheduler
that is referenced by a scheduler map in the same traffic-control-profile, the
system uses the minimum value from the scheduler.
This feature is supported for adjustments performed by the multicast application on

MPC/MIC modules on MX Series routers.
Configuring a Static Shaping-Rate Adjustment for Queues

To configure adjustment parameters for a queue:
1. Configure the percentage of adjustment for the shaping rate.
[edit class-of-service schedulers scheduler-name]

user@host# set adjust-percent percentage
2. Configure the minimum adjusted value for the shaping rate.
Do one of the following:
• Configure the minimum adjusted value for the queue.
[edit class-of-service schedulers scheduler-name]

• Configure the minimum adjusted value for the node.
[edit class-of-service traffic-control-profile profile-name]

BEST PRACTICE: Ensure that the minimum adjusted value that you
configure does not exceed the shaping rate and is not lower than the
configured transmit rate.
Configuring a Dynamic Shaping-Rate Adjustment for Queues

To configure adjustment parameters for a queue in a dynamic profile:
1. Configure the percentage of adjustment for the shaping rate.

user@host# set adjust-percent percentage

2. Configure the minimum adjusted value for the shaping rate.
Do one of the following:
• Configure the minimum adjusted value for the queue.

user@host# set adjust-minimum (rate | $junos-cos-adjust-minimum)
• Configure the minimum adjusted value for the node.
[edit dynamic-profiles profile-name class-of-service traffic-control-profile

profile-name]
BEST PRACTICE: Ensure that the minimum adjusted value that you
configure does not exceed the shaping rate and is not lower than the
configured transmit rate.
Related • Verifying the Scheduling and Shaping Configuration for Subscriber Access on page 23
Documentation
• Configuring the Minimum Adjusted Shaping Rate on Scheduler Nodes for Subscribers
on page 101
Enabling Shaping-Rate Adjustments for Subscriber Local Loops
You can enhance a CoS implementation by enabling an MX Series 3D Universal Edge

Router to adjust the hierarchical CoS policy shaping rate configured for static interface
sets that consist of two or more VLANs and represent subscriber local loops. Whenever
the digital subscriber line access multiplexer (DSLAM) resynchronizes its data transmission
rate to a digital subscriber line (DSL), the router adjusts the shaping rate for the associated
subscriber interface so that the maximum bandwidth allocation cannot exceed the
current data rate for the associated subscriber local loop. This feature ensures that data
transmission rate adjustments by the DSLAM do not cause bandwidth contention at the
subscriber’s residential gateway.
This topic includes the following tasks:
• Configuring Static Logical Interface Sets to Serve as CoS Hierarchical Scheduler Nodes
for Subscriber Loops on page 105
• Configuring the Logical Interfaces That Compose the Static Logical Interface
Sets on page 105
• Configuring Hierarchical CoS on the Static Logical Interface Sets That Serve as
Hierarchical Scheduler Nodes for Subscriber Local Loops on page 106
• Configuring ANCP Functionality That Supports and Drives Shaping-Rate Adjustments
for Subscriber Local Loops on page 108

Configuring Static Logical Interface Sets to Serve as CoS Hierarchical Scheduler Nodes for
Subscriber Loops
To configure a logical interface set, begin by including the interface-set statement with
the interface-set-name option at the [edit interfaces] hierarchy level.
An interface set is composed of two or more logical interfaces on the same physical
interface. Each logical interface in an interface set corresponds to an individual subscriber
service, such as voice, video, or data. To specify either a list of logical unit numbers or the
single outer VLAN tag used to identify the logical interfaces that compose the interface
set, include statements at the [edit interfaces interface-set interface-set-name] hierarchy
level:
• For an interface set composed of a list of logical interfaces identified by an inner VLAN
tag on Ethernet frames (called the customer VLAN, or C-VLAN, tag), you must specify
each logical interface by including the unit statement with the logical-unit-number
option.
[edit]
interfaces {
interface-set interface-set-name {
interface ethernet-interface-name { # EQ DPC port
unit logical-unit-number;
...
}
...
}
}
• For an interface set composed of a set of VLANs grouped at the DSLAM and identified
by the same service VLAN (S-VLAN) tag), you must specify the S-VLAN tag as the
outer VLAN tag for each VLAN by including the vlan-tags-outer statement with the
vlan-tag option.
[edit]
interfaces {
interface ethernet-interface-name { # EQ DPC port
vlan-tags-outer vlan-tag; # Identify the DSLAM
}
...
}
}
For more information, see Configuring Hierarchical Schedulers for CoS.
Configuring the Logical Interfaces That Compose the Static Logical Interface Sets
Each underlying physical interface must be configured to operate in hierarchical scheduler
mode and to support stacked VLAN tagging on all logical interfaces. To configure, include
the hierarchical-scheduler statement and the stacked-vlan-tagging statement at the [edit
interfaces ethernet-interface-name] hierarchy level.

To associate the individual logical interfaces of an interface set with specific subscriber
services provided by the subscriber local loop, bind an S-VLAN tag and a C-VLAN tag to
each logical interface that belongs to a scheduler node that represents a subscriber local
loop. Ethernet frames sent from the logical interfaces contain an outer VLAN tag that
identifies a DSLAM and an inner VLAN tag that identifies a subscriber port on the DSLAM.
To configure, include the vlan-tags statement at each logical interface:
[edit]
interfaces {
ethernet-interface-name { # EQ DPC port underlying an interface set
stacked-vlan-tagging; # Support 802.1Q VLAN dual-tagged frames
unit logical-unit-number { # Bind S-VLAN and C-VLAN tags to logical interface
vlan-tags inner tpid.vlan-id outer tpid.vlan-id;
}
...
}
}
For more information, see 802.1Q VLANs Overview.
Configuring Hierarchical CoS on the Static Logical Interface Sets That Serve as Hierarchical
Scheduler Nodes for Subscriber Local Loops
To configure hierarchical CoS on the static logical interface set that serves as the
hierarchical scheduler node for a subscriber local loop:
1. For each scheduler node that represents a subscriber local loop, configure an initial
shaping rate.
NOTE: The CoS shaping-rate feature is supported only for scheduler

nodes with a configured shaping rate. The initial shaping rate must be
configured by applying a traffic-control profile that includes the
shaping-rate statement. Specify the initial shaping rate as a peak rate, in
bits per second (bps), and not as a percentage. Other methods of
configuring a shaping rate are not supported with this feature.
• To enable traffic heading downstream (from the router to the DSLAM) to be

gathered into an interface set, include the interface-set statement and define the
logical interface set name as the interface-set-name option at the [edit
class-of-service interfaces] hierarchy level.
• To apply output traffic scheduling and shaping parameters at the logical interface
set level (rather than at the logical unit level), include the
output-traffic-control-profile statement and specify the name of a traffic-control
profile as the profile-name option at the [edit class-of-service interfaces interface-set
interface-set-name] hierarchy level.
To configure, include the following statements:
interfaces { # Configure interface-specific CoS for incoming packets

interface-set interface-set-name { # Configure a hierarchical scheduler

output-traffic-control-profile tc-profile-name; # Level 3 scheduler node

}
...
}
traffic-control-profiles { # Define traffic-control profiles
tc-profile-name { # Specify a scheduler map and traffic-shaping parameters
scheduler-map map-name;
shaping-rate rate; # This is the “configured shaping rate”
guaranteed-rate (percent percentage | rate);
delay-buffer-rate (percent percentage | rate);
}
...
}
You can include the statements at the following hierarchy levels:
• [edit class-of-service]
• [edit dynamic-profiles profile-name class-of-service]
2. Configure the scheduler maps referenced in the traffic-control profiles applied to the
interface sets, the schedulers referenced in those scheduler maps, and the drop profiles
referenced in those schedulers.
• A scheduler map establishes the traffic output queues (forwarding classes) for a
scheduler node and associates each queue with a specific scheduler map.
• A scheduler defines queue properties (transmit rate, buffer size, priority, and drop
profile) that specify how traffic is treated in the output queue.
• A drop profile specifies how aggressively the MX Series router drops packets that
are managed by a particular scheduler by defining either a segmented or interpolated
graph that maps output queue fullness to packet drop probability.
To configure, include the statements at the static [edit class-of-service] hierarchy

level:
[edit]
class-of-service {
scheduler-maps { # Assign queuing characteristics to output queues
map-name { # Map output queues to
forwarding-class class-name scheduler scheduler-name;
...
}
...
}
schedulers { # Define queuing characteristics
scheduler-name { # Specify queuing and buffer management
transmit-rate transmit-rate-option;
buffer-size buffer-size-option;
priority priority-level;
drop-profile-map loss-priority loss-priority-option protocol any drop-profile
drop-profile-name;
...
}
}

drop-profiles { # Define random early detection (RED) for the delay buffer
drop-profile–name { # Specify how to drop packets from an output queue
drop-profile-name { # Map a queue fullness to a drop probability
fill-level percentage drop-probability percentage; # Option 1: segmented
fill-level percentage drop-probability percentage;
...
}
interpolate { # Option 2: interpolated
drop-probability [ values ];
fill-level [ values ];
}
}
...
}
}
For more information about configuring scheduler maps, schedulers, and drop profiles,
see Mapping CoS Component Inputs to Outputs Overview.
Configuring ANCP Functionality That Supports and Drives Shaping-Rate Adjustments for
Subscriber Local Loops
To configure the Access Node Control Protocol (ANCP) functionality that supports and
drives the shaping-rate adjustments for subscriber local loops:
• Enable the ANCP agent to monitor subscriber local loop rates at the DSLAMs and
communicate this information to CoS.
• For frame-mode DSL types, optionally configure adjustments that are made to the net
data rates, the frame overhead, or both before the ANCP agent reports the values to
CoS. Rates are adjusted by a percentage. Bytes are added to or subtracted from the
overhead per frame.
• Configure each DSLAM as an ANCP neighbor of the router so that TCP connections
can be established between the router and each DSLAM.
• Identify the subscriber interface sets whose traffic is monitored and shaped by the
ANCP agent, and associate those interface sets with the corresponding identifiers
configured on the access node (DSLAM) to uniquely identify the subscriber local loops
within the access network.
The ANCP agent uses this information to build a mapping of subscribers to subscriber
interfaces. When the ANCP agent receives port management messages from a DSLAM
or other access node, it uses the access identifier contained in the message to determine
which hierarchical scheduler node corresponds to the subscriber.
To configure, include statements at the [edit protocols ancp] hierarchy level:
[edit]
protocols {
ancp {
qos-adjust; # Enable ANCP to monitor and adjust CoS shaping rates
sdsl-bytes bytes; # Specify number of bytes to adjust SDSL rate
sdsl-overhead-adjust percentage; # Specify percentage by which to adjust SDSL
rate

vdsl-bytes bytes; # Specify number of bytes to adjust VDSL rate

vdsl-overhead-adjust percentage; # Specify percentage by which to adjust VDSL
rate
vdsl2-bytes bytes; # Specify number of bytes to adjust VDSL2 rate
vdsl2-overhead-adjust percentage; # Specify percentage by which to adjust VDSL2
rate
}
neighbor ip-address; # Configure each DSLAM as an ANCP neighbor
...
interfaces { # Identify subscribers for which ANCP can adjust shaping rates
interface-set {
interface-set-name {
access-identifier identifier-string; # DSLAM ID for the local loop
}
}
...
}
...
}
...
}
Documentation Shaping-Rate Adjustments for Subscriber Local Loops on page 100
• Traffic Rate Reporting and Adjustment by the ANCP Agent
• Configuring the ANCP Agent to Report Traffic Rates to CoS
• Verifying the Configuration of ANCP for Shaping-Rate Adjustments on page 114
• Verifying the Configuration of Shaping-Rate Adjustments for Subscriber Local Loops

on page 113

Loops on page 110
Disabling Shaping-Rate Adjustments for Subscriber Local Loops
To disable hierarchical CoS shaping-rate adjustments for subscriber local loops:
• Disable hierarchical CoS traffic-shaping adjustment by ANCP:
[edit protocols ancp]

user@host# delete qos-adjust
Traffic-shaping parameters for all subscriber local loops revert to their current configured
values.
Documentation Shaping-Rate Adjustments for Subscriber Local Loops on page 100


Loops on page 110
Disabling Hierarchical Bandwidth Adjustment for Subscriber Interfaces with

Reverse-OIF Mapping
You can disable hierarchical bandwidth adjustment for all subscriber interfaces with
reverse OIF mapping enabled on a specified multicast interface. Reverse OIF mapping
is used to determine the subscriber VLAN interface and the multicast traffic bandwidth
on the interface.
To disable hierarchical bandwidth adjustment:
1. Specify that you want to access the subscriber interfaces with reverse-OIF mapping
enabled.
[edit routing-instances routing-instance routing-options multicast interface

interface-name]
user@host# edit reverse-oif-mapping
2. Disable hierarchical bandwidth adjustment for all subscriber interfaces on the interface.
user@host# set no-qos-adjust

Documentation
• Example: Configuring Multicast with Subscriber VLANs
Example: Configuring Hierarchical CoS Shaping-Rate Adjustments for Subscriber Local

Loops
This example shows how you can enable shaping-rate adjustments for static logical
interface sets that represent subscriber local loops:
1. Configure static logical interface sets to serve as CoS hierarchical scheduler nodes
for subscriber local loops.
This example uses a single scheduler node that represents two subscriber local loops.
The scheduler node is a static logical interface composed of two logical interfaces.
The underlying physical interface is port 0 on a Gigabit Ethernet EQ DPC in slot 4, PIC
0:
[edit]
interfaces {
interface-set ifset-of-logical-interfaces {
interface ge-4/0/0 {
unit 1;
unit 2;
}

}
ge-4/0/0 {
description “access interface ge-4/0/0”;
stacked-vlan-tagging;
unit 1 {
description “DSL type ADSL1 = 0x01”;
proxy-arp;
vlan-tags outer 1 inner 1; # S-VLAN tag is ’1’ and C-VLAN tag is ’1’
family inet { # Specify a secondary loopback address
}
}
unit 2 {
description “DSL type ADSL1 = 0x01”;
proxy-arp;
vlan-tags outer 1 inner 2; # S-VLAN tag is ’1’ and C-VLAN tag is ’2’
family inet { # Specify a secondary loopback address
}
}
}
}
2. Begin configuring hierarchical CoS on the static logical interface set that serves as
the hierarchical scheduler node for the group of subscriber local loops.
[edit]
class-of-service {
interfaces {
interface-set ifset-of-logical-interfaces {
output-traffic-control-profile tcp-premium-with-4–queues;
}
}
}
3. Configure the traffic-control profiles that can be applied to the scheduler node:
[edit]
class-of-service {
tcp-basic-rate { # Specify a scheduler map and traffic controls
shaping-rate 10m;
}
tcp-premium-with-4-queues { # Specify a scheduler map and traffic controls
scheduler-map smap-premium-4q;
shaping-rate 20m;
delay-buffer-rate 5m;
}
}
}
In this example, the tcp-premium-with-4-queues traffic-control profile is applied to

the interface set. The other profile provides a lower shaping rate and no guaranteed
rate.

4. Configure the scheduler map smap-premium-4q that is referenced in the traffic-control

profile for the scheduler node:
[edit]
class-of-service {
scheduler-maps { # Define the queues that comprise each scheduler node
smap-premium-4q { # Map each queue in the scheduler node to a scheduler
}
}
}
5. Configure the four schedulers (referenced in the scheduler map) that define the four
output queues for the scheduler node:
[edit]
class-of-service {
schedulers { # Define scheduling characteristics of each queue
be_sch { # Transmit rate and buffer management parameters
priority low;
}
ef_sch { # Transmit rate and buffer management parameters
...
}
af_sch { # Transmit rate and buffer management parameters
...
}
nc_sch { # Transmit rate and buffer management parameters
...
}
}
}
6. Enable ANCP to communicate with the DSLAM to adjust the CoS shaping rate for the
scheduler node.
You must enable the ANCP feature for performing CoS traffic shaping adjustments,
configure the DSLAM as an ANCP neighbor, and specify the DSLAM-assigned identifier
for the subscriber local loop represented by the scheduler node Optionally specify
byte or percentage adjustments for frame-mode DSL types.
[edit]
protocols {
ancp {
qos-adjust; # Enable ANCP to adjust CoS shaping rates and specify rate adjustments
sdsl-bytes 30;
sdsl-overhead-adjust 87;
vdsl-bytes 20;
vdsl-overhead-adjust 95;
vdsl2-bytes 20;
vdsl2-overhead-adjust 87;
}

neighbor 10.2.3.4; # Configure the DSLAM as an ANCP neighbor

interfaces { # Identify subscribers for which ANCP can adjust shaping rates
interface-set {
ifset-of-logical-interfaces {
access-identifier “dslam port 2/3”; # DSLAM ID for the local loop
}
}
}
}
}
NOTE: If ANCP is not yet enabled, the process starts when you commit a
configuration that contains the protocols ancp stanza.
7. You can display the configured shaping rate and the adjusted shaping rate for each
logical interface set configured for hierarchical CoS, issue the show class-of-service
interface-set operational command.

Documentation
• Guidelines for Configuring Shaping-Rate Adjustments for Subscriber Local Loops on

page 100
Verifying the Configuration of Shaping-Rate Adjustments for Subscriber Local Loops

Purpose Display the configured shaping rate and the adjusted shaping rate for each logical interface
set configured for hierarchical CoS.
NOTE: After shaping-rate adjustments are enabled and the router has
performed shaping-rate adjustments on a scheduler node, you can configure
a new shaping rate by including the shaping-rate statement in a traffic-control
profile and then applying that profile to that scheduler node. However, this
new shaping-rate value does not immediately result in shaping traffic at the
new rate. The scheduler node continues to be shaped at rate set by ANCP.
Only when the ANCP shaping-rate adjustment feature is disabled is the
scheduler node shaped at the newly configured shaping-rate.
Action Issue the show class-of-service interface-set operational command.
Related • Enabling Shaping-Rate Adjustments for Subscriber Local Loops on page 104
Documentation

Verifying the Configuration of ANCP for Shaping-Rate Adjustments

Purpose Use to display or clear information about the ANCP configuration for shaping-rate
adjustments.
Action • To display ANCP neighbor information, issue the show ancp neighbor operational
command.
• To clear ANCP neighbors, issue the clear ancp neighbor operational command.
• To display ANCP subscriber information, issue the show ancp subscriber operational
command.
• To display ANCP class-of-service information, issue the show ancp cos operational
command.
If ANCP is not yet enabled, the process starts when you commit a configuration that
contains the protocols ancp stanza.
Related • ANCP and the ANCP Agent Overview

Documentation
• Configuring the ANCP Agent

CHAPTER 8
Shaping Downstream Traffic Based on

Frames or Cells
• Bandwidth Management for Downstream Traffic in Edge Networks Overview on page 115
• Configuring Dynamic Shaping Parameters to Account for Overhead in Downstream
Traffic Rates on page 117
• Example: Configuring Dynamic Shaping Parameters to Account for Overhead in
Downstream Traffic Rates on page 118
• Configuring Static Shaping Parameters to Account for Overhead in Downstream Traffic
Rates on page 122
• Example: Configuring Static Shaping Parameters to Account for Overhead in
• Setting Shaping Rate and Overhead Accounting Based on PPPoE Vendor-Specific
Tags on page 125
• Configuring the Shaping Rate and Overhead Accounting Based on PPPoE
Vendor-Specific Tags on Dynamic Subscriber Interfaces on page 127
• Reporting the Effective Shaping Rate for Subscribers on page 127
• Verifying the Effective Shaping Rate Reporting Configuration on page 128
Bandwidth Management for Downstream Traffic in Edge Networks Overview
In a subscriber access network, traffic with different encapsulations can be passed

downstream to other customer premise equipment (CPE) through the MX Series router.
Managing the bandwidth of downstream ATM traffic to Ethernet interfaces can be
especially difficult because of the different Layer 2 encapsulations.
The downstream network is not necessarily the directly attached network. In typical
broadband network gateway (BNG) configurations, the directly attached network is an
Ethernet access network, which provides access to either another frame-based network,
or a cell-based network.
The overhead accounting feature enables you to shape traffic based on whether the
downstream network is a frame-based network, like Ethernet, or a cell-based network,
like ATM. It assigns a byte adjustment value to account for different encapsulations.
This feature is available on MIC and MPC interfaces.

Effective Shaping Rate

The shaping-rate, also known as peak information rate (PIR), is the maximum rate for a
scheduler node or queue.
The true rate of a subscriber at the access-loop/CPE is a function of:
• The shaping-rate in effect for the subscriber’s household, in bits per second.
• Whether the subscriber is connected to a frame-based or cell-based network.
• Number of bytes in each frame that are accounted for by the shaper.
NOTE: Chassis egress-shaping-overhead is not included in the effective rate.

Egress-shaping-overhead accounts for the physical interface overhead (ISO
OSI Layer 1). Effective shaping-rate is a Layer 2 (ISO OSI) rate.
Shaping Modes
There are two modes used for adjusting downstream traffic:
• Frame shaping mode is useful for adjusting downstream traffic with different
encapsulations. Shaping is based on the number of bytes in the frame, without regard
to cell encapsulation or padding overhead. Frame is the default shaping mode on the
router.
• Cell shaping mode is useful for adjusting downstream cell-based traffic. In cell shaping
mode, shaping is based on the number of bytes in cells, and accounts for the cell
encapsulation and padding overhead.
When you specify cell mode, the resulting traffic stream conforms to the policing rates
configured in downstream ATM switches, reducing the number of packet drops in the
Ethernet network.
To account for ATM segmentation, the router adjusts all of the rates by 48/53 to
account for 5-byte ATM AAL5 encapsulation. In addition, the router accounts for cell
padding, and internally adjusts each frame by 8 bytes to account for the ATM trailer.
Byte Adjustments
When the downstream traffic has different byte sizes per encapsulation, it is useful to
configure a byte adjustment value to adjust the number of bytes per packet to be included
in or excluded from the shaping mechanism. This value represents the number of bytes
that are encapsulated and decapsulated by the downstream equipment. For example,
to properly account for a 4-byte header stripped by the downstream network, set the
overhead-accounting bytes to -4. To properly account for a 12-byte header added by the
downstream network, set the overhead-accounting bytes to 12.
We recommend that you specify a byte adjustment value that represents the difference
between the CPE protocol overhead and B-RAS protocol overhead.

Chapter 8: Shaping Downstream Traffic Based on Frames or Cells
The system rounds up the byte adjustment value to the nearest multiple of 4. For example,
a value of 6 is rounded to 8, and a value of –10 is rounded to –8.
You do not need to configure a byte adjustment value to account for the downstream
ATM network. However, you can specify the byte value to account for additional
encapsulations or decapsulations in the downstream network.
Relationship with Other CoS Features

Enabling the overhead accounting feature affects the resulting shaping rates, guaranteed
rate, and excess rate parameters, if they are configured.
The overhead accounting feature also affects the egress shaping overhead feature that
you can configure at the chassis level. We recommend that you use the egress
shaping-overhead feature to account for the Layer 2 overhead of the outgoing interface,
and use the overhead-accounting feature to account for downstream traffic with different
encapsulations and cell-based networks.
When both features are configured, the total byte adjustment value is equal to the
adjusted value of the overhead-accounting feature plus the value of the
egress-shaping-overhead feature. For example, if the configured byte adjustment value
is 40, and the router internally adjusts the size of each frame by 8, the adjusted overhead
accounting value is 48. That value is added to the egress shaping overhead of 24 for a
total byte adjustment value of 72.
Related • To configure overhead accounting for static Ethernet interfaces, see Configuring Static
Documentation Shaping Parameters to Account for Overhead in Downstream Traffic Rates on page 122
• To configure overhead accounting for dynamic subscriber access, see Configuring

Dynamic Shaping Parameters to Account for Overhead in Downstream Traffic Rates
on page 117

Tags on page 125
Configuring Dynamic Shaping Parameters to Account for Overhead in Downstream

Traffic Rates
You can configure the overhead accounting feature to shape downstream traffic based
on either frames or cells.
You can also account for the different byte sizes per encapsulation by configuring a byte
adjustment value for the shaping mode.
This feature is supported on MPCs on MX Series routers.
To configure the overhead accounting feature in a dynamic profile:
1. Do one of the following to configure the shaping mode:
• Specify the shaping mode.
Frame shaping mode is enabled by default.

[edit dynamic-profiles profile-name class-of-service traffic-control-profiles

profile-name
user@host#set overhead-accounting (frame-mode | cell-mode)
• Configure a variable for the shaping mode.

profile-name
user@host#set overhead-accounting $junos-cos-shaping-mode
2. (Optional) Do one of the following to configure the byte adjustment value:
• Specify a byte adjustment value.

profile-name
user@host#set overhead-accounting bytes byte-value
• Configure a variable for the byte adjustment.

profile-name
user@host#set overhead-accounting bytes $junos-cos-byte-adjust
BEST PRACTICE: We recommend that you specify a byte adjustment

value that represents the difference between the customer premise
equipment (CPE) protocol overhead and B-RAS protocol overhead.
The available range is –120 through 124 bytes. The system rounds up
the byte adjustment value to the nearest multiple of 4. For example, a
value of 6 is rounded to 8, and a value of -10 is rounded to -8.
Related • Bandwidth Management for Downstream Traffic in Edge Networks Overview on page 115
Documentation
• Example: Configuring Dynamic Shaping Parameters to Account for Overhead in
Example: Configuring Dynamic Shaping Parameters to Account for Overhead in

Downstream Traffic Rates
This topic describes two scenarios for which you can configure dynamic shaping
parameters to account for packet overhead in a downstream network.
The RADIUS administrator supplies the initial values on the RADIUS server, and the service
activation is performed at subscriber login.
Figure 16 on page 119 shows the sample network that the examples reference.

Figure 16: Sample Network Topology for Downstream Traffic

Access Network
BE/BBE
Residential subscriber 1
AF
Gateway 1 subscriber traffic Carrier Network
EF
MX Series
BE/BBE
g017442
Residential DSLAM
AF
Gateway 2 subscriber 2
EF
BE/BBE Best Effort / Better-than-Best Effort

AF Assured Forwarding
EF Expidited Forwarding
Managing Traffic with Different Encapsulations

In this example, the MX Series router shown in Figure 16 on page 119 sends stacked VLAN
frames to the DSLAM, and the DSLAM sends single-tagged VLAN frames to the residential
gateway.
To accurately shape traffic at the residential gateway, the MX Series router must account
for the different frame sizes. The difference between the stacked VLAN (S-VLAN) frames
sent by the router and the single-tagged VLAN frames received at the residential gateway
is a 4-byte VLAN tag. The residential gateway receives frames that are 4 bytes less.
To account for the different frame sizes, you configure the frame shaping mode with -4
byte adjustment:
1. Configure the traffic shaping parameters in the dynamic profile and attach them to
the interface.
Enabling the overhead accounting feature affects the resulting shaping rate,
guaranteed rate, and excess rate parameters, if they are configured.
[edit]
dynamic-profiles {
ethernet-downstream-network {
interfaces {
family inet;
}
}
}
class-of-service {
tcp-example-overhead-accounting-frame-mode {
excess-rate percent $junos-cos-excess-rate
guaranteed-rate $junos-cos-guaranteed-rate
overhead-accounting $junos-cos-shaping-mode bytes $junos-cos-byte-adjust
}
}
interfaces {
}

}
}
}
}
}
the shaping rates.
Table 24: Initial Shaping Values at Subscriber Login For Traffic With
Different Encapsulations
$junos-cos-excess-rate T05 50
$junos-cos-shaping-mode T07 frame-mode
$junos-cos-byte-adjust T08 –4
2. Verify the adjusted rates.
user@host#show class-of-service traffic-control-profile

Traffic control profile: tcp-example-overhead-accounting-frame-mode, Index:
61785
Excess rate 50
Shaping rate: 10000000
Overhead accounting mode: Frame Mode
Overhead bytes: —4
Managing Downstream Cell-Based Traffic

In this example, the DSLAM and residential gateway shown in Figure 16 on page 119 are
connected through an ATM cell-based network. The MX Series router sends Ethernet
frames to the DSLAM, and the DSLAM sends ATM cells to the residential gateway.
for the different physical network characteristics.
The administrator does not need to configure a byte adjustment value to account for the
downstream ATM network, but has the option of configuring a byte adjustment value to
account for different encapsulations or decapsulations.
To account for the different frame sizes, configure cell shaping mode:
1. Configure the traffic shaping parameters in the dynamic profile and attach them to
the interface.

[edit]
dynamic-profiles {
atm-downstream-network {
interfaces {
family inet;
}
}
}
class-of-service {
tcp-example-overhead-accounting-cell-mode {
excess-rate percent $junos-cos-excess-rate
guaranteed-rate $junos-cos-guaranteed-rate
overhead-accounting $junos-cos-shaping-mode
shaping-rate $junos-cos-shaping-rate
}
}
interfaces {
}
}
}
}
}
}
the shaping rates.
Table 25: Initial Shaping Values at Subscriber Login For Downstream

Cell-Based Traffic
$junos-cos-excess-rate T05 50
$junos-cos-shaping-mode T07 cell-mode

Traffic control profile: tcp-example-overhead-accounting-cell-mode, Index:
61785
Excess rate 50
Overhead accounting Cell Mode
Overhead bytes: 0

To account for ATM segmentation, the MX Series router adjusts all of the rates by
48/53 to account for ATM AAL5 encapsulation. In addition, the router accounts for
cell padding, and internally adjusts each frame by 8 bytes to account for the ATM
trailer.
Related • Configuring Dynamic Shaping Parameters to Account for Overhead in Downstream

Documentation Traffic Rates on page 117
Configuring Static Shaping Parameters to Account for Overhead in Downstream Traffic

Rates
The overhead accounting feature enables you to account for downstream traffic that
has different encapsulations or downstream traffic from cell-based equipment, such as
ATM switches.
You can configure the overhead accounting feature to shape downstream traffic based
on frames or cell shaping mode.
You can also account for the different byte sizes per encapsulation by configuring a byte
adjustment value for the shaping mode.
To configure the shaping mode and byte adjustment value for static CoS configurations:
1. Specify the shaping mode.
Frame shaping mode is enabled by default.
[edit class-of-service traffic-control-profiles profile-name]

user@host# set overhead-accounting (frame-mode | cell-mode)
2. (Optional) Specify a byte adjustment value.
[edit class-of-service traffic-control-profiles profile-name

user@host# set overhead-accounting bytes byte-value]
BEST PRACTICE: We recommend that you specify a byte adjustment

value that represents the difference between the customer premise
equipment (CPE) protocol overhead and the B-RAS protocol overhead.
The available range is –120 through 124 bytes. The system rounds up the
byte adjustment value to the nearest multiple of 4. For example, a value
of 6 is rounded to 8, and a value of –10 is rounded to –8.
Documentation

Example: Configuring Static Shaping Parameters to Account for Overhead in

Downstream Traffic Rates
This topic describes two scenarios for which you can configure static shaping parameters
to account for packet overhead in a downstream network.
Figure 16 on page 119 shows the sample network that the examples reference.
Figure 17: Sample Network Topology for Downstream Traffic

Access Network
BE/BBE
Residential subscriber 1
AF
Gateway 1 subscriber traffic Carrier Network
EF
MX Series
BE/BBE
g017442
Residential DSLAM
AF
Gateway 2 subscriber 2
EF
BE/BBE Best Effort / Better-than-Best Effort

AF Assured Forwarding
EF Expidited Forwarding
Managing Traffic with Different Encapsulations

In this example, the MX Series router shown in Figure 16 on page 119 sends stacked VLAN
frames to the DSLAM, and the DSLAM sends single-tagged VLAN frames to the residential
gateway.
for the different frame sizes. The difference between the stacked VLAN (S-VLAN) frames
sent by the router and the single-tagged VLAN frames received at the residential gateway
is a 4-byte VLAN tag. The residential gateway receives frames that are 4 bytes less.
To account for the different frame sizes, the network administrator configures the frame
shaping mode with –4 byte adjustment:
1. The network administrator configure the traffic shaping parameters and attaches
them to the interface.
[edit]
class-of-service {
tcp-example-overhead-accounting-frame-mode {
shaping-rate 10m;
shaping-rate-priority-high 4m;
guaranteed-rate 2m;
overhead-accounting frame-mode bytes -4;
}
}
interfaces {
ge-1/0/0 {

output-traffic-control-profile tcp-example-overhead-accounting-frame-mode;
}
}
}
}
2. The network administrator verifies the adjusted rates.

Traffic control profile: tcp-example-overhead-accounting-frame-mode, Index:
61785
Shaping rate priority high: 4000000
Excess rate 50
Overhead accounting mode: Frame Mode
Overhead bytes: —4
Managing Downstream Cell-Based Traffic

In this example, the DSLAM and residential gateway shown in Figure 16 on page 119 are
connected through an ATM cell-based network. The MX Series router sends Ethernet
frames to the DSLAM, and the DSLAM sends ATM cells to the residential gateway.
for the different physical network characteristics.
To account for the different frame sizes, the network administrator configures the cell
shaping mode with –4 byte adjustment:
1. Configure the traffic shaping parameters and attach them to the interface.
[edit]
class-of-service {
tcp-example-overhead-accounting-cell-mode {
shaping-rate 10m;
shaping-rate-priority-high 4m;
guaranteed-rate 2m;
overhead-accounting cell-mode;
}
}
interfaces {
ge-1/0/0 {
output-traffic-control-profile tcp-example-overhead-accounting-cell-mode;
}
}
}
}

Traffic control profile: tcp-example-overhead-accounting-cell-mode, Index:

61785
Shaping rate priority high: 4000000
Excess rate 50
Overhead accounting mode: Cell Mode
Overhead bytes: 0
To account for ATM segmentation, the MX Series router adjusts all of the rates by
48/53 to account for ATM AAL5 encapsulation. In addition, the router accounts for
cell padding, and internally adjusts each frame by 8 bytes to account for the ATM
trailer.
Related • Configuring Static Shaping Parameters to Account for Overhead in Downstream Traffic
Documentation Rates on page 122
Setting Shaping Rate and Overhead Accounting Based on PPPoE Vendor-Specific

Tags
You can use access line parameters in PPPoE discovery packets to set the shaping-rate
and overhead-accounting class-of-service attributes on dynamic subscriber interfaces
in a broadband access network. This feature is supported on MPC/MIC interfaces on MX
Series routers.
The shaping rate is based on the actual-data-rate-downstream attribute.
The overhead accounting value is based on the access-loop-encapsulation attribute

and specifies whether the access loop uses Ethernet (frame mode) or ATM (cell mode).
You can configure class-of-service attributes, for example the shaping-rate, using the
CLI, RADIUS vendor-specific attributes, ANCP, multicast, or in this case, PPPoE
vendor-specific tags.
CLI Interaction with PPPoE Vendor-Specific Tags

When you enable this feature, the values supplied by the PPPoE vendor-specific tags
override the parameters that you have configured in the CLI for the shaping-rate and
overhead-accounting statements at the [edit dynamic-profiles profile-name class-of-service
traffic-control-profiles] hierarchy level. The shaping rate is based on the
actual-data-rate-downstream attribute, and is only overridden if the vs-tag value is less
than the configured value.
To enable this feature, include the actual-data-rate-downstream or

access-loop-encapsulation option with the vendor-specific-tags statement at the [edit
dynamic-profiles profile-name class-of-service dynamic-class-of-service-options] hierarchy
level.
RADIUS Interaction with PPPoE Vendor-Specific Tags

When you enable this feature, the PPPoE vendor-specific tags override the dynamic
configuration of the shaping-rate and overhead-accounting values in RADIUS

vendor-specific attributes. The shaping-rate value is only overridden if the vs-tag value
is less than the RADIUS value.
RADIUS CoA can overwrite the existing values. Upon receipt of a RADIUS CoA, the RADIUS
value overrides the value set from the PPPoE vendor-specific tags.
PPPoE vendor-specific tags can override the RADIUS values, but a later RADIUS CoA
request can then override that value.
ANCP Interaction with PPPoE Vendor-Specific Tags

You can mix ANCP and PPPoE vendor-specific tags on dynamic PPPoE interfaces,
dynamically instantiated PPPoE interfaces, and ACI-sets. ANCP values override the
PPPoE values. In this case, the ANCP shaping rate value overrides the PPPoE value.
Multicast QoS Adjustment Interaction with PPPoE Vendor-Specific Tags

Multicast QoS adjustments are not affected by this feature. The multicast adjustments
adjust the shaping-rate set by PPPoE vendor-specific tags.
Shaping Rate Restrictions

Shaping rate has the following restrictions regarding the downstream-rate:
• If the downstream-rate is less than the configured shaping-rate (as set in the CLI or
using RADIUS attributes) then it is applied, subject to other restrictions. If the
downstream-rate is greater than or equal to the configured shaping-rate, no changes
are performed.
• The downstream-rate cannot be less than a configured guaranteed-rate. If it is, the

downstream-rate is set to the guaranteed-rate.
• The downstream-rate cannot be less than a configured adjust-minimum-rate. If it is,

the downstream-rate is set to the adjust-mimimum-rate.
• The downstream-rate cannot be less than 1000 bps. If it is, the downstream-rate is
set to 1000 bps.
• The downstream-rate cannot be less than the sum of the transmit-rates of all queues.
Documentation

Configuring the Shaping Rate and Overhead Accounting Based on PPPoE

Vendor-Specific Tags on Dynamic Subscriber Interfaces
To configure the PPPoE vendor-specific tags feature in a dynamic profile:
NOTE: When you enable this feature, the values supplied by the PPPoE
vendor-specific tags override the parameters that you have configured for
shaping-rate and overhead-accounting statements at the [edit
dynamic-profiles profile-name class-of-service traffic-control-profile] hierarchy
level.
1. (Optional) To configure the shaping rate based on access line information:
[edit dynamic-profiles profile-name class-of-service dynamic-class-of-service-options]

user@host# set vendor-specific-tags actual-data-rate-downstream
2. (Optional)To configure the overhead-accounting based on access-line information:

user@host# set vendor-specific-tags access-loop-encapsulation
Related • Setting Shaping Rate and Overhead Accounting Based on PPPoE Vendor-Specific
Documentation Tags on page 125
Reporting the Effective Shaping Rate for Subscribers
The Effective-Shaping-Rate VSA [26–177] provides the best estimate for a subscriber’s
downstream traffic rate for accounting purposes. The VSA is included in RADIUS
Acct-Start, Acct-Stop, and Interim-Acct messages. The reported rate is the rate enforced
on the L3, L2, or L1 node according to local policy. The value of the VSA varies depending
on your configuration:
• Actual rate—When effective shaping rate reporting is enabled.
• Advisory rate—When the advisory rate is configured and effective shaping rate reporting
is not enabled.
• Port speed—When the advisory rate is not configured and effective shaping rate
reporting is not enabled.
When you disable reporting, the VSA reports either the advisory rate or port speed for
both existing subscribers and new subscribers that log in after reporting is disabled.
To enable reporting of the actual downstream traffic rate:
• Enable reporting.
[edit chassis]
user@host1# set effective-shaping-rate

NOTE: When the traffic control profile for the subscriber specifies cell-mode,
the effective shaping rate does not account for cell padding according to the
encapsulation type. The rate includes the 48/53 cell tax.
Related • Verifying the Effective Shaping Rate Reporting Configuration on page 128
Documentation
• Juniper Networks VSAs Supported by the AAA Service Framework
• AAA Accounting Messages and Supported RADIUS Attributes and Juniper Networks VSAs
for Junos OS
Verifying the Effective Shaping Rate Reporting Configuration

Purpose Verify whether reporting is enabled for the effective shaping rate. Display the effective
shaping rate when reporting is enabled.
Action • To display configuration information for effective shaping rate reporting:
[edit]
user@host# show chassis
...
effective-shaping-rate;
...
• To display the effective shaping rate in kilobits per second when reporting is enabled:
user@host> show subscribers extensive

Type: VLAN
Logical System: default
Routing Instance: default
Interface: demux0.1073741837
Interface type: Dynamic
Interface Set: ifset-1
Underlying Interface: ae1
Dynamic Profile Name: svlan-dhcp-test
State: Active
Session ID: 1
Stacked VLAN Id: 0x8100.201
VLAN Id: 0x8100.201
Login Time: 2011-11-30 00:18:04 PST
Effective shaping-rate: 31000000
...
Related • Reporting the Effective Shaping Rate for Subscribers on page 127
Documentation

CHAPTER 9
Applying CoS to Households or Individual

Subscribers Using ACI-Based Dynamic
VLANs
• Agent Circuit Identifier-Based Dynamic VLANs Bandwidth Management

Overview on page 129
• Restrictions for Configuring Adjustment of CoS Shaping Rate and Overhead Accounting
for Dynamic ACI Interface Sets on page 132
• Adjusting the CoS Shaping Rate and Overhead Accounting Parameters for Agent Circuit
Identifier-Based Dynamic VLANs on page 133
Agent Circuit Identifier-Based Dynamic VLANs Bandwidth Management Overview
A router in a subscriber access network ensures class of service (CoS) for dynamic
subscriber interfaces. An MX Series router with Modular Port Concentrator/Modular
Interface Card (MPC/MIC) interfaces ensures that subscribers receive an adequate
minimum bandwidth, referred to as the guaranteed rate, and maximum bandwidth,
referred to as the shaping rate. For dynamic VLAN subscriber interfaces based on agent
circuit identifier (ACI) information, you can shape the bandwidth either at a per-household
level for a dynamic ACI interface set, or at a per-subscriber level for a dynamic VLAN
subscriber interface associated with an ACI interface set.
To help you manage bandwidth more efficiently and economically for ACI-based dynamic
VLAN subscriber interfaces for PPPoE subscribers, you can configure the router to use
specific PPPoE vendor-specific attributes (VSAs) found in PPPoE control packets to
adjust the CoS shaping-rate and overhead-accounting attributes for dynamic ACI interface
sets and their associated ACI-based dynamic VLAN subscriber interfaces.
This overview covers the following topics:
• CoS Shaping Rate Adjustment on page 130

• CoS Overhead Accounting Adjustment on page 130
• Dynamic Profiles and Adjustment of CoS Shaping Rate and Overhead
Accounting on page 131
• Guidelines for Configuring Adjustment of CoS Shaping Rate and Overhead
Accounting on page 132

CoS Shaping Rate Adjustment

The CoS shaping rate adjustment is based on the value of the
Actual-Data-Rate-Downstream DSL Forum VSA [26-130] found in PPPoE Active
Discovery Initiation (PADI) and PPPoE Active Discovery Request (PADR) control packets
for PPPoE traffic. The Actual-Data-Rate-Downstream VSA contains the actual
downstream data rate, in bits per second, of the subscriber’s synchronized digital
subscriber line (DSL) link.
To configure the router to use the Actual-Data-Rate-Downstream VSA to adjust the CoS
shaping-rate attribute, include the vendor-specific-tags statement with the
actual-data-rate-downstream option at the [edit dynamic-profiles profile-name
class-of-service dynamic-class-of-service-options] hierarchy level in either the dynamic
profile that defines the ACI interface set or the dynamic profile that configures the
associated dynamic PPPoE (pp0) subscriber interface.
When you enable this feature, the value of the Actual-Data-Rate-Downstream VSA
overrides the shaping-rate value configured at the [edit dynamic-profiles profile-name
class-of-service traffic-control-profiles] hierarchy level only if the
Actual-Data-Rate-Downstream VSA value is less than the shaping-rate value configured
with the CLI.
CoS Overhead Accounting Adjustment

The CoS overhead accounting adjustment is based on the value of the
Access-Loop-Encapsulation DSL Forum VSA [26-144] found in PADI and PADR control
packets for PPPoE traffic. The Access-Loop-Encapsulation VSA identifies the
encapsulation used by the subscriber associated with the digital subscriber line access
multiplexer (DSLAM) access loop from which requests are initiated.
The value of the Data Link subfield in the Access-Loop-Encapsulation VSA determines
the overhead accounting mode in use on the access loop. If the Data Link subfield value
is 0 (ATM Adaptation Layer 5, or AAL5), the access loop uses cell-mode encapsulation.
If the Data Link subfield value is 1 (Ethernet), the access loop uses frame-mode
encapsulation.
In subscriber access networks where the router passes downstream ATM traffic to
Ethernet interfaces, the different Layer 2 encapsulations between the router and the
PPPoE Intermediate Agent on the DSLAM make managing the bandwidth of downstream
ATM traffic difficult. Using the Access-Loop-Encapsulation VSA to shape traffic based
on frames or cells enables the router to adjust the overhead-accounting attribute in order
to apply the correct downstream rate for the subscriber.
To configure the router to use the Access-Loop-Encapsulation VSA to adjust the CoS
overhead-accounting attribute, include the vendor-specific-tags statement with the
access-loop-encapsulation option at the [edit dynamic-profiles profile-name
class-of-service dynamic-class-of-service-options] hierarchy level in either the dynamic
profile that defines the ACI interface set or the dynamic profile that configures the
associated dynamic PPPoE (pp0) subscriber interface.

Chapter 9: Applying CoS to Households or Individual Subscribers Using ACI-Based Dynamic VLANs
When you enable this feature, the value of the Access-Loop-Encapsulation VSA always
overrides the overhead-accounting value configured at the [edit dynamic-profiles
profile-name class-of-service traffic-control-profiles] hierarchy level.
Dynamic Profiles and Adjustment of CoS Shaping Rate and Overhead Accounting
When you configure the router to use one or both of the Actual-Data-Rate-Downstream
VSA value and Access-Loop-Encapsulation VSA value to adjust the CoS shaping rate
and overhead accounting attributes, respectively, the router adjusts these attributes
when the dynamic ACI interface set is created and the router receives the PADI and PADR
packets from the first subscriber interface belonging to the ACI interface set.
You can configure CoS adjustment based on either or both VSAs in either or both of the
following dynamic profiles:
• To configure adjustment of the CoS shaping rate and overhead accounting on a

per-household basis, use the dynamic profile that defines the dynamic ACI interface
set.
• To configure adjustment of the CoS shaping rate and overhead accounting on a

per-subscriber basis, use the dynamic profile that defines the ACI-based dynamic
PPPoE (pp0) subscriber interface associated with the ACI interface set.
Table 26 on page 131 summarizes how the dynamic profile in which you configure CoS
adjustment for ACI-based dynamic VLANs using one or both VSAs affects the router
behavior.
Table 26: CoS Adjustment in Dynamic Profiles for ACI Interface Sets and
ACI-Based Subscriber Interfaces
VSAs Specified in ACI VSAs Specified in PPPoE
Interface Set Dynamic Subscriber Interface
Profile Dynamic Profile Result
Yes No Router adjusts specified CoS

attributes only for dynamic ACI
interface set
No Yes Router adjusts specified CoS

attributes only for ACI-based
dynamic PPPoE subscriber
interface
Yes Yes Router adjusts specified CoS

attributes for both dynamic ACI
interface set and ACI-based
interface
No No Router does not adjust CoS

attributes for either the dynamic
ACI interface set or the ACI-based
interface

Guidelines for Configuring Adjustment of CoS Shaping Rate and Overhead Accounting
You can also configure the router to use the Actual-Data-Rate-Downstream VSA and
Access-Loop-Encapsulation VSA values in PPPoE control packets to adjust the CoS
shaping rate and overhead accounting attributes, respectively, for dynamic subscriber
interfaces not associated with dynamic ACI interface sets.
With the exception of the constraints described in “Restrictions for Configuring Adjustment
of CoS Shaping Rate and Overhead Accounting for Dynamic ACI Interface Sets” on
page 132, most of the guidelines and restrictions that apply to this feature for use with
non–ACI-based dynamic subscriber interfaces also apply to its use for dynamic ACI
interface sets and their associated ACI-based dynamic VLAN subscriber interfaces.
Restrictions for Configuring Adjustment of CoS Shaping Rate and Overhead Accounting
for Dynamic ACI Interface Sets
The following restrictions apply when you configure the router to use the
Actual-Data-Rate-Downstream VSA and Access-Loop-Encapsulation vendor-specific
attribute (VSA) values in PPPoE control packets to adjust the CoS shaping rate and
overhead accounting attributes, respectively, for dynamic ACI interface sets and their
associated agent circuit identifier (ACI)-based dynamic VLAN subscriber interfaces:
• You cannot configure adjustment of CoS shaping rate and overhead accounting
attributes based on Actual-Data-Rate-Downstream VSA and
Access-Loop-Encapsulation VSA values that the router receives from the following
sources:
• RADIUS servers
• Access Node Control Protocol (ANCP) access loop information
• Dynamic Host Configuration Protocol (DHCP) discovery packets
• You cannot use this feature to report information about the PPPoE VSA values to
RADIUS.
• You cannot use this feature to configure CoS adjustment of upstream data traffic on
a dynamic ACI interface set.
Related • Agent Circuit Identifier-Based Dynamic VLANs Bandwidth Management Overview on


Chapter 9: Applying CoS to Households or Individual Subscribers Using ACI-Based Dynamic VLANs

Tags on page 125
Adjusting the CoS Shaping Rate and Overhead Accounting Parameters for Agent Circuit
Identifier-Based Dynamic VLANs
You can configure the router to use either or both of the Actual-Data-Rate-Downstream
[26-130] or Access-Loop-Encapsulation [26-144] DSL Forum vendor-specific attribute
(VSA) values in PPPoE control packets to adjust the CoS shaping-rate and
overhead-accounting attributes, respectively, for dynamic agent circuit identifier (ACI)
interface sets and their associated ACI-based dynamic VLAN subscriber interfaces.
Before you begin:
• To configure adjustment of the CoS shaping rate and overhead accounting attributes
on a per-household basis, create a dynamic profile that defines the dynamic ACI
interface set.
See Defining Agent Circuit Identifier Interface Sets.
• To configure adjustment of the CoS shaping rate and overhead accounting attributes
on a per-subscriber basis, create a dynamic profile that defines the ACI-based dynamic
PPPoE (pp0) subscriber interface associated with the ACI interface set.
See Configuring Dynamic VLAN Subscriber Interfaces Based on Agent Circuit Identifier
Information.
To configure the router to use the Actual-Data-Rate-Downstream or

Access-Loop-Encapsulation VSA values in PPPoE control packets to adjust the CoS
shaping-rate and overhead-accounting attributes for dynamic ACI interface sets and
associated ACI-based dynamic VLAN subscriber interfaces, do either or both of the
following:
• In a dynamic profile for an ACI interface set or a dynamic profile for an ACI-based
PPPoE subscriber interface, configure adjustment of the CoS shaping-rate attribute
based on the value of the Actual-Data-Rate-Downstream VSA.

user@host# set vendor-specific-tags actual-data-rate-downstream
• In a dynamic profile for an ACI interface set or a dynamic profile for an ACI-based
PPPoE subscriber interface, configure adjustment of the CoS overhead-accounting
attribute based on the value of the Access-Loop-Encapsulation VSA.

user@host# set vendor-specific-tags access-loop-encapsulation
Related • Agent Circuit Identifier-Based Dynamic VLANs Bandwidth Management Overview on


• Configuring Dynamic VLANs Based on Agent Circuit Identifier Information

CHAPTER 10
Managing Excess Bandwidth Distribution

and Traffic Bursts
• Excess Bandwidth Distribution on MIC and MPC Interfaces Overview on page 135
• Traffic Burst Management on MIC and MPC Interfaces Overview on page 136
• Managing Excess Bandwidth Distribution for Dynamic CoS on MIC and MPC
Excess Bandwidth Distribution on MIC and MPC Interfaces Overview
Service providers often used tiered services to provide bandwidth for excess traffic as
traffic patterns vary. By default, excess bandwidth between a configured guaranteed
rate and shaping rate is shared equally among all queues on MIC and MPC interfaces,
which might not be optimal for all subscribers to a service.
You can adjust this distribution by configuring the rates and priorities for the excess
bandwidth.
By default, when traffic exceeds the shaping or guaranteed rates, the system demotes
traffic with guaranteed high (GH) priority and guaranteed medium (GM) priority. You can
disable this priority demotion for the MIC and MPC interfaces in your router.
Related • Managing Excess Bandwidth Distribution on Static Interfaces on MICs and MPCs
Documentation
• Managing Excess Bandwidth Distribution for Dynamic CoS on MIC and MPC Interfaces
on page 138
• Per-Priority Shaping on MIC and MPC Interfaces Overview
• Traffic Burst Management on MIC and MPC Interfaces Overview on page 136

Traffic Burst Management on MIC and MPC Interfaces Overview
You can manage the impact of bursts of traffic on your network by configuring a burst-size
value with the shaping rate or the guaranteed rate. The value is the maximum bytes of
rate credit that can accrue for an idle queue or scheduler node. When a queue or node
becomes active, the accrued rate credits enable the queue or node to catch up to the
configured rate.
Figure 18: Sample Burst Shaping Rates

50,000,000
40,000,000 shaping-rate-priority-high 30m burst-size 1g
shaping-rate-priority-high 30m burst-size 1

Total Rx Rate (bps)
30,000,000
20,000,000
10,000,000
g017567
0
03:38:30 03:39:00 03:39:30 03:40:00
Time elapsed
In Figure 18 on page 136, the network administrator configures a large burst-size value for
the shaping rate, then configures a small burst-size value. The larger burst size is subject
to a maximum value. The smaller burst size is subject to a minimum value that enables
the system to achieve the configured rates.
In both configurations, the scheduler node can burst beyond its shaping rate for a brief
interval. The burst of traffic beyond the shaping rate is more noticeable with the larger
burst size than the smaller burst size.
• Guidelines for Configuring the Burst Size on page 136

• How the System Calculates the Burst Size on page 137
Guidelines for Configuring the Burst Size

Typically, the default burst-size (100 ms) for both scheduler nodes and queues on MIC
and MPC interfaces is adequate for most networks. However, if you have intermediate
equipment in your network that has very limited buffering and is intolerant of bursts of
traffic, you might want to configure a lower value for the burst size.
Use caution when selecting a different burst size for your network. A burst size that is too
high can overwhelm downstream networking equipment, causing dropped packets and
inefficient network operation. Similarly, a burst size that is too low can prevent the network
from achieving your configured rate.

Chapter 10: Managing Excess Bandwidth Distribution and Traffic Bursts
When configuring a burst size, keep the following considerations in mind:
• The system uses an algorithm to determine the actual burst size that is implemented
for a node or queue. For example, to reach a shaping rate of 8 Mbps, you must allocate
1Mb of rate credits every second. A shaping rate of 8 Mbps with a burst size of 500,000
bytes of rate-credit per seconds enables the system to transmit at most 500,000
bytes, or 4 Mbps. The system cannot implement a burst size that prevents the rate
from being achieved.
For more information, see “How the System Calculates the Burst Size” on page 137.
• There are minimum and maximum burst sizes for each platform, and different nodes
and queue types have different scaling factors. For example, the system ensures the
burst cannot be set lower than 1 Mbps for a shaping rate of 8 Mbps. To smoothly shape
traffic, rate credits are sent much faster than once per second. The interval at which
rate credits are sent varies depending on the platform, the type of rate, and the
scheduler level.
• When you have configured adjustments for the shaping rate (either by percentage or
through an application such as ANCP or Multicast OIF), the system bases the default
and minimum burst-size calculations on the adjusted shaping rate.
• When you have configured cell shaping mode to account for ATM cell tax, the system
bases the default and minimum burst-size calculations on the post-tax shaping rate.
• The guaranteed rate and shaping rate share the value specified for the burst size. If
the guaranteed rate has a burst size specified, that burst size is used for the shaping
rate; if the shaping rate has a burst size specified, that bursts size is used for the
guaranteed rate. If you have specified a burst size for both rates, the system uses the
lesser of the two values.
• The burst size configured for the guaranteed rate cannot exceed the burst-size
configured for the shaping rate. The system generates a commit error.
• If you have not configured a guaranteed rate, logical interfaces and interface sets
receive a default guaranteed rate from the port speed. Queues receive a default
guaranteed rate from the parent logical interface or interface set.
How the System Calculates the Burst Size

When calculating the burst size, the system uses an exponent of a power of two. For
example:
Shaping-rate in bps * 100 ms / (8 bits/byte * 1000 ms/s) = 1,875,000 bytes
The system then rounds this value up. For example, the system uses the following
calculation to determine the burst size for a scheduler node with a shaping rate of 150
Mbps:
Max (Shaping rate, Guaranteed rate) bps * 100 ms / (8 bits/byte * 1000 ms/s) = 1,875,000
bytes
Rounded up to the next higher power of two = 2,097,150 (which is 2**21, or 0x200000)

The system assigns a single burst size to each of the following rate pairs:
• Shaping rate and guaranteed rate
• Guaranteed high (GH) and guaranteed medium (GM)
• Excess high (EH) and excess low (EL)
• Guaranteed low (GL)
To calculate the burst size for each pair, the system:
• Uses the configured burst-size if only one of the pair is configured.
• Uses the lesser of the two burst sizes if both values are configured.
• Uses the next lower power of two.
• To calculate the minimum burst size, the system uses the greater of the two rates.
Related • Per-Priority Shaping on MIC and MPC Interfaces Overview

Documentation
• Managing Excess Bandwidth Distribution on Static Interfaces on MICs and MPCs
Managing Excess Bandwidth Distribution for Dynamic CoS on MIC and MPC Interfaces
Service providers often used tiered services that must utilize excess bandwidth as traffic
patterns vary. By default, excess bandwidth between a configured guaranteed rate and
shaping rate is shared equally among all queues with the same excess priority value,
which might not be optimal for all subscribers to a service.
This feature is supported for MIC and MPC interfaces on MX Series routers.
To configure parameters to manage excess bandwidth for subscriber interfaces:
1. Configure the parameters for the interface.
a. Configure the guaranteed and shaping rates.
i. Configure the guaranteed rate:

profile-name]
user@host# set guaranteed-rate(rate | $junos-cos-guaranteed-rate) <burst-size
(bytes | $junos-cos-guaranteed-rate-burst)>
ii. Configure the shaping rate:

profile-name]
user@host# set shaping-rate (rate | $junos-cos-shaping-rate) <burst-size (bytes
| $junos-cos-shaping-rate-burst)>
TIP: On MPC/MIC interfaces, the guaranteed rate and the shaping rate
share the value specified for the burst size. If the guaranteed rate has

Chapter 10: Managing Excess Bandwidth Distribution and Traffic Bursts
a burst size specified, it is used for the shaping rate; if the shaping rate
has a burst size specified, it is used for the guaranteed rate. If you have
specified a burst for both rates, the system uses the lesser of the two
values.
b. Configure a rate for excess bandwidth.
You can configure an excess rate for all priorities of traffic:

profile-name]
user@host# set excess-rate (percent percentage | $junos-cos-excess-rate) |
proportion value )
Optionally, you can configure an excess rate specifically for high- and low-priority
traffic. When you configure the excess-rate statement for an interface, you cannot
also configure the excess-rate-low and excess-rate-high statements.

profile-name]
user@host# set excess-rate-high(percent percentage |
$junos-cos-excess-rate-high) | proportion value )
user@host# set excess-rate-low (percent percentage | $junos-cos-excess-rate-low)
| proportion value )
BEST PRACTICE: We recommend that you configure either a

percentage or a proportion of the excess bandwidth for all schedulers
with the same parent in the hierarchy. For example, if you configure
interface 1.1 with twenty percent of the excess bandwidth, configure
interface 1.2 with eighty percent of the excess bandwidth.
2. (Optional) Configure parameters for the queue.
a. Configure the shaping rate.
[edit dynamic-profiles profile-name class-of-service scheduler scheduler-name]

user@host#set shaping-rate (rate | $junos-cos-scheduler-shaping-rate) <burst-size
bytes>
b. Configure the excess rate.

user@host#set excess-rate (percent percentage | percent
$junos-cos-scheduler-excess-rate)
c. (Optional) Configure the priority of excess bandwidth for the queue.

user@host#set excess-priority (low | high | $junos-cos-scheduler-excess-priority
| none)

TIP:
For queues, you cannot configure the excess rate or excess priority in
these cases:
• When the transmit-rate exact statement is configured. In this case,

the shaping rate is equal to the transmit rate and the queue does not
operate in the excess region.
• When the scheduling priority is configured as strict-high. In this case,

the queue gets all available bandwidth and never operates in the
excess region.
By default, when traffic exceeds the shaping or guaranteed rates, the

system demotes traffic configured with high or medium priority. To
disable priority demotion, specify the none option. You cannot configure
this option for queues configured with transmit-rate expressed as a
percent and when the parent’s guaranteed rate is set to zero.

CHAPTER 11
Configuring Targeted Distribution of

Demux Subscribers on Aggregated
Ethernet Interfaces

• Providing Accurate Scheduling for a Demux Subscriber Interface of Aggregated Ethernet
Links on page 144
• Configuring the Distribution Type for Demux Subscribers on Aggregated Ethernet
• Configuring Link and Module Redundancy for Demux Subscribers in an Aggregated
Ethernet Interface on page 146
• Configuring Rebalancing of Demux Subscribers in an Aggregated Ethernet
• Example: Separating Targeted Multicast Traffic for Demux Subscribers on Aggregated
Ethernet Interfaces on page 147
• Verifying the Distribution of Demux Subscribers in an Aggregated Ethernet
• Configuring the Distribution Type for PPPoE Subscribers on Aggregated Ethernet
• Verifying the Distribution of PPPoE Subscribers in an Aggregated Ethernet
Distribution of Demux Subscribers in an Aggregated Ethernet Interface
This topic describes the distribution options available for demux subscriber interfaces
over aggregated Ethernet.
Distribution Models
By default, the system supports hash-based distribution for all subscriber interface types
in an aggregated Ethernet bundle configured without link protection. In this model, traffic
for a logical interface can be distributed over multiple links in the bundle. This model is
desirable when there are many flows through the logical interface and you need to load
balance those flows.

Note that if the distribution flows are not even, egress CoS scheduling can be inaccurate.
In addition, scheduler resources are required on every link of the aggregated Ethernet
interface. For example, if subscriber traffic is allocated 10 MB for a triple-play service over
four links in a bundle, each of the links could receive 2.5 MB of traffic. High-density services
such as video could be limited by the bandwidth on one of the links.
Targeted distribution enables you to target the egress traffic for an IP or VLAN demux
subscriber on a single member link, using a single scheduler resource. To achieve load
balancing over the member links, the system distributes the subscriber interfaces equally
among the links. This enables the subscriber that is allocated 10 MB to be accurately
scheduled as the traffic flows through.
Sample Targeted Distribution Topology

Figure 19 on page 142 displays a sample targeted distribution of subscriber traffic across
links in an aggregated Ethernet interface. A primary and backup link is allocated for each
subscriber.
Figure 19: Targeted Subscriber Links

Layer 3 CoS schedulers GE-x.1 GE-y.1 GE-x.2 GE-z.2 GE-y.3 GE-z.3
demux0.1 demux0.2 demux0.3
Remaining Remaining Remaining

Layer 1 CoS schedulers GE-x GE-y GE-z
scheduler scheduler scheduler
AE bundle
The blue Layer 3 scheduler
g017525
represents the primary. Access Node
For example, if link GE-x went down, subscriber 1 can begin forwarding over the backup,
which is link Ge-y. When link GE-y comes back up, subscriber 1 switches back to its primary
link, GE-x.
In the event that both GE-x and GE-y go down, subscriber 3 starts forwarding through its
backup, GE-z. Subscriber 1 will have lost its primary and backup links, and will also begin
forwarding out the GE-z link. A new level 3 scheduler is assigned for this subscriber on
link GE-z. If there is a momentary lapse between the time that a new scheduler is allocated
and forwarding switches to GE-z, the traffic will be forwarding through to the remaining
scheduler. Subscriber 2 continues to forward through its primarily link, GE-z.
Redundancy and Redistribution Mechanisms

Two types of redundancy are available in the targeted distribution model: link redundancy
and module redundancy.

Chapter 11: Configuring Targeted Distribution of Demux Subscribers on Aggregated Ethernet Interfaces
By default, an aggregated Ethernet interface is enabled with link redundancy. Backup

links for a subscriber are chosen based on the link with the least number of subscribers,
which provides redundancy if a link fails.
The module redundancy option enables you to provide redundancy if a module or a link
fails. Backup links for a subscriber are chosen on a different DPC or MPC from the primary
link, based on the link with the least number of subscribers among the links on different
modules. You can enable this for the aggregated Ethernet interface.
When links are removed, affected subscribers are redistributed among the active remaining
backup links. When links are added to the system, no automatic redistribution occurs.
New subscribers are assigned to the links with the fewest subscribers (which are typically
the new links).
Considerations and Best Practices

Keep the following guidelines in mind when configuring targeted distribution for demux
subscribers:
• You can manage subscribers with both hash-based and targeted distribution models
in the same network. For example, you can allocate subscribers with interface types
such as PPPoE with hash-based distribution, and enable demux subscribers with
targeted distribution.
• We recommend that you configure module redundancy to protect against module

failures. When module redundancy is enabled, you can ensure an even distribution of
subscribers if you allocate no more than 50 percent of the links on a single DPC or MPC.
• During normal network operations, the system maintains an even balance of subscribers
among the links in a bundle, even as subscribers log in and out. However, if the
distribution of a bundle becomes uneven (for example, when a link goes down and
new subscribers are logging in), you can perform a manual rebalance of the bundle. In
addition, you can configure periodic rebalancing of the bundle with a specific time
interval.
• When you anticipate that a link will be down for an extended time, and you want to
ensure that backup links are provisioned for all subscribers, we recommend that you
remove the failed link from the bundle. This forces the affected subscribers to
redistribute to other links.
• We recommend that you apply a remaining traffic-control profile to the logical interface
to ensure that minimal scheduling parameters are applied to the remaining subscriber
traffic. This provides scheduling for subscribers that do not have schedulers allocated
because they have not been configured or they have been over-provisioned, or because
of scheduler transitions on multiple link failures.
• If you perform a cold restart on the router when it is forwarding active subscribers, the
subscriber interfaces with targeted distribution are assigned to the first links that
become available when the system is initializing so forwarding can begin. To rebalance
the system following a cold restart, perform a manual rebalance of the bundle. In
addition, we recommend that you configure Graceful Routing Engine switchover (GRES)
on the router to enable nonstop forwarding during switchover, and avoid performing
cold restarts.

• To ensure appropriate and predictable targeted distribution, you must configure chassis
network services to use enhanced-ip mode.
• Unless specifically separated, multicast traffic egresses in parallel with unicast traffic,
sharing the CoS hierarchy and aggregated Ethernet flow distribution.
Related • Configuring the Distribution Type for Demux Subscribers on Aggregated Ethernet
Documentation Interfaces on page 145
• Configuring Link and Module Redundancy for Demux Subscribers in an Aggregated

Ethernet Interface on page 146
• Configuring Rebalancing of Demux Subscribers in an Aggregated Ethernet Interface

on page 146
• Static or Dynamic Demux Subscriber Interfaces over Aggregated Ethernet Overview
Providing Accurate Scheduling for a Demux Subscriber Interface of Aggregated Ethernet

Links
Unlike VLAN subscriber interfaces, enabling link protection is not required for configuring
hierarchical CoS on demux interfaces. Instead, we recommend that you enable targeted
distribution on the demux interface to provide accurate scheduling for the aggregated
Ethernet links.
Before you begin, configure the subscriber interface with aggregated Ethernet:
• For static and dynamic IP demux interfaces, see Configuring a Static or Dynamic IP
Demux Subscriber Interface over Aggregated Ethernet.
• For static and dynamic VLAN demux interfaces, see Configuring a Static or Dynamic
VLAN Demux Subscriber Interface over Aggregated Ethernet.
To provide accurate scheduling for a demux subscriber interface of aggregated Ethernet

links:
1. Enable targeted distribution for the demux interface.
See “Configuring the Distribution Type for Demux Subscribers on Aggregated Ethernet
2. Enable hierarchical scheduling on the link aggregation bundle.
See “Configuring Hierarchical CoS for a Subscriber Interface of Aggregated Ethernet

Links” on page 35.
3. (Optional) Enable module redundancy to ensure that CoS resources are provisioned
for the aggregated Ethernet links if a module or a link fails. By default, link redundancy
is supported.
See “Configuring Link and Module Redundancy for Demux Subscribers in an Aggregated
Ethernet Interface” on page 146.

4. (Optional) Configure rebalancing periodically or manually for the subscribers. See

“Configuring Rebalancing of Demux Subscribers in an Aggregated Ethernet Interface”
on page 146.
5. Attach static or dynamic traffic shaping and scheduling parameters at the aggregated
Ethernet logical interface or its underlying physical interface. See:
• Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic

Profile on page 217
• Applying Minimal Shaping and Scheduling to Remaining Subscriber Traffic on

page 218
Documentation
• Verifying the Distribution of Demux Subscribers in an Aggregated Ethernet Interface
on page 157
Configuring the Distribution Type for Demux Subscribers on Aggregated Ethernet

Interfaces
By default, the system supports hash-based distribution of subscriber traffic in aggregated

Ethernet bundles. You can configure the system to target the egress traffic for a subscriber
on a single member link, using a single scheduler resource. The system distributes the
subscriber interfaces equally among the member links.
To configure targeted distribution:
1. Edit the chassis hierarchy level.
[edit]
user@host#edit chassis
2. Enable chassis network services for enhanced-ip mode.
[edit chassis]
user@host#set network-services enhanced-ip
3. Access the logical interface.
[edit]
user@host#edit interfaces demux0 unit logical-unit-number
4. Enable targeted distribution for the interface.
[edit interfaces demux0 unit logical-unit-number]

user@host#set targeted-distribution
Related • Verifying the Distribution of Demux Subscribers in an Aggregated Ethernet Interface


Configuring Link and Module Redundancy for Demux Subscribers in an Aggregated

Ethernet Interface
By default, an aggregated Ethernet bundle with targeted distribution is enabled with link
redundancy. Backup links for a subscriber are chosen based on the link with the fewest
subscribers, which provides redundancy if a link fails.
We recommend that you configure the module redundancy option to provide redundancy
if a module or a link fails. Backup links for a subscriber are chosen on a different DPC or
MPC from the primary link, based on the link with the fewest subscribers among the links
on different modules.
To configure module redundancy for an aggregated Ethernet bundle:
1. Access the aggregated Ethernet bundle for which you want to configure module
redundancy.
edit
user@host# edit interfaces aex aggregated-ether-options
2. Enable module redundancy for the bundle.
[edit interfaces aex aggregated-ether-options]

user@host# logical-interface-fpc-redundancy
Configuring Rebalancing of Demux Subscribers in an Aggregated Ethernet Interface
In a targeted distribution model, the system allocates demux subscriber interfaces equally
among the member links in the aggregated Ethernet interface. When links are removed,
affected subscribers are redistributed among the active remaining backup links. When
links are added to the system, no automatic redistribution occurs. New subscribers are
assigned to the links with the fewest subscribers (which are typically the new links).
During normal network operations, the system maintains an even balance of traffic
among the links in a bundle, even as subscribers log in and out. However, if the distribution
of a bundle becomes uneven (for example, when a link goes down for a period of time
and new subscribers are logging in), you can perform a manual rebalance of the bundle.
In addition, you can configure periodic rebalancing of the bundle with a specific interval.
• Configuring Periodic Rebalancing of Subscribers in an Aggregated Ethernet

• Configuring Manual Rebalancing of Subscribers on an Aggregated Ethernet

Configuring Periodic Rebalancing of Subscribers in an Aggregated Ethernet Interface

If subscribers are frequently logging in and logging out of your network, you can configure
the system to periodically rebalance the links based on a specific time and interval.
To configure periodic rebalancing:
1. Access the aggregated Ethernet interface for which you want to configure periodic
rebalancing.
edit
user@host# edit interfaces aenumber aggregated-ether-options
2. Configure the rebalancing parameters for the interface, including the time and the
interval between rebalancing actions.
[edit interfaces aenumber aggregated-ether-options]

user@host# rebalance-periodic time hour:minute <interval hours>
Configuring Manual Rebalancing of Subscribers on an Aggregated Ethernet Interface

To manually rebalance the subscribers among the links in an aggregated Ethernet bundle
with targeted distribution:
• Issue the request interface rebalance command:
user@host# request interface rebalance interface <interface-name>
Related • Verifying the Distribution of Demux Subscribers in an Aggregated Ethernet Interface

• Configuring the Distribution Type for Demux Subscribers on Aggregated Ethernet

Example: Separating Targeted Multicast Traffic for Demux Subscribers on Aggregated

Ethernet Interfaces
This example shows how to separate targeted multicast traffic from targeted unicast
traffic and send that multicast traffic to a different interface through the use of OIF maps.

Requirements
Before configuring this example, make sure to configure the distribution type for the
interface. See “Configuring the Distribution Type for Demux Subscribers on Aggregated
Ethernet Interfaces” on page 145 for instructions.

Overview
In this example, targeted traffic distribution is already configured on the router.
Dynamically created interfaces each carry their unicast traffic but all multicast traffic is
sent to the GE-5/3/9.0 interface.
Figure 20 on page 148 shows the sample network.
Figure 20: Multicast Traffic Separation Using OIF Mapping
Unicast Traffic Multicast Traffic
Targeted Data
Policy / OIF Map
Dynamic
Demux GE-5/3/9.0
Interface
AE bundle
g017850
Access Node Access Node
Configuration
• Configure an OIF Map Policy on page 149
• Configure a DHCP VLAN Dynamic Profile on page 150
• Configure a VLAN Demux Dynamic Profile on page 151
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
set policy-options policy-statement OIF-v4-all term oif539 from route-filter 224 .0.0.0/4
orlonger
set policy-options policy-statement OIF-v4-all term oif539 then map-to-interface
ge-5/3/9.0
set policy-options policy-statement OIF-v4-all term oif539 then accept
set dynamic-profiles dhcp-vlan-prof interfaces "$junos-interface-ifd-name" unit
"$junos-underlying-interface-unit" family inet unnumbered-address lo0.0
set dynamic-profiles dhcp-vlan-prof interfaces "$junos-interface-ifd-name" unit
"$junos-underlying-interface-unit" family inet unnumbered-address preferred-sour
ce-address 100.20.0.2
set dynamic-profiles demux-vlan-prof interfaces demux0 unit "$junos-interface-un it"
vlan-id "$junos-vlan-id"
demux-options underlying-interface "$junos-interface-ifd-name"


targetted-distribution
family inet unnumbered-address lo0.0
family inet unnumbered-address preferred-source-address 100.20.0.2
set dynamic-profiles demux-vlan-prof protocols igmp interface "$junos-interface- name"
version 2
promiscuous-mode
passive allow-receive
passive send-group-query
oif-map OIF-v4-all
Configure an OIF Map Policy
Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy.
To configure the OIF map:
1. Access the router policy options:
[edit]
user@host#edit policy-options
2. Edit a policy statement.
[edit policy-options]
user@host edit policy-statement OIF-v4-all
3. Create a term for mapping incoming multicast traffic to a specific interface.
[edit policy-options OIF-v4-all]

user@host edit term oif539
4. Define the match condition for the term. In this case, the term matches any route
prefix of 224/4 or longer (all multicast traffic).
[edit policy-options OIF-v4-all term oif539]

user@host set from route-filter 224/4 orlonger
5. Define the action for the term. In this case, when a match occurs, the term accepts
the traffic and maps it to interface GE-5/3/9.0.
[edit policy-options OIF-v4-all term oif539]

user@host set then map-to-interface ge-5/3/9.0
user@host set then accept
Results Confirm your configuration by issuing the show policy-options commands. If the output
does not display the intended configuration, repeat the instructions in this example to
correct the configuration.
[edit]
user@host# show policy-options

policy-statement OIF-v4-all {
term oif539 {
from {
route-filter 224.0.0.0/4 orlonger;
}
then {
map-to-interface ge-5/3/9.0;
accept;
}
}
}
Configure a DHCP VLAN Dynamic Profile
To configure a DHCP VLAN dynamic profile for client access:
1. Create a dynamic VLAN demux profile.
[edit]
user@host#edit dynamic-profiles dhcp-vlan-prof
2. Edit the dynamic profile interface.
[edit dynamic-profiles dhcp-vlan-prof]

user@host edit interfaces $junos-ifd-name
3. Edit the interface unit dynamic variable.
[edit dynamic-profiles demux-vlan-prof interfaces $junos-ifd-name]

user@host edit unit $junos-underlying-interface-unit
4. Edit the interface family.
[edit dynamic-profiles demux-vlan-prof interfaces $junos-ifd-name unit

user@host edit family inet
5. Define the loopback address.
[edit dynamic-profiles demux-vlan-prof interfaces $junos-ifd-name unit

$junos-underlying-interface-unit ]
user@host set unnumbered-address lo0.0 preferred-source-address 100.20.0.2
Results Confirm your configuration by issuing the show dynamic-profiles command. If the output
for the dhcp-vlan-prof dynamic profile does not display the intended configuration, repeat
the instructions in this example to correct the configuration.
[edit]
dhcp-vlan-prof {
interfaces {
family inet {


}
}
}
}
}
Configure a VLAN Demux Dynamic Profile
To configure the OIF map:
1. Create a dynamic VLAN demux profile.
[edit]
user@host#edit dynamic-profiles demux-vlan-prof
2. Edit the dynamic profile demux0 interface.
[edit dynamic-profiles demux-vlan-prof]

user@host edit interfaces demux0
3. Edit the interface unit dynamic variable.
[edit dynamic-profiles demux-vlan-prof interfaces demux0]

user@host edit unit $junos-interface-unit
4. Specify the VLAN ID dynamic variable.
[edit dynamic-profiles demux-vlan-prof interfaces demux0 unit

“$junos-interface-unit”]
user@host set vlan-id $junos-vlan-id
5. Access the demux options.

user@host edit demux-options
6. Define the demux underlying interface.

“$junos-interface-unit” demux-options]
user@host set underlying-interface $junos-interface-ifd-name
7. Specify that dynamically created VLANs are using targeted distribution.

user@host set targeted-distribution
8. Edit the interface family.

user@host edit family inet

9. Define the loopback address.

“$junos-interface-unit” family inet]
user@host set unnumbered-address lo0.0 preferred-source-address 100.20.0.2
10. Edit the dynamic profile IGMP protocol.
[edit dynamic-profiles demux-vlan-prof]

user@host edit protocols igmp
11. Enable IGMP on dynamically created interfaces.
[edit dynamic-profiles demux-vlan-prof protocols igmp]

user@host edit interface $junos-interface-name
12. Specify the IGMP version that you want dynamically created interfaces to use.
[edit dynamic-profiles demux-vlan-prof protocols igmp interface

$junos-interface-name]
user@host set version 2
13. Specify the OIF map that you want dynamically created IGMP interfaces to use.

user@host set oif-map OIF-v4-all
14. Specify that IGMP selectively sends and receives control traffic such as IGMP reports,
queries, and leaves.

user@host set passive allow-receive send-group-query
15. Specify that the interface accepts IGMP reports from hosts on any subnetwork.

user@host set promiscuous-mode
Results Confirm your configuration by issuing the show dynamic-profiles commands. If the output
for the dhcp-vlan-prof dynamic profile does not display the intended configuration, repeat
the instructions in this example to correct the configuration.
[edit]
demux-vlan-prof {
interfaces {
demux0 {
unit "$junos-interface-unit" {
vlan-id "$junos-vlan-id";
demux-options {
underlying-interface "$junos-interface-ifd-name";
}
targetted-distribution;
family inet {

}
}
}
}
protocols {
igmp {
interface "$junos-interface-name" {
version 2;
promiscuous-mode;
passive allow-receive send-group-query;
oif-map OIF-v4-all;
}
}
}
}
...
Verification
• Locate the Multicast Group Member on page 153

• Ensure the Targeting Aggregated Ethernet Interface for the Subscriber is
Functional on page 154
• View the Packets for the Targeted Interface on page 154
Locate the Multicast Group Member
Purpose Locate the dynamic interface and ensure that it is associated with the appropriate IGMP
group.
Action user@host>show igmp group
Interface: demux0.1073741824, Groups: 1

Group: 225.0.0.1
Source: 0.0.0.0
Last reported by: 100.20.0.10
Timeout: 52 Type: Dynamic
Interface: local, Groups: 2
Group: 224.0.0.2
Source: 0.0.0.0
Last reported by: Local
Group: 224.0.0.22
Source: 0.0.0.0
Meaning The first Interface field shows the dynamically created demux interface,
demux0.1073741824, and the Group field immediately below the first Interface field shows
the group, 225.0.0.1, to which the subscriber belongs.

Ensure the Targeting Aggregated Ethernet Interface for the Subscriber is

Functional
Purpose Use the dynamic subscriber interface value to ensure that the targeting aggregated
interface is functional.
Action user@host>show interfaces demux0.1073741824 extensive
Logical interface demux0.1073741824 (Index 810) (SNMP ifIndex 1613)

(Generation 170)
Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.1 ] Encapsulation: ENET2
Demux:
Underlying interface: ae0 (Index 708)
Link:
ge-1/0/0
ge-5/3/7
Targeting summary:
ge-1/0/0, backup, Physical link is Up
ge-5/3/7, primary, Physical link is Up
Traffic statistics:
Input bytes : 862
Output bytes : 3160
Input packets: 3
Output packets: 30
Local statistics:
Input bytes : 862
Output bytes : 3160
Input packets: 3
Output packets: 30
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: 212, Route table: 0
Flags: Sendbcast-pkt-to-re, Unnumbered
Donor interface: lo0.0 (Index 802)
Preferred source address: 100.20.0.2
Meaning The Targeting summary field shows that the primary interface, ge-5/3/7, is up.
View the Packets for the Targeted Interface
Purpose Verify that packet traffic sent to targeted interface GE-5/3/9 consists only of multicast
packets.

Action user@host>show interfaces ge-5/3/9 extensive

Physical interface: ge-5/3/9, Enabled, Physical link is Up
Interface index: 704, SNMP ifIndex: 1605, Generation: 197
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
Flow control: Disabled, Auto-negotiation: Enabled, Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Schedulers : 0
Hold-times : Up 0 ms, Down 0 ms
Current address: 00:21:59:ab:85:2a, Hardware address: 00:21:59:ab:85:2a
Last flapped : 2012-09-26 17:32:24 EDT (6d 20:44 ago)
Statistics last cleared: Never
Traffic statistics:
IPv6 transit statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Dropped traffic statistics due to STP State:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
FIFO errors: 0, Resource errors: 0
Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0

Egress queues: 8 supported, 4 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 0 0 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
Queue number: Mapped forwarding classes

0 best-effort
1 expedited-forwarding
2 assured-forwarding
3 network-control
Active alarms : None
Active defects : None
MAC statistics: Receive Transmit
Total octets 0 113871616
Total packets 0 889620
Unicast packets 0 0

Broadcast packets 0 0
Multicast packets 0 889620
CRC/Align errors 0 0
FIFO errors 0 0
MAC control frames 0 0
MAC pause frames 0 0
Oversized frames 0
Jabber frames 0
Fragment frames 0
VLAN tagged frames 0
Code violations 0
Total errors 0 0
Filter statistics:
Input packet count 0
Input packet rejects 0
Input DA rejects 0
Input SA rejects 0
Output packet count 889620
Output packet pad count 0
Output packet error count 0
CAM destination filters: 0, CAM source filters: 0
Autonegotiation information:
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: Symmetric, Remote fault: OK
Local resolution:
Flow control: None, Remote fault: Link OK
Packet Forwarding Engine configuration:
Destination slot: 0 (0x00)
CoS information:
Direction : Output
CoS transmit queue Bandwidth Buffer Priority Limit
% bps % usec
0 best-effort 95 950000000 95 0 low none
3 network-control 5 50000000 5 0 low none
Interface transmit statistics: Disabled
Logical interface ge-5/3/9.0 (Index 818) (SNMP ifIndex 1597) (Generation 149)
Flags: SNMP-Traps 0x4004000 Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 97857650
Input packets: 0
Output packets: 889620
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Protocol aenet, AE bundle: ae4.0, Generation: 180, Route table: 0
Meaning The MAC statistics Unicast packet field shows that the interface is not transmitting any

unicast packet traffic and the Multicast packet field shows that the total number of
packets being transmitted from the interface are multicast packets.
Verifying the Distribution of Demux Subscribers in an Aggregated Ethernet Interface

Purpose View the distribution status of subscribers that are targeted to links in an aggregated
Ethernet interface.
Action • To display a summary of the distribution of links on the demux interface:
user@host> show interfaces demux0 extensive
• To display the targeted distribution on a specific aggregated Ethernet interface:
user@host> show interfaces targeting aex
• Configuring Rebalancing of Demux Subscribers in an Aggregated Ethernet Interface

on page 146
Configuring the Distribution Type for PPPoE Subscribers on Aggregated Ethernet

Interfaces
By default, the system supports hash-based distribution of subscriber traffic in aggregated

Ethernet bundles. You can configure the system to target the egress traffic for a subscriber
on a single member link, using a single scheduler resource. The system distributes the
subscriber interfaces equally among the member links.
To configure targeted distribution:
1. Edit the chassis hierarchy level.
[edit]
user@host#edit chassis
2. Enable chassis network services for enhanced-ip mode.
[edit chassis]
user@host#set network-services enhanced-ip
3. Access the logical interface.
[edit]
user@host#edit interfaces pp0 unit logical-unit-number
4. Enable targeted distribution for the interface.
[edit interfaces pp0 unit logical-unit-number]

user@host#set targeted-distribution


Documentation
• Verifying the Distribution of PPPoE Subscribers in an Aggregated Ethernet Interface
on page 158
Verifying the Distribution of PPPoE Subscribers in an Aggregated Ethernet Interface

Purpose View the distribution status of subscribers that are targeted to links in an aggregated
Ethernet interface.
Action • To display a summary of the distribution of links on the demux interface:
user@host> show interfaces pp0 extensive
• To display the targeted distribution on a specific aggregated Ethernet interface:
user@host> show interfaces targeting aex

Documentation

CHAPTER 12
Applying CoS Using Parameters Received

from RADIUS
• Subscriber Interfaces That Provide Initial CoS Parameters Dynamically Obtained from
RADIUS on page 159
• CoS Traffic Shaping Attributes for Dynamic Interface Sets and Member Subscriber
Sessions Overview on page 166
• Guidelines for Configuring CoS Traffic Shaping Attributes for Dynamic Interface Sets
and Member Subscriber Sessions on page 168
• Configuring Initial CoS Parameters Dynamically Obtained from RADIUS on page 169
• Configuring Static Default Values for Traffic Scheduling and Shaping on page 170
• Applying CoS Traffic-Shaping Attributes to Dynamic Interface Sets and Member
Subscriber Sessions on page 171
• CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets on page 174
• Example: Configuring Initial CoS Parameters Dynamically Obtained from
RADIUS on page 179
Subscriber Interfaces That Provide Initial CoS Parameters Dynamically Obtained from
RADIUS
You can configure interface-specific CoS parameters that the router obtains when
subscribers log in at appropriately configured static or dynamic subscriber interfaces.
This feature is supported only for interfaces on Enhanced Queuing Dense Port
Concentrators (EQ DPCs) in MX Series 3D Universal Edge Routers.
To configure a dynamic profile to provide initial CoS Services, make sure you understand
the following concepts:
• Dynamic Configuration of Initial CoS in Access Profiles on page 160

• Predefined Variables for Dynamic Configuration of Initial Traffic Shaping on page 160
• Predefined Variables for Dynamic Configuration of Initial Scheduling and
Queuing on page 161

Dynamic Configuration of Initial CoS in Access Profiles

When a router interface receives a join message from a DHCP subscriber, the Junos OS
applies the values configured in the dynamic profile associated with that router interface.
A dynamic profile that is activated through its association with a subscriber interface is
known as an access dynamic profile. You can associate a dynamic profile with a subscriber
interface on the router by including statements at the [edit dynamic-profiles profile-name
class-of-service interfaces] hierarchy level.
The Junos OS supports predefined variables for obtaining a scheduler-map name and
traffic-shaping parameters from the RADIUS authentication server and predefined
variables for obtaining a scheduler name and scheduler parameters from the RADIUS
authentication server. When a client authenticates over a router interface associated
with the access dynamic profile, the router replaces the predefined variables with
interface-specific values obtained from the RADIUS server.
NOTE: To associate dynamically configured initial CoS features with a

subscriber interface, reference Junos OS predefined variables—and not
user-defined variables—in an access dynamic profile for that interface.
Predefined Variables for Dynamic Configuration of Initial Traffic Shaping

You can configure an access dynamic profile that provides initial traffic-shaping
parameters when a subscriber logs in. The Junos OS obtains this information from the
RADIUS server when a subscriber authenticates over the static or dynamic subscriber
interface to which the access dynamic profile is attached.
If you define the Juniper Networks authentication and authorization VSA for CoS
traffic-shaping parameter values (attribute number 26–108) on the RADIUS
authentication server, the RADIUS server includes the values in RADIUS Access-Accept
messages it sends to the router when a subscriber successfully authenticates over the
interface.
To provide an initial scheduler map name and traffic shaping parameters obtained from
the RADIUS authentication server when a subscriber logs in, reference the Junos OS
predefined variables for CoS listed in Table 27 on page 160 in an access dynamic profile
associated with the subscriber interface.
Table 27: CoS Predefined Variables for Scheduler Map and Traffic Shaping
Variable Description
$junos-cos-scheduler-map Scheduler-map name to be dynamically configured in a traffic-control profile in the access

dynamic profile when a subscriber logs in.
NOTE: The scheduler map referenced by the scheduler-map statement can be defined
dynamically (at the [edit dynamic-profiles profile-name class-of-service scheduler-maps]
hierarchy level) or statically (at the [edit class-of-service scheduler-maps] hierarchy level).

Chapter 12: Applying CoS Using Parameters Received from RADIUS
Table 27: CoS Predefined Variables for Scheduler Map and Traffic Shaping (continued)
$junos-cos-shaping-rate Shaping rate to be dynamically configured in a traffic-control profile in the access dynamic
profile when a subscriber logs in. You can configure a RADIUS authentication server to include
this information in the Accept-Accept message when a subscriber successfully authenticates
over the static or dynamic subscriber interface to which the access dynamic profile is attached.
$junos-cos-guaranteed-rate Guaranteed rate to be dynamically configured in a traffic-control profile in the access dynamic
$junos-cos-delay-buffer-rate Delay-buffer rate to be dynamically configured in a traffic-control profile in the access dynamic
Predefined Variables for Dynamic Configuration of Initial Scheduling and Queuing

You can configure an access dynamic profile that provides initial traffic-shaping
parameters when a subscriber logs in. The Junos OS obtains this information from the
RADIUS server when a subscriber authenticates over the static or dynamic subscriber
If you define the Juniper Networks authentication and authorization VSA for CoS
scheduling and queuing parameter values (attribute number 26–146) on the RADIUS
authentication server, the RADIUS server includes the values in RADIUS Access-Accept
messages it sends to the router when a subscriber successfully authenticates over the
interface.
To provide an initial scheduler name and scheduler and queuing parameters obtained
from the RADIUS authentication server when a subscriber logs in, reference the Junos
OS predefined variables listed in Table 28 on page 161 in an access dynamic profile
associated with the subscriber interface.
Table 28: CoS Predefined Variables for Scheduling and Queuing

$junos-cos-scheduler Name of a scheduler to be dynamically configured in the access dynamic

profile. You can configure a RADIUS authentication server to include this
information in the Accept-Accept message when a subscriber successfully
authenticates over the static or dynamic subscriber interface to which the
access dynamic profile is attached.
$junos-cos-scheduler-transmit-rate Transmit rate to be dynamically configured for the scheduler in the access
dynamic profile. You can configure a RADIUS authentication server to include
this information in the Accept-Accept message when a subscriber successfully

Table 28: CoS Predefined Variables for Scheduling and Queuing (continued)
$junos-cos-scheduler-bs Buffer size, as a percentage of total buffer, to be dynamically configured for

the scheduler in the access dynamic profile. You can configure a RADIUS
authentication server to include this information in the Accept-Accept message
when a subscriber successfully authenticates over the static or dynamic
subscriber interface to which the access dynamic profile is attached.
$junos-cos-scheduler-pri Packet-scheduling priority value to be dynamically configured for the scheduler

in the access dynamic profile. You can configure a RADIUS authentication
server to include this information in the Accept-Accept message when a
subscriber successfully authenticates over the static or dynamic subscriber
$junos-cos-scheduler-dropfile-low Name of the drop profile for RED for loss-priority level low to be dynamically
configured for the scheduler in the access dynamic profile. You can configure
a RADIUS authentication server to include this information in the Accept-Accept
message when a subscriber successfully authenticates over the static or
dynamic subscriber interface to which the access dynamic profile is attached.
NOTE: The drop profile must be configured statically (at the [edit
class-of-service schedulers scheduler-name drop-profiles] hierarchy level) for
loss-priority low.
$junos-cos-scheduler-dropfile-medium-low Name of the drop profile for RED for loss-priority level medium-low to be
dynamically configured for the scheduler in the access dynamic profile. The
Junos OS obtains this information from the RADIUS server when a subscriber
class-of-service schedulers scheduler-name drop-profiles] hierarchy level).
$junos-cos-scheduler-dropfile-medium-high Name of the drop profile for RED for loss-priority level medium-high to be
dynamically configured for the scheduler in the access dynamic profile. You
can configure a RADIUS authentication server to include this information in
the Accept-Accept message when a subscriber successfully authenticates
over the static or dynamic subscriber interface to which the access dynamic
profile is attached.
$junos-cos-scheduler-dropfile-high Name of the drop profile for RED for loss-priority level high to be dynamically

Table 28: CoS Predefined Variables for Scheduling and Queuing (continued)
$junos-cos-scheduler-dropfile-any Name of the drop profile for RED for loss-priority level any to be dynamically
Related • Subscriber Activation and Service Management in an Access Network

Documentation
• Dynamic Profiles Overview
• Dynamic Variables Overview
• Junos OS Predefined Variables
• Example: Configuring Initial CoS Parameters Dynamically Obtained from RADIUS on

page 179
Changing CoS Services Overview
This topic describes how to provide CoS when subscribers dynamically upgrade or
downgrade services in an access environment.
You can configure your network with an access profile that provides all subscribers with
default CoS parameters when they log in. For example, all subscribers can receive a basic
data service. By configuring the access profile with Junos OS predefined variables for
RADIUS-provided CoS parameters, you also enable the service to be activated for those
subscribers at login.
To enable subscribers to activate a service or upgrade to different services through

RADIUS change-of-authorization (CoA) messages after login, configure a service profile
that includes user-defined variables.
Types of CoS Variables Used in a Service Profile

You can configure variables for the following CoS parameters in a service profile:
• Shaping rate
• Delay buffer rate
• Guaranteed rate
• Scheduler map
For each CoS parameter, you must associate a RADIUS vendor ID. For each vendor ID,
you must assign an attribute number and a tag. The tag is used to differentiate between

values for different CoS variables when you specify the same attribute number for those
variables. These values are matched with the values supplied by RADIUS during subscriber
authentication. All of the values in the dynamic profile must be defined in RADIUS or
none of the values are passed.
Optionally, you can configure default values for each parameter. Configuring default
values is beneficial if you do not configure RADIUS to enable service changes. During
service changes, RADIUS takes precedence over the default value that is configured.
Static and Dynamic CoS Configurations

Depending on how you configure CoS parameters in the access and service profiles,
certain CoS parameters are replaced or merged when subscribers change or activate
new services.
Static configuration is when you configure the scheduler map and schedulers in the static
[edit class-of-service] hierarchy and reference the scheduler map in the dynamic profile.
Dynamic configuration is when you configure the scheduler map and schedulers within
the dynamic profile.
The CoS configuration also depends on whether you have enabled multiple subscribers
on the same logical interface using the aggregate-clients statements in the dynamic
profile referenced by DHCP. When you specify the aggregate-clients replace statement,
the scheduler map names are replaced. In both cases, if the length of the scheduler map
name exceeds 128 characters, subscribers cannot log in. When you specify the
aggregate-clients merge statement, the scheduler map names specified in the dynamic
profile are appended.
BEST PRACTICE: To improve CoS performance in IPv4, IPv6, and dual-stack

networks, we recommend that you use the aggregate-clients replace statement
rather than the aggregate-clients merge statement.
Scenarios for Static and Dynamic Configuration of CoS Parameters

Table 29 on page 165 lists the scenarios for static and dynamic configuration of CoS
parameters in access profiles and service profiles at subscriber login. The table also lists
the behavior for each configuration for service activation and service modification using
RADIUS CoA messages.

Table 29: CoS Services and Variables

Dynamic CoS Dynamic CoS
Configuration Configuration
(Multiple Subscribers (Multiple Subscribers
Enabled on a Logical Enabled on a Logical
Static CoS Dynamic CoS Interface with the Interface with the
Configuration (Single Configuration (Single aggregate-clients aggregate-clients
Scenario Subscriber) Subscriber) merge Statement) replace Statement)
Subscriber login • Configure RADIUS • Configure RADIUS • Configure RADIUS • Configure RADIUS
values or default values or default values or default values or default
values for all values for all values for all values for all
parameters in parameters in parameters in parameters in
access profile access profile access profile access profile
• Configure scheduler • Configure scheduler • Configure scheduler • Configure scheduler
map in edit map and schedulers map and schedulers map and schedulers
class-of-service in access profile in access profile in access profile
hierarchy and
reference in access
profile
RADIUS CoA for service Replaces the following Replaces the following Combines the values of Replaces the following
or variable change parameters: parameters: the following parameters:
parameters to their
• Delay buffer rate • Delay buffer rate maximum scalar value: • Delay buffer rate
• Guaranteed rate • Guaranteed rate • Guaranteed rate
• Delay buffer rate
• Scheduler map • Shaping rate • Shaping rate
• Guaranteed rate
• Shaping rate • Scheduler map • Scheduler map
• Shaping rate
Appends the scheduler

map parameter
RADIUS CoA for service Does not merge Merge queues if the Merge queues if the Merge queues if the
activation queues queue specified in the queue specified in the queue specified in the
service profile is not service profile is not service profile is not
NOTE:In this case, use already in use for the already in use for the already in use for the
a similar configuration subscriber subscriber subscriber
to the access profile,
including the same NOTE: Do not NOTE: Do not NOTE: Do not
name for the instantiate a CoA instantiate a CoA instantiate a CoA
traffic-control-profile. request using a service request using a service request using a service
During service dynamic profile that is dynamic profile that is dynamic profile that is
activation, this already in use on the already in use on the already in use on the
configuration replaces same logical interface. same logical interface. same logical interface.
the original
configuration in the
access profile.
Related • Configuring Static Hierarchical Scheduling in a Dynamic Profile on page 32

Documentation
• Dynamic Profile Attachment to DHCP Subscriber Interfaces Overview
• RADIUS Attributes and Juniper Networks VSAs Supported by the AAA Service Framework

CoS Traffic Shaping Attributes for Dynamic Interface Sets and Member Subscriber
Sessions Overview
To control bandwidth at a household level in a subscriber access network, you can apply
RADIUS dynamic class of service (CoS) traffic-shaping attributes to a dynamic interface
set and its member subscriber sessions when the subscriber sessions are authenticated.
(The dynamic interface set itself does not go through the authentication process.)
A household is represented by either a dynamic interface set or a dynamic

agent-circuit-identifier (ACI) interface set from which the subscriber sessions originate.
For this feature, dynamic interface sets and dynamic ACI interface sets are mapped to
Level 2 of the Junos OS CoS scheduler hierarchy, which enables you to use CoS
traffic-shaping to shape the bandwidth at the household (interface set) level.
The subscriber sessions, also referred to as subscriber interfaces or client sessions, can be
dynamic VLAN, PPPoE, or IP demultiplexing (IP demux) subscriber interfaces. The
subscriber interfaces are mapped to Level 3 of the Junos OS CoS scheduler hierarchy.
• Supported Network Configurations on page 166

• Traffic-Control Profiles in Subscriber Interface Dynamic Profiles on page 166
• CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets and Member
Supported Network Configurations

Applying RADIUS dynamic CoS traffic-shaping attributes to a dynamic interface set and
its member subscriber sessions is supported for the following network configurations:
• Dynamic IP demux subscriber interfaces (for DHCP subscribers) over either a dynamic
interface set or a dynamic ACI interface set
• Dynamic PPPoE subscriber interfaces over either a dynamic interface set or a dynamic
ACI interface set
Traffic-Control Profiles in Subscriber Interface Dynamic Profiles

To apply dynamic CoS traffic-shaping attributes to a dynamic interface set and its
member subscriber sessions, you must define and attach the traffic-control profiles for
both the dynamic interface set and the dynamic subscriber sessions within the dynamic
profile for the subscriber interface.
At the [edit dynamic-profiles profile-name class-of-service traffic-control-profiles] hierarchy

level in the dynamic profile, configure both of the following:
• Traffic-control profile for the dynamic VLAN, PPPoE, or IP demux subscriber interfaces
• Traffic-control profile for the dynamic interface set or dynamic ACI interface set to
which the subscriber interfaces belong

RADIUS tag values for the Junos OS CoS traffic shaping predefined variables used in
both traffic-control profiles must be in the 100s range, as described in “CoS Traffic Shaping
Predefined Variables for Dynamic Interface Sets” on page 174.
At the [edit dynamic-profiles profile-name interfaces] hierarchy level in the dynamic profile,
use the output-traffic-control-profile statement to apply the traffic-control profiles to
the dynamic subscriber interface and the dynamic interface set or dynamic ACI interface
set.
CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets and Member Subscriber
Sessions
The set of $junos-cos-parameter predefined dynamic variables has been duplicated and
assigned a RADIUS tag value in the 100s range for use with this feature. The RADIUS tag
value is the only difference between the existing CoS traffic-shaping predefined dynamic
variables and the predefined dynamic variables that you must use with this feature.
Both RADIUS instances of the $junos-cos-parameter predefined dynamic variables are

available, but you must use the dynamic variables with tag values in the 100s range to
apply CoS traffic-shaping attributes to both the dynamic interface set and member
subscriber sessions in a subscriber interface dynamic profile.
For example, the existing $junos-cos-shaping-rate predefined variable is assigned RADIUS

vendor ID 4874, attribute number 108, and tag value 2. To apply CoS traffic-shaping
attributes to the dynamic interface set and its member subscriber sessions, you must
instead use the $junos-cos-shaping-rate predefined variable that is assigned RADIUS
vendor ID 4874, attribute number 108, and tag value 102.
NOTE: Do not configure a combination of $junos-cos-parameter predefined

dynamic variables with RADIUS tag values in the 100s range and
$junos-cos-parameter predefined dynamic variables with tag values not in
the 100s range in the same traffic-control profile. If you do so, the subscriber
authentication process fails.
Related • Guidelines for Configuring CoS Traffic Shaping Attributes for Dynamic Interface Sets
Documentation and Member Subscriber Sessions on page 168
• Applying CoS Traffic-Shaping Attributes to Dynamic Interface Sets and Member


Guidelines for Configuring CoS Traffic Shaping Attributes for Dynamic Interface Sets
and Member Subscriber Sessions
Observe the following guidelines when you apply dynamic CoS traffic-shaping attributes
to a dynamic interface set or a dynamic ACI interface set and its member subscriber
sessions. For complete information about the Junos OS CoS traffic-shaping predefined
dynamic variables and RADIUS tag values used with this feature, see “CoS Traffic Shaping
Predefined Variables for Dynamic Interface Sets” on page 174.
• This feature is supported only for dynamically configured and instantiated subscriber
interfaces.
• Do not configure a combination of $junos-cos-parameter predefined dynamic variables

with RADIUS tag values in the 100s range and $junos-cos-parameter predefined dynamic
variables with tag values not in the 100s range in the same traffic-control profile. If you
do so, the subscriber authentication process fails.
• Use the $junos-cos-adjust-minimum predefined variable (tag 109) only in traffic-control

profiles for dynamic subscriber interfaces. Using this variable in a traffic-control profile
for a dynamic interface set or dynamic ACI interface set has no effect.
• Do not configure the $junos-cos-excess-rate-high predefined variable (tag 110) when

the $junos-cos-excess-rate predefined variable (tag 105) is configured, and vice-versa.
• Do not configure the $junos-cos-excess-rate-low predefined variable (tag 111) when

the $junos-cos-excess-rate predefined variable (tag 105) is configured, and vice-versa.
• Do not configure the $junos-cos-byte-adjust-frame predefined variable (tag 114) when

the $junos-cos-byte-adjust predefined variable (tag 108) is configured, and vice-versa.
• Do not configure the $junos-cos-byte-adjust-cell predefined variable (tag 115) when

the $junos-cos-byte-adjust predefined variable (tag 108) is configured, and vice-versa.
• Use the per-priority $junos-cos-shaping-rate-parameter predefined variables (tags 116

through 125) only in traffic-control profiles for dynamic interface sets or dynamic ACI
interface sets. Using these variables in traffic-control profiles for a dynamic logical
subscriber interface causes the subscriber session to fail.
Related • Applying CoS Traffic-Shaping Attributes to Dynamic Interface Sets and Member
Documentation Subscriber Sessions on page 171

Configuring Initial CoS Parameters Dynamically Obtained from RADIUS
You can configure a subscriber interface so that subscribers receive initial CoS parameters
that the router obtains from the RADIUS authentication server when subscribers log in
using that logical interface on the router.
1. Configure external RADIUS server VSAs with values that you expect subscribers to
log in with.
• To configure a RADIUS authentication server to include CoS traffic-shaping

parameters in authentication grants on certain subscriber interfaces, configure
Juniper Networks VSA 26–108.
• To configure a RADIUS authentication server to include CoS scheduling and queuing

parameters in authentication grants a certain subscriber interfaces, configure Juniper
Networks VSA 28–146.
See Configuring Router or Switch Interaction with RADIUS Servers and Configuring
RADIUS Server Parameters for Subscriber Access.
2. Configure a subscriber interface that supports hierarchical CoS.
3. Associate a traffic-control profile with the interface.
See “Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic

4. Configuring initial traffic-shaping parameters to be obtained from RADIUS.
See “Configuring Dynamic Traffic Shaping and Scheduling Parameters in a Dynamic

5. Configure forwarding classes and scheduler maps statically.
See Configuring Forwarding Classes and Configuring Scheduler Maps.
6. Configure a scheduler to specify initial scheduling and queuing parameters to be

dynamically obtained from RADIUS when a subscriber logs in.
See “Configuring Dynamic Schedulers with Variables in a Dynamic Profile” on page 15.
Related • Subscriber Interfaces That Provide Initial CoS Parameters Dynamically Obtained from
Documentation RADIUS on page 159
• Example: Configuring Initial CoS Parameters Dynamically Obtained from RADIUS on

page 179
• Subscriber Activation and Service Management in an Access Network
• Juniper Networks VSAs Supported by the AAA Service Framework

Configuring Static Default Values for Traffic Scheduling and Shaping
To provide subscribers with default values for CoS parameters, configure user-defined
variables for CoS parameters and assign static default values to the variables. If you have
configured values to be supplied by a RADIUS CoA, subscribers receive the default value
when deactivating a service.
To configure user-defined variables with default values for CoS in a dynamic profile:
1. Specify that you want to configure variables in the dynamic profile.
[edit dynamic-profiles residential-silver variables]
2. Configure a default value for the shaping rate.

user@host# set srate default-value 5m
3. Configure a default value for the guaranteed rate.

user@host# set grate default-value 5m
4. Configure a default value for the delay buffer rate.

user@host# set dbrate default-value 10m
5. Configure a default value for the scheduler map.

user@host# set smap default-value triple-play
6. Configure the variables for the CoS parameters in the traffic-control profile.
Either the shaping rate or the guaranteed rate is required in the traffic-control profile.
a. Access the traffic-control profile in the dynamic profile.
user@host# edit dynamic-profiles residential-silver class-of-service

traffic-control-profiles tcp1
b. Configure the scheduler map variable.
[edit dynamic-profiles residential-silver class-of-service traffic-control-profiles

tcp1]
user@host# set scheduler-map "$smap"
c. Configure the shaping rate variable.

tcp1]
user@host# set shaping-rate "$srate"
d. Configure the guaranteed rate variable.

tcp1]

user@host# set guaranteed-rate "$grate"
e. Configure the delay buffer rate variable.

tcp1]
user@host# set delay-buffer-rate "$dbrate"
Documentation
Applying CoS Traffic-Shaping Attributes to Dynamic Interface Sets and Member

Subscriber Sessions
RADIUS dynamic class of service (CoS) traffic-shaping attributes to a dynamic interface
set or agent-circuit-identifer (ACI) interface set and its member subscriber sessions when
the member sessions are authenticated. The dynamic interface set or ACI interface set
represents the household from which the subscriber sessions originate. The subscriber
sessions, also referred to as client sessions or subscriber interfaces, can be dynamic VLAN,
PPPoE, or IP demultiplexing (IP demux, for DHCP) subscriber interfaces.
To apply RADIUS dynamic CoS traffic-shaping attributes to both the dynamic interface
set and its member subscriber sessions, you must configure two traffic-control profiles
in the dynamic profile for the subscriber interface: one traffic-control profile for the
“parent” dynamic interface set, and a second traffic-control profile for the dynamic
subscriber interfaces. RADIUS tag values for the Junos OS CoS traffic shaping predefined
variables used in both traffic-control profiles must be in the 100s range.
Before you begin:
• Create a dynamic profile that defines the VLAN, PPPoE, or IP demux logical subscriber
interface.
See the following topics:
• Configuring a Basic Dynamic Profile
• Configuring a Dynamic Profile Used to Create Single-Tag VLANs
• Configuring a Dynamic Profile Used to Create Stacked VLANs

• Configuring Dynamic PPPoE Subscriber Interfaces Using Dynamic Profiles
• Configuring Dynamic Subscriber Interfaces Using IP Demux Interfaces in Dynamic

Profiles
To apply dynamic CoS traffic-shaping attributes to a dynamic ACI or non-ACI interface

set and its member subscriber sessions in a dynamic profile for the subscriber interface:
1. Configure two traffic-control profiles at the [edit dynamic-profiles profile-name

class-of-service traffic-control profiles] hierarchy level:
• Traffic-control profile for the VLAN, PPPoE, or IP demux dynamic subscriber

interfaces
• Traffic-control profile for the dynamic interface set or dynamic ACI interface set to
which the subscriber interfaces belong
2. In the traffic-control profiles configured for the dynamic interface set and the subscriber
interfaces, reference Junos OS CoS traffic-shaping predefined variables with RADIUS
tag values in the 100s range.
See “CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets” on page 174
for a complete list of the Junos OS predefined variables and RADIUS tag values that
you must use in the traffic-control profiles for the dynamic subscriber interfaces and
the dynamic interface set.
3. At the [edit dynamic-profiles profile-name interfaces] hierarchy level, use the

output-traffic-control-profile statement to apply the traffic-control profiles to the
dynamic subscriber interface and the dynamic interface set or dynamic ACI interface
set.
Example: Dynamic
PPPoE Subscriber
Interface over Dynamic
ACI Interface Set
The following example shows a dynamic profile named pppoe-subscriber that configures
a dynamic PPPoE (pp0) subscriber interface over a dynamic ACI interface set.
The traffic-control-profiles stanza defines two traffic-control profiles: tcp-pppoe-session

for the dynamic PPPoE subscriber interface, and tcp-parent-aci-set for the dynamic
“parent” ACI interface set. The $junos-cos-shaping-rate predefined variable included in
each of these traffic-control profiles is assigned RADIUS vendor ID 4874, attribute number
108, and tag value 102. The $junos-cos-shaping-mode variable is assigned RADIUS vendor
ID 4874, attribute number 108, and tag value 107.
The interfaces stanza applies output traffic-control profile tcp-pppoe-session to the

dynamic PPPoE (pp0) subscriber interface, and output traffic-control profile
tcp-parent-aci-set to the dynamic ACI interface set.
[edit dynamic-profiles]
pppoe-subscriber {
interfaces {
interface-set "$junos-interface-set-name" {

interface pp0 {
unit "$junos-interface-unit";
}
}
pp0 {
ppp-options {
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
no-keepalives;
family inet {
unnumbered-address lo0.0;
}
}
}
}
class-of-service {
tcp-pppoe-session {
scheduler-map smap-1;
overhead-accounting $junos-cos-shaping-mode frame-mode-bytes -4
cell-mode-bytes 12;
}
tcp-parent-aci-set {
overhead-accounting $junos-cos-shaping-mode frame-mode-bytes -4
cell-mode-bytes 12;
}
}
interfaces {
pp0 {
output-traffic-control-profile tcp-pppoe-session;
}
}
interface-set $junos-interface-set-name {
output-traffic-control-profile tcp-parent-aci-set;
}
}
}
}
}
Related • CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets on page 174
Documentation

CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets
RADIUS CoS traffic-shaping attributes to a dynamic interface set and its member
subscriber sessions when the member sessions are authenticated. The dynamic interface
set, which represents the household level in a subscriber access network, can be either
a dynamic agent-circuit-identifier (ACI) interface set or a non-ACI–based dynamic
interface set. The subscriber sessions belonging to the interface set can be dynamic
VLAN, DHCP, or PPPoE subscriber interfaces.
To apply RADIUS CoS traffic-shaping attributes to both the dynamic interface set and
its member subscriber sessions, you must configure two traffic-control profiles in the
dynamic profile for the subscriber interface: one traffic-control profile for the “parent”
dynamic interface set, and a second traffic-control profile for the dynamic subscriber
interfaces. RADIUS tag values for the Junos OS CoS traffic-shaping predefined variables
used in these traffic-control-profiles must be in the 100s range, as described in
Table 30 on page 174.
To accommodate this feature, the set of existing $junos-cos-parameter predefined

dynamic variables for traffic shaping have been duplicated and assigned a tag value in
the 100s range, as listed in Table 30 on page 174. The tag value is the only difference
between the existing predefined dynamic variables and the predefined dynamic variables
that you must use with this feature.
For example, the existing $junos-cos-shaping-rate predefined variable is assigned RADIUS

vendor ID 4874, attribute number 108, and tag value 2. To apply RADIUS CoS
traffic-shaping attributes to the dynamic interface set and its member subscriber sessions,
you must instead use the $junos-cos-shaping-rate predefined variable that is assigned
RADIUS vendor ID 4874, attribute number 108, and tag value 102.
Table 30 on page 174 describes the Junos OS predefined dynamic variables and RADIUS
tag values that you can use in a dynamic profile to apply RADIUS CoS traffic-shaping
attributes to the dynamic interface set and its member subscriber sessions. The table
lists the predefined dynamic variables in ascending order by tag value.
NOTE: All of the predefined variables listed in Table 30 on page 174 use
RADIUS vendor ID 4874 and RADIUS attribute value 108.
Interface Sets
RADIUS Tag
Predefined Variable Value Description
$junos-cos-scheduler-map 101 Scheduler-map name configured in

a traffic-control profile in a dynamic
profile.

Interface Sets (continued)
RADIUS Tag
$junos-cos-shaping-rate 102 Shaping rate configured in a

traffic-control profile in a dynamic
profile. Represents the maximum
bandwidth of a CoS scheduler node.
$junos-cos-guaranteed-rate 103 Guaranteed rate configured in a

profile. Represents the minimum
bandwidth of a CoS scheduler node.
$junos-cos-delay-buffer-rate 104 Delay-buffer rate configured in a

profile.
$junos-cos-excess-rate 105 Excess rate configured in a

profile; scheduler weighting when
operating in the excess region
between the guranteed rate and the
shaping rate.
NOTE: Do not configure the

$junos-cos-excess-rate variable
when either the
$junos-cos-excess-rate-high
variable or the
$junos-cos-excess-rate-low
variable is configured.
$junos-cos-traffic-control-profile 106 Traffic-control profile configured in

a dynamic profile for subscriber
access.
$junos-cos-shaping-mode 107 Overhead-accounting mode

configured in a traffic-control profile
in a dynamic profile to shape
downstream ATM traffic based on
either frames (frame-mode) or cells
(cell-mode).
$junos-cos-byte-adjust 108 Byte adjustment value for the cell

or frame shaping mode configured
in a traffic-control profile in a
dynamic profile.

$junos-cos-byte-adjust variable
when either the
$junos-cos-byte-adjust-frame
variable or the
$junos-cos-byte-adjust-cell
variable is configured.

RADIUS Tag
$junos-cos-adjust-minimum 109 Minimum adjusted shaping rate

for a dynamic subscriber interface.
Specifying this variable in a
traffic-control profile for a dynamic
interface set has no effect.
$junos-cos-excess-rate-high 110 Shaping rate configured for excess

high-priority traffic in a
profile.

$junos-cos-excess-rate-high
variable when the
$junos-cos-excess-rate variable is
configured.
$junos-cos-excess-rate-low 111 Shaping rate configured for excess

low-priority traffic in a
profile.

$junos-cos-excess-rate-low
variable when the
$junos-cos-excess-rate variable is
configured.
$junos-cos-shaping-rate-burst 112 Burst size for the shaping rate

in a dynamic profile.
$junos-cos-guaranteed-rate-burst 113 Burst size for the guaranteed rate

in a dynamic profile.
$junos-cos-byte-adjust-frame 114 Overhead bytes when downstream

ATM traffic is in frame-mode.

$junos-cos-byte-adjust-frame
variable when the
$junos-cos-byte-adjust variable is
configured.

RADIUS Tag
$junos-cos-byte-adjust-cell 115 Overhead bytes when downstream

ATM traffic is in cell-mode.

$junos-cos-byte-adjust-cell
variable when the
$junos-cos-byte-adjust variable is
configured.
$junos-cos-shaping-rate-priority-high 116 Shaping rate configured for

interface set or dynamic ACI
interface set at a household level.
subscriber interface is prohibited.
$junos-cos-shaping-rate-priority-high-burst 117 Shaping rate burst size configured

for high-priority traffic in a
$junos-cos-shaping-rate-priority-medium 118 Shaping rate configured for

medium-priority traffic in a
$junos-cos-shaping-rate-priority-medium-burst 119 Shaping rate burst size configured

for medium-priority traffic in a

RADIUS Tag
$junos-cos-shaping-rate-priority-low 120 Shaping rate configured for

$junos-cos-shaping-rate-priority-low-burst 121 Shaping rate burst size configured

for low-priority traffic in a
$junos-cos-shaping-rate-excess-high 122 Shaping rate configured for excess

$junos-cos-shaping-rate-excess-high-burst 123 Shaping rate burst size configured

for excess high-priority traffic in a
$junos-cos-shaping-rate-excess-low 124 Shaping rate configured for excess


RADIUS Tag
$junos-cos-shaping-rate-excess-low-burst 125 Shaping rate burst size configured

for excess low-priority traffic in a
Related • Applying CoS Traffic-Shaping Attributes to Dynamic Interface Sets and Member
Documentation Subscriber Sessions on page 171
Example: Configuring Initial CoS Parameters Dynamically Obtained from RADIUS
The following configuration is an example of a client dynamic profile in which initial CoS
parameters are dynamically obtained from the RADIUS server when a subscriber
authenticates over the interface to which the dynamic profile is applied.
For this example, assume that the RADIUS authentication server has been configured
with traffic-shaping parameters (at Juniper Networks VSA 26-108) and CoS scheduling
and queuing parameters (at Juniper Networks VSA 26–146).
The subscriber interface is a single-unit static gigabit Ethernet VLAN interface on an EQ

DPC port:
[edit]
interfaces {
ge-9/0/3 {
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
address 192.168.32.2/24;
}
}
}
}

The client dynamic profile residential_silver attaches the traffic-control profile tcp_1 to
the subscriber interface that is defined in the dynamic profile using the
$junos-interface-ifd-name predefined variable.
[edit]
dynamic-profiles {
residential_silver {
interfaces {
“$junos-interface-ifd-name” {
unit “$junos-underlying-interface-unit” {
family inet;
}
}
}
class-of-service {
interfaces {
output-traffic-control-profile tcp_1;
}
}
}
}
}
}
The traffic-control profile tcp_1, references Junos OS predefined variables to obtain a

scheduler-map name and traffic-shaping parameter values from RADIUS when a
subscriber logs in. For this example, assume that the RADIUS server replaces the Junos
OS predefined variable $junos-cos-scheduler-map scheduler-map name business_smap_1.
The scheduler map business_smap_1 is configured in the client dynamic profile:
[edit]
dynamic-profiles {
class-of-service {
tcp_1 {
scheduler-map “$junos-cos-scheduler-map”; # ’business_smap_1’
guaranteed-rate "$junos-cos-guaranteed-rate";
}
}
scheduler-maps {
business_smap_1 {
forwarding-class best-effort scheduler be_sched;
forwarding-class ef scheduler home_sched
}
}
}
}
}

A scheduler definition references Junos OS predefined variables to obtain scheduler

configurations from RADIUS when a subscriber logs in. For this example, assume that
the RADIUS server provides scheduler configurations for schedulers named be_sched
and home_sched, which are included in the scheduler map business_smap_1:
[edit]
dynamic-profiles {
class-of-service {
schedulers {
“$junos-cos-scheduler” { # ’be_sched’ and ’home_sched’
buffer-size "$junos-cos-scheduler-bs";
“$junos-cos-scheduler-dropfile-low“;
“$junos-cos-scheduler-dropfile-medium-low“;
“$junos-cos-scheduler-dropfile-medium-high“;
“$junos-cos-scheduler-dropfile-high“;
}
}
}
}
}
Static configurations for CoS consist of configurations for the forwarding classes used
in the scheduler map business_smap_1 and configurations for drop-profile names provided
by RADIUS for as part of the scheduler configurations provided (for be_sched and
home_sched) when a subscriber logs in:
[edit]
class-of-service {
queue 0 best-effort;
queue 1 ef;
}
drop-profiles {
. . . configurations_for_drop_profile_names_provided_by_RADIUS . . .
}
}
}
Related • Subscriber Activation and Service Management in an Access Network

Documentation
• Subscriber Interfaces That Provide Initial CoS Parameters Dynamically Obtained from
RADIUS on page 159


CHAPTER 13
Modifying a Subscriber’s Shaping

Characteristics After a Subscriber is
Instantiated
• CoS Adjustment Control Profiles Overview on page 183

• Configuring CoS Adjustment Control Profiles on page 185
• Verifying the CoS Adjustment Control Profile Configuration on page 185
CoS Adjustment Control Profiles Overview
CoS adjustment control profiles control which applications and algorithms can modify
a subscriber’s shaping characteristics after a subscriber is instantiated. Subscriber shaping
characteristics are configured using the Junos OS CLI or by RADIUS messages. Adjustment
control profiles enable subscriber shaping characteristics by to be adjusted by other
applications like ANCP, PPPoE tags, and RADIUS Change of Authorization (CoA) after
a subscriber is instantiated. Adjustment control profiles are router-wide and apply to
both static and dynamic interfaces.
Table 31 on page 183 describes the applications and their associated default algorithms
that can be configured to perform rate adjustments after the subscriber is instantiated.
Table 31: Adjustment Control Profile Applications and Algorithms

Default
Application Priority Default Algorithm Description
RADIUS-CoA 1 Adjust-always RADIUS CoA messages can update the subscriber’s

attributes (like shaping rate) after the subscriber is
authenticated and QoS parameters (like shaping rate)
are assigned.
ANCP 1 Adjust-always The ANCP application can modify the existing shaping
rate for both static and dynamic logical interfaces, and
static interface sets. By default, ANCP can override all
other applications. The shaping rate must be specified
in order to override it.

Table 31: Adjustment Control Profile Applications and Algorithms (continued)

Default
Application Priority Default Algorithm Description
PPPoE-Tags 2 Adjust-less The PPPoE IA tag access-rate-downstream can modify

the Junos OS CLI configured shaping-rate value, as well
as the RADIUS shaping- rate value. By default, these
values can be modified by subsequent RADIUS CoA
messages and ANCP actions. These values are conveyed
in PPPoE (PADI) discovery packets.
NOTE: The lower the priority value, the higher the priority.
Applications and Associated Algorithms in Adjustment Control Profiles

You must enable each application to perform rate adjustments. Rate adjustments are
global and affect all static and dynamically instantiated subscribers. The following rules
apply to adjustment control profiles:
• If no adjustment control profile is configured, the default adjustment control profile is

used.
• You can configure a maximum of one adjustment control profile; a commit error occurs
if you configure more than one adjustment control profile.
• If an application is not configured with an adjustment control profile, Junos OS uses

its default values for priority and algorithm. For example, if ANCP is not configured in
the adjustment control profile, the ANCP application is set to a priority of 1 and the
algorithm is set to adjust-always.
• Adjustment control profiles apply to both static and dynamic interfaces.
• You can configure the algorithm to the following values:
• Adjust-never
• Adjust-always
• Adjust less
• Adjust less than or equal
• Adjust greater
• Adjust greater than or equal
• When you modify an adjustment control profile, the changes take effect immediately
and the modified profile is used for all further adjustments. However, existing
adjustments are not reevaluated when you modify the adjustment control profile.
For example, if you have an ANCP adjustment that overrides a PPPoE adjustment on
interface ge-1/1/0.100, and then you use the adjustment control profile to change the
priority so that the ANCP priority is now lower than the PPPoE priority, Junos OS does
not go back and reevaluate the adjustment on ge-1/1/0.100.

Chapter 13: Modifying a Subscriber’s Shaping Characteristics After a Subscriber is Instantiated
Related • Configuring CoS Adjustment Control Profiles on page 185

Documentation
• adjustment-control-profiles on page 483
Configuring CoS Adjustment Control Profiles
To configure adjustment control profiles:
NOTE: You can only configure one adjustment control profile.
1. Configure the adjustment control profile name.
[edit]
user@host# edit class-of-service adjustment-control-profiles profile-name
2. (Optional) Configure the adjustment controls for the Access Node Control Protocol
(ANCP) application:
[edit class-of-service adjustment-control-profiles profile-name ]

user@host# set application ancp priority priority algorithm algorithm
3. (Optional) Configure the adjustment controls for the RADIUS CoA application:

user@host# set application radius-coa priority priority algorithm algorithm
4. (Optional) Configure the adjustment controls for the PPPoE tags:

user@host# set application pppoe-tags priority priority algorithm algorithm
5. (Optional) Verify your configuration.
user@host> show class-of-service adjustment-control-profiles

name: ANCP, priority: 1, algorithm: less;
name: RADIUS CoA, priority: 1, algorithm: always;
name: PPPoE IA tags, priority: 2, algorithm: less;
Related • CoS Adjustment Control Profiles Overview on page 183

Documentation
• overhead-accounting (Dynamic Traffic Shaping) on page 611
Verifying the CoS Adjustment Control Profile Configuration

Purpose View the class-of-service (CoS) adjustment control profile.
Action • To display the CoS adjustment control profile:
user@host> show class-of-service adjustment-control-profile profile-name

user@host> show class-of-service adjustment-control-profile acp1

name: ANCP, priority: 1, algorithm: less
name: RADIUS CoA, priority: 1, algorithm: always
name: PPPoE IA tags, priority: 2, algorithm: less
user@host>

Documentation
• application (Adjustment Control Profiles) on page 488

CHAPTER 14
Configuring Dynamic CoS for L2TP
• CoS for L2TP LAC Subscriber Interfaces Overview on page 187

• CoS for L2TP LNS Inline Services Overview on page 189
• Configuring Dynamic CoS for an L2TP LAC Tunnel on page 190
• Configuring Dynamic CoS for an L2TP LNS Inline Service on page 192
CoS for L2TP LAC Subscriber Interfaces Overview
You can apply CoS to the Layer 2 Tunnel Protocol (L2TP) access concentrator (LAC)
component.
In Layer 2 Tunnel Protocol (L2TP) configurations, IP and L2TP headers are added to
packets arriving at a PPP subscriber interface on the L2TP access concentrator (LAC)
before being tunneled to the L2TP network server (LNS). You can manage the IP header
by configuring classifiers and rewrite-rules that transfer the ToS (Type of Service) value
or the 802.1p value from the inner IP header to the outer IP header of the L2TP packet.
Figure 21 on page 187 shows the classifier and rewrite rules that you can configure from
the LAC to the LNS, and from the LNS to the LAC.
Figure 21: CoS Configuration for L2TP LAC Topology
RADIUS
server
CLEC network
ISP network
PPP connection LNS

LAC
PC
Classify (Layer 2 and Layer 3) and Rewrite (Layer 2)

g017488
Classify and Rewrite (Layer 2 and Layer 3)
• Traffic from LAC to LNS on page 188

• LAC Tunnels: Traffic from LNS to LAC on page 188

Traffic from LAC to LNS

To set the ToS value or the 802.1p value on the inner IP header, you can configure both
fixed and behavior aggregate (BA) classifiers for subscribers at Layer 2 or Layer 3 of the
network.
Table 32 on page 188 lists the configuration options for applying classifiers to a subscriber
interface on an ingress LAC tunnel.
Table 32: Ingress LAC Tunnel Classifier Options

Classifier Subscriber Interface
Fixed Either of the following:
• PPP interface
• Underlying VLAN interface
Layer 2 Either of the following:
• PPP interface
• Underlying VLAN interface
Layer 3 Family of PPP interfaces
You cannot configure a Layer 2 and fixed classifier together.
The behavior of the Layer 2 and Layer 3 classifiers depends on the configuration. For
example, a Layer 3 classifier for a family of PPP interfaces overrides a Layer 2 classifier
configured at the PPP interface, except for the unknown packets and control packets.
If you do not configure a classifier for Layer 2, the system applies the default Layer 3
classifier so that tunneled and terminated subscribers have the same behavior. To prevent
unknown packets and control packets from being discarded, the system assigns them
to the best-effort forwarding class.
For egress tunnels, you configure rewrite rules at the PPP interface to set the ToS or
802.1p value of the outer IP header. Rewrite rules are applied accordingly to the forwarding
class, packet loss priority (PLP), and code point.
LAC Tunnels: Traffic from LNS to LAC

On a LAC, mapping the inner IP header to the outer IP header of the L2TP packet depends
on the classifier and rewrite-rule configurations. For example, Table 33 on page 189 lists
the values for the classifier and rewrite rules for a VLAN interface. For assured forwarding,
the inner 802.1p value (ob001) is classified with the assured-forwarding class and low
loss priority at the ingress interface. Based on the assured-forwarding class and low loss
priority in the rewrite rule, the ToS value in the outer IP header is set to ob001.

Chapter 14: Configuring Dynamic CoS for L2TP
Table 33: Sample Result for the Classifier and Rewrite Rules for a VLAN Interface
Inner .1p Value Forwarding Class Loss Priority Code Point Outer ToS Value
ob000 best-effort low 000 ob000
ob001 assured-forwarding low 001 ob001
ob101 expedited-forwarding low 101 ob101
ob111 network-control low 11 ob111
Related • Configuring Dynamic CoS for an L2TP LAC Tunnel on page 190
Documentation
CoS for L2TP LNS Inline Services Overview
You can apply hierarchical scheduling and per-session shaping to Layer 2 Tunnel Protocol
(L2TP) network server (LNS) inline services using a static or dynamic CoS configuration.
This feature is supported on MIC and MPC interfaces on MX240, MX480, and MX960
routers.
• Guidelines for Applying CoS to the LNS on page 189

• Hardware Requirements for Inline Services on the LNS on page 190
Guidelines for Applying CoS to the LNS

In L2TP configurations, IP, UDP, and L2TP headers are added to packets arriving at a PPP
subscriber interface on the L2TP access concentrator (LAC) before being tunneled to
the LNS.
When a service interface is configured for an L2TP LNS session, it has an inner IP header
and an outer IP header. You can configure CoS for an LNS session that corresponds to
the inner IP header only. The outer IP header is used for L2TP tunnel processing only.
However, we recommend that you configure classifiers and rewrite-rules to transfer the
ToS (type of service) value from the inner IP header to the outer IP header of the L2TP
packet.
Figure 22 on page 190 shows the classifier and rewrite rules that you can configure on an
LNS inline service.

Figure 22: Processing of CoS Parameters in an L2TP LNS Inline Service

Egress tunnel (from LAC to Uplink)
Fixed or BA Multifield
IP/UDP/L2TP decapsulation
classification classification
LAC
peer Core / Internet
interface
Multifield
Shaping IP/UDP/L2TP capsulation Rewrite rule
classification
g017575
Ingress tunnel (from Uplink to LAC)
By default, the shaping calculation on the service interface includes the L2TP
encapsulation. If necessary, you can configure additional adjustments for downstream
ATM traffic from the LAC or differences in Layer 2 protocols.
Hardware Requirements for Inline Services on the LNS

Hierarchical scheduling for L2TP LNS inline services is supported on MIC and MPC
interfaces only. The services that you can configure depend on the hardware combination.
Table 34 on page 190 lists the supported inline services and peer interfaces for each MIC
and MPC combination.
Table 34: Hardware Requirements for L2TP LNS Inline Services

Inline Service Support–With Inline Service Support–Without
MPC Module Per-Session Shaping Per-Session Shaping
MX-MPC1-3D No Yes
MX-MPC2-3D
MX-MPC1-3D-Q Yes Yes
MX-MPC2-3D-Q
MX-MPC2-3D-EQ
MX80
MPC-3D-16XGE-SFPP No No
Related • Configuring Static CoS for an L2TP LNS Inline Service

Documentation
• Configuring Dynamic CoS for an L2TP LNS Inline Service on page 192
Configuring Dynamic CoS for an L2TP LAC Tunnel
In L2TP configurations, IP and L2TP headers are added to packets arriving at a PPP
subscriber interface on the LAC before being tunneled to the L2TP network server (LNS).

Classifiers and rewrite rules enable you to properly transfer the ToS (Type of Service)
value or the 802.1p value from the inner IP header to the outer IP header of the L2TP
packet.
Before you begin, configure the L2TP LAC. See Configuring an L2TP LAC.
To manage the IP header values for a LAC tunnel:
1. Configure the classifier for the inner tunnel.
a. Define the fixed or behavior aggregate (BA) classifier.
• To configure a fixed classifier:
[edit class-of-service interfaces interface-name unit logical-unit-number]

user@host# set forwarding-class class-name
• To configure a BA classifier:
user@host#set classifiers (ieee-802.1 | inet-precedence) classifier-name
forwarding-class class-name loss-priority level code-points [ aliases ] [
bit-patterns]
b. Apply the classifier to the Layer 2 interface or Layer 3 interface. For Layer 2, you
can apply the classifier at the PPP interface or an underlying VLAN interface. For
Layer 3, you can apply classifiers to a family of PPP interfaces.
• To apply the classifier for the IEEE 802.1p value:
[edit dynamic-profiles profile-name class-of-service interfaces interface-name

unit logical-unit-number classifiers]
user@host# set ieee-802.1 (classifier-name | default) vlan-tag (inner | outer)
• To apply the classifier for the ToS value:

user@host# set inet-precedence (classifier-name | default)
2. Configure the rewrite rule for the egress tunnel.
a. Configure the rewrite rule with the forwarding class and the loss priority value.
user@host# set rewrite-rules (ieee-802.1 | inet-precedence) rewrite-name
forwarding-class class-name loss-priority level code-point (alias | bits)
b. Apply the rewrite rule to the PPP interface for which the L2TP tunnel is configured.
• To apply the rewrite-rule for the IEEE 802.1p value:

unit logical-unit-number rewrite-rules]
user@host# set ieee-802.1 (rewrite-name | default) vlan-tag (outer |
outer-and-inner)
• To apply the rewrite rule for the ToS value:


user@host# set inet-precedence (rewrite-name | default)
Documentation
• CoS for L2TP LAC Subscriber Interfaces Overview on page 187
Configuring Dynamic CoS for an L2TP LNS Inline Service
You can configure hierarchical scheduling for an L2TP LNS inline service and manage
the IP header values using rewrite rules and classifiers.
Before you begin, configure the L2TP LNS inline service interface. See Configuring an L2TP
LNS with Inline Service Interfaces.
To configure CoS for an L2TP LNS inline service in a dynamic profile:
1. Configure the hierarchical scheduler for the service interface (si) interface.
[edit interfaces si-fpc/port/pic ]

user@host# set hierarchical-scheduler maximum-hierarchy-levels 2
BEST PRACTICE: To enable Level 3 nodes in the LNS scheduler hierarchy

and to provide better scaling, we recommend that you also specify a
maximum of two hierarchy levels.
2. Configure the LNS to reflect the IP ToS value in the inner IP header to the outer IP
header.
[edit services l2tp tunnel-group name]

user@host# set tos-reflect
3. Configure the classifier for egress traffic from the LAC.
a. Define the fixed or behavior aggregate (BA) classifier.
• To configure a fixed classifier:
[edit class-of-service interfaces interface-name unit logical-unit-number]

• To configure a BA classifier:
user@host# set classifiers (dscp | dscp-ipv6 | inet-precedence) classifier-name
forwarding-class class-name loss-priority level code-points [ aliases ] [
bit-patterns]
b. Apply the classifier to the service interface.
• To apply the classifier for the DSCP or DSCP IPv6 value:

user@host# set dscp (classifier-name | default)
user@host# set dscp-ipv6 (classifier-name | default)

• To apply the classifier for the ToS value:

4. Configure and apply a rewrite-rule to ingress traffic to the LAC:
a. Configure the rewrite rule with the forwarding class and the loss priority value.
user@host# set rewrite-rules (dscp | dscp-ipv6 | inet-precedence) rewrite-name
forwarding-class class-name loss-priority level code-point (alias | bits)
b. Apply the rewrite rule to the service interface.
• To apply the rewrite rule for the DSCP or DSCP IPv6 value:

user@host# setdscp (rewrite-name | default)
user@host# set dscp-ipv6 (rewrite-name | default)
• To apply the rewrite rule for the ToS value:

5. (Optional) Configure additional adjustments for downstream ATM traffic.
By default, the shaping calculation on the service interface includes the L2TP
encapsulation. If necessary, you can configure additional adjustments for downstream
ATM traffic from the LAC or differences in Layer 2 protocols.
[edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name]

user@host# set overhead-accounting (frame-mode | cell-mode |
$junos-cos-shaping-mode) <bytes (byte-value | $junos-cos-byte-adjust)
6. Apply the traffic-control profile.
[edit dynamic-profiles profile-name class-of-service interfaces

$junos-interface-ifd-name unit $junos-interface-unit]
Documentation
• CoS for L2TP LNS Inline Services Overview on page 189
• Example: Configuring an L2TP LNS



CHAPTER 15
Applying CoS to Groups of Subscriber

Interfaces
• CoS for Interface Sets of Subscribers Overview on page 195

• Example: Configuring a Dynamic Interface Set of VLAN Subscribers on page 198
• Example: Configuring a Dynamic Service VLAN Interface Set of Subscribers in a Dynamic
Profile on page 211
CoS for Interface Sets of Subscribers Overview
Interface sets enable service providers to group logical interfaces so they can apply CoS
parameters to all of the traffic in the group.
Interface sets are beneficial for various scenarios in a subscriber access network. For
example, you can use an interface set to configure a local loop with a small number of
subscribers. Interface sets are also useful for grouping a large number of subscribers into
a particular service class or for defining traffic engineering aggregates for DSLAMs.
• Guidelines for Configuring Dynamic Interface Sets in a Subscriber Access

Network on page 196

Guidelines for Configuring Dynamic Interface Sets in a Subscriber Access Network

Interface sets enable service providers to group logical interfaces so they can apply CoS
parameters to all of the traffic in the group.
Interface sets are beneficial for various scenarios in a subscriber access network. For
example, you can use an interface set to configure a local loop with a small number of
subscribers. Interface sets are also useful for grouping a large number of subscribers into
a particular service class or for defining traffic engineering aggregates for DSLAMs.
When configuring interface sets for subscriber access, keep the following guidelines in
mind:
• You can configure interface sets of VLAN demux, PPPoE, or demux interfaces over
aggregated Ethernet interfaces.
• An interface can only belong to one interface set. If you try to add the same interface
to different interface sets, the commit operation fails.
• You configure the interface set and the traffic scheduling and shaping parameters in
a dynamic profile. However, you must apply the traffic-control profile to the interface
set in the static [edit class-of-service] hierarchy.
NOTE: This rule applies to all interface sets except ACI sets.
• The $junos-interface-set-name predefined variable is available only for RADIUS Accept

messages; change of authorization (CoA) requests are not supported.
• The $junos-svlan-interface-set-name predefined variable locally generates an interface

set name for use by dual-tagged VLAN interfaces based on the outer tag of the
dual-tagged VLAN. The format of the generated variable is physical_interface_name -
outer_VLAN_tag. For example, an aggregated Ethernet interface “ae0,” with a
dual-tagged VLAN interface that has an outer tag of “111,” results in a
$junos-svlan-interface-set-name dynamic variable of “ae0-111”. Similarly, a
non-aggregated Ethernet interface of ge-1/1/0, with the same dual-tagged VLAN
interface that has an outer tag of “111,” results in a $junos-svlan-interface-set-name
dynamic variable of “ge-1/1/0-111”.
• The $junos-tagged-vlan-interface-set-name predefined variable locally generates an

interface set name used for grouping logical interfaces stacked over logical stacked
VLAN demux interfaces for either a 1:1 (dual-tagged; individual client) VLAN or N:1
(single tagged; service) VLAN. The format of the generated variable differs with VLAN
type as follows:
• Dual-tagged (client) VLAN—physical_interface_name - outer_VLAN_tag -

inner_VLAN_tag. For example, an aggregated Ethernet interface “ae0,” with a
dual-tagged VLAN interface that has an outer tag of “111” and an inner tag of “200,”
results in a $junos-tagged-vlan-interface-set-name dynamic variable of “ae0-200-111”.
Similarly, a non-aggregated Ethernet interface of ge-1/1/0, with the same dual-tagged

Chapter 15: Applying CoS to Groups of Subscriber Interfaces
VLAN interface that has an outer tag of “111” and an inner tag of “200,” results in a
$junos-tagged-vlan-interface-set-name dynamic variable of “ge-1/1/0-200-111”.
• Single tagged (service) VLAN—physical_interface_name - VLAN_tag. For example, an

aggregated Ethernet interface “ae0,” with an N:1 VLAN using the single tag of “200,”
results in a $junos-tagged-vlan-interface-set-name dynamic variable of “ae0-200”.
Similarly, a non-aggregated Ethernet interface of ge-1/1/0, with the same N:1 VLAN
using the single tag of “200,” results in a $junos-tagged-vlan-interface-set-name
dynamic variable of “ge-1/1/0-200”.
• All dynamic demux, dual-tagged VLAN logical interfaces with the same outer VLAN
tag and physical interface are assigned to the same interface set and all CoS values
provisioned with the dynamic profile are applied to the interfaces that are part of the
set.
• The interface set name must be explicitly referenced in the CoS configuration as part
of the static configuration outside of the dynamic profile. The CoS configuration is
static and the interface set name must be statically referenced.
NOTE: This rule applies to all interface sets except ACI sets.
• RADIUS can return an access-accept message under certain conditions. A configured

RADIUS VSA for the interface set name takes precedence over the locally generated
variable on the router. This means that if the interface-set-name VSA is configured on
RADIUS, the router continues to use this variable instead of the locally generated value
from the dynamic variable.
• Sets of aggregated Ethernet interfaces are supported on MPC/MIC interfaces on MX

Series routers only.
• The supported interface stacks for aggregated Ethernet in an interface set include
VLAN demux interfaces, IP demux interfaces, and PPPoE logical interfaces over VLAN
demux interfaces.
• The link membership list and scheduler mode of the interface set are inherited from
the underlying aggregated Ethernet interface over which the interface set is configured.
• When an aggregated Ethernet interface operates in link protection mode, or if the

scheduler mode is configured to replicate member links, the scheduling parameters
of the interface set are copied to each of the member links.
• If the scheduler mode of the aggregated Ethernet interface is set to scale member
links, the scheduling parameters are scaled based on the number of active member
links and applied to each of the aggregated interface member links.
Related • Configuring an Interface Set of Subscribers in a Dynamic Profile on page 198

Documentation
Profile on page 211

Configuring an Interface Set of Subscribers in a Dynamic Profile
Interface sets enable you to provide hierarchical scheduling to a group of subscriber

interfaces.
Before you begin, configure the subscriber interfaces that you intend to include in the
interface set.
To configure an interface set of subscriber interfaces:
1. Configure the interface set in the dynamic profile.
[edit dynamic-profiles profile-name interfaces]

Replacing the interface-set-name variable with the $junos-interface-set-name,

$junos-svlan-interface-set-name, or $junos-tagged-vlan-interface-set-name predefined
variable. The interface set is created dynamically when the subscriber logs in.
2. Include the interfaces within the dynamic interface-set.
[edit dynamic-profiles profile-name interfaces interface-set $junos-interface-set-name]

user@host# set interface interface-name unit logical-unit-number
3. Apply traffic shaping and queuing parameters to the interface set.
TIP: You must configure the interface set in the static [edit class-of-service]
hierarchy, not in the [edit dynamic-profiles] hierarchy.
[edit class-of-service interfaces]

user@host# edit interface-set interface-set-name
[edit class-of-service interfaces interface-set interface-set-name]
Related • CoS for Interface Sets of Subscribers Overview on page 195

Documentation
• CoS for Interface Sets of Subscribers Overview on page 195
• Example: Configuring a Dynamic Interface Set of VLAN Subscribers on page 198
• CoS for Aggregated Ethernet Subscriber Interfaces Overview on page 8
Example: Configuring a Dynamic Interface Set of VLAN Subscribers

• Configuring the Dynamic VLANs on page 199
• Configuring Dynamic Traffic Scheduling and Shaping on page 201
• Configuring the Interface Set in the Dynamic Profile on page 204

• Configuring DHCP Access on page 205

• Configuring RADIUS Authentication on page 206
Requirements
This example uses the following software and hardware components:
• MX Series Router with MPCs
Overview
In this example, the network administrator groups dynamic VLAN interfaces in an interface
set. The interface set is configured in a dynamic profile, and enables hierarchical scheduling
for the VLAN interfaces for a multiplay service.
DHCP is used as the access method, and RADIUS is used as the authentication method
for the interfaces associated with the interface set.
Configuring the Dynamic VLANs

CLI Quick To quickly configure the dynamic VLANs, copy the following commands and paste them
Configuration into the router terminal window:
[edit]
edit dynamic-profiles vlan-prof
edit interfaces $junos-interface-ifd-name unit $junos-interface-unit
set vlan-id $junos-vlan-id
set demux-source inet
set family inet unnumbered-address lo0.0 preferred-source-address 100.20.32.2
top
edit interfaces ge-1/0/0
set hierarchical-scheduler
set vlan-tagging
edit auto-configure vlan-ranges dynamic-profile vlan-prof
set ranges any
set accept inet
top
set interfaces lo0 unit 0 family inet address 100.20.32.2/32
Configuring the Dynamic Profile for the Autoconfigured VLANs
Step-by-Step In this section, you create a dynamic profile for the VLAN IDs to be automatically assigned
Procedure when subscribers log in.
To configure the dynamic profile for the VLANs:
1. Configure the dynamic profile.
[edit]
user@host#edit dynamic-profile vlan-prof
2. Configure the interfaces.
[edit dynamic-profiles vlan-prof]

user@host#edit interfaces $junos-interface-ifd-name unit $junos-interface-unit
3. Add the VLAN ID variable.
[edit dynamic-profiles vlan-prof interfaces $junos-interface-ifd-name unit

$junos-interface-unit]
user@host#set vlan-id $junos-vlan-id
4. Configure the demux source as IPv4.

user@host#set demux-source inet
5. Configure the family.

user@host#set family inet unnumbered-address lo0.0 preferred-source-address
100.20.32.2
Configuring the VLAN Interfaces
Step-by-Step To configure the VLAN interfaces:

Procedure
1. Create the VLAN interface.
[edit]
user@host# edit interfaces ge-1/0/0
2. Enable hierarchical scheduling.

3. Configure VLAN tagging.

user@host# set vlan-tagging
4. Configure auto-configuration for the dynamic profile.

user@host# edit auto-configure vlan-ranges dynamic-profile vlan-prof
5. Configure any VLAN ID range.
[edit interfaces ge-1/0/0 auto-configure vlan-ranges dynamic-profile vlan-prof]

user@host# set ranges any
6. Specify IPv4 traffic for the VLAN.
[edit interfaces ge-1/0/0 auto-configure vlan-ranges dynamic-profile vlan-prof]

user@host# set accept inet
Configuring the Loopback Interface
Step-by-Step To configure the loopback interface:

Procedure
1. Create the loopback interface.
[edit]

user@host# edit interfaces lo0
2. Configure the unit and the family.
[edit intefaces lo0]

user@host# set unit 0 family inet address 100.20.32.2/32
Configuring Dynamic Traffic Scheduling and Shaping

CLI Quick To quickly configure the traffic scheduling and shaping parameters, copy the following
Configuration commands and paste them into the router terminal window:
[edit]
edit dynamic-profiles multiplay class-of-service schedulers be_sch
set transmit-rate percent 12
set buffer-size percent 12
set priority low
up
edit ef_sch
set priority low
up
edit af_sch
set priority low
up
edit nc_sch
set priority low
up
edit voice_sch
set priority low
up
edit video_sch
set priority low
up
edit game_sch
set priority low
up
edit data_sch
set priority low
up 2
edit scheduler-maps all_smap
set forwarding-class be scheduler be_sch
set forwarding-class ef scheduler ef_sch

set forwarding-class af scheduler af_sch

set forwarding-class nc scheduler nc_sch
set forwarding-class voice scheduler voice_sch
set forwarding-class video scheduler video_sch
set forwarding-class game scheduler game_sch
set forwarding-class data scheduler data_sch
up 2
edit traffic-control-profiles multiplay
set scheduler-map all_smap
set shaping-rate 100m
set guaranteed-rate 20m
Configuring the Schedulers in the Dynamic Profile
Step-by-Step In this section, you create a dynamic profile for the multiplay service and configure
Procedure scheduling and shaping.
To configure the schedulers:
1. Create the multiplay dynamic profile.
[edit]
user@host# edit dynamic-profiles multiplay class-of-service schedulers
2. Configure the best effort scheduler.
[edit dynamic-profiles multiplay class-of-service schedulers]

user@host# edit be_sch
user@host# set buffer-size percent 12
3. Configure the expedited forwarding scheduler.

user@host# edit ef_sch
4. Configure the assured forwarding scheduler.

user@host# edit af_sch
5. Configure the network control scheduler.

user@host# edit nc_sch
6. Configure the voice scheduler.

user@host# edit voice_sch


7. Configure the video scheduler.

user@host# edit video_sch
8. Configure the gaming scheduler.

user@host# edit game_sch
9. Configure the data scheduler.

user@host# edit data_sch
Configuring the Scheduler Map in the Dynamic Profile
Step-by-Step To configure the scheduler map:

Procedure
1. Configure the scheduler map for all of the services.
[edit dynamic-profiles multiplay class-of-service]

user@host# edit scheduler-maps all_smap
2. Configure the forwarding classes for each service in the scheduler map.
[edit dynamic-profiles multiplay class-of-service scheduler-maps all_smap]

user@host# set forwarding-class be scheduler be_sch
user@host# set forwarding-class ef scheduler ef_sch
user@host# set forwarding-class af scheduler af_sch
user@host# set forwarding-class nc scheduler nc_sch
user@host# set forwarding-class voice scheduler voice_sch
user@host# set forwarding-class video scheduler video_sch
user@host# set forwarding-class game scheduler game_sch
user@host# set forwarding-class data scheduler data_sch
Configuring the Traffic-Control Profile in the Dynamic Profile
Step-by-Step To configure the traffic-control profile the interface set:

Procedure
1. Configure the traffic-control profile.
[edit dynamic-profiles multiplay class-of-service]

user@host# edit traffic control-profiles multiplay
2. Configure the scheduler map.

[edit dynamic-profiles multiplay class-of-service traffic control-profiles multiplay]

user@host# set scheduler-map all_smap
3. Configure the shaping rate.

user@host# set shaping-rate 100m
4. Configure the guaranteed rate.

user@host# set guaranteed-rate 20m
Configuring the Interface Set in the Dynamic Profile

CLI Quick To quickly configure the interface set, copy the following commands and paste them
Configuration into the router terminal window:
[edit]
edit dynamic-profiles multiplay
edit interfaces interface-set $junos-interface-set-name
set interface $junos-interface-ifd-name unit $junos-underlying-interface-unit
top
edit class-of-service interfaces interface-set
set output-traffic-control-profile multiplay
Configuring the Interfaces for the Interface Set
Step-by-Step To configure the interface variable for the interface set:

Procedure
1. Configure the dynamic profile for the interface set.
[edit]
user@host#edit dynamic-profiles multiplay
2. Configure the interface using the Junos OS predefined variable.
[edit dynamic-profiles multiplay]

user@host#edit interfaces $junos-interface-ifd-name unit
3. Configure the family.
[edit dynamic-profiles multiplay interfaces $junos-interface-set-name unit

user@host#set family inet unnumbered-address lo0.0 preferred-source-address
100.20.32.2
Configuring the Interface Set
Step-by-Step To configure the interface set:

Procedure
1. Configure the interface set using the Junos OS predefined variable.
[edit dynamic-profiles multiplay]

user@host#edit interfaces interface-set $junos-interface-set-name
2. Add the dynamic VLAN interfaces to the interface set.

[edit dynamic-profiles multiplay interfaces $junos-interface-set-name]

user@host#set interface $junos-interface-ifd-name unit
Applying the Traffic-Control Profile to the Interface Set
Step-by-Step You apply the traffic-control profile outside of the dynamic profile in the [edit
Procedure class-of-service] hierarchy.
To apply the traffic-control profile:
1. Specify the interface set to which you want to apply the traffic-control profile.
user@host#edit interfaces interface-set dynamic-set
2. Attach the output traffic-control profile defined in the dynamic profile to the interface
set.

user@host#set output-traffic-control-profile multiplay
Configuring DHCP Access

CLI Quick To quickly configure DHCP access, copy the following commands and paste them into
Configuration the router terminal window:
[edit]
edit system services dhcp-local-server authentication
set password multiplay
set username-include user-prefix multiplay
up 1
set dynamic-profile dhcp-vlan-prof aggregate-clients replace
set group vlans interface ge-1/0/0
top
edit access address-assignment pool v4 family inet
set network 100.20.0.0/16
set range limited low 100.20.0.10
set range limited high 100.20.128.250
set dhcp-attributes maximum-lease-time 84600
Configuring the DHCP Local Server
Step-by-Step To configure DHCP access:

Procedure
1. Configure the DHCP local server.
[edit system]
user@host# edit services dhcp-local-server authentication
2. Set the password.
[edit system services dhcp-local-server authentication]

user@host# set password multiplay
3. Specify that you want to include optional information in the username.

[edit system services dhcp-local-server authentication]

user@host# set username-include user-prefix multiplay
4. Attach the dynamic profile with the interface set.
[edit system services dhcp-local-server]

user@host# set dynamic-profile dhcp-vlan-prof aggregate-clients replace
5. Configure a group for the VLAN interface.
[edit system services dhcp-local-server]

user@host# set group vlans interface ge-1/0/0
Configuring Address Assignment Pools
Step-by-Step To configure address assignment pools:

Procedure
1. Configure the pool of IPv4 addresses.
[edit access]
user@host#edit address-assignment pool v4 family inet
2. Configure the family of interfaces in the pool.
[edit access address-assignment pool v4]

user@host#set network 100.20.0.0/16
3. Configure the upper and lower bounds of the address range.

user@host#set range limited low 100.20.0.10
user@host#set range limited high 100.20.128.250
4. Configure the maximum length of time in seconds for which a subscriber can request
and hold a lease.

user@host#set dhcp-attributes maximum-lease-time 84600
Configuring RADIUS Authentication

CLI Quick To quickly configure RADIUS authentication, copy the following commands and paste
Configuration them into the router terminal window:
[edit]
edit access radius-server 172.28.30.108
set secret $9$1u5ErvW87bwgSr4Zji5T
set timeout 5
set retry 5
up 2
edit profile acc-prof
set authentication-order radius
set radius authentication-server 172.28.30.108

Configuring RADIUS Access
Step-by-Step To configure RADIUS access:

Procedure
1. Configure the RADIUS server.
[edit access]
user@host#edit radius-server 172.28.30.108
2. Configure the required secret (password) that the local router or switch passes to
the RADIUS client.
[edit access radius-server 172.28.30.108]

user@host# set secret $9$1u5ErvW87bwgSr4Zji5T
3. Configure the length of time that the local router or switch waits to receive a
response from a RADIUS server.

user@host# set timeout 5
4. Configure the number of times that the router or switch attempts to contact a
RADIUS accounting server.

user@host# set retry 5
5. Configure the access profile.
[edit access]
user@host#edit profile acc-prof
6. Configure the authentication order.
[edit access profile acc-prof ]

user@host# set authentication-order radius
7. Configure the authentication server.
[edit access profile acc-prof]

user@host#set radius authentication-server 172.28.30.108
Results
dynamic-profiles {
vlan-prof {
interfaces {
demux-source inet;
family inet {
}
}
}
}
}
multiplay {

class-of-service {
multiplay {
scheduler-map all_smap;
shaping-rate 100m;
}
}
interfaces {
interface-set “$junos-interface-set-name” {
interface “$junos-interface-ifd-name” {
unit “$junos-underlying-interface-unit”;
}
}
output-traffic-control-profile multiplay;
}
}
}
scheduler-maps {
all_smap {
forwarding-class voice scheduler voice_sch;
forwarding-class game scheduler game_sch;
}
}
schedulers {
be_sch {
priority low;
}
ef_sch {
priority low;
}
af_sch {
priority low;
}
nc_sch {
priority low;
}
voice_sch {

priority low;
}
video_sch {
priority low;
}
game_sch {
priority low;
}
data_sch {
priority low;
}
}
}
}
access {
radius-server {
172.28.30.108 {
secret "$9$1u5ErvW87bwgSr4Zji5T"; ## SECRET-DATA
timeout 5;
retry 5;
}
}
profile acc-prof {
authentication-order radius;
radius {
authentication-server 172.28.30.108;
}
}
address-assignment {
pool v4 {
family inet {
network 100.20.0.0/16;
range limited {
low 100.20.0.10;
high 100.20.128.250;
}
dhcp-attributes {
maximum-lease-time 84600;
}
}
}
}
}
class-of-service {
interfaces {
interface-set dynamic-set {
output-traffic-control-profile multiplay;
}
}
}

interfaces {
interface-set “$junos-interface-set-name” {
interface "$junos-interface-ifd-name" {
unit "$junos-underlying-interface-unit";
}
}
family inet {
}
}
}
}
}
}
interfaces {
ge-1/0/0 {
vlan-tagging;
auto-configure {
vlan-ranges {
dynamic-profile vlan-prof {
accept inet;
ranges {
any;
}
}
}
}
}
lo0 {
unit 0 {
family inet {
address 100.20.32.2/32;
}
}
}
}
system {
services {
dhcp-local-server {
authentication {
password multiplay;
username-include {
user-prefix multiplay;
}
}
dynamic-profile multiplay aggregate-clients replace;
group vlans {
}
}
}
}

Verification
To confirm that the configuration is correct, perform these tasks:
• Verifying the Interfaces that are Included in the Interface Set on page 211
• Verifying the Traffic Scheduling and Shaping Parameters for the Interface
Set on page 211
Verifying the Interfaces that are Included in the Interface Set
Purpose Verify the interfaces included in the interface set.
Action user@host> show interfaces interface-set dynamic-set terse
Verifying the Traffic Scheduling and Shaping Parameters for the Interface Set
Purpose Verify that the traffic scheduling and shaping parameters are applied properly to an
interface included in the interface set.
Action user@host> show class-of-service interface
Example: Configuring a Dynamic Service VLAN Interface Set of Subscribers in a Dynamic

Profile

interfaces. In this example, by using the $junos-svlan-interface-set-name internal dynamic
variable when specifying the interface set name, you can locally generate an interface
set name for use by SVLAN interfaces based on the outer tag of the dual-tagged VLAN.
The format of the generated variable is physical_interface_name - outer_VLAN_tag.

Requirements
Before you begin, configure the subscriber interfaces that you intend to include in the
interface set. You can find general configuration instructions for the supported dynamic
interface configuration in DHCP Subscriber Interface Overviewand in the following:
• For dynamic VLAN interfaces, see Configuring a Static or Dynamic VLAN Subscriber
Interface over Aggregated Ethernet.

• For dynamic IP demux interfaces, see Configuring Dynamic Subscriber Interfaces Using
IP Demux Interfaces in Dynamic Profiles and Configuring a Static or Dynamic IP Demux
Subscriber Interface over Aggregated Ethernet.
• For dynamic VLAN demux interfaces, see Configuring Dynamic Subscriber Interfaces
Using VLAN Demux Interfaces in Dynamic Profiles.
Overview
interfaces. By using the $junos-svlan-interface-set-name internal dynamic variable when
specifying the interface set name, you can locally generate an interface set name for use
by SVLAN interfaces based on the outer tag of the dual-tagged VLAN. The format of the
generated variable is physical_interface_name - outer_VLAN_tag.
This example includes the following statements:
• interface-set—Configures the name of the scheduler for dynamic CoS. In this example,
you use the $junos-svlan-interface-set-name variable to obtain the locally generated
interface set name for use by SVLAN interfaces based on the outer tag of the
dual-tagged VLAN.
• output-traffic-control-profile—Applies an output traffic scheduling and shaping profile

to the interface set.
• output-traffic-control-profile-remaining—Applies an output traffic scheduling and

shaping profile for remaining traffic to the interface set.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
[edit]
set dynamic-profiles profile-dhcp-ipdemux interfaces interface-set
$junos-svlan-interface-set-name interface $junos-interface-ifd-name unit
set dynamic-profiles profile-dhcp-ipdemux interfaces $junos-interface-ifd-name unit
set class-of-service traffic-control-profiles tcp1 scheduler-map schedMap
set class-of-service traffic-control-profiles tcp1 shaping-rate 50m
set class-of-service traffic-control-profiles tcp1 guaranteed-rate 200k
set class-of-service traffic-control-profiles tcp3 scheduler-map ss1q0q1
set class-of-service traffic-control-profiles tcp3 shaping-rate 20m
set class-of-service traffic-control-profiles tcp3 guaranteed-rate 5m
set class-of-service interfaces interface-set ae0-111 output-traffic-control-profile tcp1
set class-of-service interfaces interface-set ae0-111
output-traffic-control-profile-remaining tcp3
Step-by-Step To configure an SVLAN interface set of subscriber interfaces:

Procedure
1. Access the dynamic profile you want to modify for interface sets.

[edit]
user@host# edit dynamic-profiles profile-dhcp-ipdemux
2. Access the dynamic profile interface configuration.
[edit dynamic-profiles profile-dhcp-ipdemux]

user@host# edit interfaces
3. Configure the SVLAN interface set in the dynamic profile.
The interface set is created dynamically when the subscriber logs in.
[edit dynamic-profiles profile-dhcp-ipdemux interfaces]

user@host# edit interface-set $junos–svlan-interface-set-name
4. Include dynamic IP demux interface creation within the dynamic interface set.
[edit dynamic-profiles profile-dhcp-ipdemux interfaces interface-set

$junos-svlan-interface-set-name]
user@host# set interface $junos-interface-ifd-name unit
5. Access the SVLAN interface set name that you expect

$junos-svlan-interface-set-name to generate. For example, to specify the expected
interface set name for aggregated Ethernet interface ae0 and outer VLAN tag 111,
include ae0-111 for the interface-set-name variable.

user@host# edit interface-set ae0-111
6. Apply traffic shaping and queuing parameters to the SVLAN interface set.
TIP: You must configure the interface set in the static [edit
class-of-service] hierarchy, not in the [edit dynamic-profiles] hierarchy.
[edit class-of-service interfaces interface-set ae0-111]

user@host# set output-traffic-control-profile tcp1
7. Apply traffic shaping and queuing parameters to any remaining traffic on the SVLAN
interface set.
[edit class-of-service interfaces interface-set ae0-111]

user@host# set output-traffic-control-profile-remaining tcp3
Results
From configuration mode, confirm your configuration by entering the show

dynamic-profiles command and the show class-of-service command. If the output does
not display the intended configuration, repeat the instructions in this example to correct
the configuration.

dynamic-profiles {
profile-dhcp-ipdemux {
interfaces {
interface-set "$junos-svlan-interface-set-name" {

interface "$junos-interface-ifd-name" {
}
}
}
}
}
}
user@host# show class-of-service

class-of-service {
tcp1 {
scheduler-map schedMap;
shaping-rate 50m;
}
tcp3 {
inactive: scheduler-map ss1q0q1;
shaping-rate 20m;
guaranteed-rate 5m;
}
}
interfaces {
interface-set ae0-111 {
output-traffic-control-profile-remaining tcp3;
}
}
}
Verification
Verifying the Interfaces that are Included in the Interface Set
Purpose Verify the interfaces that are included in the interface set.
Action user@host> show class-of-service interface-set
Displaying Information for Active Subscribers
Purpose Display information for active subscribers.
Action user@host> show subscribers detail
Related • Dynamic Profiles Overview

Documentation

• Configuring Remaining Common Queues on MIC and MPC Interfaces on page 94


CHAPTER 16
Applying CoS to Subscriber Interfaces
• Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic

Profile on page 217
• Applying Minimal Shaping and Scheduling to Remaining Subscriber Traffic on page 218
• Applying a Rewrite Rule Definition to a Subscriber Interface in a Dynamic
Profile on page 219
• Applying a Classifier to a Subscriber Interface in a Dynamic Profile on page 220
• Applying CoS Attributes to VLANs Using Agent-Circuit-Identifiers on page 221
Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic Profile
After you configure the traffic shaping and scheduling CoS parameters in a dynamic
profile, you apply them to an interface. The output traffic-control profile enables you to
provide traffic scheduling to the interface.
To apply CoS attributes to an interface in a dynamic profile:
1. Specify that you want to apply CoS attributes to an interface in the dynamic profile.
user@host# edit dynamic-profiles profile-name class-of-service
2. Configure the interface name and logical interface using a variable, and apply the
output traffic-control profile to the interface.
[edit dynamic-profiles profile-name class-of-service interfaces]

$junos-underlying-interface-unit output-traffic-control-profile profile-name
You can use one of the following methods to specify the output traffic-control profile
you want to use:
• Reference the $junos-cos-traffic-control-profile predefined variable. At subscriber

login, subscriber management takes one of the following actions, in the order listed:
a. If RADIUS is being used and it returns a value for the traffic-control profile,
subscriber management uses the RADIUS value.
b. If RADIUS is not being used, subscriber management uses the default

traffic-control profile (which is specified by the predefined-variables-default
statement at the [edit dynamic-profiles] hierarchy).

For example:

$junos-underlying-interface-unit output-traffic-control-profile
$junos-cos-traffic-control-profile
• Explicitly reference the name of the traffic-control profile.
For example:

$junos-underlying-interface-unit output-traffic-control-profile tcp-sales-2

Applying Minimal Shaping and Scheduling to Remaining Subscriber Traffic
It is beneficial to apply a remaining traffic-control profile to a logical interface to provide

minimal CoS scheduling when you have not configured or over-provisioned Layer 3
schedulers. In the event that schedulers are not available, the remaining subscriber traffic
receives the essential level of service.
To configure scheduling for remaining subscriber traffic:

2. Apply the remaining traffic-control profile to the port on which you enabled hierarchical
scheduling.

user@host# set output-traffic-control-profile-remaining profile-name
Related • Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic Profile

Chapter 16: Applying CoS to Subscriber Interfaces
Applying a Rewrite Rule Definition to a Subscriber Interface in a Dynamic Profile
Rewrite rules define the marking for various CoS values, including DSCP, DSCP IPv6, IP
precedence, and IEEE 802.1 CoS values. Rewrite rules have an associated forwarding
class and code-point alias or bit set.
NOTE: By default, subscriber lawful intercept does not intercept DHCP control
packets that are generated by the routing engine. To ensure that a DHCP
control packet generated by the routing engine is intercepted, you need to
configure the ieee-802.1 rewrite-rule for VLAN demux.
For dynamic CoS, you define the rewrite rules mapping for the CoS values statically, then
reference the rewrite rule configuration in the dynamic profile for the subscriber interface.
To configure a rewrite rule in a dynamic profile:
1. Define the rewrite-rules mapping for the traffic that passes through all queues on the
interface. The available rewrite-rules types for dynamic CoS are dscp, dscpv6,
ieee-802.1 and inet-precedence.
See Configuring Rewrite Rules.
2. Apply the rewrite-rules definition to the subscriber interface in the dynamic profile.
[edit dynamic-profiles profile-name class-of-service interfaces interface-name unit

logical-unit-number]
user@host# edit rewrite-rules
3. Configure the applicable rewrite rule markers in the dynamic profile.
• For DSCP:

logical-unit-number rewrite-rules]
user@host# set dscp (rewrite-name | default)
• For DSCPv6:

user@host# set dscp-ipv6 (rewrite-name | default)
• For IEEE 802.1:

user@host# set ieee-802.1 (rewrite-name | default) vlan-tag (outer | outer-and-inner)
• For inet-precedence:


• Applying IEEE 802.1p Rewrite Rules to Dual VLAN Tags
• Rewriting Packet Header Information Overview
Applying a Classifier to a Subscriber Interface in a Dynamic Profile
You can apply the classification map to a subscriber interface in a dynamic profile.
For dynamic CoS, you define the classification map for the CoS values statically, then
reference the classifier configuration in the dynamic profile for the subscriber interface.
To apply a classifier to an interface in a dynamic profile:
1. Define the classifier.
The available classifier types for dynamic CoS are dscp, dscp-ipv6, ieee-802.1, and
inet-precedence.
See Defining Classifiers.
2. Apply the classifier definition to the subscriber interface in the dynamic profile.

user@host# edit classifiers
3. Configure the applicable classifiers in the dynamic profile.
• For DSCP:

logical-unit-number classifiers]
user@host# set dscp (classifier-name | default)
• For DSCPv6:

user@host# set dscp-ipv6 (classifier-name | default)
• For IEEE 802.1:

user@host# set ieee-802.1 (classifier-name | default) vlan-tag (inner | outer)
• For inet-precedence:


• Applying a Rewrite Rule Definition to a Subscriber Interface in a Dynamic Profile on

page 219
• Behavior Aggregate Classifier Types Overview
• Default Behavior Aggregate Classification Overview
Applying CoS Attributes to VLANs Using Agent-Circuit-Identifiers
To apply CoS attributes, such as shaping, at the household level, you must set and define
the CoS policy for the agent-circuit-identifier VLAN interface set using the dynamic profile
for the agent-circuit-identifier interface set (not the subscriber profile). You can also
configure a traffic-control profile and a remaining traffic-control profile for a dynamic
interface set.
The following example is a CoS profile for an ACI set using a unique-ID based dynamic
scheduler map:
Before you apply CoS attributes to VLANs:
Configure a CoS dynamic profile with a simple traffic-control profile that is applied to
the dynamic interface set that represents the ACI VLAN.
1. Configure CoS to support a dynamic interface set in the CoS profile:
[edit dynamic-profiles profile-name]

user@host# edit interface "$junos-interface-name"
2. Configure the interfaces.
[edit dynamic-profiles profile-name interfaces]

user@host# edit interface-set "$junos-interface-set-name"
user@host# edit interface "$junos-interface-ifd-name"
3. Configure the CoS traffic-control profile.
user@host# edit traffic-control-profiles traffic-control-profile-name
user@host# set shaping-rate rate
user@host# set guaranteed-rate rate
4. Specify the interfaces.

user@host# edit interface-set "$junos-interface-set-name"
user@host# edit output-traffic-control-profile profile-name

The following example is a CoS profile for an ACI set using a unique ID-based dynamic
scheduler map:
aci-set-profile {
variables {
ds1q0q2DP uid;
ds1q1q2DP uid;
be1_dp uid;
ef1_dp uid;
af1_dp uid;
nc1_dp uid;
}
interfaces {
interface "$junos-interface-ifd-name";
}
}
class-of-service {
tcp2 {
inactive: scheduler-map ss1q0q1DP;
shaping-rate 50m;
overhead-accounting bytes -20;
}
tcp3 {
scheduler-map "$ds1q1q2DP";
shaping-rate 30m;
overhead-accounting bytes -20;
}
}
interfaces {
output-traffic-control-profile-remaining tcp3;
}
}
scheduler-maps {
"$ds1q0q2DP" {
forwarding-class be scheduler "$be1_dp";
forwarding-class af scheduler "$af1_dp";
forwarding-class nc scheduler "$nc1_dp";
}
"$ds1q1q2DP" {
forwarding-class ef scheduler "$ef1_dp";
forwarding-class af scheduler "$af1_dp";
forwarding-class nc scheduler "$nc1_dp";
}
}
schedulers {
"$be1_dp" {
priority low;


}
"$ef1_dp" {
priority low;
}
"$af1_dp" {
priority low;
}
"$nc1_dp" {
priority low;
}
}
}
}
Documentation


PART 2
Configuring Dynamic Filters and Policers

• Dynamic Firewall Filters Overview on page 227
• Configuring Static Firewall Filters That Are Dynamically Applied on page 231
• Streamlining Processing of Chains of Static Filters on page 239
• Dynamically Attaching Static or Fast Update Filters to an Interface on page 245
• Configuring Filters That Are Created Dynamically on page 249
• Using Ascend Data Filters to Implement Firewalls Based on RADIUS
Attributes on page 267
• Configuring Fast Update Filters to Provide More Efficient Processing Over Classic Static
Filters on page 283
• Defending Against DoS and DDoS Attacks Using Unicast RPF and Fail Filters on page 303
• Improving Scaling and Performance of Filters on Static Subscriber Interfaces on page 311
• Configuring Dynamic Service Sets on page 315
• Configuring Rate-Limiting Premium and Non-Premium Traffic on an Interface Using
Hierarchical Policers on page 317
• Monitoring and Managing Firewalls for Subscriber Access on page 333


CHAPTER 17
Dynamic Firewall Filters Overview
• Understanding Dynamic Firewall Filters on page 227

• Defining Dynamic Filter Processing Order on page 228
Understanding Dynamic Firewall Filters
Firewall filters provide rules that define whether to accept or reject packets that are
transiting an interface on a router. The subscriber management feature supports four
categories of firewall filters:
• Classic filters are static filters that are applied to an interface dynamically. They are
compiled at commit time and then, when a service is activated, an interface-specific
filter is created and attached to a logical interface. This dynamic application is
performed by associating input or output filters with a dynamic profile. When triggered,
a dynamic profile applies the filter to an interface. Because classic filters are static,
they cannot contain subscriber-specific terms (also called rules).
• Parameterized filters allow you to implement customized filters for each subscriber
session. In parameterized filters, you use variables to define a filter. When services are
activated for a subscriber, actual values such as policing rates, destination addresses,
or ports are substituted for the variables and are used to create filters.
• Ascend-Data-Filters allow you to create dynamic filters based on values received from
the RADIUS server in the Ascend-Data-Filter attribute (RADIUS attribute 242). The
filter is configured on the RADIUS server and contains rules that specifically match
conditions for traffic and define an action for the router to perform. When services are
activated for a subscriber, a filter is created based on the values in the RADIUS attribute.
You can also use Ascend-Data-Filters to create static filters by configuring the
Ascend-Data-Filter attribute in a dynamic profile.
• Fast update filters are similar to classic filters. However, fast update filters support
subscriber-specific, rather than interface-specific, filter values. Fast update filters also
allow individual filter terms to be incrementally added or removed from filters without
requiring that the entire filter be recompiled for each modification. Fast update filters
are essential for networking environments in which multiple subscribers share the same
logical interface.
You configure firewall filters to determine whether to accept or reject traffic before it
enters or exits an interface to which the firewall filter is applied. An input (or ingress)

firewall filter is applied to packets that are entering a network. An output (or egress)
firewall filter is applied to packets that are exiting a network. You can configure firewall
filters to subject packets to filtering or class-of-service (CoS) marking (grouping similar
types of traffic together and treating each type of traffic as a class with its own level of
service priority).
Related • Classic Filters Overview on page 231

Documentation
• Ascend-Data-Filter Policies for Subscriber Management Overview on page 267
• Parameterized Filters Overview on page 249
• Fast Update Filters Overview on page 284
• Dynamically Attaching Statically Created Filters for Any Interface Type on page 246
• Dynamically Attaching Statically Created Filters for a Specific Interface Family Type
on page 245
• Dynamically Attaching Filters Using RADIUS Variables
Defining Dynamic Filter Processing Order
You can force filter processing to occur in a particular order by using the precedence
statement. You specify a precedence for input and output filters within a dynamic profile
at the [edit dynamic-profiles profile-name interfaces (interface-name | demux0) unit
logical-unit-number family family] hierarchy level.
The precedence range is from 0 through 250. Setting a lower precedence value for a
filter gives it a higher precedence within the dynamic profile. A precedence of zero (the
default) gives the filter the highest precedence. If no precedence is specified, the filter
receives a precedence of zero (highest precedence). Filters with matching precedence
(zero or otherwise) are applied in random order.
Before you define a precedence for a filter in a dynamic profile.
1. Create the filters you want to attach to the dynamic profile.
See Firewall Filters Overview for information about firewall filters and how to create
them.
2. Create a basic dynamic profile.
3. Attach the filters to the dynamic profile.
See “Dynamically Attaching Statically Created Filters for Any Interface Type” on
page 246, “Dynamically Attaching Statically Created Filters for a Specific Interface
Family Type” on page 245, or Dynamically Attaching Filters Using RADIUS Variables.
To define a precedence for an input and output filter:
1. Specify the input filter precedence in the dynamic profile.

Chapter 17: Dynamic Firewall Filters Overview
[edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number

family family]
user@host# set filter input precedence 50
2. Specify the output filter precedence in the dynamic profile.

family family]
user@host# set filter output precedence 5

Documentation
• Firewall Filters Overview


CHAPTER 18
Configuring Static Firewall Filters That Are

Dynamically Applied
• Classic Filters Overview on page 231

• Basic Classic Filter Syntax on page 234
• Examples: Configuring Static Filters on page 234
Classic Filters Overview
The dynamic firewall feature supports classic filters, which are static filters that are
applied to an interface dynamically. They are compiled at commit time and then, when
a service is activated, an interface-specific clone of the filter is created and attached to
a logical interface. This dynamic application is performed by associating input or output
filters with a dynamic profile.
This overview covers:
• Classic Filter Types on page 231

• Classic Filter Components on page 232
• Classic Filter Processing on page 232
• Guidelines for Creating and Applying Classic Filters for Subscriber Interfaces on page 233
Classic Filter Types

The following classic filter types are supported:
• Port (Layer 2) firewall filter—Port firewall filters apply to Layer 2 switch ports. You can
apply port firewall filters only in the ingress direction on a physical port.
• VLAN firewall filter—VLAN firewall filters provide access control for packets that enter
a VLAN, are bridged within a VLAN, and leave a VLAN. You can apply VLAN firewall
filters in both ingress and egress directions on a VLAN. VLAN firewall filters are applied
to all packets that are forwarded to or forwarded from the VLAN.
• Router (Layer 3) firewall filter—You can apply a router firewall filter in both ingress and
egress directions on Layer 3 (routed) interfaces.

Classic Filter Components

When creating a classic filter, you first define the family address type (inet or inet6) and
then you define one or more terms that specify the filtering criteria and the action to take
when a match occurs.
Each term, or rule, consists of the following components:
• Match conditions—Specifies values or fields that the packet must contain. You can
define various match conditions, including:
• IP source address field
• IP destination address field
• Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) source port
field
• IP protocol field
• Internet Control Message Protocol (ICMP) packet type
• TCP flags
• interfaces
• Actions—Specifies what to do when a match condition occurs. Possible actions are to

accept or discard a packet. In addition, packets can be counted to collect statistical
information. If no action is specified for a term, the default action is to accept the
packet.
Classic Filter Processing

The order of the terms within a classic filter is important. Packets are tested against each
term in the order in which the terms are listed in the firewall filter configuration. When a
firewall filter contains multiple terms, the router takes a top-down approach and compares
a packet against the first term in the firewall filter. If the packet matches the first term,
the router executes the action defined by that term to either accept or reject the packet,
and no other terms are evaluated. If the router does not find a match between the packet
and first term, it then compares the packet to the next term in the firewall filter by using
the same match process. If no match occurs between the packet and the second term,
the router continues to compare the packet to each successive term defined in the firewall
filter until a match is found. If a packet does not match any terms in a firewall filter, the
default action is to discard the packet.
You can also specify a precedence (from 0 through 255) for input and output filters
within a dynamic profile to force filter processing in a particular order. Setting a lower
precedence value for a filter gives it a higher precedence within the dynamic profile. Filters
with lower precedence values are applied to interfaces before filters with higher
precedence values. A precedence of zero (the default) gives the filter the highest
precedence. If no precedence is specified, the filter receives a precedence of zero (highest
precedence). Filters with matching precedence (zero or otherwise) are applied in random
order.

Chapter 18: Configuring Static Firewall Filters That Are Dynamically Applied
NOTE: Dynamic filters do not process outbound packets that are sourced
from the routing engine. To filter outbound packets that are sourced from
the routing engine, you can create static outbound filters for each interface.
Guidelines for Creating and Applying Classic Filters for Subscriber Interfaces
Dynamic configuration of firewall filters is supported. However, you can also continue to
create static firewall filters for interfaces as you do normally, and then dynamically apply
those filters to statically created interfaces using dynamic profiles. You can also use
dynamic profiles to attach input and output filters through RADIUS.
When creating and applying filters, keep the following in mind:
• Dynamic application of only input and output filters is supported.
• The filters must be interface-specific.
• You can create family-specific inet and inet6 filters.
• You can create interface-specific filters at the unit level that apply to any family type
(inet or inet6) configured on the interface.
• You can add or remove both IPv4 and IPv6 filters with the same service activation or
deactivation.
• You can remove one filter type without impacting the other type of filter. For example,
you can remove IPv6 filters and leave the current IPv4 filters active.
• You can chain up to five input filters and four output filters together.
• If you do not configure and apply a filter, the interface uses the default group filter
configuration.
• You cannot modify or delete a firewall filter while subscribers on the same logical
interface are bound.
Related • Understanding Dynamic Firewall Filters on page 227

Documentation
on page 245
• Verifying and Managing Firewall Filter Configuration on page 333

Basic Classic Filter Syntax
This section provides the basic classic filter CLI statement syntax. The first part of this
syntax provides the CLI statements to associate an input and output filter with a dynamic
profile. The second part of this syntax represents the configured input and output filters
applied to the dynamic profile. When a DHCP event occurs, the dynamic profile applies
the specified filters to the DHCP client interface on the router.
[edit]
dynamic-profiles [profile-name] {
interfaces {
[$junos-interface-ifd-name] {
unit [$junos-underlying-interface-unit] {
family family] {
filter {
input {
[filter-name];
precedence [precedence];
}
output {
[filter-name];
precedence [precedence];
}
}
}
}
}
}
[edit]
firewall {
family [family] {
filter [filter-name] {
[desired filter configuration]
}
filter [filter-name] {
}
}
}
Related • Dynamically Attaching Statically Created Filters for a Specific Interface Family Type
Examples: Configuring Static Filters
This topic provides some static filter configuration examples.
firewall {
policer p1 {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 10m;

}
then discard;
}
family inet {
filter dfwd {
interface-specific;
term 1 {
from {
source-address {
192.1.1.0/24;
}
}
then {
count c1;
next term;
}
}
term 2 {
from {
source-address {
192.2.1.0/24;
}
}
then count c2;
}
term 3 {
then accept;
}
}
filter dfwd1 {
interface-specific;
term 1 {
from {
address {
192.1.1.0/24;
}
}
then {
discard;
}
}
}
filter tos {
interface-specific;
term 1 {
from {
precedence priority;
}
then forwarding-class assured-forwarding;
}
term 2 {
then {
log;
accept;
}
}

}
filter dfwd2 {
interface-specific;
term 1 {
from {
forwarding-class best-effort;
}
then {
sample;
forwarding-class expedited-forwarding;
}
}
term 2 {
then accept;
}
}
filter nodhcp {
term dhcpdiscover {
from {
protocol udp;
source-port 68;
destination-port 67;
}
then {
discard;
}
}
term others {
then accept;
}
}
filter p1 {
interface-specific;
term 1 {
from {
precedence priority;
}
then {
policer p1;
log;
}
}
term 2 {
then accept;
}
}
filter dscp {
interface-specific;
term 1 {
from {
dscp af11;
}
then log;
}
term 2 {
then accept;

}
}
filter tcm {
interface-specific;
term 1 {
from {
dscp af11;
}
then policer p1;
}
term 2 {
then accept;
}
}
}
traceoptions {
flag dynamic;
}
}
Related • Dynamically Attaching Statically Created Filters for Any Interface Type on page 246
Documentation
on page 245


CHAPTER 19
Streamlining Processing of Chains of

Static Filters
• Configuring Firewall Filter Bypass on page 239

• Example: Bypassing Firewall Filters on page 240
Configuring Firewall Filter Bypass
You can streamline the filter process, decrease the amount of packet handling for each
filter in a chain, and effectively bypass unnecessary filters by using the service-filter-hit
match/action combination at the [edit firewall family family-name filter filter-name term
term-name] hierarchy level.
To bypass firewall filters using the service-filter-hit match/action combination, you

configure the service-filter-hit action in at least one filter in the chain and configure
service-filter-hit match condition in any subsequent filters that you want to bypass. All
packets must pass through each filter in a chain. However, after the service-filter-hit flag
is set in a packet, the packet “bypasses” any subsequent filters that contain the
service-filter-hit match condition and more efficiently passes (accepts) marked packets
and accelerating the filter process.
NOTE: When using the service-filter-hit match/action combination, the order

in which the filters are applied is important. You can ensure the order in which
the filters are processed by specifying a filter precedence value for the
interface. See “Defining Dynamic Filter Processing Order” on page 228 for more
information about dynamic filter processing.
To bypass filter processing:
1. Specify the service-filter-hit action for any filters in a filter chain.
[edit firewall family inet filter video term 1]

user@host# set then service-filter-hit
When the match conditions for the filter are met, the service-filter-hit action is set to
indicate to subsequent filters that further processing is unnecessary.

2. Specify the service-filter-hit match condition in any filters with a lower precedence
(that is, a higher precedence statement value) that you want to detect service-filter-hit
actions applied from previous filters in the chain.
[edit firewall family inet filter data term 1]

user@host# set from service-filter-hit
3. Configure the filter to pass (accept) any packet that has a service-filter-hit action
applied from any previous filters.
[edit firewall family inet filter data term 1]


Documentation
• Example: Bypassing Firewall Filters on page 240
Example: Bypassing Firewall Filters
This example describes how to configure multiple filters using the service-filter-hit
match/action combination and contains the following sections:
• Before You Begin on page 240

• Filter Bypass Overview on page 240
• Configuring Filter Bypass on page 241
Before You Begin

When using the service-filter-hit match/action combination, keep the following in mind:
• The order in which the filters are applied is important. You can ensure the order in which
the filters are processed by specifying a filter precedence value for the interface. See
“Defining Dynamic Filter Processing Order” on page 228 for more information about
dynamic filter processing and how to use the precedence statement.
• The following example uses policers to further define the match conditions each filter
uses. These filters are not described here. To better understand how to configure
policers, see Statement Hierarchy for Configuring Policers.
Filter Bypass Overview

Packets must pass through each filter in a chain. However, if you create a chain of filters
to process different types of packets (for example, voice, video, and data packets), you
can streamline the filter process, decreasing the amount of packet handling for each
filter in the chain, effectively bypassing unnecessary filters, by using the service-filter-hit
match/action combination at the [edit firewall family family-name filter filter-name term
term-name] hierarchy level.
Figure 23 on page 241 shows the logical processing flow through a chain of three filters
(voice, video, and data) where only processing for a specific data type is desired. This

Chapter 19: Streamlining Processing of Chains of Static Filters
configuration example shows an ingress filter flow. Though subsequent ingress filters in
a chain can detect whether the service-filter-hit action is set, egress filters do not. To
bypass egress filters, you must also configure the service-filter-hit match/action
combination on those filters.
Figure 23: Logical Flow Example for Filter Bypass Processing

Voice Packets
Voice Video Data Routing

Interface
Filter Filter Filter Table
Video and Data Packets Video Packets
g017470
Voice, Video, and Data Packets Data Packets
Configuring Filter Bypass

• Configuring the Voice Filter on page 241
• Configuring the Video Filter on page 242
• Configuring the Data Filter on page 242
• Results on page 242
CLI Quick To quickly configure this example:

Configuration
[edit]
set firewall filter voice term T1 from address 1.1.1.1/32
set firewall filter voice term T1 from source-port 5004-5005
set firewall filter voice term T1 then forwarding-class assured-forwarding service-filter-hit
accept
set firewall filter voice term default then accept
set firewall filter video term T1 from service-filter-hit
set firewall filter video term T1 then accept
set firewall filter video term T2 from source-address 10.10.10.10/32
set firewall filter video term T2 then policer video-policer service-filter-hit accept
set firewall filter video term default then accept
set firewall filter data term T1 from service-filter-hit
set firewall filter data term T1 then accept
set firewall filter data term T2 then policer data-policer service-filter-hit accept
Configuring the Voice Filter
Step-by-Step To configure the voice filter for the logical flow in Figure 23 on page 241:
Procedure
1. Configure the filter to apply the assured forwarding class and set the service-filter-hit
action for traffic from a specific address and port range (over which voice traffic is
expected).
[edit]
set firewall filter voice term T1 from address 1.1.1.1/32
set firewall filter voice term T1 from source-port 5004-5005
set firewall filter voice term T1 then forwarding-class assured-forwarding
service-filter-hit accept

2. Configure the filter default action to pass (accept) packet traffic from any other
address or port range.
[edit]
set firewall filter voice term default then accept
Configuring the Video Filter
Step-by-Step To configure the video filter for the logical flow in Figure 23 on page 241:
Procedure
1. Configure the filter to pass (accept) incoming packets that are tagged by the
service-filter-hit action.
[edit]
set firewall filter video term T1 from service-filter-hit
set firewall filter video term T1 then accept
2. Configure the filter to apply a video policer and set the service-filter-hit action for
traffic from a specific address (over which video traffic is expected).
[edit]
set firewall filter video term T2 from source-address 10.10.10.10/32
set firewall filter video term T2 then policer video-policer service-filter-hit accept
3. Configure the filter default action to pass (accept) packet traffic from any other
address or port range.
[edit]
set firewall filter video term default then accept
Configuring the Data Filter
Step-by-Step To configure the data filter for the logical flow in Figure 23 on page 241:
Procedure
1. Configure the filter to pass (accept) incoming packets that are tagged by the
service-filter-hit action.
[edit]
set firewall filter data term T1 from service-filter-hit
set firewall filter data term T1 then accept
2. Configure the filter to apply a data policer and set the service-filter-hit action for
traffic from a specific address (over which video traffic is expected).
[edit]
set firewall filter data term T2 then policer data-policer service-filter-hit accept
Results
Display the results of the configuration:
[edit firewall]
user@host# show
filter voice {
term T1 {
from {
address {

Chapter 19: Streamlining Processing of Chains of Static Filters
1.1.1.1/32;
}
source-port 5004-5005;
}
then {
forwarding-class assured-forwarding;
service-filter-hit;
accept;
}
}
term default {
then accept;
}
}
filter video {
term T1 {
from {
service-filter-hit;
}
then accept;
}
term T2 {
from {
source-address {
10.10.10.10/32;
}
}
then {
policer video_policer;
service-filter-hit;
accept;
}
}
term default {
then accept;
}
}
filter data {
term T1 {
from {
service-filter-hit;
}
then accept;
}
term T2 {
then {
policer data_policer;
service-filter-hit;
accept;
}
}
}

Documentation

• Statement Hierarchy for Configuring Policers
• Configuring Firewall Filter Bypass on page 239

CHAPTER 20
Dynamically Attaching Static or Fast

Update Filters to an Interface
• Dynamically Attaching Statically Created Filters for a Specific Interface Family

Type on page 245
Dynamically Attaching Statically Created Filters for a Specific Interface Family Type
You can dynamically attach statically created filters for either IPv4 (inet) or IPv6 (inet6)
interface types. These filters apply only to interfaces of the specified type.
Before you can attach a statically created filter using a dynamic profile.
1. Create the filters you want to attach.
See Firewall Filters Overview for information about classic firewall filters and how to
create them. See “Configuring Fast Update Filters” on page 288 for information about
creating fast update filters.
To dynamically attach statically created input and output filters:
1. Specify the unit family type you want to use when dynamically attaching the filters.
a. For IPv4 interfaces, specify the inet unit family.
[edit dynamic-profiles access-profile interfaces ge-1/1/1 unit 1]

b. For IPv6 interfaces, specify the inet6 unit family.

user@host# set family inet6
2. Specify the input filter in the dynamic profile.
[edit dynamic-profiles access-profile interfaces ge-1/1/1 unit 1 family inet]

user@host# set filter input static-input-filter
3. Specify the output filter in the dynamic profile.

NOTE: The following example specifies an optional precedence value for

the output filter.
[edit dynamic-profiles access-profile interfaces ge-1/1/1 unit 1 family inet]

user@host# set filter output static-output-filter precedence 50

Documentation
• Using Junos OS Defaults Groups
Dynamically Attaching Statically Created Filters for Any Interface Type
You can dynamically attach statically created filters for any interface type. These filters
apply to any interfaces that are created using the dynamic profile.
NOTE: For an L2TP LNS on MX Series routers, you can attach firewall for
static LNS sessions by configuring these at logical interfaces directly on the
inline services device (si-fpc/pic/port). RADIUS-configured firewall
attachments are not supported.
Before you can attach a statically created filter using a dynamic profile.
1. Create the filters you want to attach.
See Firewall Filters Overview for information about classic firewall filters and how to
create them. See “Configuring Fast Update Filters” on page 288 for information about
creating fast update filters.
To dynamically attach statically created input and output filters for all interfaces created
dynamically using the dynamic profile:
1. Access the dynamic profile, interface, and unit that you want to use when applying
the static filters.
[edit]
user@host# edit dynamic-profiles access-profile interfaces ge-1/1/1 unit 1
2. Specify the input filter for the interface unit.

Chapter 20: Dynamically Attaching Static or Fast Update Filters to an Interface
user@host# set filter input static-input-filter
3. Specify the output filter for the interface unit.

user@host# set filter output static-output-filter

Documentation
on page 245
• Using Junos OS Defaults Groups


CHAPTER 21
Configuring Filters That Are Created

Dynamically

• Unique Identifiers for Firewall Variables on page 250
• Configuring Unique Identifiers for Parameterized Filters on page 252
• Sample Dynamic-Profile Configuration for Parameterized Filters on page 253
• Dynamic Profile After UID Substitutions for Parameterized Filters on page 255
• Multiple Parameterized Filters on page 256
• Parameterized Filter Processing Overview on page 256
• Parameterized Filters Configuration Considerations on page 258
• Guidelines for Creating and Applying Parameterized Filters for Subscriber
• IPv4 Parameterized Filter Match Conditions on page 260
• IPv6 Parameterized Filter Match Conditions on page 260
• Parameterized Filter Actions and Modifiers on page 261
• Parameterized Filter Policer Actions on page 262
• Interface-Shared Filters Overview on page 262
• Example: Implementing a Filter for Households That Use ACI-Based VLANs on page 263
• Example: Dynamic-Profile Parsing on page 264
• Example: Firewall Dynamic Profile on page 265
Parameterized Filters Overview
Parameterized filters allow you to implement customized filters for each subscriber
session. In parameterized filters, you use variables called unique identifiers (UIDs) to
define your filter. When services are activated for a subscriber, actual values are
substituted for the variables and are used to create filters.
Parameterized filters are configured under a dynamic profile. You can configure a general
baseline filter under a dynamic profile and then provide specific variables of that filter
when a dynamic session is activated. These variables can include policing rates,
destination addresses, ports, and other items.

To provide better scaling, the system analyzes a dynamic profile, and then determines
whether the set of variables for one session is the same as for a previous session. If a
matching filter already exists, the session creates an interface-specific filter copy of that
filter template. If the filter does not already exist, the session reads the configuration and
compiles a new filter. This filter is installed as a template with an interface-specific filter
copy for the current session pointing to it.

Documentation
Unique Identifiers for Firewall Variables
The system uses unique identifiers (UIDs) to aid with scaling. The UID enables the system
to determine when configuration objects from multiple subscribers are identical and can
be shared. In many situations, such as a filter definition, sharing a single filter among
multiple subscribers instead of creating a new filter for every subscriber helps to conserve
system resources.
Within a dynamic profile a UID is used to name a configuration object. The system assigns
the value of the UID (the object's name) based upon all the variables contained within
that configuration stanza along with the dynamic profile's name. The assigned UID value
consists of the UID name combined with the string_UID and a unique number. For instance,
the UID $my-filter might be given the value my-filter_UID1022.
You must first define a UID under the variable stanza using the option uid. The UID must
be defined at the end, after all the variables that are assigned values externally.
dynamic-profile test-profile {
[variables] {
... [other variables] ...
[my-filter] {
uid;
}
}
}
After a UID has been defined, it can then be used to name an object:
dynamic-profile test-profile {
firewall {
family inet {
filter [$my-filter] {
... [filter definition that makes use of other variables] ...
}

Chapter 21: Configuring Filters That Are Created Dynamically
}
}
}
As previously described, the system assigns the value of $my-filter depending on the
values of the variables used within that filter's definition.
The UID is also used in any other place that the object's name is used. For example, here
is an interface stanza to use $my-filter as an input filter:
dynamic-profile [test-profile] {
interfaces {
[$junos-interface-ifd-name]" {
unit [$junos-interface-unit] {
family inet {
filter {
input [$my-filter];
}
}
}
}
}
}
You can define multiple configuration objects of the same type (that is, multiple filters)
as long as each one uses its own, individual, UID. To ensure that the system selects the
correct object when assigning a name, use the uid-reference variable.
When the uid-reference is used, it is effectively evaluated twice. First, the value of the
uid-reference variable is retrieved. Second, that value is used as the name of a UID and
that UID value is retrieved. A uid-reference with a value that is not the name of a UID is
considered an error.
A uid-reference is defined similarly to any other variable:
variables {
[my-filter-selector] {
uid-reference;
}
}
}
A uid-reference is used wherever the name of the object is needed. One example is the
name of the input filter in the following interface stanza:
interfaces {
unit [$junos-interface-unit] {
family inet {
filter {
input [$my-filter-selector];
}
}
}

}
}
}
Consider the case where two parameterized filters are defined: $my-filter-1 and
$my-filter-2. The $my-filter-selector variable might be assigned the value my-filter-1 or
my-filter-2, depending upon which filter is appropriate.
Related • Configuring Unique Identifiers for Parameterized Filters on page 252

Documentation
Configuring Unique Identifiers for Parameterized Filters
This topic discusses how to configure unique identifiers (UIDs) that can then be used in
parameterized filters. The dynamic profile obtains and replaces data for these variables
from an incoming client data packet.
To configure unique identifiers for parameterized filters in a dynamic profile:
1. Access the desired dynamic profile.
[edit]
user@host# edit dynamic-profiles Profile1
[edit dynamic-profiles Profile1]
2. Configure the UIDs.
If the value for the variable UID comes from RADIUS, configure the variable as a UID
reference.
[edit dynamic-profiles Profile1]

user@host# set variable policer1 uid
user@host# set variable policer2 uid
user@host# set variable filter1 uid
user@host# set variable filter2 uid
user@host# set variables in-filter uid-reference
Example of UIDs that can be used in parameterized filters:
dynamic profile {
Profile1 {
variables {
policer1 uid;
filter1 uid;
policer2 uid;
filter2 uid;
in-filter {
uid-reference;
}
}
}

Related • Unique Identifiers for Firewall Variables on page 250

Documentation
Sample Dynamic-Profile Configuration for Parameterized Filters
In the following sample configuration, the my-svc-prof profile provides two different
filters: my-filt-1gw and my-filt-2gw. These filters match on either one or two gateway
addresses and apply a policer for that traffic. The name of the filter to apply, the gateway
addresses, and the bandwidth for the policer are passed into the service profile from the
RADIUS service activation. The uid-reference type supports selection of a particular UID
generated object out of multiple objects in the profile. The UID type indicates that a
variable is used for UID generation.
dynamic-profile {
[my-svc-prof] {
variable {
[my-in-filter] {
mandatory;
uid-reference;
}
gw1 {
mandatory;
}
gw2 {
mandatory;
}
bw {
mandatory;
}
my-filt-1gw {
uid;
}
my-filt-2gw {
uid;
}
[my-policer] {
uid;
}
}
interfaces {
unit [$junos-underlying-interface-unit] {
family inet {
filter {
input [$my-in-filter];
}
}
}
}

}
firewall {
policer [$my-policer] {
if-exceeding {
bandwidth-limit $bw;
burst-size-limit 15000;
}
then discard;
}
family inet {
filter [$my-filt-1gw] {
interface-specific;
term t0 {
from {
destination-address $gw1;
}
then {
policer [$my-policer];
}
}
term last {
then {
count drops;
discard;
}
}
}
filter [$my-file-2gw] {
interface-specific;
term t0 {
from {
destination-address {
$gw1;
$gw2;
}
}
then {
policer [$my-policer];
}
}
term last {
then {
count drops;
discard;
}
}
}
}
}
}
}
Related • Dynamic Profile After UID Substitutions for Parameterized Filters on page 255
Documentation

Dynamic Profile After UID Substitutions for Parameterized Filters
In the following example, the client session is created on the ge-1/0/0.7 interface and
this service is activated:
my-svc-prof(my-filt-1gw, 207.17.137.239/32, 0, 5m)
A dynamic profile is created by the process. The UIDs assigned by the process are based
on the parameters being passed in as well as the sessions previously created.
dynamic-profile {
[my-svc-prof] {
interfaces {
ge-1/0/0 {
unit 7 {
family inet {
filter {
input my-filt-1gw_UID1022;
}
}
}
}
}
firewall {
policer my-policer_UID1005 {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 15000;
}
then discard;
}
family inet {
filter my-filt-1gw_UID1022 {
interface-specific;
term t0 {
from {
destination-address 207.17.137.239/32;
}
then {
policer my-policer_UID1005;
}
}
term last {
then {
count drops;
discard;
}
}
}
filter my-filt-2gw_UID11018 {
interface-specific;
term t0 {
from {
207.17.137.239/32;

0;
}
}
then {
policer my-policer_UID1005;
}
}
term last {
then {
count drops;
discard;
}
}
}
}
}
}
}
Related • Sample Dynamic-Profile Configuration for Parameterized Filters on page 253

Documentation
Multiple Parameterized Filters
Differing filter match conditions can be achieved by allowing the filter that is being
attached to be selected by the unique-identifier--reference capabilities of parameterized
filters. If a variable number of terms or varying match conditions are needed, multiple
filters are defined. When the service is activated, that activation will select the particular
filter that should be applied in the stanza specifying the interface, unit, family and
input/output filter:
interfaces {
ge-1/0/0 {
unit 7 {
family inet {
filter {
input my-filt-1gw-uid1022;
}
}
}
}
}
Related • Parameterized Filter Processing Overview on page 256

Documentation
Parameterized Filter Processing Overview
When creating a parameterized filter, you first define the family address type (inet or
inet6) and then you define one or more terms that specify the filtering criteria and the
action to take when a match occurs.

Each term, or rule, consists of the following components:
• Match conditions—Specifies values or fields that the packet must contain. You can
define various match conditions, including:
• IP source address field
• IP destination address field
• Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) source port
field
• IP protocol field
• Internet Control Message Protocol (ICMP) packet type
• TCP flags
• interfaces
• Actions—Specifies what to do when a match condition occurs. Possible actions are to

accept or discard a packet. In addition, packets can be counted to collect statistical
information. If no action is specified for a term, the default action is to accept the
packet.
The processing of parameterized filters is the same as classic filters. The order of the
terms within a parameterized filter is important. Packets are tested against each term
in the order in which the terms are listed in the firewall filter configuration. When a firewall
filter contains multiple terms, the router takes a top-down approach and compares a
packet against the first term in the firewall filter. If the packet matches the first term, the
router executes the action defined by that term to either accept or reject the packet, and
no other terms are evaluated. If the router does not find a match between the packet
and first term, it then compares the packet to the next term in the firewall filter by using
the same match process. If no match occurs between the packet and the second term,
the router continues to compare the packet to each successive term defined in the firewall
filter until a match is found. If a packet does not match any terms in a firewall filter, the
default action is to discard the packet.
You can also specify a precedence (from 0 through 255) for input and output filters
within a dynamic profile to force filter processing in a particular order. Setting a lower
precedence value for a filter gives it a higher precedence within the dynamic profile. Filters
with lower precedence values are applied to interfaces before filters with higher
precedence values. A precedence of zero (the default) gives the filter the highest
precedence. If no precedence is specified, the filter receives a precedence of zero (highest
precedence). Filters with matching precedence (zero or otherwise) are applied in an
unspecified order.
NOTE: Parameterized filters do not support outbound packets that are

sourced from the routing engine.
Related • Parameterized Filters Configuration Considerations on page 258

Documentation

Parameterized Filters Configuration Considerations
Keep the following considerations in mind when configuring parameterized filters.
• Subscriber IP Address on page 258

• Interaction with Static Configuration on page 258
• Interface-Specific Dynamic Service Filters on page 258
• Service Session Support on page 258
• Filter Naming Conventions on page 259
Subscriber IP Address
In most deployment scenarios, the interface is based on the subscriber’s IP address.
Because subscribers may not be unique, they cannot be used in determining similar filters
and policers. Do not use the junos-subscriber-ip-address IP address as a match candidate.
Doing so causes unique filters per subscriber, which inhibits scaling.
Interaction with Static Configuration

Searching for a filter to attach takes place in the following order:
1. Static filter. For example, firewall family inet filter my-filter.
2. Fast update filter within the current dynamic profile. For example, dynamic-profile
[profile-name] firewall family inet fast-update-filter my-filter.
3. Parameterized filter within the current dynamic profile. For example, dynamic-profile
[profile-name] firewall family inet filter.
The following static configuration objects may be referenced by a parameterized filter.

The search order is first in the static configuration and then in the current dynamic-profile:
• firewall policer
• firewall hierarchical-policer
• three-color policer
• policy-options prefix-list
If an object in the static configuration is being used by an active parameterized filter, you
cannot delete that object from the configuration while the subscriber is logged in.
Interface-Specific Dynamic Service Filters

All dynamic service filters must be defined as interface-specific.
Service Session Support

Parameterized filters and policers are supported for service activations only, not client
sessions.

Filter Naming Conventions

The base filter name is based on the interface and direction (ingress and egress) appended
to it. With parameterized filters, the filter-naming process comes from the UID.

Documentation
Guidelines for Creating and Applying Parameterized Filters for Subscriber Interfaces
Dynamic configuration of firewall filters is supported. However, you can also continue to
create static firewall filters for interfaces as you do normally, and then dynamically apply
those filters to statically created interfaces using dynamic profiles. You can also use
dynamic profiles to attach input and output filters through RADIUS.
When creating and applying filters, keep the following in mind:
• Dynamic application of only input and output filters is supported.
• The filters must be interface-specific.
• You can create family-specific inet andinet6 filters.
• You can create interface-specific filters at the unit level that apply to any family type
(inet or inet6) configured on the interface.
deactivation.
• You can chain up to five input filters and four output filters together.
• If you do not configure and apply a filter, the interface uses the default group filter
configuration.
• You cannot modify a firewall filter while subscribers on the same logical interface are
bound.
Related • Parameterized Filter Processing Overview on page 256

Documentation

IPv4 Parameterized Filter Match Conditions
The following IPv4 match conditions are supported for parameterized filters. Their syntax
is the same as the static filter syntax.
address
destination-address
destination-port
destination-port-except
destination-prefix-list
dscp
dscp-except
forwarding-class
forwarding-class-except
icmp-code
icmp-code-except
icmp-type
icmp-type-except
loss-priority
loss-priority-except
packet-length
packet-length-except
port
port-except
precedence
precedence-except
prefix-list
protocol
protocol-except
service-filter-hit
source-address
source-class
source-port
source-port-except
source-prefix-list
ttl
ttl-except
Related • Firewall Filter Match Conditions for IPv4 Traffic

Documentation
IPv6 Parameterized Filter Match Conditions
The following IPv6 match conditions are supported for parameterized filters. Their syntax
address
destination-address
destination-port

destination-port-except
destination-prefix-list
forwarding-class
forwarding-class-except
icmp-code
icmp-code-except
icmp-type
icmp-type-except
loss-priority
loss-priority-except
packet-length
packet-length-except
port
port-except
prefix-list
service-filter-hit
source-address
source-class
source-port
source-port-except
source-prefix-list
traffic-class
traffic-class-except
Related • Firewall Filter Match Conditions for IPv6 Traffic

Documentation
Parameterized Filter Actions and Modifiers
The following actions and modifiers are supported for parameterized filters. Their syntax
accept
count
discard
forwarding-class
hierarchical-policer
log
loss-priority
next
policer
port-mirror
port-mirror-instance
reject
routing-instance
sample
service-accounting
service-accounting-deferred
service-filter-hit

three-color-policer
Related • Firewall Filter Terminating Actions

Documentation
• Firewall Filter Nonterminating Actions
Parameterized Filter Policer Actions
The following policer actions are supported for parameterized filters. Their syntax is the
same as the existing static policer syntax.
discard
forwarding-class
loss-priority
Related • Firewall Filter Terminating Actions

Documentation
• Firewall Filter Nonterminating Actions
Interface-Shared Filters Overview
Interface-shared filters can be defined statically or dynamically, but can only be applied
using dynamic profiles, and are supported for both client and service sessions. The same
interface-shared instance can be attached to multiple interfaces only if these interfaces
reference the same interface-shared filter name and have the same shared name.
The shared name can be taken from either the $junos-interface-set-name variable or the
$junos-svlan-interface-set-name variable, where the values of the variables are provided
by the related client session or service session. For example, if the
$junos-interface-set-name variable is defined as the shared name, the same
interface-shared filter instance is attached to all logical interfaces that belong to the
interface set defined by the variable of that session. Similarly, if
$junos-svlan-interface-set-name is defined for the shared name, all logical interfaces
that belong to the VLAN interfaces set defined by the session's variable share the same
interface-shared instance.
With VLAN subscriber interfaces that use the agent-circuit-identifier information, many
subscribers share the same underlying logical interface. Because some of these
subscribers are related to each other as part of the same household, you must apply an
interface-shared filter to the subscriber logical interfaces that make up the household
to be able to filter and police these related subscribers at a household level. All interfaces
that share the same interface-shared filter instance share the same set of counters and
policer actions.
The base filter name of a parameterized filter is assigned depending upon the profile
name and the contents of the filter definition. Therefore, when an interface-shared filter
is used with parameterized filters, all service sessions that want to share the same instance
of an interface-shared filter must have the exact same parameterized filter and profile.
A service session uses a different instance of the interface-shared filter if either the
parameterized filter or the profile is different.

Related • Example: Implementing a Filter for Households That Use ACI-Based VLANs on page 263
Documentation
Example: Implementing a Filter for Households That Use ACI-Based VLANs
In the following example using an interface-shared filter, you configure a dynamic profile
that is used to implement agent-circuit-identifier VLAN household filtering. If
$junos-input-filter is FILTER1 and $junos-interface-set-name is ACI1, then a filter with the
name FILTER1-ACI1-in is created and attached to the demux0 unit. When a subsequent
login from the same household occurs, it is in the same VLAN. If $junos-input-filter is also
FILTER1, the next demux0 interface also has the FILTER1-ACI1-in filter attached. A low
value precedence was used with the interface-shared filter. If you want to have the
interface-shared filter applied first, give a higher precedence to any other filters that are
attached to the same interfaces.
Filter with interface-set match cannot be used on dynamic interface—dynamic

interface-set match is not supported. The shared-name of an interface-shared filter can
now be populated from the $junos-svlan-interface-set-name variable. This means
interface-shared filter can also be attached to dynamic SVLAN interface-set, before
which the shared-name could only be taken from the $junos-interface-set-name variable.
Before you can attach an interface-shared filter using a dynamic profile.
To configure an interface-shared filter using a dynamic profile that is used to implement

agent-circuit-identifier VLAN household filtering:
1. Access the dynamic profile you want to use.
[edit]
user@host# edit dynamic-profiles client-profile
2. Specify the interfaces and the unit.
[edit dynamic-profiles client-profile]

user@host# edit interfaces demux0 unit $junos-interface-unit
3. Specify the family.
[edit dynamic-profiles client-profile interfaces demux0 unit “$junos-interface-unit”]

user@host# edit family inet
4. Specify the input filter and the filter terms for the interface unit.
[edit dynamic-profiles client-profile interfaces demux0 unit “$junos-interface-unit”

family inet]
user@host# edit input $junos-input-filter shared-name $junos-interface-set-name
precedence precedence-number
5. Specify the output filter and the filter terms for the interface unit.
[edit dynamic-profiles client-profile interfaces demux0 unit “$junos-interface-unit”

family inet]

user@host# edit input $junos-output-filter shared-name $junos-interface-set-name

precedence precedence-number
6. Specify that you want to configure a firewall, and specify the family.
[edit dynamic-profiles client-profile]

user@host# edit firewall family inet
7. Specify the filter.
[edit dynamic-profiles client-profile firewall family inet

user@host# edit filter uid
8. Specify that the filter is an interface-shared filter.
[edit dynamic-profiles client-profile firewall family inet filter uid]

user@host# set interface-shared
[edit]
dynamic-profile {
client-profile {
interfaces {
demux0 {
unit $junos-interface-unit {
family inet {
filter {
input $junos-input-filter shared-name $junos-interface-set-name precedence
10;
}
}
}
}
}
}
}
firewall {
family inet {
filter FILTER1 {
interface-shared;
term… # the filter’s terms
}
}
}
Related • Dynamically Attaching Statically Created Filters for a Specific Interface Family Type
Example: Dynamic-Profile Parsing
The following example shows the basic dynamic-profile parsing steps for parameterized
filters.

1. Read dynamic-profiles my-svc-prof interface ge-1/0/0 unit 7 family inet filter input
and get the value my-filt-1gw_UID1022. The my-in-filter variable received the name
of the UID (my-filt-1gw) from the first service parameter. The name
my-filt-1gw_UID1022 comes from the value of the my-filt-1gw UID.
2. Determine whether a static filter called my-filt-1gw_UID1022 exists. If so, this is the
existing classic filter case and not a parameterized filter.
3. Try to read dynamic-profile my-svc-prof firewall family inet fast-update-filter

my-filt-1gw_UID1022’. If this exists, this is a fast update filter, not a parameterized
filter.
4. Try to read dynamic-profile my-svc-prof firewall family inet filter

my-filt-1gw_UID1022. If this does not exist, return a “filter not found” error.
5. Search for a template named my-filt-1gw_UID1022. If it does not exist:
a. Read the parameterized filter configuration. This adds the match destination
address 207.17.137.239 and the policer my-policer_UID1005 as the action.
b. Determine whether my-policer_UID1005 exists. If it does not, read the

dynamic-profile my-svc-prof firewall policer my-policer_UID1005 configuration
and create the my-policer_UID1005 policer.
c. Compile the my-filt-1gw_UID1022 filter.
d. Install my-filt-1gw_UID1022 as a filter template.
6. Create and install an interface-specific filter reference named

my-filt-1gw_UID1022-ge-1/0/0.7-in with my-filt-1gw_UID1022 as its template.
7. Attach my-filt-1gw_UID1022-ge-1/0/0.7-in to interface ge-1/0/0.7.
When subsequent sessions are created with the same parameters, the system returns
the same my-filt-1gw_UID1022 filter name. In this case, Step 5 finds the existing filter
template and proceeds directly to Step 6.
Related • Sample Dynamic-Profile Configuration for Parameterized Filters on page 253

Documentation
Example: Firewall Dynamic Profile
In this example, dynamic firewall is configured for subscriber access using Junos IPv4
predefined variables.
The predefined variables equate to RADIUS settings as follows:
Junos OS Predefined Variable RADIUS VSA Name RADIUS Attribute Number
$junos-input-filter Ingress-Policy-Name 26–10
$junos-output-filter Egress-Policy-Name 26–11

dynamic-profiles {
DynamicFilterProfile {
interfaces {
family inet {
filter {
input “$junos-input-filter”;
output “$junos-output-filter”;
}
}
}
}
}
}
}
NOTE: You must also configure any global firewall parameters.

Documentation

CHAPTER 22
Using Ascend Data Filters to Implement

Firewalls Based on RADIUS Attributes
• Ascend-Data-Filter Policies for Subscriber Management Overview on page 267

• Ascend-Data-Filter Attribute Fields on page 269
• Dynamically Applying Ascend-Data-Filter Policies to Subscriber Sessions on page 272
• Example: Configuring Dynamic Ascend-Data-Filter Support for Subscriber
Access on page 274
• Example: Configuring Static Ascend-Data-Filter Support for Subscriber
Access on page 277
• Verifying and Managing Dynamic Ascend-Data-Filter Policy Configuration on page 281
Ascend-Data-Filter Policies for Subscriber Management Overview
Subscriber management enables you to use Ascend-Data-Filters to create policies for

subscriber traffic. An Ascend-Data-Filter is a binary value that is configured on the RADIUS
server. The filter contains rules that specify match conditions for traffic and an action for
the router to perform (such as accept or discard the traffic). The match conditions might
include the source and destination IP address or port, the protocol, the filter direction,
the traffic class, and policer information.
Subscriber management uses a dynamic profile to obtain the Ascend-Data-Filter attribute

(RADIUS attribute 242) from the RADIUS server and apply the policy to a subscriber
session. Dynamic profiles support Ascend-Data-Filters for inet and inet6 family types,
and both families can be present in a dynamic profile. You include Junos OS predefined
variables in the dynamic profiles — $junos-adf-rule-v4 for family inet and
$junos-adf-rule-v6 for inet6. The Ascend-Data-Filter attribute can include rules for both
address families. The predefined variables map the Ascend-Data-Filter rules for the
respective family to the Junos OS firewall filter process. A firewall filter is created and
attached to the subscriber’s logical interface.
You can also configure a static Ascend-Data-Filter by manually entering the required
binary data as a hexadecimal string in a dynamic profile. A statically configured
Ascend-Data-Filter in a dynamic profile takes precedence over an Ascend-Data-Filter
attribute that is received from RADIUS. The static method is time-consuming to configure;
it is typically used only for testing purposes.

The Ascend-Data-Filter attribute is supported in RADIUS Access-Accept and Change of

Authorization (CoA) messages.
CoA updates existing filters based on the Ascend-Data-Filter Type field, as shown in the
following list:
• If the Type field is 1, IPv4 rules are updated and IPv6 rules are unchanged. The opposite
is true if the Type field is 3.
• If both Type 1 and 3 are specified, then all rules are updated.
• If the CoA has no Ascend-Data-Filter rules, then the existing rules are unchanged.
Filter Naming Conventions

Each Ascend-Data-Filter has a unique name, which is assigned by the dynamic firewall
process, dfwd. The assigned names are displayed in the results of the show subscriber
extensive and show firewall commands. Ascend-Data-Filters use the following naming
convention:
__junos_adf_session#-interfacename-family-direction
For example:
__junos_adf_33847-ge/1/0/4.53-init-in
Each Ascend-Data-Filter rule maps to a single term, and the term names are simply t0,
t1, ..., tn. If you configure the counter option, the router adds a count action to each term
that is created. The counter names are a combination of the the term names with -cnt
appended. For example t0-cnt and t1-cnt.
Use of Multiple Sessions with Ascend-Data-Filters on an Interface

An interface can have multiple subscriber sessions, each session using its own
Ascend-Data-Filter rules. When an Ascend-Data-Filter is applied to a subscriber session,
the rules are created independently of any other filters and are added to the interface
filter list. The Ascend-Data-Filter rules for the other sessions on the same interface are
also added to the filter list. All packets that are processed for the interface must go
through all filters, and the filters are applied according to the precedence you set.
Because the filter list can be a combination of several rules, you must consider how the
multiple filters coexist. You must ensure that the filters are designed and applied correctly
in order to provide the desired filtering and resulting action. For example, a session might
have a filter that accepts traffic from Subscriber-A and discards all other traffic. However,
a second session on the same interface might have a filter that accepts traffic from
Subscriber-B only and discards other traffic. When the two filters are combined in the
filter list, traffic from Subscriber-B is discarded by the first filter, and traffic from
Subscriber-A is discarded by the second filter. As a result, no traffic is accepted on the
interface because the two filters essentially cancel out each other and discard all traffic.

Chapter 22: Using Ascend Data Filters to Implement Firewalls Based on RADIUS Attributes
Optional ADF Filter Requirement for Some Subscribers

When you include either of the predefined variables—$junos-adf-rule-v4 or
$junos-adf-rule-v6—in the dynamic profile, by default the RADIUS reply message must
include the Ascend-Data-Filter attribute (RADIUS attribute 242) for each subscriber. If
the attribute is not included, the router reports an error.
A service provider might apply the same dynamic profile to a mixed pool of subscribers,
such that the attribute is included by RADIUS for some of the subscribers and is not
included for others. By default, the router returns an error for each of the subscribers
without the attribute, consuming system resources. You can configure the dynamic profile
to accommodate such a mixture of subscribers by making the attribute requirement
optional. To do so, and to suppress attribute error reporting, specify the not-mandatory
option with the adf statement at the [edit dynamic-profiles profile-name interfaces
interface-name unit logical-unit-number family family filter] hierarchy level. With this
configuration, the Ascend-Data-filter is simply not created when the Ascend-Data-Filter
attribute is not present.
Related • Dynamically Applying Ascend-Data-Filter Policies to Subscriber Sessions on page 272

Documentation
Ascend-Data-Filter Attribute Fields
Table 35 on page 269 provides information about the fields used in the Ascend-Data-Filter
attribute (RADIUS attribute 242) and how the fields map to Junos OS filter functions.
The table lists the fields in the order in which they occur in the Ascend-Data-Filter attribute.
Table 35: Ascend-Data-Filter Attribute Fields

Action or Classifier Format Value Junos OS Filter Function
Type 1 byte • 1 = IPv4

• 3 = IPv6
Filter or forward 1 byte • 0 = filter • 0 = maps to discard

• 1 = forward action
• 1 = maps to accept
action
Indirection 1 byte • 0 = egress • 0 = adds egress terms

• 1 = ingress to the output filter
• 1= adds ingress terms to
the input filter
Spare 1 byte – –

Table 35: Ascend-Data-Filter Attribute Fields (continued)

Source IP address IPv4 = 4 bytes IP address of the source • 0 = no mapping

interface performed
IPv6 = 16
• From source-address
bytes
address entry added to
term
Destination IP IPv4 = 4 bytes IP address of the • 0 = no mapping

address destination interface performed
IPv6 = 16
• From
bytes
destination-address
address entry added to
term
Source IP prefix 1 byte • Type 1 = Number of • 0 = no mapping

leading zeros in the performed
wildcard mask • From source-address
• Type 3 = Higher order prefix entry added to
contiguous bits of the term
address that make up
the network portion of
the address
Destination IP prefix 1 byte • Type 1 = Number of • 0 = no mapping

leading zeros in the performed
wildcard mask • From
• Type 3 = Higher order destination-address
contiguous bits of the prefix entry added to
address that make up term
the network portion of
the address
Protocol 1 byte Protocol type • 0 = no mapping

performed
• IPv4 = from protocol
number added to term
• IPv6 = from next-header
number added to term
Established 1 byte Not implemented Not implemented
Source port 2 bytes Port number of the source From source-port x - y entry
port added to term
Destination port 2 bytes Port number of the From destination-port x - y

destination port entry added to term
Source port qualifier 1 byte • 0 = no compare • 0 = no mapping

• 1 = less than performed
• 1 – 3 = mapped to
• 2 = equal to
corresponding option
• 3 = greater than
• 4 = mapped to except
• 4 = not equal to
match option


Destination port 1 byte • 0 = no compare • 0 = no mapping

qualifier • 1 = less than performed
• 1 – 3 = mapped to
• 2 = equal to
corresponding match
• 3 = greater than
option
• 4 = not equal to
• 4 = mapped to except
match option
Reserved 2 bytes Not used Not used
Marking value 1 byte • For IPv4 = Type of Not implemented

Service (ToS)
• For IPv6 =
Differentiated Services
Code Point (DSCP)
Marking mask 1 byte 0 = no packet marking Not implemented
Traffic class 1–41 bytes • 0 = no traffic class Maps to the forwarding

(required if there is no class name. The action
profile) forwarding-class name is
• First byte specifies the added to term.
length of the ASCII
name of the traffic class
• Traffic class must be
statically configured
• Name can optionally be
null terminated, which
consumes 1 byte
• If a name is given, it
must match one of the
default forwarding
classes (such as
best-effort) or the name
of a forwarding class
configured under the
[edit class-of-service
scheduler-maps
map-name] stanza.


Rate-limit profile 1–41 bytes • 0 = no rate limit Maps to the policer

(required if there is no policer-name action
profile) modifier of the same
• First byte specifies the name. The action policer
length of the ASCII, name is added to term.
followed by the ASCII
name of the profile
• Profile must be
statically configured
• Name can optionally be
null terminated, which
consumes 1 byte
• If a name is given, it
must match the name
of one of the firewall
policers that is
configured under the
[edit firewall] stanza.
Related • Ascend-Data-Filter Policies for Subscriber Management Overview on page 267

Documentation
Dynamically Applying Ascend-Data-Filter Policies to Subscriber Sessions
Subscriber management enables you to use dynamic profiles to dynamically apply

policies that are defined in Ascend-Data-Filters (RADIUS attribute 242) to subscriber
sessions. The dynamic profiles include a Junos OS predefined variable that maps the
rules and actions defined in the Ascend-Data-Filter to Junos OS features. The RADIUS
administrator configures the Ascend-Data-Filter on the RADIUS server in a separate
operation.
Subscriber management dynamic profiles use the following Junos OS predefined variables
to map family-specific Ascend-Data-Filter rules to Junos OS filter functionality:
• $junos-adf-rule-v4—Used for IPv4 family inet.
• $junos-adf-rule-v6—Used for IPv6 family inet6.
To configure a dynamic profile to dynamically apply the policy defined by an

Ascend-Data-Filter to a subscriber session:
1. Specify the dynamic profile in which you want to include the Ascend-Data-Filter.
Specify the interface, the logical unit number, and the family type.
[edit]
user@host# edit dynamic-profiles profile-name interfaces interface-name unit
logical-unit-number family family
2. Specify that you want to include an Ascend-Data-Filter in the dynamic profile.


family family]
user@host# edit filter adf
3. Specify the Junos OS predefined variable that maps the Ascend-Data-Filter actions
to Junos OS filter functionality. Use the variable that corresponds to the specified
family type.

family family filter adf]
user@host# set rule ($junos-adf-rule-v4 | $junos-adf-rule-v6)
NOTE: You can also statically configure the Ascend-Data-Filter in this

step by entering the filter in hexadecimal format, rather than use a
predefined variable. You might use a static filter for testing purposes.
4. (Optional) Suppress error-reporting in the event the RADIUS reply messages do not
include the Ascend-Data-Filter attribute.

user@host# set not-mandatory
5. (Optional) Enable the counter feature. The counter increments each time a packet
matches the rule.

user@host# set counter
6. (Optional) Specify the input precedence used to establish the order in which filters
on the interface are applied. A lower precedence value equals a higher precedence.
The precedence relates to other dynamic filters configured on the same interface.

user@host# set input-precedence precedence
7. (Optional) Specify the output precedence used to establish the order in which filters
on the interface are applied. A lower precedence value equals a higher precedence.
The precedence relates to other dynamic filters configured on the same interface.

user@host# set output-precedence precedence

Documentation
• Verifying and Managing Dynamic Ascend-Data-Filter Policy Configuration on page 281
• Example: Configuring Dynamic Ascend-Data-Filter Support for Subscriber Access on

page 274

• Example: Configuring Static Ascend-Data-Filter Support for Subscriber Access on

page 277
Example: Configuring Dynamic Ascend-Data-Filter Support for Subscriber Access
This example shows how to configure support for dynamic Ascend-Data-Filter policies.

Requirements
• Ensure that the Ascend-Data-Filter has been configured on the RADIUS server.
• Create the dynamic profile. See Dynamic Profiles Overview.
• Configure RADIUS support. See Configuring RADIUS Server Parameters for Subscriber
Access.
Overview
Ascend-Data-Filters are configured on a RADIUS server, and contain rules that create
policies. Subscriber management uses a dynamic profile to obtain the Ascend-Data-Filter
attribute (RADIUS attribute 242) from the RADIUS server and apply the policy to a
subscriber session.
• Specify the dynamic profile to use to apply the Ascend-Data-Filter policy to the
subscriber session.
• Specify the Junos OS predefined variable that maps the Ascend-Data-Filter rules to
Junos OS filter functionality.
• Configure optional settings, which include counting the rule usage and setting the
precedence order for the filter.
Configuration
Step-by-Step To configure dynamic Ascend-Data-Filter support:
Procedure
1. Specify the dynamic profile in which you want to include the Ascend-Data-Filter,
and configure the interface, the logical unit number, and the family type.
[edit]
user@host# edit dynamic-profiles adf-profile-v4 interfaces
$junos-interface-ifd-name unit $junos-underlying-interface-unit family inet
2. Specify that you want to include an Ascend-Data-Filter in the dynamic profile and
provide the Junos OS predefined variable as the rule that maps the
Ascend-Data-Filter actions to Junos OS filter functionality.

[edit dynamic-profiles adf-profile-v4 interfaces “$junos-interface-ifd-name” unit

“$junos-underlying-interface-unit” family inet]
user@host# set filter adf rule $junos-adf-rule-v4
3. Enable the counter for the rule.

user@host# set filter adf counter
4. Specify the precedence for received packets on the interface.

user@host# set filter adf input-precedence 75
5. Specify the precedence for transmitted packets on the interface.

user@host# set filter adf output precedence 80
Results From configuration mode, confirm your configuration by entering the show
dynamic-profiles command. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.
[edit]
...
adf-profile-v4 {
interfaces {
family inet {
filter {
adf {
rule "$junos-adf-rule-v4";
counter;
input-precedence 75;
output-precedence 80;
...
If you are done configuring the device, enter commit from configuration mode.
Verification
To confirm that the configuration is working properly, perform these tasks:
• Verifying that Dynamic Ascend-Data-Filter Rules Are Applied to Subscriber

Sessions on page 275
• Verifying Dynamic Ascend-Data-Filter Usage on page 276
Verifying that Dynamic Ascend-Data-Filter Rules Are Applied to Subscriber

Sessions
Purpose Verify that the Ascend-Data-Filter rules were attached to the subscriber.

Action From operational mode, enter the show subscribers extensive command.
user@host>show subscribers extensive

Type: DHCP
User Name: user1-adf
IP Address: 192.168.1.10
IP Netmask: 255.255.255.0
Interface: ge-1/0/0.0
Interface type: Static
Dynamic Profile Name: adf-profile-v4
MAC Address: 00:10:94:00:00:01
State: Active
Radius Accounting ID: 5
Login Time: 2010-08-12 14:06:27 PDT
ADF IPv4 Input Filter Name: __junos_adf_5-ge-1/0/0.0-inet-in
Rule 0: 0101010000000000d87f9200001800000000000000000000
from {
}
then {
accept;
}
Rule 1: 010001000000000000000000000006000000001900020000
from {
protocol 6;
}
then {
discard;
}
Rule 2: 010101000000000000000000000000000000000000000000
then {
accept;
}
Meaning The output shows the information for the dynamic profile, including Ascend-Data-Filter
rules. Verify the following information:
• The User Name field indicates the correct subscriber.
• The Dynamic Profile Name field is correct for the subscriber.
• The correct Ascend-Data-Filter rules are applied to the subscriber. The display shows
the rules that are configured on the RADIUS server.
Verifying Dynamic Ascend-Data-Filter Usage
Purpose Verify usage of the dynamic Ascend-Data-Filter. Counter statistics are displayed when
the counter option is configured for the adf command in the dynamic profile.
Action From operational mode, enter the show firewall command.
user@host> show firewall

Filter: __junos_adf_5-ge-1/0/0.0-inet-in
Counters:
Name Bytes Packets
t0-cnt 32758 22
t1-cnt 22199 15
t2-cnt 21723 14
Meaning The output shows the name of the filter and lists the counter activity. If the counter option
is not configured, the output displays only the filter name.

Documentation
Example: Configuring Static Ascend-Data-Filter Support for Subscriber Access
This example shows how to configure support for static Ascend-Data-Filter policies. In
a static configuration, you manually configure the Ascend-Data-Filter as part of the
dynamic profile configuration. This procedure differs from dynamic configuration, in which
the Ascend-Data-Filter is defined on the RADIUS server and then subscriber management
uses a predefined variable to map the Ascend-Data-Filter rules to Junos OS filter
functionality. Because creating a static Ascend-Data-Filter configuration can be
labor-intensive, you might typically use this method for testing purposes.

Requirements
• Create the dynamic profile. See Dynamic Profiles Overview.
• Configure RADIUS support. See Configuring RADIUS Server Parameters for Subscriber
Access.
Overview
Ascend-Data-Filters contain rules that create policies. Subscriber management uses a
dynamic profile to apply the policy to a subscriber session. You manually configure the
Ascend-Data-Filter as part of the dynamic policy.
• Specify the dynamic profile to use to apply the Ascend-Data-Filter policy to the
subscriber session.
• Configure the Ascend-Data-Filter.
• Configure optional settings, which include counting the rule usage and setting the
precedence for received and transmitted traffic.

Configuration
Step-by-Step To configure static Ascend-Data-Filter support:
Procedure
1. Specify the dynamic profile in which you want to create the Ascend-Data-Filter,
and configure the interface, the logical unit number, and the family type.
[edit]
user@host# edit dynamic-profiles adf-profile-v4 interfaces
$junos-interface-ifd-name unit $junos-underlying-interface-unit family inet
2. Configure the Ascend-Data-Filter. Enclose the filter values within quotation marks.
You can configure multiple Ascend-Data-Filter rules in the same dynamic profile.

user@host# set filter adf rule “01000100 0A020100 00000000 18000000
00000000 00000000”
3. Enable the counter for the rule.

user@host# set filter adf counter
4. Specify the precedence for received packets on the interface.

user@host# set filter adf input-precedence 80
5. Specify the precedence for transmitted packets on the interface.

user@host# set filter adf output precedence 85
Results From configuration mode, confirm your configuration by entering the show
[edit]
...
adf-profile-v4 {
interfaces {
family inet {
filter {
adf {
rule "01000100 0A020100 00000000 18000000 00000000 00000000";
counter;
input-precedence 80;
output-precedence 85;
...

Results
The Ascend-Data-Filter rule defined in Step 2 of the procedure configures an input policy
that filters all packets from network 10.2.1.0 with wildcard mask 255.255.255.0 to any
destination.
Table 36 on page 279 lists the values specified in the Ascend-Data-Filter rule.
Table 36: Ascend-Data-Filter Rule

Action or Classifier Hex Value Junos OS Filter Function
Type 01 IPv4
Forward 00 Forward
Indirection 01 Ingress
Spare 00 None
Source IP address 0a020100 10.2.1.0
Destination IP address 00000000 Any
Source IP mask 18 24 (255.255.255.0)
Destination IP mask 00 0 (0.0.0.0)
Protocol 00 None
Established 00 None
Source port 0000 None
Destination port 0000 None
Source port qualifier 00 None
Destination port qualifier 00 None
Reserved 0000 None
Verification
To confirm that the configuration is working properly, perform these tasks:
• Verifying that Static Ascend-Data-Filter Rules are Applied to Subscriber

Sessions on page 280
• Verifying Static Ascend-Data-Filter Usage on page 280

Verifying that Static Ascend-Data-Filter Rules are Applied to Subscriber Sessions
Purpose Verify that the Ascend-Data-Filter rules you manually configured were attached to the
subscriber.
Action From operational mode, enter the show subscribers extensive command.
user@host>show subscriber extensive

Type: DHCP
User Name: user1-adf
IP Address: 192.168.1.10
IP Netmask: 255.255.255.0
Dynamic Profile Name: adf-profile-v4
MAC Address: 00:10:94:00:00:01
State: Active
Login Time: 2010-08-12 14:06:27 PDT
ADF IPv4 Input Filter Name: __junos_adf_5-ge-1/0/0.0-inet-in
Rule 0: 010001000A02010000000000180000000000000000000000
from {
}
then {
accept;
}
Meaning The output shows the information for the dynamic profile, including Ascend-Data-Filter
rules. Verify the following information:
• The User Name field indicates the correct subscriber.
• The Dynamic Profile Name field is correct for the subscriber.
• The correct static Ascend-Data-Filter rule is applied to the subscriber.
Verifying Static Ascend-Data-Filter Usage
Purpose Verify usage of the static Ascend-Data-Filter. Counter statistics are displayed when the
counter option is configured for the adf command in the dynamic profile.
Action From operational mode, enter the show firewall command.
Filter: __junos_adf_5-ge-1/0/0.0-inet-in
Counters:
Name Bytes Packets
t0-cnt 32758 22

Meaning The output shows the name of the filter and the lists counter activity. If the counter option
is not configured, the output displays only the filter name.

Documentation
Verifying and Managing Dynamic Ascend-Data-Filter Policy Configuration

Purpose View or manage information for Ascend-Data-Filters.
Action • To display statistics for Ascend-Data-Filters:
• To display firewall log information:
• To clear filter counters:
user@host> clear firewall all

Documentation


CHAPTER 23
Configuring Fast Update Filters to Provide

More Efficient Processing Over Classic
Static Filters

• Basic Fast Update Filter Syntax on page 287
• Configuring Fast Update Filters on page 288
• Example: Configuring Fast Update Filters for Subscriber Access on page 289
• Match Conditions and Actions in Fast Update Filters on page 290
• Configuring the Match Order for Fast Update Filters on page 291
• Fast Update Filter Match Conditions on page 292
• Fast Update Filter Actions and Action Modifiers on page 293
• Configuring Terms for Fast Update Filters on page 293
• Configuring Filters to Permit Expected Traffic on page 294
• Avoiding Conflicts When Terms Match on page 295
• Associating Fast Update Filters with Interfaces in a Dynamic Profile on page 300

Fast Update Filters Overview
Fast update filters provide more efficient filter processing over classic static filters when
dynamic services are implemented for multiple subscribers that share the same logical
interface.
Fast update filters support subscriber-specific filter values, as opposed to classic filters,
which are interface-specific. Fast update filters allow individual filter terms, or rules, to
be added or removed from filters without requiring the router to recompile the filter after
each modification—terms are added and removed when subscriber services are added
and removed.
Using the fast update filters feature involves three distinct operations:
1. Creating the filter—You define fast update filters under the [edit dynamic-profiles
profile-name firewall family family] hierarchy. The dynamic-profiles stanza enables
you to use dynamic variables to create subscriber-specific configurations for the filter’s
match terms. See “Configuring Fast Update Filters” on page 288.
2. Associating the filter with a dynamic profile—You use the [edit dynamic-profiles
profile-name interface interface-name unit unit-number family family hierarchy to
associate the filter with a dynamic profile. This is the same procedure used for classic
filters. See “Associating Fast Update Filters with Interfaces in a Dynamic Profile” on
page 300.
3. Attaching the filter to an interface—When a subscriber logs in, the dynamic profile
instantiates the subscriber session and applies the properties of the profile, including
the fast update filter, to the session interface. This is the same procedure used for
classic filters. Also, similar to classic filters, the name of fast update filters can be
provided in a user’s RADIUS file.
When a dynamic profile instantiates a subscriber session and applies a fast update filter,
the router verifies that the filter is not already present on the session interface. If the filter
is not present, the router adds the filter. If the filter is already present on the interface,
the router simply adds any new terms that are not in the existing filter. This procedure is
reversed when subscriber sessions are deleted. Any terms that were added by a session
are then removed when the session is deleted. The filter is deleted when the last subscriber
session is deleted.
NOTE: You can optionally specify that a term can be added only once and
cannot be modified. See “Match Conditions and Actions in Fast Update Filters”
on page 290.
This overview covers:
• Fast Update Filter Components on page 285

• Fast Update Filter Processing on page 285

Chapter 23: Configuring Fast Update Filters to Provide More Efficient Processing Over Classic Static Filters
• Fast Update Filter Names on page 286

• Guidelines for Creating and Applying Fast Update Filters on page 286
Fast Update Filter Components

When creating a fast update filter, you define one or more terms that specify the filtering
criteria and the action to take when a match occurs.
Each term consists of the following components:
• Match condition—Specifies values or fields that the packet must contain. You can
match a maximum of five fields in a fast update filter. A match condition can contain
a single value or range. This differs from classic filters, in which terms can have multiple
values. However, you can use additional terms to specify multiple ranges. “Fast Update
Filter Match Conditions” on page 292 lists the supported match conditions for fast
update filters. The order in which the terms appear in a fast update filter is not important,
because the router examines the most specific term first. (Classic filters examine the
terms in the order in which the terms are listed.)
• Action—Specifies what to do when a packet matches the match condition. If no action

is specified for a term, the default action is to accept the packet. “Fast Update Filter
Actions and Action Modifiers” on page 293 lists the supported actions for fast update
filters.
Terms that are added to the filter during session instantiation must have a unique set of
match conditions. Two terms overlap, or conflict, if a packet can match both sets of
conditions—as a result, there are two different actions for the packet. You can ensure
that terms are unique by using the $junos-subscriber-ip-address variable as the
source-address (for an input filter) or destination-address (for an output filter) in the from
statement. You must then supply the source-address or destination-address condition,
as appropriate, as the first condition in the match-order statement.
Related • Fast Update Filter Actions and Action Modifiers on page 293
Documentation
• Avoiding Conflicts When Terms Match on page 295
Fast Update Filter Processing

You must use the match-order statement to explicitly specify the order in which the router
examines filter match conditions. Also, the router examines only those conditions that
you include in the match-order statement. When a fast update filter contains multiple
terms, the router compares a packet against the terms starting with the most specific
condition first. When the packet first matches a condition, the router performs the action
defined in the term to either accept or reject the packet, and then no other terms are
evaluated. If the router does not find a match between the packet and first term, it then
compares the packet to the next term in the filter. The router continues to compare the
packet to the next specified term until a match is found. If there is no match after all
terms have been examined, the router silently drops the packet.

You can specify a precedence (from 0 through 255) for input and output filters within a
dynamic profile to force filter processing in a particular order. Setting a lower precedence
value for a filter gives it a higher precedence within the dynamic profile. Filters with lower
precedence values are applied to interfaces before filters with higher precedence values.
A precedence of zero (the default) gives the filter the highest precedence. If no precedence
is specified, the filter receives a precedence of zero (highest precedence). Filters with
matching precedence (zero or otherwise) are applied in random order.
Fast Update Filter Names

When a filter is attached to an interface, the router first searches for a classic filter with
the specified name, and then uses the classic filter. If no classic filter exists with that
name, the router then searches in the dynamic profile for a fast update filter with the
specified name, and uses that filter.
If two different dynamic profiles include a fast update filter with the same name, the
match-order specification of the two filters must be identical. If the two filters are activated
on the same interface, the terms are added together.
The router includes the filter name in show firewall command results. The router also
creates unique names for filter terms and counters for the show firewall command.
When a fast update filter is created by the activation of a dynamic profile, the router
creates an interface-specific name for the filter. The name uses the following format,
which is also used for classic filters:
<filter-name>-<interface-name>.<subunit>-<direction>
For example, an input filter named httpFilter on interface ge-1/0/0.5 is named as follows
(in indicates an input filter and out indicates an output filter):
http-filter-ge-1/0/0.5–in
The router creates unique names for the filter terms and counters by appending the
session ID to all term and counter names. Terms that use the only-at-create statement
have a session-id of 0. Terms and counters use the following format:
<term-name>-<session-id>
<counter-name>-<session-id>
Guidelines for Creating and Applying Fast Update Filters

Fast update filters enable you to create subscriber-specific firewall filters and dynamically
apply these filters to statically created interfaces using dynamic profiles. Individual terms
can be added to, or removed from, a filter without requiring that the entire filter be
recompiled.
When creating and applying fast update filters, keep the following in mind:
• Dynamic application of input and output filters is supported.
• You cannot use the same fast update filter as both an input and output filter in the
same dynamic profile attached to an interface.

• Fast update filters must always include terms that permit DHCP traffic to pass. See
“Configuring Filters to Permit Expected Traffic” on page 294.
• You can create family inet and inet6 filters.
deactivation.
• The interface-specific statement is required for all fast update filters.
• The match-order statement is required—you must explicitly state the order of the match
fields in a fast update filter. See “Configuring the Match Order for Fast Update Filters”
on page 291.
• The match-order statement uses an implied wildcard for conditions that you specify
in the statement. If you specify a condition that is not also configured in the from
specification of a filter term, the router considers that a wildcard for that condition.
• A filter term can have only a single value or range; however, you can configure multiple
terms to specify multiple ranges.
• You can match a maximum of five match conditions in a filter.

Documentation
on page 245
Basic Fast Update Filter Syntax
This section shows the basic fast update filter statement syntax. The first part of this
syntax provides the CLI statements to associate an input and output filter with a dynamic
profile. The second part of this syntax represents the configured input and output filters
associated to the dynamic profile. When a DHCP event occurs, the dynamic profile applies
the specified filters to the DHCP client interface on the router.

interfaces {
family family {
filter {
input filter-name;
precedence precedence;
output filter-name;
}

}
}
}
}
firewall {
family family {
fast-update-filter filter-name {
}
}
}
}
Related • Configuring Fast Update Filters on page 288

Documentation
Configuring Fast Update Filters
You configure a fast update filter in a dynamic profile—this enables you to use dynamic
variables in the filter configuration. After you configure fast update filters, you then use
the dynamic-profiles syntax to associate the filter with the subscriber interface.
To configure a fast update filter for subscriber access:
[edit]
user@host# edit dynamic-profiles myProfile
2. Specify that you want to configure a firewall, and specify the family.
[edit dynamic-profiles myProfile]

user@host# edit firewall family inet
3. Specify that you want to configure a fast update filter and assign a name to the filter.
[edit dynamic-profiles myProfile firewall family inet]

user@host# edit fast-update-filter httpFilter
4. Specify the interface-specific statement. This statement is mandatory.
[edit dynamic-profiles myProfile firewall family inet fast-update-filter httpFilter]

user@host# set interface-specific
5. Configure the match order to use for the filter terms.

user@host# set match-order [source-address protocol destination-port]
See “Configuring the Match Order for Fast Update Filters” on page 291.
6. Specify that you want to configure a term for the filter and assign the name to the
term. Configure the match conditions and actions for the term.

user@host# edit term term1

[edit dynamic-profiles myProfile firewall family inet fast-update-filter httpFilter term

term1]
user@host# set from protocol tcp
user@host# set from source-address $junos-subscriber-ip-address
user@host# set from destination-port http
user@host# set then count http-cnt
See “Configuring Terms for Fast Update Filters” on page 293.
Related • Configuring the Match Order for Fast Update Filters on page 291
Documentation
• Associating Fast Update Filters with Interfaces in a Dynamic Profile on page 300
• Guidelines for Configuring Firewall Filters
• Guidelines for Applying Firewall Filters
Example: Configuring Fast Update Filters for Subscriber Access
This example shows you how to configure a fast update filter that is an input filter that
counts the HTTP and non-HTTP packets from a subscriber. In the example, you use the
firewall stanza to create the filter and the interfaces stanza to attach the filter.

firewall {
family inet {
fast-update-filter httpFilter {
interface-specific;
match-order [source-address protocol destination-port];
term term1 {
from {
protocol tcp;
source-address $junos-subscriber-ip-address;
destination-port http;
}
then {
count http-cnt;
}
}
term term2 {
from {
protocol tcp;
}
then {
count non-http-cnt;
}
}
}
}

}
interfaces {
family inet {
filter {
input httpFilter;
}
}
}
}
}

Documentation
Match Conditions and Actions in Fast Update Filters
To create a fast update filter, you use the term statement to specify conditions that a
packet must have, and to specify the action the router performs when those conditions
exist in the packet.
This section covers:
• Match Conditions on page 290

• Actions on page 291
• Adding Terms Only Once on page 291
Match Conditions
Match conditions specify characteristics that a packet must have—if the conditions exist
in the packet, the router then performs the specified action. You use the from keyword
in the term statement to specify match conditions for the filter. The packet must match
all conditions in the from specification for the action to be performed, which also means
that their order in the from specification is not important.
An individual condition in a from specification can contain a single value or range. You
can match a maximum of five match conditions in a filter.
“Fast Update Filter Match Conditions” on page 292 lists the match conditions you can use
in fast update filters.
NOTE: The router uses an implied wildcard for conditions that you include
in the match-order statement. If you include a condition that is not configured
in the from specification of a filter term, the router considers that a wildcard
for the condition.
For example, if you include the dscp condition in the match-order statement,
but do not configure a dscp value in the from specification of the filter term,
the router performs the action configured in the then specification of the filter
on all DSCP values.

Actions
Actions and action modifiers specify the operation the router performs when a particular
match condition exists in a packet. You use the then keyword in the term statement to
specify the actions to perform on packets whose characteristics match the conditions
specified in the preceding from specification.
Action modifiers are actions taken in addition to the specified action. You can configure
any combination of action modifiers. For the action or action modifier to take effect, all
conditions in the from specification must match. If you specify log as one of the actions
in a term, this constitutes a termination action; whether any additional terms in the filter
are processed depends on the traffic through the filter. The action modifier operations
carry a default accept action. For example, if you specify an action modifier and do not
specify an action, the specified action modifier is implemented and the packet is accepted.
“Fast Update Filter Actions and Action Modifiers” on page 293 lists the actions and action
modifiers you can use in fast update filters.
Adding Terms Only Once

You can optionally specify that a term can be added only when the fast update filter is
first created, and cannot be later changed by adding or removing conditions. We
recommend that you only use the only-at-create option for terms that do not include
subscriber-specific data in their match conditions, such as common or default terms
(counting the default drop packet, for instance).
Related • Configuring Terms for Fast Update Filters on page 293

Documentation
Configuring the Match Order for Fast Update Filters
You must include the match-order statement to explicitly specify the order in which router
examines the match conditions. The router examines only those match conditions that
you include in the statement. You can match a maximum of five conditions.
NOTE: If the match-order statement contains a condition that is not specified

in the from statement of a term, the router considers that a wildcard for that
condition.
If you use the same fast update filter in multiple dynamic profiles, you must
configure the same match order for all profiles.
To configure the order in which the router examines the match conditions of a fast update
filter:
1. Access the fast update filter:


user@host# edit firewall family inet fast-update-filter httpFilter
2. Specify the mandatory interface-specific statement.

3. Configure the match order for the match conditions in the filter. Use brackets to enclose
multiple match conditions.

user@host# set match-order [source-address protocol destination-port]

Documentation
Fast Update Filter Match Conditions
Table 37: Fast Update Filter Match Conditions

Match Condition Description
destination-address prefix IP destination address field.
destination-port number TCP or UDP destination port field. Can be a single number, a single
range, or one of the standard port synonyms.
dscp number Differentiated services code point. Can be a single number, a single
range, or the standard synonyms. IPv4 only.
match-terms Series of match conditions. Enclose the string within quotation

string-of-conditions marks and use semicolons to separate entries. For example,
match-terms “protocol tcp; destination-port http”;. Dynamic profile
variables are not allowed in the string.
protocol number IP protocol field. Can be a single number, a single range, or one of
the standard protocol synonyms. IPv4 only.
source-address prefix IP source address field.
source-port number TCP or UDP source port field. Can be a single number, a single
range, or one of the standard protocol synonyms.

Documentation

Fast Update Filter Actions and Action Modifiers
Table 38: Fast Update Filter Actions and Action Modifiers

Action or Action Modifier Description
Actions
accept Accept the packet.
action-terms string-of-actions A series of multiple actions or action modifiers. Enclose the

string within quotation marks and use semicolons to separate
entries. For example, action-terms “log; count http-cnt”;.
Dynamic profile variables are not allowed in the string.
discard Drop the packet silently, without sending an Internet Control

Message Protocol (ICMP) message.
ignore-term Do not add this term to the filter. All match conditions and
actions are ignored.
port-mirror Port mirror packets.
routing-instance routing-instance Forward packets to specified routing instance.
Action Modifiers
count counter-name Increment the specified counter.
forwarding-class class Classify the packet into one of the following forwarding
classes: as, assured-forwarding, best-effort,
expedited-forwarding, or network-control.
log Log the packet header information.
loss-priority (high | medium-high | Set the loss priority level for packets.
medium-low| low)
policer policer-name Rate-limit packets based on the specified policer.

Documentation
Configuring Terms for Fast Update Filters
A fast update filter consists of one or more terms. A term is made up of one or more
match conditions and the action to take when a packet matches the specified conditions.
To configure a term for a fast update filter:
1. Access the fast update filter.

user@host# edit firewall family inet fast-update-filter httpFilter
2. Create the new term and assign a name to the term.

user@host# set term term1
3. Configure the match condition for the term. See “Fast Update Filter Match Conditions”
on page 292 for the supported match conditions for fast update filters.

user@host# set from source-address $junos-subscriber-ip-address
user@host# set from destination-port http
4. Configure the action that the router takes when the match conditions are met. See
“Fast Update Filter Actions and Action Modifiers” on page 293 for the supported actions
for fast update filters.

5. (Optional) Configure the action modifiers that you want the router to take when the
match conditions are met. See “Fast Update Filter Actions and Action Modifiers” on
page 293 for the supported action-modifiers for fast update filters.

user@host# set then count http-cnt
6. (Optional) Configure the term to be added only once, when the fast update filter is
first created.

user@host# set only-at-create

Documentation
• Stateless Firewall Filter Overview
• Stateless Firewall Filter Components
Configuring Filters to Permit Expected Traffic
You must explicitly configure your firewall filter to permit expected traffic, such as DHCP
traffic, to pass. Otherwise, the expected traffic is denied when the filter is applied to the
interface. This requirement applies to both classic and fast update filters.
The following example shows a fast update filter that might be used to accept DHCP
traffic. The actual filter you use depends on the expected traffic in your network.

In the example, the term allow-dhcp accepts all DHCP traffic from all source addresses.
The term also includes the only-at-create option to specify that the term is applied only
when the filter is first applied. The term sub-allow-dhcp includes the Junos OS predefined
variable $junos-subscriber-ip-address, which permits all subscriber-specific DHCP traffic.
The match-order statement configuration lists the conditions from most-specific to

least-specific, as recommended in “Configuring the Match Order for Fast Update Filters”
on page 291. Because this filter is designed to permit ingress DHCP traffic, the
source-address condition is listed first.
firewall {
family inet {
fast-update-filter psf1 {
interface-specific;
match-order [ source-address destination-address protocol destination-port ];
term allow-dhcp {
only-at-create;
from {
source-address 0.0.0.0/32;
protocol udp;
}
then accept;
}
term sub-allow-dhcp {
from {
protocol udp;
}
then accept;
}
}
}
}
Related • Configuring the Match Order for Fast Update Filters on page 291
Documentation
Avoiding Conflicts When Terms Match
A fast update filter can contain multiple terms, each with a variety of match conditions.
However, when you configure multiple terms in a filter, you must ensure that the terms
do not overlap, or conflict with each other. Two terms are considered to overlap when it
is possible for a packet to match all conditions of both terms. Because each term specifies
a different action for matches, the router cannot determine which action to take. When
terms overlap, a conflict error occurs and the session fails when the dynamic profile
attempts to apply the filter. The error log indicates the overlapping terms.

How the Router Evaluates Terms in a Filter

The router creates a table of match conditions when examining terms. The table, which
is similar to a routing table, is based on the conditions included in the match-order
statement. When the router receives a packet, the router examines the packet’s contents
in the sequence specified in the match-order statement.
For example, using the sample configuration in the following Match-Order Example, the
router first examines the packet’s source-address, then the destination-address, and
finally the destination-port. As shown in the following table, the two terms in the filter do
not overlap because each term has a different destination-port specification. The router
then takes the appropriate filter action for the term that matches the destination-port
value of the packet.
Term source-address destination-address destination-port Action
t55 subscriber’s 3.1.1.2/32 http count t55_cntr

address
accept
t999 subscriber’s 3.1.1.2/32 https count t999_cntr

address
accept
Match-Order Example firewall {

family inet {
interface-specific;
match-order [ source-address destination-address destination-port ];
term t55 {
from {
}
then {
count t55_cntr;
accept;
}
}
term t999 {
from {
destination-port https;
}
then {
count t999_cntr;
accept;
}
}
}
}

Using Implied Wildcards

This section shows an example of how you might use an implied wildcard specification
in the match configuration. A condition in the match-order statement is an implied wildcard
when that condition is not configured in the from specification of a term in the filter.
NOTE: When you use ranges (for example, a range of values or a wildcard)
in terms, the ranges must not overlap—overlapping ranges create a conflict
error. However, you can configure a range in one term and an exact match in
another term. For example, in the following filter table, the wildcard
destination port value in term t3 does not overlap the destination port
specifications in terms t55 and t999 because the http and https values are
exact matches.
In the Implied Wildcard Example configuration, the router views the destination-port
condition in the match-order statement as an implied wildcard for term t3, because there
is no destination-port value configured in that term. As a result, the wildcard specifies
that for term t3 any destination-port value is accepted. The filter table appears as follows:
t3 subscriber’s 3.1.1.2/32 any (wildcard) count t3_cntr

address
accept
t55 subscriber’s 3.1.1.2/32 http count t55_cntr

address
accept
t999 subscriber’s 3.1.1.2/32 https count t999_cntr

address
accept
In the following filter configuration, traffic with a destination port of http matches term
t55 and traffic with a destination port of https matches term t999. Traffic with a
destination port other than http or https matches term t3, which is the implied wildcard.
Implied Wildcard firewall {

Example family inet {
interface-specific;
match-order [ source-address destination-address dscp protocol destination-port
];
term t3 {
from {
}
then {

count t3_cntr;
accept;
}
}
term t55 {
from {
}
then {
count t55_cntr;
accept;
}
}
term t999 {
from {
}
then {
count t999_cntr;
accept;
}
}
}
}
}
Conflict Caused by Overlapping Ranges

This section shows two examples of overlapping ranges in terms. When you use ranges
(such as a wildcard or a range of values) in terms, the ranges must not
overlap—overlapping ranges create a conflict error and the session fails.
In the following filter configuration, the destination-port ranges in the two terms overlap.
Ports in the range from 50 through 80 match both term src0 and term src1, which each
specify different actions to take.
NOTE: You can configure a range in one term and an exact match in another
term. See the section, Using Implied Wildcards, for an example that uses a
wildcard for a match condition in one term and an exact match for the
condition in a second term.
src0 subscriber’s 10.1.1.2/32 0–80 count c1_cntr

address
accept

src1 subscriber’s 10.1.1.2/32 50–100 count c2_cntr

address
accept
Overlapping Ranges firewall {

Example 1 family inet {
fast-update-filter fuf–src {
interface-specific;
match-order [ source-address destination-address destination-port ];
term src0 {
from {
destination-port 0–80;
}
then {
count c1_cntr;
accept;
}
}
term src1 {
from {
destination-port 50–100;
}
then {
count c2_cntr;
accept;
}
}
}
In this filter configuration, the protocol specification in terms src21 and src22 use the
implied wildcard, which configures a range for each term. Because overlapping ranges
are not allowed, a conflict error results.
Term source-address destination-address protocol destination-port Action
src20 subscriber’s 10.1.1.2/32 udp any count

address (wildcard) c20_cntr
accept
src21 subscriber’s 10.1.1.2/32 any http count

accept
src21 subscriber’s 10.1.1.2/32 any https count

accept

Overlapping Ranges firewall {

Example 2 family inet {
fast-update-filter fuf–src2 {
interface-specific;
match-order [ source-address destination-address protocol destination-port ];
term src20 {
from {
protocol udp;
}
then {
count c20_cntr;
accept;
}
}
term src21 {
from {
}
then {
count c21_cntr;
accept;
}
}
term src22 {
from {
}
then {
count c22_cntr;
accept;
}
}
}

Documentation
Associating Fast Update Filters with Interfaces in a Dynamic Profile
After you configure the fast update filter, you reference the filter in the interfaces stanza
of a dynamic profile. When the dynamic profile instantiates a subscriber session, the
router applies the terms of the filter to the interface.

To apply a fast update filter to an interface in a dynamic profile:
[edit]
2. Specify the interface for the dynamic profile—use the dynamic interface variable.

user@host# edit interfaces $junos-interface-ifd-name
3. Specify the underlying interface—use the unit number variable.
[edit dynamic-profiles myProfile interfaces “$junos-interface-ifd-name”]

user@host# edit unit $junos-underlying-interface-unit
4. Specify the family. Use inet if you are using IPv4 filters or inet6 for IPv6 filters.
[edit dynamic-profiles myProfile interfaces “$junos-interface-ifd-name” unit

“$junos-underlying-interface-unit”]
5. Specify the filters that you want to apply to the interface.

user@host# set filter input httpFilter
user@host# set filter output myOutFilter

Documentation


CHAPTER 24
Defending Against DoS and DDoS Attacks

Using Unicast RPF and Fail Filters
• Unicast RPF in Dynamic Profiles for Subscriber Interfaces on page 303

• Configuring Unicast RPF in Dynamic Profiles for Subscriber Interfaces on page 304
• Configuring Unicast RPF and Fail Filters in Dynamic Profiles for Subscriber
• Configuring a Fail Filter for Unicast RPF in Dynamic Profiles for Subscriber
• Example: Configuring Unicast RPF in a Dynamic Profile on MX Series Routers on page 305
Unicast RPF in Dynamic Profiles for Subscriber Interfaces
Unicast reverse-path forwarding (RPF) provides a way to reduce the effect of

denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks on IPv4 and
IPv6 interfaces. When you configure unicast RPF on an interface, it checks the packet
source address. Packets that pass the check are forwarded. Packets that fail the check
are dropped, or if a fail filter is configured, are passed to the filter for further evaluation.
Unicast RPF has two behavioral modes, strict and loose. When you configure unicast
RPF in a dynamic profile, strict mode is the default. In strict mode, unicast RPF checks
whether the source address of the incoming packet matches a prefix in the routing table,
and whether the interface expects to receive a packet with this source address prefix. In
loose mode, unicast RPF checks only whether the source address has a match in the
routing table. It does not check whether the interface expects to receive a packet from
a specific source address.
For both modes, when an incoming packet fails the unicast RPF check, the packet is not
accepted on the interface. Instead, unicast RPF counts the packet and sends it to an
optional fail filter, if present. The fail filter determines what further action is taken on the
packet. In the absence of a fail filter, the packet is silently discarded.
Related • Configuring Unicast RPF and Fail Filters in Dynamic Profiles for Subscriber Interfaces
• For more detailed information about unicast RPF in general, see Configuring Unicast
RPF

Configuring Unicast RPF in Dynamic Profiles for Subscriber Interfaces
This topic describes how to configure unicast RPF for subscriber interfaces in dynamic
profiles on MX Series routers.
To configure a unicast RPF with a fail filter in a dynamic profile:
1. Access the dynamic profile.
[edit]
user@host# edit dynamic-profiles profile-name
2. Access the interface and specify the address family

user@host# edit interfaces interface-name unit logical-unit-number family inet
3. Enable the RPF check and specify the fail filter.
[edit dynamic-profiles profile-name interface interface-name unit logical-unit-number

family inet]
user@host# set rpf-check fail-filter filter-name
Configuring Unicast RPF and Fail Filters in Dynamic Profiles for Subscriber Interfaces
This topic provides a summary of unicast RPF configuration for subscriber interfaces in
dynamic profiles on MX Series routers. Unicast RPF provides a way to reduce the effect
of denial-of-service attacks on IPv4 and IPv6 interfaces by checking the source IP address
against the routing table. Packets that do not match are silently discarded, unless an
optional fail filter is configured. The fail filter performs an additional check and directs
some action be taken on certain packets. Typical actions include logging the packets or
passing them even though they failed the RPF check.
NOTE: Although the fail filter is technically optional, for dynamic profiles in
a DHCP environment you must configure a filter to pass DHCP packets. By
default, the RPF check prevents DHCP packets from being accepted on
interfaces protected by the RPF check. The fail filter identifies the DHCP
packets and passes them on.
To configure unicast RPF in dynamic profiles:
1. Enable unicast RPF on one or more interfaces in a dynamic profile.
See “Configuring Unicast RPF in Dynamic Profiles for Subscriber Interfaces” on page 304.
2. (Optional) Create a fail filter to evaluate failed packets and perform further actions.

Chapter 24: Defending Against DoS and DDoS Attacks Using Unicast RPF and Fail Filters
See “Configuring a Fail Filter for Unicast RPF in Dynamic Profiles for Subscriber
Related • Unicast RPF in Dynamic Profiles for Subscriber Interfaces on page 303
Documentation
Configuring a Fail Filter for Unicast RPF in Dynamic Profiles for Subscriber Interfaces
This topic describes how to configure a fail filter at the [edit firewall] hierarchy level that
can be optionally applied by unicast RPF for subscriber interfaces in dynamic profiles on
MX Series routers.
NOTE: In contrast to statically configured fail filters, RPF-check fail filters

used in a dynamic profile cannot be specific to a particular interface.
To configure a firewall fail filter:
1. Create the filter.
[edit]
user@host# edit firewall family inet filter filter-name
2. Specify a term for the filter.
[edit firewall family inet filter filter-name]

user@host# edit term term-name
3. Configure the match conditions for the filter.
[edit firewall family inet filter filter-name term term-name]

user@host# set from match-conditions
4. Configure the actions to be taken for the matching packets.
[edit firewall family inet filter filter-name term term-name]

user@host# set then actions
5. (Optional) Repeat Steps 3 and 4 for additional filter terms.
Example: Configuring Unicast RPF in a Dynamic Profile on MX Series Routers
This example shows how to help defend the router ingress interfaces against
denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks by configuring
unicast reverse-path forwarding (RPF) on a customer-edge interface to filter incoming
traffic. Unicast RPF verifies the unicast source address of each packet that arrives on an

ingress interface where unicast RPF is enabled. Packets that fail verification are silently
discarded unless a fail filter performs some other action on them.

Requirements
This example uses the following software and hardware components:
• An MX Series 3D Universal Edge router
Before you begin:
• Configure the dynamic profile that you intend to use to apply the RPF check.
Overview
Large amounts of unauthorized traffic—such as attempts to flood a network with fake
service requests in a denial-of-service (DoS) attack—can consume network resources
and deny service to legitimate users. One way to help prevent DoS and distributed
denial-of-service (DDoS) attacks is to verify that incoming traffic originates from
legitimate network sources.
Unicast RPF helps ensure that a traffic source is legitimate (authorized) by comparing
the source address of each packet that arrives on an interface to the forwarding-table
entry for its source address. If the router uses the same interface that the packet arrived
on to reply to the packet's source, this verifies that the packet originated from an
authorized source, and the router forwards the packet. If the router does not use the
same interface that the packet arrived on to reply to the packet's source, the packet
might have originated from an unauthorized source, and the router discards the packet,
or passes it to a fail filter.
The fail filter enables you to set criteria for packets you want to be passed in spite of
failing the RPF check, such as DHCP packets, which are dropped by default.
On MX Series routers, you can configure unicast RPF in a dynamic profile to apply the
configuration to one or more subscriber interfaces. See Configuring Unicast RPF for more
information about the behavior and limitations of unicast RPF on MX Series routers.
In this example, you configure the router to protect against potential DoS and DDoS
attacks from the Internet perpetrated through IPv4 packets arriving on dynamically
created VLAN demux interfaces. The dynamic profile, vlan-demux-prof, establishes that
VLAN demux interfaces are automatically created for subscribers. Unicast RPF is enabled
on the dynamic interfaces by the rpf-check term.
By default, unicast RPF prevents Dynamic Host Configuration Protocol (DHCP) packets
from being accepted on interfaces to which it applies. When DHCP packets are discarded,

no new subscribers can be created by the dynamic profile. To enable interfaces to accept
DHCP packets, you must apply a fail filter that properly sorts through the packets that
fail the check and identifies the DHCP packets. In this example, you configure the
allow-dhcp term in the filter rpf-pass-dhcp. This term matches, counts, and accepts IPv4
packets that are destined for the DHCP port and any address. The default term drops all
other packets that fail the RPF check.
This example does not show all possible configuration choices.
Configuration
To enable unicast RPF with a fail filter in a dynamic profile, perform these tasks:
• Configuring the Dynamic Profile to Apply RPF Checking to Dynamic VLAN Demux
• Configuring the RPF-Check Fail Filter on page 308
Configuring the Dynamic Profile to Apply RPF Checking to Dynamic VLAN Demux
Interfaces
CLI Quick To quickly configure the dynamic profile to apply unicast RPF to dynamically created
Configuration VLAN demux interfaces, copy the following commands, paste them in a text file, remove
any line breaks, and then copy and paste the commands into the CLI.
edit dynamic-profiles vlan-demux-prof interfaces demux0

edit unit $junos-interface-unit
set demux-options underlying-interface $junos-interface-ifd-name
set vlan-id $junos-vlan-id
edit family inet
set unnumbered-address lo0.0
set rpf-check fail-filter rpf-pass-dhcp
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode.
To configure unicast RPF on the router:
1. Create a dynamic profile.
[edit]
user@host# edit dynamic-profiles vlan-demux-prof
2. Specify that the dynamic VLAN profile use the demux interface.
[edit dynamic-profiles vlan-demux-prof]

user@host# edit interfaces demux0
3. Specify that the dynamic profile applies the demux interface unit value to the
dynamic VLANs.
[edit dynamic-profiles vlan-demux-prof interfaces demux0]

user@host# edit unit $junos-interface-unit
4. Specify the logical underlying interface for the dynamic VLANs.
[edit dynamic-profiles vlan-demux-prof interfaces demux0 unit $junos-interface-unit]

user@host# set demux-options underlying-interface $junos-interface-ifd-name
5. Configure the variable that results in dynamically created VLAN IDs.

user@host# set vlan-id $junos-vlan-id
6. Configure the IPv4 address family for the demux interfaces.

7. Configure the unnumbered address for the family.
[edit dynamic-profiles vlan-demux-prof interfaces demux0 unit $junos-interface-unit

family inet]
user@host# set unnumbered-address lo0.0
8. Configure unicast RPF and specify the fail filter that is applied to incoming packets
that fail the check.
[edit dynamic-profiles vlan-demux-prof interfaces demux0 unit $junos-interface-unit

family inet]
user@host# set fail-filter fail-filter rpf-pass-dhcp
Configuring the RPF-Check Fail Filter
CLI Quick To quickly configure the unicast RPF-check fail filter, copy the following commands,
Configuration paste them in a text file, remove any line breaks, and then copy and paste the commands
into the CLI.
edit firewall family inet filter rpf-pass-dhcp

edit term allow-dhcp
set from destination-port dhcp
set from destination-address 255.255.255.255/32
set then count rpf-dhcp-traffic
set then accept
up
edit term default
set then discard
Mode.
To configure the RPF-check fail filter:
1. Create the fail filter.
[edit firewall]
user@host# edit family inet filter rpf-pass-dhcp
2. Define the filter term that identifies DHCP packets based on the DHCP destination
port, then counts and passes the packets.
[edit firewall family inet filter rpf-pass-dhcp]

user@host# edit term allow-dhcp
user@host# set from destination-port dhcp
user@host# set from destination-address 255.255.255.255/32

user@host# set then count rpf-dhcp-traffic

3. Define the filter term that drops all other failed packets.
[edit firewall filter rpf-pass-dhcp]

user@host# edit term default
user@host# set then discard
Results From configuration mode, confirm the unicast RPF configuration by entering the show
[edit]
vlan-demux-prof {
interfaces {
demux0 {
demux-options {
underlying-interface "$junos-interface-ifd-name";
}
family inet {
unnumbered-address lo0.0;
rpf-check {
fail-filter rpf-pass-dhcp;
}
}
}
}
}
}
From configuration mode, confirm the fail filter configuration by entering the show firewall
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.
[edit]
user@host# show firewall
family inet {
filter rpf-pass-dhcp {
term allow-dhcp {
from {
255.255.255.255/32;
}
destination-port dhcp;
}
then {
count rpf-dhcp-traffic;
accept;
}
}
term default {
then {

discard;
}
}
}
}
Verification
• Verifying That Unicast RPF Is Enabled on the Router on page 310
Verifying That Unicast RPF Is Enabled on the Router
Purpose Verify that unicast RPF is enabled.
Action Verify that unicast RPF is enabled by using the show subscribers extensive command.

Type: VLAN
Interface: ae0.1073741824
Dynamic Profile Name: vlan-demux-prof
State: Active
Session ID: 9
VLAN Id: 100
Login Time: 2011-08-26 08:17:00 PDT
IPv4 rpf-check Fail Filter Name: rpf-pass-dhcp
Meaning The IPv4 rpf-check Fail Filter Name field displays rpf-pass-dhcp, the name of the fail filter
applied by the dynamic profile for IPv4 packets failing the RPF check.
Related • Unicast RPF in Dynamic Profiles for Subscriber Interfaces on page 303
Documentation
• Configuring Unicast RPF and Fail Filters in Dynamic Profiles for Subscriber Interfaces
on page 304

CHAPTER 25
Improving Scaling and Performance of

Filters on Static Subscriber Interfaces
• Firewall Filters and Enhanced Network Services Mode Overview on page 311
• Configuring a Filter for Use with Enhanced Network Services Mode on page 313
Firewall Filters and Enhanced Network Services Mode Overview
Under normal conditions, every firewall filter is generated in two different formats --
compiled and term-based. The compiled format is used by the routing engine (RE) kernel,
FPCs, and MS-DPs. The term-based format is used by MPCs. Compiled firewall filters
are duplicated for each interface or logical interface to which they are applied. Term-based
filters, instead of being duplicated, are referenced by each interface or logical interface.
When a combination of MPCs and any other cards populate a chassis, the creation of
both firewall filter file formats is necessary. In most networks, the creation of both filter
formats and any amount of duplication for compiled firewall filters has no effect on the
router. However, in subscriber management networks that include thousands of statically
configured subscriber interfaces, creating filters in multiple formats and duplicating those
filters for each interface can utilize a large portion of router memory resources. You can
use either Enhanced IP Network Services mode or Enhanced Ethernet Network Services
mode to improve the scaling and performance specific to routing filters in a subscriber
access network that uses statically configured subscriber interfaces.
In configurations where interfaces are created either statically or dynamically and firewall
filters are applied dynamically, you must configure the chassis network services to run
in enhanced mode. In configurations where interfaces are created statically and firewall
filters are applied statically, you must configure chassis network services to run in
enhanced mode and also configure each firewall filter for enhanced mode.
NOTE: Do not use enhanced mode for firewall filters that are intended for
control plane traffic. Control plane filtering is handled by the Routing Engine
kernel, which cannot use the term-based format of the enhanced mode filters.
Table 39 on page 312 shows the configuration options when determining enhanced
network services mode usage.

Table 39: Enhanced Network Services Mode and Firewall Filter Use Case Determination
Chassis Enhanced Mode Firewall Filter Enhanced
Interface and Filter Configuration Required Mode Required
Dynamically-created interfaces and dynamically-applied filters Yes No
Statically-created interfaces and dynamically-applied filters Yes No
Statically-created interfaces and statically-applied filters Yes Yes
To achieve significant resource savings for the router, combine chassis and filter enhanced
mode configuration as follows:
• Install only MPCs in the chassis.
NOTE: Configuring chassis network services to run one of the enhanced

network services modes results in the router enabling only MPCs and
MS-DPCs. Because MS-DPCs use compiled firewall filter format, a router
chassis that is configured for one of the enhanced network services modes,
configuring standard (non-enhanced) firewall filters for use with any
MS-DPCs can decrease optimal resource efficiency.
• When configuring static interfaces on the router, configure chassis network services
to run either Enhanced IP Network Services mode or Enhanced Ethernet Network
Services mode.
• When statically applying firewall filters to statically-created interfaces, configure any

firewall filters for enhanced mode to limit the filter creation to only term-based format.

Chapter 25: Improving Scaling and Performance of Filters on Static Subscriber Interfaces
NOTE: Any firewall filters that are not configured for enhanced mode are
created in both compiled and term-based format, even if the chassis is
running one of the enhanced network services modes. Only term-based
(enhanced) firewall filters will be generated, regardless of the setting of
the enhanced-mode statement at the [edit chassis network-services]
hierarchy level, if any of the following are true:
• Flexible filter match conditions are configured at the [edit firewall family
family-name filter filter-name term term-name from] or [edit firewall filter
filter-name term term-name from] hierarchy levels.
• A tunnel header push or pop action, such as GRE encapsulate or

decapsulate is configured at the [edit firewall family family-name filter
filter-name term term-name then] hierarchy level.
• Payload-protocol match conditions are configured at the [edit firewall

family family-name filter filter-name term term-name from] or [edit firewall
filter filter-name term term-name from] hierarchy levels.
• An extension-header match is configured at the [edit firewall family

family-name filter filter-name term term-name from] or [edit firewall filter
filter-name term term-name from] hierarchy levels.
• A match condition is configured that only works with MPC cards, such
as firewall bridge filters for IPv6 traffic.
WARNING: Any firewall filter meeting the previous criteria will not be
applied to the loopback, lo0, interface of DPC based FPCs. This means
that term-based (enhanced) filters configured for use on the loopback
interface of a DPC based FPC will not be applied. This will leave the RE
unprotected by that filter.
Related • Network Services Mode Overview

Documentation
• Configuring Junos OS to Run a Specific Network Services Mode in MX Series Routers
Configuring a Filter for Use with Enhanced Network Services Mode
For a statically-applied enhanced mode filter to function on statically created interfaces,

you must include the enhanced mode statement in each filter. However, you do not need
to configure the enhanced mode statement in filters that are dynamically applied to either
static or dynamically-created interfaces.

NOTE: For either static or dynamic interfaces to use enhanced network

services mode, you must configure the router chassis network services to use
either Enhanced IP Network Services mode or Enhanced Ethernet Network
Services mode. By configuring chassis network services to run in one of the
enhanced modes, the router enables only MPCs and MS-DPCs in the chassis.
See “Firewall Filters and Enhanced Network Services Mode Overview” on
page 311 for details.
To configure a stateless firewall filter to use enhanced mode:
1. Create or edit the stateless firewall filter.
NOTE: You can configure enhanced mode firewall filters for only inet and
inet6 filter families.
For IPv4:
[edit]
user@host# edit firewall family inet filter filter-name
For IPv6:
[edit]
user@host# edit firewall family inet6 filter filter-name
2. Specify the filter as an enhanced mode filter.
[edit firewall family inet filter filter-name]

user@host# set enhanced-mode
3. Configure or modify any filter terms.
See Example: Configuring and Applying a Simple Filter for a filter configuration example.
Related • Understanding How to Use Firewall Filters

Documentation
• Network Services Mode Overview
• Configuring Junos OS to Run a Specific Network Services Mode in MX Series Routers

CHAPTER 26
Configuring Dynamic Service Sets
• Dynamic Service Sets Overview on page 315

• Associating Service Sets with Interfaces in a Dynamic Profile on page 315
• Verifying and Managing Service Sets Information on page 316
Dynamic Service Sets Overview
A service set is a collection of services to be performed by an Adaptive Services (AS) or

Multiservices PIC. You configure a service-set definition at the [edit services] hierarchy
level. You can then apply the service set to one or more interfaces on the router. The
service set can be applied either dynamically or statically.
To dynamically associate a service set to interfaces you include the service-set statement
with the input or output statement at the [edit dynamic-profiles profile-name interfaces
interface-name unit logical-unit-number family family service] hierarchy level.
To statically associate a defined service set with an interface, you include the service-set
statement with the input or output statement at the [edit interfaces interface-name unit
logical-unit-number family family service] hierarchy level.
Related • Associating Service Sets with Interfaces in a Dynamic Profile on page 315
Documentation
• Understanding Service Sets
• Applying Filters and Services to Interfaces
Associating Service Sets with Interfaces in a Dynamic Profile
After you configure a service set, you use a dynamic profile to dynamically associate the
service set with interfaces. You reference the filter in the interfaces stanza of a dynamic
profile. When the dynamic profile instantiates a subscriber session, the router applies
the terms of the filter to the interface.
To apply a service set to an interface in a dynamic profile:
[edit]

2. Specify the interface for the dynamic profile—use the dynamic interface variable.

user@host# edit interfaces $junos-interface-ifd-name
3. Specify the underlying interface—use the unit number variable.
[edit dynamic-profiles myProfile interfaces “$junos-interface-ifd-name”]

user@host# edit unit $junos-underlying-interface-unit
4. Specify the family. Dynamic service sets are supported only on family inet (IPv4).

“$junos-underlying-interface-unit”]
5. Specify the input and output service sets that you want to apply to the interface.

user@host# set service input service-set inputService_200
user@host# set service input post-service-filter postService_15
user@host# set service output service-set outputService_320
Related • Dynamic Service Sets Overview on page 315

Documentation
• Configuring Service Sets to be Applied to Services Interfaces
• Applying Filters and Services to Interfaces
Verifying and Managing Service Sets Information

Purpose View information for service sets:
Action • To display summary information for service sets:
user@host> show services service-sets summary
• To display interface-specific information for service sets:
user@host>show services service-sets summary interface interface-name

Documentation
• CLI Explorer

CHAPTER 27
Configuring Rate-Limiting Premium and

Non-Premium Traffic on an Interface
Using Hierarchical Policers
• Methods for Regulating Traffic by Applying Hierarchical Policers on page 317

• Hierarchical Policer Applied as Filter Action on page 320
• Example: Configuring Hierarchical Policers to Limit Rates of Services in a Static
Environment on page 321
Methods for Regulating Traffic by Applying Hierarchical Policers
You can deploy policers to enforce service level agreements limiting the input rate at the
edge, and at the boundary between domains, to guarantee an equitable deployment of
the service among the different domains. Policers determine whether each packet
conforms (falls within the traffic contract), exceeds (using up the excess burst capacity),
or violates (totally out of the traffic contract rate) the configured traffic policies, and
then sets the prescribed action.
Hierarchical policers rate-limit premium traffic separately from the aggregate traffic on
an interface as determined by different configured rates. You can use a hierarchical policer
to rate-limit ingress Layer 2 traffic at a physical or logical interface and apply different
policing actions based on whether the traffic or packets are classified for expedited
forwarding (EF) or for a lower priority, such as non-expedited forwarding (non-EF).
Hierarchical policers provide cross-functionality between the configured physical interface

and the Packet Forwarding Engine. You can apply a hierarchical policer for premium and
aggregate (premium plus normal) traffic levels to a logical interface.

Hierarchical policing uses two token buckets, one for premium (EF) traffic and one for
aggregate (non-EF) traffic, as shown in Figure 24 on page 318.
Figure 24: Hierarchical Policer

EF Traffic
Premium Policer
g017301
non-EF Traffic
Aggregate Policer
The class-of-service (CoS) configuration determines which traffic is EF and which is

non-EF. Logically, hierarchical policing is achieved by chaining two policers.
• Premium policer—You configure the premium policer with traffic limits for high-priority
EF traffic only: a guaranteed bandwidth and a corresponding burst-size limit. EF traffic
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 configurable action for nonconforming traffic is to discard
the packets.
• Aggregate policer—You configure the aggregate policer (also known as a logical

interface policer) with an aggregate bandwidth (to accommodate both high-priority
EF traffic up to the guaranteed bandwidth and normal-priority non-EF traffic) and a
burst-size limit for non-EF traffic only. Non-EF traffic is categorized as nonconforming
when its average arrival rate exceeds the amount of aggregate bandwidth not currently
consumed by EF traffic and its average packet size exceeds the burst-size limit defined
in the aggregate policer. For an aggregate policer, the configurable actions for
nonconforming traffic are to discard the packets, assign a forwarding class, or assign
a packet loss priority (PLP) level.
NOTE: You must configure 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 only non-EF traffic passes through the interface
unrestricted; no EF traffic arrives at the interface.
Ingress traffic is first classified into EF and non-EF traffic prior to applying a policer. EF
traffic is guaranteed the bandwidth specified as the premium bandwidth limit, while
non-EF traffic is rate-limited to the amount of aggregate bandwidth not currently
consumed by the EF traffic. Non-EF traffic is rate-limited to the entire aggregate
bandwidth only while no EF traffic is present.
Hierarchical policing uses two token buckets, one for aggregate (non-EF) traffic and one
for premium (EF) traffic. In Figure 24 on page 318, the premium policer policies EF traffic
and the aggregate policer polices non-EF traffic. In the sample configuration that follows,
the hierarchical policer is configured with the following components:
• Premium policer has a bandwidth limit set to 2 Mbps, burst-size limit set to 50 KB, and
nonconforming action set to discard packets.

Chapter 27: Configuring Rate-Limiting Premium and Non-Premium Traffic on an Interface Using Hierarchical Policers
• Aggregate policer has a bandwidth limit set to 10 Mbps, burst-size limit set to 100 KB,
and nonconforming action set to mark high PLP.
[edit]
user@host# show dynamic-profiles firewall
hierarchical-policer policer-agg-prem {
aggregate {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 100k;
}
then {
loss-priority high;
}
}
premium {
if-exceeding {
bandwidth-limit 2m;
}
then {
discard;
}
}
}
EF traffic is guaranteed a bandwidth of 2 Mbps. Bursts of EF traffic—EF traffic that arrives

at the interface at rates above 2 Mbps—can also pass through the interface, provided
that sufficient tokens are available in the 50 KB burst bucket. When no tokens are
available, EF traffic is rate-limited using the discarded action associated with the premium
policer.
Non-EF traffic is metered to a bandwidth limit that ranges between 8 Mbps and 10 Mbps,
depending on the average arrival rate of the EF traffic. Bursts of non-EF traffic—non-EF
traffic that arrives at the interface at rates above the current limit for non-EF traffic—also
pass through the interface, provided that sufficient tokens are available in the 100 KB
bandwidth bucket. Aggregate traffic in excess of the currently configured bandwidth or
burst size are rate-limited using the action specified for the aggregate policer, which in
this example is set to a high PLP.
The premium traffic is policed by both the premium policer and aggregate policer.
Although the premium policer rate-limits the premium traffic, the aggregate policer
decrements the credits but does not drop the packets. The aggregate policer rate-limits
the non-premium traffic. Therefore, the premium traffic is assured to have the bandwidth
configured for premium, and the non-premium traffic is policed to the remaining
bandwidth.
Related • Example: Configuring Hierarchical Policers to Limit Rates of Services in a Static

Documentation Environment on page 321

Hierarchical Policer Applied as Filter Action
After you define firewall filters and policers, you must apply them to take effect.
• You can apply the same firewall filter to multiple interfaces at the same time. By default
on MX Series routers, these filters aggregate their counters and policing actions when
those interfaces share a Packet Forwarding Engine. To override this behavior and make
each counter or policer function specific to each interface application, include the
interface-specific statement in the firewall filter.
[edit dynamic-profiles profile-name firewall family family filter filter-name

Interface-specific filters are particularly useful for IPTV services where television services
are delivered using the IP suite over a packet-switched network instead of being
delivered through traditional satellite signal and cable television formats.
NOTE: When you define an interface-specific filter, you must limit the filter
name to no more than 52 bytes. Firewall filter names are restricted to 64
bytes in length and interface-specific filters have the specific-name
appended to them to differentiate their counters and policing actions. If
the automatically generated filter instance name exceeds this maximum
length, the system may reject the filter’s instance name.
• Alternatively, you can apply a policer to a logical interface either directly or indirectly
through a filter that references the policer function. By default, policers are term-specific.
Junos OS creates a separate policer instance when the same policer is referenced in
multiple terms of a firewall filter.
Hierarchical policers provide cross-functionality between the configured physical interface

and the Packet Forwarding Engine for provider edge applications. You can apply a
hierarchical policer as a filter action for premium and aggregate (premium plus normal)
traffic levels to a logical interface. Additionally, an interface-specific filter can have a
hierarchical policer as a filter action whether or not the hierachical policer is a logical
interface policer.
A logical interface policer (also known as an aggregate policer) can police the traffic
from multiple protocol families without requiring a separate instantiation of a policer for
each such family on the logical interface. You define a logical interface policer by including
the logical-interface-policer statement when defining the policer.
[edit dynamic-profiles profile-name firewall policer policer-name

user@host# set logical-interface-policer
To apply a logical interface policer on an MX Series router as an action in a firewall filter

term, you must specify both the interface-specific statement in the firewall filter and the
logical-interface-policer statement in the related policer. Using a filter to evoke a logical
interface filter has the added benefits of increased match flexibility as well as support
for two-color policer styles (a policer that classifies traffic into two groups using only the

bandwidth-limit and burst-size-limit parameters), which can only be attached at the

family level through a filter action.
NOTE: A non-interface-specific filter can only have a hierarchical policer if

no logical interface-specific filter action is specified.
Related • Methods for Regulating Traffic by Applying Hierarchical Policers on page 317
Documentation
• Example: Configuring Hierarchical Policers to Limit Rates of Services in a Static
Environment on page 321
Example: Configuring Hierarchical Policers to Limit Rates of Services in a Static

Environment
This example shows how to configure a hierarchical policer and apply the policer to
ingress Layer 2 traffic at a logical interface on an MX Series router.

Requirements
Before you begin, be sure that your environment meets the following requirements:
• The interface on which you apply the hierarchical policer is an interface hosted on an
MX Series router.
• 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 filter is also applied, the policer is executed first.
Overview
In this example, you configure a hierarchical policer and apply the policer to ingress Layer 2
traffic at a logical interface. Table 40 on page 322 describes the hierarchy levels at which
you can configure and apply hierarchical policers on logical and physical interfaces.

Table 40: Hierarchical Policer Configuration and Application Summary

Policer Configuration Layer 2 Application Key Points
Hierarchical Policer
Hierarchically rate-limits Layer 2 ingress traffic for all protocol families. Cannot be applied to egress traffic, Layer 3 traffic, or at
a specific protocol level of the interface hierarchy. Supported on interfaces on Dense Port Concentrators (DPCs) in MX Series
routers.
Aggregate and premium policing Option A (physical interface)—Apply directly to Hierarchically rate-limit Layer 2
components of a hierarchical policer: Layer 2 input traffic on a physical interface: ingress traffic for all protocol
families and logical interfaces
[edit dynamic-profiles profile-name [edit dynamic-profiles profile-name interfaces] configured on a physical
firewall] interface-name { interface.
hierarchical-policer policer-name { layer2-policer {
aggregate { input-hierarchical-policer policer-name; Include the layer2-policer
if-exceeding { } configuration statement at the
bandwidth-limit bps; } [edit dynamic-profiles
burst-size-limit bytes; profile-name interfaces
} interface-name] hierarchy level.
then {
discard; NOTE: If you apply a
forwarding-class class-name; hierarchical policer at a physical
loss-priority supported-value; interface, you cannot also apply
} a hierarchical policer to any of
} the member logical interfaces.
premium {
if-exceeding { Option B (logical interface)—Apply directly to Hierarchically rate-limit Layer 2
bandwidth-limit bps; Layer 2 input traffic on a logical interface: ingress traffic for all protocol
burst-size-limit bytes; families configured on a specific
} [edit dynamic-profiles profile-name interfaces] logical interface.
then { interface-name {
discard; unit unit-number { Include the layer2-policer
} layer2-policer { configuration statement at the
} input-hierarchical-policer policer-name; [edit dynamic-profiles
} } profile-name interfaces
} interface-name unit unit-number]
} hierarchy level.
NOTE: You must configure at

least one protocol family for the
logical interface.
You apply the policer to the Gigabit Ethernet logical interface ge-1/2/0.0, which you
configure for IPv4 traffic. When you apply the hierarchical policer to the logical interface,
IPv4 traffic is hierarchically rate-limited. If you choose to apply the hierarchical policer
to physical interface ge-1/2/0, hierarchical policing applies to IPv4 traffic across the
logical interface as well.
Configuration
The following example requires you to navigate various levels in the configuration
hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
Mode.

To configure this example, perform the following tasks:
• Configuring a Basic Dynamic Profile for Subscriber Management on page 324

• Configuring the Interfaces on page 325
• Configuring the Firewall Filter on page 325
• Configuring the Forwarding Classes on page 327
• Configuring the Hierarchical Policer on page 328
• Applying the Hierarchical Policer to Layer 2 Ingress Traffic at a Physical or Logical
CLI Quick To quickly configure this example, copy the following configuration commands into a
Configuration text file, remove any line breaks, and then paste the commands into the CLI at the [edit]
hierarchy level.
set dynamic-profiles basic-profile

set dynamic-profiles basic-profile interfaces “$junos-interface-ifd-name”
set dynamic-profiles basic-profile interfaces "$junos-interface-ifd-name" unit
“$junos-underlying-interface-unit”
set dynamic-profiles basic-profile interfaces "$junos-interface-ifd-name" unit
$junos-underlying-interface-unit family inet
set dynamic-profiles interfaces ge-1/2/0 unit 0 family inet address 10.8.0.0/31
set dynamic-profiles basic-profile firewall family inet filter hierarch-filter
set dynamic-profiles basic-profile firewall family inet filter hierarch-filter interface-specific
set dynamic-profiles basic-profile firewall family inet filter hierarch-filter term match-ip1
from precedence critical-ecp protocol
from protocol tcp
then hierarchical-policer hp1-share filter-specific
from precedence internet-control
from protocol tcp
then hierarchical-policer hp2-share
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
normal
normal
set dynamic-profiles basic-profile firewall hierarchical-policer policer-agg-prem aggregate
if-exceeding bandwidth-limit 10m burst-size-limit 100k
set dynamic-profiles basic-profile firewall hierarchical-policer policer-agg-prem aggregate
then forwarding-class fc1
set dynamic-profiles basic-profile firewall hierarchical-policer policer-agg-prem premium
if-exceeding bandwidth-limit 2m burst-size-limit 50k
set dynamic-profiles basic-profile firewall hierarchical-policer policer-agg-prem premium
then discard

set dynamic-profiles basic-profile interfaces ge-1/2/0 unit 0 layer2-policer

input-hierarchical-policer policer-agg-prem
Configuring a Basic Dynamic Profile for Subscriber Management
Step-by-Step A dynamic profile is a set of characteristics, defined in a type of template, that you can
Procedure use to provide dynamic subscriber access and services for broadband applications. These
services are assigned dynamically to interfaces. A basic profile must contain a profile
name and have both an interface variable name (such as $junos-interface-ifd-name)
included at the [edit dynamic-profiles profile-name interfaces hierarchy level and logical
interface variable name (such as $junos-underlying-interface-unit or
$junos-interface-unit) at the [edit dynamic-profiles profile-name interfaces
variable-interface-name unit] hierarchy level.
1. Create the new dynamic profile.
[edit]
user@host# set dynamic-profiles basic-profile
2. Define the interface-name variable statement with the internal

$junos-interface-ifd-name variable used by the router to match the interface name
of the receiving interface.
[edit dynamic-profiles basic-profile]

user@host# set interfaces “$junos-interface-ifd-name”
3. Define the variable-interface-name unit statement with the internal variable.
• When referencing an existing interface, specify the

$junos-underlying-interface-unit variable used by the router to match the unit
value of the receiving interface.
• When creating dynamic interfaces, specify the $junos-interface-unit variable

used by the router to generate a unit value for the interface.
[edit dynamic-profiles basic-profile interfaces "$junos-interface-ifd-name"]

user@host# set unit $junos-underlying-interface-unit
or
[edit dynamic-profiles basic-profile interfaces "$junos-interface-ifd-name"]

user@host# set unit $junos-interface-unit
4. Define the family address type (inet for IPv4) for the $junos-interface-unit variable.
[edit dynamic-profiles basic-profile interfaces "$junos-interface-ifd-name" unit

Results Confirm the configuration of the dynamic profile by entering the show dynamic-profiles
[edit]
dynamic-profiles {
basic-profile {

interfaces {
family inet;
}
}
}
}
}
Configuring the Interfaces
Step-by-Step Define the physical and logical interfaces for this hierarchical policer example.
Procedure
1. Configure the physical interface.

user@host# set interfaces ge-1/2/0
2. Configure the logical interface as unit 0 with its IPv4 (inet) protocol family interface.
[edit dynamic-profiles basic-profile interfaces ge-1/2/0]

user@host# set unit 0 family inet address 10.8.0.0/31
NOTE: If you apply a Layer 2 policer to this logical interface, you must
configure at least one protocol family.
Results Confirm the configuration by entering the show dynamic-profiles basic-profile interfaces
[edit]
user@host# show dynamic-profiles basic-profile interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 10.8.0.0/31;
}
}
}
Configuring the Firewall Filter
Step-by-Step To configure a hierarchical policer as a filter action, you must first configure a firewall
Procedure filter.
1. Configure the family address type (inet for IPv4) for the firewall filter and specify
the filter name.
We recommend that you name the filter something that indicates the filter’s purpose.


user@host# set firewall family inet filter hierarch-filter
2. To override the aggregation of the counters and policing actions and make each
counter or policy function specific to each interface application, include the
interface-specific statement in the filter.
[edit dynamic-profiles basic-profile firewall family inet filter hierarch-filter]

3. Specify the term names for the filter.
Make each term name unique and represent what its function is.
[edit dynamic-profiles basic-profile firewall family inet filter hierarch-filter]

user@host# set term match-ip1
user@host# set term match-ip2
4. In each firewall filter term, specify the conditions used to match components of a
packet.
Configure the first term to match IPv4 packets received through TCP with the IP
precedence field critical-ecp (0xa0) protocol, and apply the hierarchical policer as
a filter action.
[edit dynamic-profiles basic-profile firewall family inet filter hierarch-filter term

match-ip1]
user@host# set from precedence critical-ecp protocol
5. Specify the actions to take when the packet matches all of the conditions in the
first term. Enable all hierarchical policers in one filter to share the same policer
instance in the Packet Forward Engine.

match-ip1]
user@host# set then hierarchical-policer hp1-share filter-specific
6. Configure the second term to match IPv4 packets received through TCP with the
IP precedence field internet-control (0xc0), and apply the hierarchical policer as a
filter action.

match-ip2]
user@host# set from precedence internet-control
7. Specify the actions to take when the packet matches all of the conditions in the
second term.
[edit dynamic-profiles basic-profile firewall family inet filter inet-filter term match-ip2]
user@host# set then hierarchical-policer hp2-share
Results Confirm the configuration by entering the show dynamic-profiles basic-profile firewall
[edit]
user@host# show dynamic-profiles basic-profile firewall

family inet {
filter hierarch-filter {
interface-specific;
term match-ip1 {
from {
precedence critical-ecp protocol;
protocol tcp;
}
then hierarchical-policer hp1-share;
}
term match-ip2 {
from {
precedence internet-control;
protocol tcp;
}
then hierarchical-policer hp2-share;
}
}
}
Configuring the Forwarding Classes
Step-by-Step Define forwarding classes referenced as aggregate policer actions. For hierarchical policers
Procedure to work, ingress traffic must be correctly classified into premium and non-premium
buckets. Some class-of-service (CoS) configuration is required because the hierarchical
policer must be able to separate premium/expedited forwarding (EF) traffic from
non-premium/non-EF traffic.
1. Enable configuration of the forwarding classes.
[edit]
user@host# set class-of-service forwarding-classes
2. Define CoS forwarding classes to include the designation of which forwarding class
is premium. This defaults to the forwarding class associated with EF traffic.
[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
Results Confirm the configuration of the forwarding classes referenced as aggregate policer
actions by entering the show class-of-service configuration command. If the command
output does not display the intended configuration, repeat the instructions in this
procedure to correct the configuration.
[edit]
user@host# show class-of-service
class fc0 queue-num 0 priority high policing-priority premium;
class fc1 queue-num 1 priority low policing-priority normal;
}

Configuring the Hierarchical Policer
Step-by-Step Configure the aggregate and premium policing components of a hierarchical policer.
Procedure
1. Enable configuration of the hierarchical policer.

user@host# set firewall hierarchical-policer policer-agg-prem
2. Configure the aggregate policer to have a bandwidth limit set to 10 Mbps, burst-size
limit set to 100 KB, and nonconforming action set to change the forwarding class
to fc1.
[edit dynamic-profiles basic-profile firewall hierarchical-policer policer-agg-prem]

user@host# set aggregate if-exceeding bandwidth-limit 10m burst-size-limit 100k
user@host# set aggregate then forwarding-class fc1
NOTE: For aggregate policers, the configurable actions for a packet in

a nonconforming flow are to discard the packet, change the loss priority,
or change the forwarding class.
3. Configure the premium policer to have a bandwidth limit set to 2 Mbps, burst-size
limit set to 50 KB, and nonconforming action set to discard packets.
[edit dynamic-profiles basic-profile firewall hierarchical-policer policer-agg-prem]

user@host# set premium if-exceeding bandwidth-limit 2m burst-size-limit 50k
user@host# set premium then discard
NOTE: The bandwidth limit for the premium policer must not be greater
than that of the aggregate policer. For the premium policers, the only
configurable action for a packet in a nonconforming traffic flow is to
discard the packet.
Results Confirm the configuration of the hierarchical policer by entering the show dynamic-profiles
basic-profile firewall configuration command. If the command output does not display
the intended configuration, repeat the instructions in this procedure to correct the
configuration.
[edit]
user@host# show dynamic-profiles basic-profile firewall
hierarchical-policer policer-agg-prem {
aggregate {
if-exceeding {
bandwidth-limit 10m;
}
then {
forwarding-class fc1;
}

}
premium {
if-exceeding {
bandwidth-limit 2m;
}
then {
discard;
}
}
}
Applying the Hierarchical Policer to Layer 2 Ingress Traffic at a Physical or Logical

Interface
Step-by-Step You can apply policers directly to an interface or applied through a filter to affect only
Procedure matching traffic. In most cases, you can invoke a policing function at ingress, egress, or
in both directions.
• For physical interfaces, a hierarchical policer uses a single policer instance to rate-limit
all logical interfaces and protocol families configured on a physical interface, even if
the logical interfaces have mutually exclusive families such as inet or bridge.
• For logical interfaces, a hierarchical policer can police the traffic from multiple protocol
families without requiring a separate instantiation of a policer for each such family on
the logical interface.
To hierarchically rate-limit Layer 2 ingress traffic for IPv4 traffic on logical interface
ge-1/2/0.0, reference the policer from the logical interface configuration.
1. Configure the logical interface.

user@host# set interfaces ge-1/2/0 unit 0
When you apply a policer to Layer 2 traffic at a logical interface, you must define at
least one protocol family for the logical interface.
2. Apply the policer to the logical interface.
[edit dynamic-profiles basic-profile interfaces ge-1/2/0 unit 0]

user@host# set layer2-policer input-hierarchical-policer policer-agg-prem
Alternatively, to hierarchically rate-limit Layer 2 ingress traffic for all protocol families
and for all logical interfaces configured on physical interface ge-1/2/0, reference
the policer from the physical interface configuration.
Results Confirm the configuration of the hierarchical policer by entering the show dynamic-profiles
basic-profile interfaces configuration command. If the command output does not display
the intended configuration, repeat the instructions in this procedure to correct the
configuration.
[edit]
user@host# show dynamic-profiles basic-profile interfaces
ge-1/2/0 {
unit 0 {

layer2-policer {
input-hierarchical-policer policer-agg-prem;
}
family inet {
address 10.8.0.0/31;
}
}
}
Verification
• Displaying Traffic Statistics for the Interface on page 330

• Displaying Number of Packets Policed by the Specified Policer on page 332
Displaying Traffic Statistics for the Interface
Purpose Verify the traffic flow through the physical interface.
Action Use the show interfaces operational mode command for physical interface ge-1/2/0, and
include the detail or extensive option.
user@host> show interfaces ge-1/2/0 extensive
Physical interface: ge-1/2/0, Enabled, Physical link is Down

Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 1000mbps, BPDU Error:
None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Pad to minimum frame size: Disabled
Device flags : Present Running Down
Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
Link flags : None
Schedulers : 0
Current address: 4c:96:14:77:77:08, Hardware address: 4c:96:14:77:77:08
Last flapped : 2014-11-10 13:36:25 EST (01:26:30 ago)
Traffic statistics:
IPv6 transit statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Dropped traffic statistics due to STP State:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3

incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,

FIFO errors: 0, Resource errors: 0
Output errors:
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0,
Resource errors: 0
0 0 0 0
1 0 0 0
2 0 0 0
3 0 0 0
4 0 0 0
5 0 0 0
6 0 0 0
7 0 0 0
Queue number: Mapped forwarding classes

0 best-effort
1 expedited-forwarding
2 assured-forwarding
3 network-control
4 be1
5 ef1
6 af1
7 nc1
Active alarms : LINK
Active defects : LINK
Total octets 0 0
Total packets 0 0
Unicast packets 0 0
FIFO errors 0 0
Oversized frames 0
Jabber frames 0
Fragment frames 0
Code violations 0
Total errors 0 0
Filter statistics:
Input DA rejects 0
Input SA rejects 0

Negotiation status: Incomplete
Destination slot: 0 (0x00)
CoS information:
Direction : Output
CoS transmit queue Bandwidth Buffer Priority
Limit
% bps % usec
0 best-effort 95 950000000 95 0 low
none
3 network-control 5 50000000 5 0 low
none
Interface transmit statistics: Disabled
Meaning The command output section for Traffic statistics lists the number of bytes and packets
received and transmitted on the interface.
Displaying Number of Packets Policed by the Specified Policer
Purpose Verify the number of packets evaluated by the policer. Premium policer counters are not
supported.
Action Use the show policer operational mode command and optionally specify the name of
the policer policer-agg-prem. The command output displays the number of packets
evaluated by the specified policer in each direction.
user@host> show policer policer-agg-prem

Policers:
Name Bytes Packets
policer-agg-prem-ge-1/2/0.0-inet-i 10372300 103723
The -inet-i suffix denotes a policer applied to IPv4 input traffic. In this example, the policer
is applied to input traffic only.
Meaning The command output displays the number of packets evaluated by the specified policer
in each direction.
Documentation

CHAPTER 28
Monitoring and Managing Firewalls for

Subscriber Access

• Enhanced Policer Statistics Overview on page 333
Verifying and Managing Firewall Filter Configuration

Purpose View or manage information for firewall filters:
NOTE: The router creates unique names for fast update filters and for filter
terms and counters. See Naming Fast Update Filters in “Fast Update Filters
Overview” on page 284 for information.
Action • To display statistics for firewall filters:
• To display firewall log information:
user@host> show firewall log
• To clear filter counters:

Documentation
• CLI Explorer
Enhanced Policer Statistics Overview
You can use the enhanced policer statistics to analyze traffic for debugging purposes on
MPC/MIC interfaces on MX Series routers and Multi-Rate Ethernet Enhanced Queuing
IP Services DPC with SFP and XFP.

Enhanced policer statistics provide the following:
• Offered packet statistics for traffic subjected to policing.
• OOS packet statistics for packets that are marked out-of-specification by the policer.
Changes to all packets that have out-of-specification actions, such as discard, color
marking, or forwarding-class, are included in this counter.
• Transmitted packet statistics for traffic that is not discarded by the policer. When the
policer action is discard, the statistics are the same as the within-specification statistics;
when the policer action is non-discard (loss-priority or forwarding-class), the statistics
are included in this counter.
Related • show policer

Documentation
• show firewall on page 746
• enhanced-policer on page 538

PART 3
Configuring Dynamic Multicast

• Configuring Dynamic IGMP to Support IP Multicasting for Subscribers on page 337
• Configuring Dynamic MLD to Enable Subscribers to Access Multicast
Networks on page 343


CHAPTER 29
Configuring Dynamic IGMP to Support IP

Multicasting for Subscribers
• Dynamic IGMP Configuration Overview on page 337

• Subscriber Management IGMP Model Overview on page 337
• Configuring Dynamic DHCP Client Access to a Multicast Network on page 338
• Example: IGMP Dynamic Profile on page 340
Dynamic IGMP Configuration Overview
The Internet Group Management Protocol (IGMP) is a host to router signaling protocol
for IPv4 used to support IP multicasting. This protocol manages the membership of hosts
and routers in multicast groups. IP hosts use IGMP to report their multicast group
memberships to any immediately neighboring multicast routers. Multicast routers use
IGMP to learn, for each of their attached physical networks, which groups have members.
Subscriber access supports the configuration of IGMP within the dynamic profiles hierarchy.
By specifying IGMP statements within a dynamic profile, you can dynamically apply IGMP
configuration when a subscriber connects to an interface using a particular access
technology (DHCP), enabling the subscriber to access a carrier (multicast) network.

Documentation
• Subscriber Management IGMP Model Overview on page 337
• Configuring IGMP
Subscriber Management IGMP Model Overview
In an IPTV network, channel changes occur when a set-top box (STB) sends IGMP
commands that inform an upstream device (for example, a multiservice access node
[MSAN] or services router) whether to start or stop sending multicast groups to the
subscriber. In addition, IGMP hosts periodically request notification from the STB about
which channels (multicast groups) are being received.

You can implement IGMP in the subscriber management network in the following ways:
• Static IGMP—All multicast channels are sent to the MSAN. When the MSAN receives
an IGMP request to start or stop sending a channel, it adds the subscriber to the
multicast group and then discards the IGMP packet.
• IGMP Proxy—Only multicast channels currently being viewed are sent to the MSAN.
If the MSAN receives a request to view a channel that is not currently being forwarded
to the MSAN, it forwards the request upstream. However, the upstream device does
not see all channel change requests from each subscriber, limiting bandwidth control
options.
• IGMP Snooping—Only multicast channels currently being viewed are sent to the MSAN.
The MSAN forwards all IGMP requests upstream, unaltered, even if it is already receiving
the channel. The upstream device sees all channel change requests from each
subscriber. Using IGMP snooping enables the broadband services router to determine
the mix of services and the bandwidth requirements of each subscriber and adjust the
bandwidth made available to each service.
• IGMP Passthrough—The MSAN transparently passes IGMP packets upstream to the

broadband services router.
IGMP hosts (sources) also periodically verify that they are sending the correct traffic by
requesting that each client send information about what multicast groups it wants to
receive. The responses to this IGMP query can result in a substantial upstream traffic
burst.
IGMPv2 is the minimum level required to support IPTV, and is the most widely deployed.
Emerging standards specify IGMPv3.
Related • Dynamic IGMP Configuration Overview on page 337

Documentation
Configuring Dynamic DHCP Client Access to a Multicast Network
This topic describes how to create a basic dynamic profile that enables DHCP clients to
dynamically access the multicast network.
Before you configure dynamic profiles for initial client access:
2. Configure the necessary router interfaces that you want accessing DHCP clients to
use.
See DHCP Subscriber Interface Overview for information about the types of interfaces
you can use with dynamic profiles and how to configure them.
3. Ensure that the router is configured to enable communication between the client and
the RADIUS server.

Chapter 29: Configuring Dynamic IGMP to Support IP Multicasting for Subscribers
See Specifying the Authentication and Accounting Methods for Subscriber Access.
4. Configure all RADIUS values that you want the profiles to use when validating DHCP
clients for access to the multicast network.
See Configuring RADIUS Server Parameters for Subscriber Access
To configure an initial client access dynamic profile:
1. Access an IGMP access profile.
user@host# edit dynamic-profiles access-profile

[edit dynamic-profiles access-profile]
user@host#
2. Define the IGMP interface with the interface variable.
NOTE: The variable value is replaced by the name of the interface over
which the router received the DHCP message.
[edit dynamic-profiles access-profile]

user@host# set protocols igmp interface $junos-interface-name
3. (Optional) Enable or disable accounting on the IGMP interface.
[edit dynamic-profiles access-profile protocols igmp interface “$junos-interface-name”]

user@host# set accounting
or

user@host# set no-accounting
NOTE: This statement enables you to override the accounting setting at

the IGMP protocol level. For example, if IGMP accounting is enabled at
the [edit protocols igmp interface interface-name] hierarchy level, you can
use the no-accounting statement to disable accounting for any IGMP
interfaces that are dynamically created by the dynamic profile. If IGMP
accounting is not enabled at the [edit protocols igmp interface
interface-name] hierarchy level, you can use the accounting statement to
enable accounting for any IGMP interfaces that are dynamically created
by the dynamic profile.
4. Set the IGMP interface to remain enabled.

user@host# set disable:$junos-igmp-enable
NOTE: RADIUS is capable of disabling IGMP. By assigning the enable

variable to the disable statement, you can ensure that IGMP remains
enabled.

5. (Optional) Specify a group policy for the IGMP interface.

user@host# set group-policy report-reject-policy
6. (Optional) Enable immediate leave on the IGMP interface.

user@host# set immediate-leave:$junos-igmp-immediate-leave
7. (Optional) Set the IGMP interface to obtain the IGMP version from RADIUS.

user@host# set version $junos-igmp-version
Related • Configuring a Basic Dynamic Profile

Documentation
Example: IGMP Dynamic Profile
In this example, IGMP is configured for subscriber access using Junos OS predefined
variables.
The predefined variables equate to RADIUS settings as follows:
Junos OS Predefined Variable RADIUS VSA Name RADIUS Attribute Number
$var-igmp-version IGMP-Version 26–78
$var-igmp-access-grp IGMP-Access-Name 26–71
$var-igmp-access-src-grp IGMP-Access-Src-Name 26–72

interfaces {
demux0 {
demux-options {
underlying-interface "$junos-underlying-interface";
}
family inet {
demux-source {
“$junos-subscriber-ip-address”;
}
}
}
}
}
protocols {
igmp {
interface "$junos-interface-name" {
version "$var-igmp-version";

Chapter 29: Configuring Dynamic IGMP to Support IP Multicasting for Subscribers
group-policy [ "$var-igmp-access-grp" "$var-igmp-access-src-grp" ];

}
}
}
NOTE: You must also configure any global IGMP parameters.
Related • Configuring Dynamic DHCP Client Access to a Multicast Network on page 338
Documentation


CHAPTER 30
Configuring Dynamic MLD to Enable

Subscribers to Access Multicast Networks
• Dynamic MLD Configuration Overview on page 343
Dynamic MLD Configuration Overview
The Multicast Listener Discovery (MLD) Protocol manages the membership of hosts and
routers in multicast groups. IP version 6 (IPv6) multicast routers use MLD to learn, for
each of their attached physical networks, which groups have interested listeners. Each
router maintains a list of host multicast addresses that have listeners for each subnet,
as well as a timer for each address. However, the router does not need to know the
address of the listeners—just the address of the hosts. The router provides addresses to
the multicast routing protocol it uses; this ensures that multicast packets are delivered
to all subnets where there are interested listeners. In this way, MLD is used as the transport
for the Protocol Independent Multicast (PIM) protocol.
Subscriber access supports the configuration of MLD within the dynamic profiles hierarchy
for dynamically created interfaces. By specifying MLD statements within a dynamic
profile, you can dynamically apply MLD configuration when a subscriber connects to an
interface using a particular access technology (DHCP), enabling the subscriber to access
a carrier (multicast) network.

Documentation
• Examples: Configuring MLD


PART 4
Configuring HTTP Redirect

• Configuring HTTP Redirect Services to Provide Authentication and Authorization
Services for Redirected Subscribers on page 347
• Monitoring and Managing HTTP Redirect Services on page 371


CHAPTER 31
Configuring HTTP Redirect Services to

Provide Authentication and Authorization
Services for Redirected Subscribers
• Redirecting HTTP Requests Overview on page 347

• Remote HTTP Redirect Server Operation Flow on page 348
• Local HTTP Redirect Server Operation Flow on page 350
• Configuring HTTP Redirect Services on page 351
• Example: Walled Garden as a Service Filter on page 355
• Example: Walled Garden as an HTTP Service Rule on page 356
• Example: Configuring an HTTP Service and Attaching It to a Static Interface on page 356
• Example: HTTP Service Attached to a Dynamic Interface on page 364
• Example: Configuring Destination Address Rewrite for HTTP Redirect on page 366
• Example: Configuring Redundant Multiservice on page 367
Redirecting HTTP Requests Overview
HTTP request traffic from subscribers is aggregated from access networks onto a
Broadband Remote Access Server (B-RAS) router, where HTTP traffic can be intercepted
and redirected to a captive portal. A captive portal provides authentication and
authorization services for redirected subscribers before granting access to protected
servers outside of a walled garden. A walled garden defines a group of servers where
access is provided to subscribers without reauthorization through a captive portal. You
can use a captive portal page as the initial page a subscriber sees after logging in to a
subscriber session and as a page used to receive and manage HTTP requests to
unauthorized Web resources.
The HTTP redirect service implements a data handler and a control handler and registers
them with service rules applicable to the HTTP applications. These rules are parsed by
the captive-portal-content-delivery process on the routing engine. The data handler
applies the rules to HTTP data flows and handles rewriting the IP destination address
or sending an HTTP 302 response with a preconfigured redirect URL. In addition, the
control handler maintains a connection with the captive-portal-content-delivery process
on the routing engine to learn configuration changes, such as the redirect URL and the

rewrite IP destination and port pair. To achieve faster performance, the control handler
maintains a cache of relevant configured entities, such as URLs on Multiservices DPC.
Packet flow differs depending on the following configurations:
• Walled garden as a service filter–HTTP traffic destined to servers within the walled
garden does not flow to Multiservices DPC. However, any HTTP traffic destined outside
of the walled garden flows to the Multiservices DPC.
• Walled garden as an HTTP policy term–All HTTP traffic flows to the Multiservices
DPC. The HTTP service handler determines whether traffic is allowed to go to a walled
garden.
• HTTP request packet–If the flow is destined to servers within the walled garden, no
action is taken.
An HTTP redirect service can be attached to either a static or dynamic interface. For
dynamic subscriber management, HTTP services can be attached dynamically at
subscriber login or by using a change of authorization (CoA).
Redundant multiservice PIC and DPC support for HTTP redirect distributes captive portal
content delivery rules to both PICs to leverage all framework support (for IPv4 only).
Data traffic is sent only to the active PIC and rule processing is performed on the active
PIC.

Documentation
• Defining Various Levels of Services for DHCP Subscribers
Remote HTTP Redirect Server Operation Flow
You can use the remote HTTP redirect feature in configurations where the redirect server
resides outside of the router and on a policy server, such as Session and Resource Control
(SRC).
An HTTP redirect remote server that resides in a walled garden behind routers processes
HTTP requests redirected to it and responds with a redirect URL to a captive portal. When
you use a remote HTTP redirect server, you need to configure an HTTP service rule to
rewrite the IP-DA of the incoming HTTP requests on the service router so that the requests
reach the remote HTTP redirect server before being redirected to a captive portal.
The following general sequence occurs during access configuration for a remote HTTP
redirect server deployment:
1. The subscriber logs in.
2. RADIUS authenticates the subscriber and sends a service activate (IP-DA rewrite),
which redirects traffic to the redirect policy server in a walled garden.
3. The subscriber attempts to access the content server.

Chapter 31: Configuring HTTP Redirect Services to Provide Authentication and Authorization Services for Redirected Subscribers
4. The router first redirects the HTTP traffic to SRC, which redirects it to the captive
portal.
5. The captive portal sends an authorization page back to the subscriber.
6. The subscriber enters credentials to obtain authorization.
7. The captive portal verifies the subscriber credentials.
8. The captive portal authorizes the subscriber and notifies SRC.
9. SRC checks the subscriber database and formulates a policy to allow the subscriber
access to the content server.
10. SRC sends the policy directly to the router or notifies the RADIUS server, which in turn
sends a change of authorization (CoA) to the router.
11. The router attaches the new policy, overriding the initial IP-DA write.
The subscriber now has access to the content server.
The following example shows a configuration for IP-DA rewrite:
[edit services captive-portal-content-delivery]

rule ipda-rewrite {
match-direction input-output;
term 1 {
from {
applications http {
}
}
then {
rewrite destination-address 100.20.1.2;
}
}
}
Related • Local HTTP Redirect Server Operation Flow on page 350

Documentation

Local HTTP Redirect Server Operation Flow
You can use the local HTTP redirect feature in configurations where the redirect server
resides locally on the router.
An HTTP redirect local server that resides locally on a router processes HTTP requests
redirected to it and responds with a redirect URL to a captive portal. You can implement
the local server as a service within a service set, which provides more scalability and
better performance. When you use a local HTTP redirect server, you need to configure
an HTTP service rule to redirect HTTP requests to a captive portal within a walled garden.
The following general sequence occurs during access configuration for a local HTTP
redirect server deployment:
1. The subscriber logs in.
2. RADIUS authenticates the subscriber and sends a service activate (HTTP redirect),
which redirects HTTP traffic to the captive portal in a walled garden.
3. The subscriber attempts to access the content server (HTTP traffic).
4. The subscriber’s HTTP traffic is redirected to the captive portal by the router.
5. The captive portal sends an authorization page back to the subscriber.
6. The subscriber enters credentials to obtain authorization.
7. The captive portal verifies the subscriber credentials.
8. The captive portal authorizes the subscriber.
The subscriber now has access to the content server.
The following example shows a configuration for HTTP redirect:

rule redirect {
match-direction input-output
term 1 {
from {
applications junos-http;
}
then {
redirect http://100.20.2.10/index.html; # this is the captive portal page }
}
}
Related • Remote HTTP Redirect Server Operation Flow on page 348

Documentation

Configuring HTTP Redirect Services
This example shows how to configure an HTTP redirect service.

Requirements
Before you begin:
1. Configure the connection between the redirect server and the JUNOS router by
configuring policies on the controller.
2. On the controller, configure a policy that includes the following policy actions to define
which traffic to send to the redirect server:
• An exception action to specify that an HTTP application receive traffic.
• An HTTP redirect policy action to specify the URL to receive packets identified in
the exception application action.
Overview
In this example, you configure a walled garden with services and policies.
Configuration
Mode.
To configure the HTTP redirect service:
1. Configure the packet and installation.
[edit chassis]
fpc 1 {
pic 0 {
adaptive-services {
service-package {
extension-provider {
control-cores 1;
data-cores 7;
object-cache-size 1024;
policy-db-size 64;
package jservices-cpcd;
syslog {
daemon any;
external any;
}

}
}
}
}
}
2. Configure the units and assign the VLAN IDs.
[edit interfaces]
ge-0/0/1 {
vlan-tagging;
unit 1 {
vlan-id 100;
family inet {
address 100.20.1.1/24;
}
}
}
3. Configure the policy options.
policy-options {
prefix-list google {
74.125.19.0/24;
}
}
4. Configure the service options.
firewall {
family inet {
service-filter walled {
term google {
from {
destination-prefix-list {
google;
}
}
then skip;
}
term http {
from {
destination-port [ 80 8080 ];
}
then service;
}
term skip {
then skip;
}
}
service-filter fromSRC {
term SRC {
from {
source-address {
10.1.2.3/32;
}
source-port 8800;
}

then service;
}
term skip {
then skip;
}
}
}
}
5. Configure the captive portal content delivery services.
services {
captive-portal-content-delivery {
rule test {
match-direction input;
term t1 {
then {
rewrite;
}
}
}
profile ipda-rewrite {
cpcd-rules test;
ipda-rewrite-options {
destination-address 10.1.2.3;
}
}
traceoptions {
file cpcdd;
flag all;
}
}
service-set sset1 {
captive-portal-content-delivery-profile ipda-rewrite;
interface-service {
service-interface ms-1/0/0;
}
}
stateful-firewall {
rule Rule1 {
term 1 {
from {
applications [ junos-icmp-all junos-dhcp-server junos-tftp junos-http ];
}
then {
accept;
}
}
term 2 {
from {
applications SRC;
}
then {
accept;

}
}
}
}
}
6. Configure the applications.
applications {
application SRC {
protocol tcp;
}
}
Results From configuration mode, confirm your configuration by entering the show services
configuration instructions in this example to correct it.
For brevity, this show services command output includes only the configuration that is
relevant to this example. Any other configuration on the system has been replaced with
ellipses (...).
[edit]
user@host# show services captive-content-delivery
Verification
To confirm that the configuration is working properly, perform this task:
• Verifying HTTP Redirect Requests on page 354
Verifying HTTP Redirect Requests
Purpose View information and statistics for the HTTP redirect configuration.
Action • To display services statistics:
user@host# show services captive-portal-content-delivery statistics
• To display services flows:
user@host# show services captive-portal-content-delivery flows
• To clear services statistics:
user@host# clear services captive-portal-content-delivery statistics
Related • Redirecting HTTP Requests Overview on page 347

Documentation

Example: Walled Garden as a Service Filter
Service filters are configured under the firewall and are not specific to captive portal
content delivery. The following example shows a walled garden with one server, which
is the captive portal:
[edit firewall family inet]

root@host# show
service-filter walled {
term 1 {
from {
100.20.2.3/32; ## this is the address of captive portal
}
}
then skip; ## skip service DPC for http traffic
## destined to captive portal
}
}
The following example shows a walled garden within a subnet:
service-filter walled-net {
term 2 {
from {
destination-prefix-list {
100.20.2.0/24; ## '100.20.2.0/24' is not defined
}
}
then skip;
}
}
The following example shows the configuration of an IPv6 walled garden:

rule walled-garden {
term 1 {
from {
destination-address 2001:2002:0:1::/64; ## captival portal resides here
}
then {
accept;
}
}
}

Documentation

Example: Walled Garden as an HTTP Service Rule
HTTP service rule configuration resides under the services hierarchy and uses the captive
portal and content delivery (captive-portal-content-delivery) service. The following
example shows a walled garden configured as an HTTP service rule:

rule walled-garden {
term 1 {
from {
destination-address 100.20.2.3/32; ## captive portal
}
then {
accept;
}
}
}
When a remote HTTP redirect server is used, you need to configure an HTTP service rule
to rewrite the IP-DA of incoming HTTP requests on the service router so that the requests
reach the remote HTTP redirect server before being redirected to a captive portal. If the
destination port is not specified, the default behavior is determined by the rewrite
configuration. If no rewrite configuration is available, the destination port is not rewritten.
The following example shows a configuration for IP-DA rewrite:

rule ipda-rewrite {
term 1 {
from {
}
then {
rewrite destination-address 100.20.2.10; # this is the remote
# redirect server.
}
}
}

Documentation
Example: Configuring an HTTP Service and Attaching It to a Static Interface
This example shows how to configure an HTTP redirect service and attach it to a static
interface.



Requirements
Before you begin:
• Configure the connection between the redirect server and the JUNOS router.
• Define the source address (10.0.0.0/24 is used in this example).
• Define the interface(s) used for subscriber traffic.
Overview
You can configure an HTTP redirect service set and attach it to a static interface using
either of these examples:
• Configuring HTTP redirect service using an interface-specific filter
• Configuring HTTP redirect service using a next-hop method
Configuration
• Configuring HTTP Redirect Service Using an Interface-Specific Filter on page 357
• Configuring HTTP Redirect Service Using a Next-Hop Method on page 360
• Results on page 363
Configuring HTTP Redirect Service Using an Interface-Specific Filter
Mode.
To configure the HTTP redirect service using an interface-specific filter:
1. Configure the package and installation.
[edit chassis]
fpc 11 {
pic 1 {
adaptive-services {
service-package {
control-cores 1;
data-cores 7;
policy-db-size 64;
syslog {
daemon none;
external none;
kernel none;
pfe none;
}

}
}
}
}
}
2. Configure the static interface, unit, and assign the VLAN ID. Also, define the redirect
filter and HTTP input and output service sets, and service filters.
[edit interfaces]
xe-0/0/1 {
unit 900 {
vlan-id 900;
family inet {
filter {
input redirect-in;
}
service {
input {
service-set http-redirect-sset service-filter http-redirect-sfilter;
}
output {
service-set http-redirect-sset;
}
}
}
}
}
3. Configure the service options by defining the interface-specific filter using multiple
walled garden destination addresses to direct traffic, and the service filter to redirect
HTTP traffic to servers inside the walled garden.
[edit firewall]
family inet {
filter redirect-in {
interface-specific;
term DNS {
from {
}
then {
accept;
}
}
term Wall-Garden {
from {
50.18.115.82/32;
108.162.204.216/32;
108.162.203.216/32;
54.241.3.103/32;
54.241.8.247/32;
198.41.186.31/32;
198.41.187.31/32;
}
}

then {
count Wall-Garden;
accept;
}
}
term HTTP {
from {
protocol tcp;
}
then {
count HTTP;
accept;
}
}
term DROP_ALL {
then {
discard;
}
}
}
service-filter http-redirect-sfilter {
term 1 {
from {
source-address {
10.0.0.0/24;
}
A1.B1.C1.D1/32; # replace with your own IP address (server inside the walled
garden)
garden)
garden)
}
}
then skip;
}
term 2 {
from {
source-address {
10.0.0.0/24;
}
protocol tcp;
destination-port [ http 8080 ];
}
then {
count SVC-HTTP;
service;
}
}
term 3 { # this term will make the remaining traffic to be accept and not serviced
(not redirected)

then skip; # if the intention is to drop the remaining traffic, then this term must be
changed to discard.
}
4. Configure the service filter as a walled garden by defining a rule named redirect,
referencing the rule in a profile named http-redirect, configuring a service set named
http-redirect-sset that references the http-redirect captive portal content delivery
profile, and attaching the http-redirect service set to static interface ms-11/1/0.
[edit services]
rule redirect {
term 1 {
then {
redirect http://redirection-portal/redirection/;
}
}
}
profile http-redirect {
cpcd-rules redirect;
}
}
service-set http-redirect-sset {
captive-portal-content-delivery-profile http-redirect;
interface-service {
service-interface ms-11/1/0;
}
}
}
Configuring HTTP Redirect Service Using a Next-Hop Method
Mode.
To configure the HTTP redirect service using a next-hop method:
1. Configure the service filter by defining a rule named redirect, referencing the rule in
a profile named http-redirect, configuring a service set named http-redirect-sset
that references the http-redirect captive portal content delivery profile, and attaching
the next-hop service set to inside-service-interface ms-11/1/0.1, and to
outside-service-interface ms-11/1/0.2.
[edit services]
rule redirect {
term REDIRECT {
then {
redirect http://redirection-portal/redirection/;
}
}
}

profile http-redirect {
cpcd-rules redirect;
}
}
service-set http-redirect-sset {
captive-portal-content-delivery-profile http-redirect;
next-hop-service {
inside-service-interface ms-11/1/0.1;
outside-service-interface ms-11/1/0.2;
}
}
2. Configure the package and installation.
[edit chassis]
fpc 11 {
pic 0 {
adaptive-services {
service-package layer-3;
}
}
pic 1 {
adaptive-services {
service-package {
control-cores 1;
data-cores 7;
policy-db-size 64;
syslog {
daemon none;
external none;
kernel none;
pfe none;
}
}
}
}
}
}
3. Configure the interfaces used for subscriber traffic and define the interface VLAN
where any redirected traffic will arrive. Also, define the service options for redirect
filter, and inside and outside service domains.
NOTE: The values configured for the service options are shown for
example only. You must configure and provision appropriate values as
per the requirement.
[edit interfaces]
xe-0/0/1 {
unit 900 { <<<<<<<<<<< interface.vlan where the traffic that must be redirected
will arrive

description "VLAN REDIRECT";

vlan-id 900;
family inet {
filter {
input FF_HTTP_REDIR_IN;
}
address 10.205.255.10/30;
}
}
ms-11/1/0 {
services-options {
open-timeout 4;
close-timeout 2;
inactivity-tcp-timeout 5;
inactivity-asymm-tcp-timeout 5;
inactivity-non-tcp-timeout 5;
session-timeout 5;
tcp-tickles 0;
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet {
filter {
output FF_CPCD_REDIRECT_OUTPUT;
}
}
service-domain outside;
}
}
4. Configure interface-specific filters to direct output traffic to the outside service

domain, and input traffic to the inside service domain.
[edit firewall]
family inet {
filter FF_CPCD_REDIRECT_OUTPUT {
interface-specific;
term One {
then {
count back-to-default;
}
}
}
filter FF_HTTP_REDIR_IN {
interface-specific;
term ACCEPTED_PREFIXES {
from {
prefix-list {
User-PRIVATE-Blocks-01;
}
}
then next term;
}

term HTTP {
from {
protocol tcp;
}
then {
count http;
}
}
}
}
5. Configure the policy option and statement to use a private blocks prefix list for the
source address, for example, 10.0.0.0/24.
[edit policy-options]
policy-statement User-PRIVATE-Blocks-01 {
10.0.0.0/24;
}
Results
From configuration mode, confirm your configuration and display the current operational
state of all captive portal interfaces by entering the show services captive-content-delivery
command using various options. If the output does not display the intended configuration,
show services captive-portal-content-delivery

user@host> show services captive-portal-content-delivery pic xe-0/0/1
Name Index
xe-0/0/1 20
user@host> show services captive-portal-content-delivery profile

Profile Rules or Rule Sets
http-redirect 1
cpcd-rules 1
user@host> show services captive-portal-content-delivery http-redirect

http-redirect 1
user@host> show services captive-portal-content-delivery rule

Rule Name Term Name
redirect REDIRECT
rewrite term 1
user@host> show services captive-portal-content-delivery rule redirect term t1

Rule name: redirect
Rule match direction: input
Term name: term 1
Term action: redirect
Term action option: http://redirection-portal/redirection/
user@host> show services captive-portal-content-delivery service-set http-redirect-sset detail

Service Set Id Profile Compiled Rules

http-redirect-sset 1 http-redirect 1
user@host> show services captive-portal-content-delivery statistics interface ms-11/1/0

service-set interface: ms-11/1/0
Packets received Packets altered

5 3
Verification
To confirm that HTTP redirect services have been configured correctly, perform these
tasks:
user@host# show services captive-portal-content-delivery statistics
user@host# show services captive-portal-content-delivery flows
user@host# clear services captive-portal-content-delivery statistics

Documentation
Example: HTTP Service Attached to a Dynamic Interface
A dynamic service attachment uses a dynamic profile. In the following dynamic profile
example, the name of the service set can be populated dynamically for each subscriber
at instantiation time. This dynamic profile encapsulates a service attachment point
associated with a statically preprovisioned service set sset-1.
dynamic-profiles {
profile prof-2 { # parameterized service attachment
interfaces {
family inet {
service {
input {
service-set $junos-service-set service-filter $junos-service-filter;
post-input-filter $junos-post-input-filter ;

}
output {
service-set $junos-service-set;
}
}
}
}
}
}
}
}
To handle scalability more efficiently, in the following example the name of the service
set can be populated dynamically for each subscriber at instantiation time.
dynamic-profiles {
profile prof-2 { # parameterized service attachment
interfaces {
family inet {
service {
input {
service-set $junos-service-set service-filter $junos-service-filter;
post-input-filter $junos-post-input-filter ;
}
output {
service-set $junos-service-set;
}
}
}
}
}
}
}
}
The following attaches a service set dynamically at family inet6:
dynamic-profiles {
profile prof-1 {
interfaces {
family inet6 {
service {
input {
service-set sset-1 service-filter fltr-1;
post-input-filter pfltr-1 ;
}
output {
service-set sset-1 service-filter fltr-1;
}
}
}
}

}
}
}
}

Documentation
Example: Configuring Destination Address Rewrite for HTTP Redirect

Requirements
• Multiservices DPC PIC
Overview
This procedure shows how to configure an DA rewrite rule. The destination port is not
specified and the default behavior is determined by the rewrite configuration. If no rewrite
configuration is available, the destination port is not rewritten.
Configuration
Example: Configuring a Rewrite Rule
Step-by-Step 1. Configure the service rule:

Procedure
user@host# set rule da-rewrite
2. Specify the term name:
[edit services captive-portal-content-delivery da-rewrite]

user@host# set term t1
3. Specify the match conditions for the term:
[edit services captive-portal-content-delivery da-rewrite inet-filter term t1]

user@host# set from applications junos-http
4. Specify the actions to take if the packet matches all the conditions in that term:
[edit services captive-portal-content-delivery da-rewrite inet-filter term t1]

user@host# set then rewrite desitnation-address 2001:2002::1;
Results Confirm the configuration by entering the show services configuration command. If the
command output does not display the intended configuration, repeat the instructions in
this procedure to correct the configuration.

rule da-rewrite {

term 1 {
from {
}
then {
rewrite destination-address 2001:2002::1; # this is the remote redirect server.
}
}
}
The following example shows the configuration for an IPv6-DA rewrite service rule.
Because the destination port is not specified, the default behavior is determined by the
rewrite configuration. If no rewrite configuration is available, the destination port is not
rewritten.
[edit services captive-portao-content-delivery]

rule ipv6da-rewrite {
term 1 {
from {
}
then {
rewrite destination-address 2001:2002::1; # this is the remote
# redirect server.
}
}
}
Verification
Displaying HTTP Redirect configuration
Purpose Verify the HTTP requests are redirected to the server.
Action user@host> show services detail

Documentation
Example: Configuring Redundant Multiservice


Requirements
• Multiservices DPC PIC
Overview
This procedure shows how to configure redundant multiservice support.
Configuration
Example: Configuring Redundant Multiservice for IPv4
Step-by-Step 1. Configure the interface:

Procedure
[edit interfaces]
user@host# set interface rms0
2. Configure the redundant multiservice service set:
[edit services]
user@host# set service-interface rms0
3. Configure the redundant multiservice service set attachment:
[edit interfaces]
user@host# set ge-1/0/0 unit 100
Results Confirm the configuration by entering the show redundancy-options configuration

command.
show redundancy-options
redundancy-options {
primary ms-2/1/0;
secondary ms-3/1/0;
hot-standby;
}
unit 0 {
family inet;
}
Confirm the service set configuration by entering the show

captive-portal-content-delivery-profile configuration command.
show captive-portal-content-delivery-profile httpRedirect

interface-service {
service-interface rms0;
}
Confirm the service set attachment by entering the show show vlan-id configuration
command.
show vlan-id 100

family inet {
service {
input {
service-set sset10 service-filter walled;
}

output {
service-set sset10;
}
}
address 192.1.4.1/24;
}
Verification
Displaying Redundant Multiservice Configuration
Purpose Verify the redundant multiservice configuration.
Action user@host> show interfaces redundancy detail


CHAPTER 32
Monitoring and Managing HTTP Redirect

Services

user@host> show services captive-portal-content-delivery statistics
user@host> show services captive-portal-content-delivery flows
user@host> clear services captive-portal-content-delivery statistics

Documentation


PART 5
Configuring Subscriber Secure Policy

• Configuring Subscriber Secure Policy Traffic Mirroring on page 375
• Configuring Subscriber Secure Policy and L2TP LAC and LNS Subscribers on page 379
• Configuring RADIUS-Initiated Subscriber Secure Policy Traffic Mirroring on page 381
• Configuring Subscriber Secure Policy Support for IPv4 Multicast Traffic on page 395
• Configuring DTCP-Initiated Subscriber Secure Policy Traffic Mirroring on page 397
• Configuring Intercept-Related Information for Subscriber Secure Policy on page 409
• Configuring the Mediation Device for Subscriber Secure Policy on page 413
• Monitoring and Managing DTCP Messages on page 423


CHAPTER 33

Traffic Mirroring
• Subscriber Secure Policy Overview on page 375

• Subscriber Secure Policy Licensing Requirements on page 376
• Configuring Support for Subscriber Secure Policy Mirroring on page 376
Subscriber Secure Policy Overview
Subscriber secure policy enables you to mirror traffic on a per-subscriber basis. You can
mirror the content of subscriber traffic as well as monitor events related to the subscriber
session that is being mirrored.
Subscriber secure policy mirroring can be based on information provided by either RADIUS
or Dynamic Tasking Control Protocol (DTCP), and can mirror both IPv4 and IPv6 traffic.
Configuration of subscriber secure policy mirroring is independent of the actual mirroring
session—you can configure the mirroring parameters at any time. Also, you can use a
single RADIUS or DTCP server to provision mirroring operations on multiple routers in a
service provider’s network. To provide security, the ability to configure, access, and view
the subscriber secure policy components and configuration is restricted to authorized
users.
After subscriber secure policy is triggered, both the subscriber incoming and outgoing
traffic are mirrored. The original traffic is sent to its intended destination and the mirrored
traffic is sent to a mediation device for analysis. The actual mirroring operation is
transparent to subscribers whose traffic is being mirrored. A special UDP/IP header is
prepended to each mirrored packet sent to the mediation device. The mediation device
uses the header to differentiate multiple mirrored streams that arrive from different
sources.
Subscriber Secure Policy for Subscribers on VLANs

Interface-based subscriber secure policy is supported on dynamic, authenticated VLAN
interfaces and VLAN demux interfaces. When you enable subscriber secure policy for
these interfaces, traffic for all configured families (inet, inet6) including Layer 2 and Layer
3 control traffic is mirrored. The mirrored packets include Layer 2 encapsulations.

Traffic Filtering For DTCP-Initiated Subscriber Secure Policy Mirrored Traffic

You can filter mirrored traffic before it is sent to a mediation device. With this feature,
service providers can reduce the volume of traffic sent to a mediation device. For some
types of traffic, such as IPTV or video on demand, you do not need to mirror the entire
content of the traffic because the content may already be known or controlled by the
service provider.
Mirroring-Related Event Reporting

Subscriber secure policy also supports the use of SNMPv3 traps to report events related
to the mirroring operation to an external device. Types of information sent in traps include
identifying information for subscribers, such as username or IP address, and subscriber
session events, such as login or logout events or mirroring session activation or
deactivation. The traps map to messages defined in the Lawfully Authorized Electronic
Surveillance (LAES) for IP Network Access, American National Standard for
Telecommunications.
Related • RADIUS-Initiated Subscriber Secure Policy Overview on page 381

Documentation
• DTCP-Initiated Subscriber Secure Policy Overview on page 397
• Intercept-Related Events Transmitted to the Mediation Device on page 409
Subscriber Secure Policy Licensing Requirements
To enable and use subscriber secure policy, you must install and properly configure the
Subscriber Secure Policy license.
Related • Junos OS Feature Licenses

Documentation
• Junos OS Feature License Keys
• License Enforcement
Configuring Support for Subscriber Secure Policy Mirroring
Subscriber secure policy runs on the radius-flow-tap service. This topic describes the
steps to configure radius-flow-tap support for RADIUS-initiated and DTCP-initiated
subscriber secure policy mirroring.
To configure the radius-flow-tap service to support subscriber secure policy mirroring:
1. Configure the flow-tap service used for subscriber secure policy mirroring.
[edit services]
user@host# edit radius-flow-tap
2. Assign the tunnel interfaces that the radius-flow-tap service uses.
[edit services radius-flow-tap]

user@host# set interfaces vt-1/1/0.0

Chapter 33: Configuring Subscriber Secure Policy Traffic Mirroring
If a currently used tunnel interface is deleted from the pool of interfaces, the active
mirroring sessions are redistributed from the deleted interface to other tunnel interfaces
in the pool. Also, when a new tunnel interface is added into the pool, the service adds
the new interface to the list of interfaces available for new mirroring sessions or for
existing sessions transferred from a failed interface.
3. Specify the source IP address that the radius-flow-tap service uses for mirroring. This
address is used in the IP header prepended to mirrored packets that are sent to the
content destination device.

user@host# set source-ipv4-address ipv4-address
4. (Optional) Specify the forwarding class that is applied to the mirrored packets sent
to the mediation device.
If you do not specify a forwarding class, mirrored packets inherit the forwarding class
from the original packet (which is the forwarding class set by default classification
that CoS applies to the packet on the ingress interface).

5. (Optional) Specify the lawful intercept policy that determines what traffic, if any, is
not sent to the mediation device.
You can add or change a lawful intercept policy any time, but a changed policy does
not apply to a currently enabled policy. To change a policy, add a policy with a new
name, use DTCP DISABLE to turn off the current policy, and use DTCP ENABLE to
point to the new policy name.

user@host# set policy policy-name
Related • Subscriber Secure Policy Overview on page 375

Documentation
• Configuring RADIUS-Initiated Subscriber Secure Policy Mirroring Overview on page 382
• Configuring DTCP-Initiated Subscriber Secure Policy Mirroring Overview on page 398
• Guidelines for Configuring Subscriber Secure Policy Mirroring on page 383


CHAPTER 34
Configuring Subscriber Secure Policy and

L2TP LAC and LNS Subscribers
• Subscriber Secure Policy and L2TP LAC Subscribers on page 379

• Subscriber Secure Policy and L2TP LNS Subscribers on page 379
Subscriber Secure Policy and L2TP LAC Subscribers
RADIUS-initiated per-subscriber traffic mirroring can be applied to subscribers whose

traffic is tunneled with L2TP. Both subscriber ingress traffic (from the subscriber into the
tunnel) and subscriber egress traffic (from the tunnel to the subscriber) are mirrored at
the subscriber-facing ingress interface on the LAC. The ingress traffic is mirrored after
PPPoE decapsulation and before L2TP encapsulation. The egress traffic is mirrored after
L2TP decapsulation. The mirrored packet includes the complete HDLC frame sent to the
LNS rather than only the IP datagram.

Documentation
• RADIUS Attributes Used for Subscriber Secure Policy on page 392
Subscriber Secure Policy and L2TP LNS Subscribers
Dynamic Tasking Control Protocol (DTCP)-initiated and RADIUS-initiated per-subscriber

traffic mirroring can be applied to Point-to-Point Protocol (PPP) subscribers whose
traffic is tunneled with Layer 2 Tunneling Protocol (L2TP). At the L2TP network server
(LNS), both subscriber ingress traffic (from the L2TP access concentrator, or LAC, to the
LNS) and subscriber egress traffic (from the LNS to the LAC) are mirrored at the inline
services (si) interface corresponding to the subscriber. Ingress traffic is mirrored after
decapsulation of L2TP, HDLC, and PPP headers. The egress traffic is mirrored before the
IP datagram is encapsulated. The mirrored traffic contains only the IP datagram belonging
to the subscriber.

Documentation


CHAPTER 35
Configuring RADIUS-Initiated Subscriber

Secure Policy Traffic Mirroring
• RADIUS-Initiated Subscriber Secure Policy Overview on page 381

• Configuring RADIUS Server Support for Subscriber Secure Policy Mirroring on page 383
• Subscriber Secure Policy Traffic Mirroring Architecture Using RADIUS on page 384
• RADIUS-Initiated Traffic Mirroring Interfaces on page 386
• RADIUS-Initiated Traffic Mirroring Process at Subscriber Login on page 388
• RADIUS-Initiated Traffic Mirroring Process for Logged-In Subscribers on page 389
• Configuring Tunnel Interfaces for Subscriber Secure Policy Mirroring on page 390
• Terminating RADIUS-Initiated Subscriber Traffic Mirroring on page 393
RADIUS-Initiated Subscriber Secure Policy Overview
RADIUS-initiated mirroring creates secure policies based on RADIUS VSAs and uses
RADIUS attributes to identify the subscriber whose traffic is to be mirrored. Mirroring is
initiated without regard to the subscriber location, router, interface, or type of traffic.
The mirroring operation can be initiated by RADIUS messages as follows:
• Subscriber login—Mirroring starts when the subscriber logs in and the router receives
the trigger in a RADIUS Access-Accept message. Using triggers in RADIUS
Access-Accept messages enables you to mirror per-subscriber traffic without regard
to how often the subscriber logs in or out, or which router or interface the subscriber
uses.
• In-session—Mirroring starts when the router receives the trigger in a RADIUS change
of authorization request (CoA-Request) message. Using triggers in CoA-Request
messages enables you to immediately mirror traffic of a subscriber who is already
logged in.

Related • Subscriber Secure Policy Traffic Mirroring Architecture Using RADIUS on page 384
Documentation
Configuring RADIUS-Initiated Subscriber Secure Policy Mirroring Overview
Before you configure subscriber secure policy traffic mirroring, note the following:
• Subscriber secure policy mirroring runs on the radius-flow-tap service infrastructure.

To configure the subscriber secure policy service, you must have the same privileges
that are required to configure the radius-flow-tap service.
• The subscriber secure policy feature requires some system resources while mirroring,
encrypting, and sending traffic to the mediation device. For example, you might elect
to use a 10-Gigabit Ethernet interface for the tunnel to the mediation device if you
expect the amount of traffic you plan to mirror to approach 1 Gbps of actual user data.
To configure the subscriber secure policy service:
1. Configure tunnel interfaces (vt interfaces) that are used to send mirrored content to
the mediation device.
See “Configuring Tunnel Interfaces for Subscriber Secure Policy Mirroring” on page 390.
2. Configure radius-flow-tap service support for secure subscriber policy. This support
includes optional forwarding-class information that the subscriber secure policy
service uses to send mirrored traffic to the content destination device.
See “Configuring Support for Subscriber Secure Policy Mirroring” on page 376.
3. Configure an access profile that specifies the RADIUS-related support for subscriber
secure policy on the router, including a list of one or more RADIUS authentication
servers. The router uses the list of specified servers for both authentication and dynamic
request operations. You must also configure the RADIUS dynamic request feature,
which provides the CoA message support used in-session traffic mirroring.
See “Configuring RADIUS Server Support for Subscriber Secure Policy Mirroring” on
page 383.
4. Ensure that the following support is also configured:
• The RADIUS record of the mirrored subscriber must include the RADIUS attributes
and VSAs required for subscriber secure policy mirroring. See “RADIUS Attributes
Used for Subscriber Secure Policy” on page 392 for descriptions of the supported
attributes used in RADIUS Accept-Accept and CoA messages.
• The mediation device must be configured to accept the mirrored content.
5. (Optional) Enable the mirroring of IPv4 multicast traffic on the router.
See “Enabling Subscriber Secure Policy Mirroring for IPv4 Multicast Traffic” on page 396.
6. (Optional) Configure SNMPv3 trap support to report mirroring-related events to the

mediation device.
See “Configuring SNMPv3 Traps for Subscriber Secure Policy Mirroring” on page 411.

Chapter 35: Configuring RADIUS-Initiated Subscriber Secure Policy Traffic Mirroring
To terminate an active subscriber mirroring session at any time.
See “Terminating RADIUS-Initiated Subscriber Traffic Mirroring” on page 393.
Related • RADIUS Attributes Used for Subscriber Secure Policy on page 392
Documentation
• Terminating RADIUS-Initiated Subscriber Traffic Mirroring on page 393
Guidelines for Configuring Subscriber Secure Policy Mirroring
The subscriber secure policy service uses the radius-flow-tap service infrastructure.
When configuring subscriber secure policy mirroring, consider the following guidelines
regarding the relationship between subscriber secure policy service and the
radius-flow-tap service:
• The radius-flow-tap service [edit services radius-flow-tap] and the flow-tap service
[edit services flow-tap] cannot run simultaneously on the router. Therefore, flow-tap
and subscriber secure policy mirroring cannot run simultaneously on the same router.
• You can configure one instance of the radius-flow-tap service on the router. Subscriber
secure policy RADIUS-initiated mirroring and DTCP-initiated mirroring use the
radius-flow-tap service.
• If you delete the radius-flow-tap service all subscriber secure policy mirroring stops.

Documentation
Configuring RADIUS Server Support for Subscriber Secure Policy Mirroring
This topic describes how to configure support for the RADIUS server that initiates
subscriber-based traffic mirroring. You create an access profile to specify the RADIUS
server support.
To configure the router’s interaction with the RADIUS server in support of subscriber
secure policy mirroring:
1. Create the access profile and assign a name.
[edit access]
user@host# edit profile profile-name
2. Specify RADIUS as the authentication method.
[edit access profile profile-name]

user@host# set authentication-order radius
3. Specify the IP address of the RADIUS server that performs authentication. This server
also performs dynamic request (CoA) functions.

user@host# set radius authentication-server ip-address
4. Specify the secret to use when communicating with the RADIUS server.

user@host# set radius-server server-address secret password
5. Specify other optional RADIUS configuration settings as needed, such as accounting

support.

Documentation
Subscriber Secure Policy Traffic Mirroring Architecture Using RADIUS
Figure 25 on page 384 shows the architecture of the RADIUS-initiated subscriber secure
policy mirroring environment.
Figure 25: RADIUS-Initiated Subscriber Secure Policy Architecture
Access Function Delivery Function Collection Function
Provisioning RADIUS Provisioning Provisioning

server
Mediation
Events Device Events
Content Content
Intercept
Access Law
Point Enforcement
Agency
Service Law
g017564
Provider Enforcement
Domain Domain
Table 41 on page 385 describes the functions and components of a RADIUS-initiated

subscriber secure policy traffic mirroring environment.


Components
Function or Component Description
Collection function The collection function is responsible for

collecting intercepted content and identifying
information from the delivery function.
The collection function is the responsibility of

the law enforcement agency (LEA).
Delivery function The delivery function delivers information that

it receives from the access function to the
collection function.
The delivery function is performed by the

mediation device.
Access function The access function has access to the intercept

target’s traffic content and intercept-related
events. It is responsible for collecting this
information and sending it to the delivery
function.
The access function is the responsibility of

intercept access points (IAPs).
Events Intercept-related events, such as login or logout

events or mirroring session activation or
deactivation. The router sends the events to the
mediation device in SNMP traps.
LEA Law enforcement agency. The LEA provides

intercept targets to the service provider who
provisions the mediation device.
Mediation device The mediation device receives provisioning

information from the LEA, and it uses the
information to send provisioning information to
the RADIUS server.
The mediation device also receives

intercept-related events and intercepted
content from the router, and delivers the events
and intercepted content to the LEA.
RADIUS server The RADIUS server receives provisioning

information from the mediation device. It
identifies subscribers whose traffic is to be
mirrored, and triggers mirroring sessions on the
IAP (the router) by including mirroring-related
RADIUS attributes and VSAs in Access-Accept
or CoA-Request messages that it sends to the
IAP.


Components (continued)
Function or Component Description
IAP Intercept access point. In a subscriber access

network the Juniper Networks router is the IAP.
Using subscriber secure policies, the IAP

intercepts traffic to and from the subscriber
whose traffic is being mirrored. It encapsulates
the intercepted content in a packet header and
delivers it to the mediation device, while also
sending the content to the intended destination.
The IAP also sends intercept-related events to

the mediation device using SNMP traps.

Documentation
RADIUS-Initiated Traffic Mirroring Interfaces
Figure 26 on page 386 shows the interfaces involved in RADIUS-initiated secure subscriber
policy traffic mirroring.
Figure 26: RADIUS-Initiated Traffic Mirroring Interfaces
Handover
Internal Network Interfaces (INI) Interfaces (HI)
RADIUS
server INI-1 HI-1
Mediation
INI-2 Device HI-2
INI-3 HI-3 Law
Intercept Enforcement
Access Agency
Point
Destination
Service Law
g017578
Domain Domain
Table 42 on page 387 describes the interfaces involved in RADIUS-initiated secure

subscriber policy traffic mirroring.

Table 42: RADIUS-Initiated Traffic Mirroring Interfaces

Interface Description
HI-1 Handover Interface 1—Administrative interface between the LEA and the service provider mediation device.
The LEA sends provisioning information to the mediation device on this interface.
HI-2 Handover Interface 2—Intercept-related information interface between the LEA and the mediation device
that is used to deliver intercept-related events to the LEA. These events can be subscriber session events
such as login, logout, and authentication.
HI-3 Handover Interface 3—Intercepted content Interface between the mediation device and LEA that is used
to deliver intercepted content to the LEA.
INI-1 Internal network Interface 1—Interface used to send intercept provisioning information from the mediation
device to the RADIUS server.
INI-2 Internal network interface 2—Interface used to send intercept-related events from the router to the
mediation device. This information is sent in SNMP traps.
INI-3 Internal network interface 3—Interface used to send intercepted content from the router to the mediation
device.
Documentation

RADIUS-Initiated Traffic Mirroring Process at Subscriber Login
Figure 27 on page 388 shows the process for a RADIUS-initiated subscriber mirroring
operation that is initiated when the mirrored subscriber logs in.
Figure 27: RADIUS-Initiated Subscriber Secure Policy Model at Login
Handover
Access-Accept RADIUS INI-1 HI-1

3 server 1
4 2
7 Mediation 8
INI-2 Device HI-2
9 10
5 INI-3 HI-3 Law
Access 6 Agency
Point
Destination
Service Law
g017566
Domain Domain
1— The LEA sends provisioning information for 6—The IAP sends the original subscriber traffic
a subscriber whose traffic is to be mirrored to its intended destination.
over the HI-1 interface to the mediation
device.
2— The mediation device sends the provisioning 7— As subscriber-related events occur, the IAP
information over the INI-1 interface to the sends the events in SNMP traps over the
RADIUS server. INI-2 interface to the mediation device.
3— The subscriber logs in, requesting 8—The mediation device provides the events
authentication by the RADIUS server. over the HI-2 interface to the LEA.
4— The RADIUS server authenticates the 9—The IAP encapsulates the mirrored content
subscriber and sends an Access-Accept in a packet header and sends it over the
message containing mirroring-related INI-3 interface to the mediation device. The
RADIUS attributes in Juniper Networks VSAs IAP uses the destination IP address of the
to the IAP (the router). mediation device that it received in the
Access-Accept messaged from the RADIUS
server.
5— The IAP creates a subscriber secure policy 10—The mediation device sends mirrored
based on the mirroring VSAs and begins content over the HI-3 interface to the LEA.
mirroring the subscriber’s traffic.
Documentation

RADIUS-Initiated Traffic Mirroring Process for Logged-In Subscribers
Figure 28 on page 389 shows the process for a RADIUS-initiated subscriber mirroring
operation that is initiated after the subscriber has logged in.
Figure 28: RADIUS-Initiated Subscriber Secure Policy Model After Login

Handover
CoA-Request RADIUS INI-1

server
1 4 3 HI-1 2
7 Mediation 8
INI-2 Device HI-2
9 10
5 INI-3 HI-3 Law
Access 6 Agency
Point
Destination
Service Law
g017574
Domain Domain
1— The subscriber logs in, requesting 6—The IAP sends the original subscriber traffic
authentication by the RADIUS server. The to its intended destination.
RADIUS server authenticates the subscriber
(no mirroring activity occurs).
2— The LEA sends provisioning information for 7— As subscriber-related events occur, the IAP
a subscriber whose traffic is to be mirrored sends the events in SNMP traps over the
over the HI-1 interface to the mediation INI-2 interface to the mediation device.
device.
3— The mediation device sends the provisioning 8—The mediation device provides events over
information over the INI-1 interface to the the HI-2 interface to the LEA.
RADIUS server.
4— The RADIUS server sends a CoA message 9—The IAP encapsulates the mirrored
containing the mirroring-related RADIUS subscriber content in a packet header and
attributes and VSAs to the IAP (the router). sends it to the mediation device over the
INI-3 interface. The IAP uses the destination
IP address that it received in the
Access-Accept messaged from the RADIUS
server.
5— The RADIUS CoA message initiates the 10—The mediation device sends mirrored
mirroring operation. The IAP creates the content over the HI-3 interface to the LEA.
subscriber secure policy based on the
mirroring VSAs and immediately begins
mirroring subscriber traffic.
Documentation

Configuring Tunnel Interfaces for Subscriber Secure Policy Mirroring
The router, acting as the IAP, uses tunnel interfaces (vt interfaces) to send mirrored traffic
to the mediation device. The IAP equally distributes the mirrored traffic across the
available tunnel interfaces.
Because the MX Series 3D Universal Edge Routers do not support Tunnel Services PICs,
you create a pool tunnel interfaces on MX Series routers at the [edit chassis] hierarchy
level.
You can configure up to 2048 mirrored subscriber sessions per chassis.
To configure a pool of tunnel interfaces for use by subscriber secure policy mirroring:
1. Access the chassis configuration, and specify the slot number of the DPC, MPC, or
MIC.
• On the MX80 router, the range is 0 through 1.
• On other MX Series routers, if two System Control Boards (SCBs), are installed, the
range is 0 through 11. If three SCBs are installed, the range is 0 through 5 and 7
through 11.
[edit chassis]
user@host# edit fpc 1
2. Configure the PIC number of the FPC.
• On MX80 routers, if the FPC is 0, the PIC number can only be 0. If the FPC is 1, the
PIC range is 0 through 3.
• For all other MX Series routers, the range is 0 through 3.
[edit chassis fpc 1]

user@host# edit pic 1
3. Specify that the FPC and PIC are to be used for tunnel interfaces.
[edit chassis fpc 1 pic 1]

user@host# edit tunnel-services
4. Specify the amount of bandwidth to reserve for tunnel traffic on each Packet
Forwarding Engine.
• 1g indicates that 1 Gbps of bandwidth is reserved for tunnel traffic.
• 10g indicates that 10 Gbps of bandwidth is reserved for tunnel traffic.
If you specify a bandwidth that is not compatible, tunnel services are not activated.
For example, you cannot specify a bandwidth of 1 Gbps for a Packet Forwarding Engine
on a 10-Gigabit Ethernet 4-port DPC.
[edit chassis fpc 1 pic 1 tunnel-services]

user@host#
user@host# set bandwidth 1g
5. Configure the tunnel interfaces, including the family.

To configure subscriber secure policy mirroring for IPv6 traffic, configure the tunnel
interfaces for both the inet and inet6 families.
[edit interfaces]
user@host# set vt-1/1/0 unit 0 family inet
user@host# set vt-1/1/0 unit 0 family inet6
Related • Configuring RADIUS-Initiated Subscriber Secure Policy Mirroring Overview on page 382
Documentation
• Subscriber Secure Policy and L2TP LNS Subscribers on page 379

RADIUS Attributes Used for Subscriber Secure Policy
Table 43 on page 392 lists the RADIUS VSAs that are associated with subscriber secure
policy. If these VSAs are present in the RADIUS Access-Accept message for a subscriber,
the action specified in the LI-Action attribute takes effect.
Mirroring VSAs that the RADIUS server sends to the router are salt-encrypted. Salt
encryption is a random string of data used to modify a password hash.
Table 43: RADIUS-Based Mirroring Attributes

Attribute Number Attribute Name Description Value
[26-58] LI-Action Traffic mirroring Salt-encrypted

action integer
• 0 = stop mirroring
• 1 = start mirroring
• 2 = no action
[26-59] Med-Dev-Handle Identifier that Salt-encrypted string

associates mirrored
traffic with a specific
subscriber
Med-Dev-Handle
includes:
• Intercept-Identifier
• Acct-Session-ID
(optional)
[26-60] Med-Ip-Address IP address of Salt-encrypted IP

mediation device to address
which mirrored traffic
is forwarded
[26-61] Med-Port-Number UDP port in the Salt-encrypted

mediation device to integer
which mirrored traffic
is forwarded
NOTE: CoA-Request messages that include any of the RADIUS-based

mirroring attributes (VSAs 26–58, 26–59, 26–60, or 26–61) must always
include all four VSAs. If the CoA action is to stop mirroring (VSA 26–58 value
is 0), then the values of the other three attributes in the CoA message must
match the existing attribute values, or the action fails.
If a subscriber is already logged in, Table 44 on page 393 lists the RADIUS attributes that
can be present in RADIUS CoA messages to identify the subscriber whose traffic is to
have a mirroring action applied (activation or deactivation).

Table 44: RADIUS Attributes Used in CoA Messages to Identify Subscribers

for Traffic Mirroring
Attribute Number Attribute Name
[1] User-Name
[44] Acct-Session-ID
Triggering Subscriber Secure Policy for Subscribers on Dynamic Authenticated VLANs
BEST PRACTICE: When you have DHCPv4/DHCPv6 subscribers over VLANs,

two sessions are created for each subscriber—one for the Layer 2 VLAN, and
one for DHCP. In this case, we recommend that you use one trigger that
matches both the DHCP and the VLAN session.
If authentication is performed on both the VLAN session and the DHCP

session, we recommend that you use a separate, unique username for the
VLAN and DHCP sessions to allow RADIUS to distinguish on which of the
sessions to trigger subscriber secure policy traffic mirroring. Otherwise, when
the DHCP session is authenticated and activated, traffic mirroring fails.

Documentation
Terminating RADIUS-Initiated Subscriber Traffic Mirroring
You can terminate RADIUS-initiated traffic mirroring sessions by the following action:
• RADIUS CoA message receipt—Terminated upon receipt of a CoA message with the
VSA 26-58 (LI-Action) value of 0. The RADIUS administrator configures the LI-Action
of 0 in the mirrored subscriber’s RADIUS record.

Documentation


CHAPTER 36

Support for IPv4 Multicast Traffic
• Subscriber Secure Policy Support for IPv4 Multicast Traffic on page 395
• Enabling Subscriber Secure Policy Mirroring for IPv4 Multicast Traffic on page 396
Subscriber Secure Policy Support for IPv4 Multicast Traffic
IP multicast traffic is used for applications such as audio or video streaming, IPTV, video
conferencing, or online gaming. Multicast traffic is sent to multiple subscribers who have
joined a multicast group.
Secure subscriber policy allows for the mirroring of IPv4 multicast traffic sent to a specific
subscriber. If multiple subscribers whose traffic requires mirroring join the same multicast
session, the subscriber secure policy feature mirrors each subscriber’s traffic and forwards
it separately to the mediation device with the proper prepended header.
Mirroring of multicast traffic is supported only for subscribers in the default logical system.
You can enable and disable the mirroring of multicast traffic on a per-chassis basis. You
cannot enable or disable it on a per-subscriber basis.
Triggering the Mirroring of IPv4 Multicast Traffic

Multicast traffic being sent towards a subscriber does not contain much of the identifying
information used to trigger mirroring of a subscriber’s unicast traffic. For example, the
multicast packet contains the multicast group address in the destination address of the
packet instead of the subscriber’s IP address. It also does not contain the user name or
MAC address of the subscriber, and does not include information obtained by RADIUS
or DHCP. Therefore, methods of identifying multicast traffic that is received by a subscriber
are not the same as methods of identifying a subscriber’s unicast traffic or multicast
traffic that is sent by a subscriber.
To join a multicast group, a subscriber sends an IGMP join request, and it receives a reply.
The reply contains the multicast groups to which the subscriber is registered. Triggering
the mirroring of multicast traffic is based on the sending of the IGMP join request and the
information in the IGMP reply. If the subscriber’s unicast traffic is already being mirrored
either through DTCP-initiated or RADIUS-initiated traffic mirroring, and the subscriber

sends an IGMP join request, mirroring of multicast traffic sent to the subscriber is initiated.
The traffic being mirrored is based on the groups contained in the IGMP reply.
Related • Enabling Subscriber Secure Policy Mirroring for IPv4 Multicast Traffic on page 396
Documentation
Enabling Subscriber Secure Policy Mirroring for IPv4 Multicast Traffic
This topic describes the steps to enable subscriber secure policy mirroring of IPv4 multicast
traffic. You can enable and disable IPv4 multicast intercept on a per chassis basis.
To configure the radius-flow-tap service to support subscriber secure policy mirroring:
1. Configure the flow-tap service used for subscriber secure policy mirroring.
[edit services]
2. Enable the interception of multicast traffic.

user@host# set multicast-interception
Related • Subscriber Secure Policy Support for IPv4 Multicast Traffic on page 395
Documentation

CHAPTER 37
Configuring DTCP-Initiated Subscriber

Secure Policy Traffic Mirroring

• Example: Configuring Traffic That Is Mirrored Using DTCP-Initiated Subscriber Secure
Policy on page 399
• Subscriber Secure Policy Traffic Mirroring Architecture Using DTCP on page 400
• DTCP-Initiated Traffic Mirroring Interfaces on page 402
• DTCP-Initiated Traffic Mirroring Process on page 404
• DTCP Messages Used for Subscriber Secure Policy on page 405
• DTCP Traffic Mirroring Triggers on page 405
• Terminating DTCP-Initiated Subscriber Traffic Mirroring Sessions on page 408
DTCP-Initiated Subscriber Secure Policy Overview
Dynamic Tasking Control Protocol (DTCP)-initiated mirroring creates secure policies to

mirror traffic for the subscriber based on DTCP messages. The attributes in a DTCP ADD
message trigger the router to start mirroring traffic and specify the interface on which
the mirroring takes place. The mirroring operations can be initiated by DTCP messages
as follows:
• Subscriber login—Mirroring starts on the specified interface when the subscriber logs
in. The DTCP ADD message must be sent to the router before the subscriber logs in.
• In-session—Mirroring starts for all subscribers that match the trigger supplied in the
DTCP ADD message when the router receives a DTCP ADD message.
Related • Subscriber Secure Policy Traffic Mirroring Architecture Using DTCP on page 400
Documentation

Configuring DTCP-Initiated Subscriber Secure Policy Mirroring Overview
Before you configure subscriber secure policy traffic mirroring, note the following:
• Subscriber secure policy mirroring runs on the radius-flow-tap service infrastructure.

To configure the subscriber secure policy service, you need the same privileges that
are required to configure the radius-flow-tap service.
• The subscriber secure policy feature requires some system resources while mirroring,
encrypting, and sending traffic to the mediation device. For example, you might elect
to use a 10-Gigabit Ethernet interface for the tunnel and mediation device if you expect
the amount of traffic you plan to mirror to approach 1 Gbps of actual user data.
To configure DTCP-initiated subscriber secure policy service:
1. Configure tunnel interfaces that are used to send mirrored content to the mediation
device.
See “Configuring Tunnel Interfaces for Subscriber Secure Policy Mirroring” on page 390.
2. Configure the radius-flow-tap service support for secure subscriber policy. This support
includes configuring the tunnels and optional forwarding-class information that the
subscriber secure policy service uses to send mirrored traffic to the content destination
device.
See “Configuring Support for Subscriber Secure Policy Mirroring” on page 376.
3. Configure the mediation device as a user on the router. This user account allows the
router to receive DTCP messages from the mediation device.
See “Configuring the Mediation Device as a User on the Router” on page 420.
4. Configure the mediation device to provision traffic mirroring on the router.
See “Configuring the Mediation Device to Provision Traffic Mirroring” on page 421.
5. Configure a DTCP-over-SSH connection to the mediation device.
See “Configuring a DTCP-over-SSH Connection to the Mediation Device” on page 421.
6. (Optional) Enable mirroring of IPv4 multicast traffic on the router.
See “Enabling Subscriber Secure Policy Mirroring for IPv4 Multicast Traffic” on page 396
7. Configure SNMPv3 trap support to report mirroring information to an external device.
See “Configuring SNMPv3 Traps for Subscriber Secure Policy Mirroring” on page 411.
You can terminate an active subscriber mirroring session at any time.
See “Terminating DTCP-Initiated Subscriber Traffic Mirroring Sessions” on page 408.
Related • DTCP-Initiated Subscriber Secure Policy Overview on page 397

Documentation

Chapter 37: Configuring DTCP-Initiated Subscriber Secure Policy Traffic Mirroring
Example: Configuring Traffic That Is Mirrored Using DTCP-Initiated Subscriber Secure

Policy
This example shows how to configure traffic that is mirrored using DTCP-initiated
subscriber secure policy.

Requirements
• Juniper Networks MX Series routers.
• Junos OS Release 12.3R1 or later.
Overview
This example drops all video on demand TCP traffic from subnet 10.0.0.0/8 to any
subscriber on which the policy named vod is enabled.
To configure traffic mirroring using DTCP-initiated subscriber secure policy:
1. Create a policy.
2. Set up the policy to filter IPv4 or IPv6 traffic by source or destination address, or port,
protocol, or DSCP value.
3. Apply the policy using the DTCP attribute X-Drop-Policy.
4. Use the X-Drop-Policy with the ADD DTCP command to begin filtering traffic when
mirroring is triggered.
NOTE: To begin filtering traffic that is currently being mirrored, use the
X-Drop-Policy attribute with the new ENABLE DTCP command. To stop
filtering traffic that is currently being mirrored, use the X-Drop-Policy attribute
with the new DISABLE DTCP command.
Configuration
Step-by-Step To configure filtering mirrored traffic before it is sent to a mediation device:
Procedure
1. Specify that you want to configure radius-flow-tap.
[edit services]
2. Specify that you want to configure a video on demand policy.

user@host# edit policy vod

3. Specify inet as the family that you want to use.
[edit services radius-flow-tap vod]

user@host# edit inet
4. Specify t1 as the term name for the IPv4 drop-policy.
[edit services radius-flow-tap vod inet]

user@host# edit drop-policy t1
5. Specify the source address for the drop-policy.
[edit services radius-flow-tap vod inet drop-policy t1]

user@host# edit source-address 10.0.0.0/8
6. Specify the match criteria that you want to use.
[edit services radius-flow-tap vod inet drop-policy t1]

user@host# set protocol tcp
Results From configuration mode, confirm your configuration by entering the show services
instructions in this example to correct it.
[edit services radius-flow-tap policy]

vod {
inet {
drop-policy t1 {
from{
source-address {
10.0.0.0/8;
}
protocol tcp;
}
}
}

Documentation
Subscriber Secure Policy Traffic Mirroring Architecture Using DTCP
Figure 29 on page 401 shows the architecture of the DTCP-initiated subscriber secure
policy mirroring environment.

Figure 29: DTCP-Initiated Subscriber Secure Policy Architecture
Provisioning Provisioning
Events Mediation Events

Device
Content Content
Intercept
Access Law
Point Enforcement
Agency
Service Law
g017563
Domain Domain
Table 45 on page 401 describes the functions and components of a DTCP-initiated

subscriber secure policy traffic mirroring environment.

Components
Function or
Component Description
Collection The collection function is responsible for collecting intercepted content and
function identifying information from the delivery function.
The collection function is the responsibility of the law-enforcement agency

(LEA).
Delivery function The delivery function delivers information that it receives from the access
function to the collection function.
The delivery function is performed by the mediation device.
Access function The access function has access to the intercept target’s traffic content and
intercept-related events. It is responsible for collecting this information and
sending it to the delivery function.
The access function is performed by intercept access points (IAPs).
Events Intercept-related events, such as login or logout events or mirroring session

activation or deactivation. The router sends the events to the mediation device
in SNMP traps.
LEA Law enforcement agency. The LEA provides intercept targets to the service
provider who provisions the mediation device.


Components (continued)
Function or
Component Description
Mediation device The mediation device receives provisioning information from the LEA, and it
uses the information to send provisioning information to the IAP (the router).
The mediation device also receives intercept-related events and intercepted

content from the router, and delivers the events and content to the LEA.
IAP Intercept access point. In a subscriber access network the Juniper Networks
router is the IAP.
Using subscriber secure policies, the IAP intercepts traffic to and from the
subscriber whose traffic is being mirrored. It encapsulates the intercepted
content in a packet header and delivers it to the mediation device, while also
sending the traffic to the intended destination.
The IAP also sends intercept-related events to the mediation device using
SNMP traps.

Documentation
DTCP-Initiated Traffic Mirroring Interfaces
Figure 30 on page 402 shows the interfaces involved in DTCP-initiated secure subscriber
Figure 30: DTCP-Initiated Traffic Mirroring Interfaces
Handover
INI-1 HI-1
Mediation HI-2
INI-2 Device IRI
INI-3 HI-3 Law
Access Agency
Point
Destination
Service Law
g017577
Domain Domain

Table 46 on page 403 describes the interfaces involved in DTCP-initiated secure subscriber
Table 46: DTCP-Initiated Traffic Mirroring Interfaces

Interface Description
HI-1 Handover Interface 1—Administrative interface between the LEA and the service provider mediation device.
The LEA sends provisioning information to the mediation device on this interface.
HI-2 Handover Interface 2—Intercept-related information interface between the LEA and the mediation device
that is used to deliver intercept-related events to the LEA. These events can be subscriber session events
such as login, logout, and authentication.
HI-3 Handover Interface 3—Intercepted content Interface between the mediation device and LEA that is used
to deliver intercepted content to the LEA.
INI-1 Internal network Interface 1—Interface used to send DTCP messages containing intercept provisioning
information from the mediation device to the router.
INI-2 Internal network interface 2—Interface used to send intercept-related events from the router to the mediation
device. This information is sent in SNMP traps.
INI-3 Internal network interface 3—Interface used to send intercepted content from the router to the mediation
device.
Documentation

DTCP-Initiated Traffic Mirroring Process
Figure 31 on page 404 shows the process for a DTCP-initiated subscriber mirroring operation.
Figure 31: DTCP-Initiated Subscriber Secure Policy Model
Handover
DTCP-over-SSH HI-1
2 1
INI-1 HI-2
5 Mediation 6
INI-2 Device HI-3
7 8
3 INI-3 Law
4 Agency
Access
Point
Destination
Service Law
g017565
Domain Domain
1— The LEA sends provisioning information for 5— As intercept-related events occur, the IAP
a subscriber whose traffic is to be mirrored sends the events in SNMP traps over the
over the HI-1 interface to the mediation INI-2 interface to the mediation device.
device.
2— The mediation device sends a DTCP ADD 6—The mediation device provides the
message that contains provisioning intercept-related events over the HI-2
information over the INI-1 interface to the interface to the LEA.
IAP (the router).
3— The IAP creates a subscriber secure policy 7— The IAP sends the mirrored content to the
based on information in the DTCP ADD mediation device over the INI-3 interface.
message. If the IAP receives the DTCP ADD
before the subscriber logs in, mirroring
begins when the subscriber logs in. If the
router receives the DTCP ADD after the
subscriber logs in, mirroring begins when the
ADD message is received.
4— The IAP sends the original subscriber traffic 8—The mediation device sends mirrored
to its intended destination. content over the HI-3 interface to the LEA.
Documentation

DTCP Messages Used for Subscriber Secure Policy
You can use DTCP to provision traffic mirroring on the router by sending DTCP messages
from the mediation device to the router.
There are three types of DTCP messages:
• ADD—Triggers mirroring of subscriber secure policy sessions. You include an attribute

that triggers the router to begin mirroring a subscriber session. You can also include
attributes that identify where to send the mirrored session data and how to uniquely
identify traffic when simultaneous intercepts are active. The ADD message also provides
instructions to populate fields in the encapsulation header for packets sent to the
mediation device.
• LIST—Requests information about sessions that are currently being mirrored. This
information is returned in a LIST response.
• DELETE—Removes a subscriber mirroring trigger or can be used to disable all mirroring.
Related • DTCP-Initiated Traffic Mirroring Process on page 404

Documentation
• ADD DTCP on page 428
• DELETE DTCP on page 431
• LIST DTCP on page 435
DTCP Traffic Mirroring Triggers
Table 47 on page 405 lists the DTCP attributes that you can use in DTCP ADD messages
to trigger traffic mirroring.
Table 47: DTCP Mirroring Triggers for Use in ADD Messages

Attribute Name DTCP Message Semantic Description
Account Session ID X-Act-Sess-Id Trigger that is based on the

text string of the Account
Session ID associated with the
subscriber session.
If the subscriber logs out, the

intercept terminates. We
recommend that you use other
triggers to ensure that all
sessions for a subscriber are
intercepted.

Table 47: DTCP Mirroring Triggers for Use in ADD Messages (continued)
Calling Station ID X-Call-Sta-Id Trigger that is based on the

text string of the Calling
Station ID associated with the
subscriber.
If the subscriber is not logged

on, the policy is applied at any
current or subsequent
subscriber log in.
IP Address X-IP-Addr Trigger for the IPv4 address

that is associated with a
subscriber.
If you use the IP Address

trigger, and the subscriber is
not using the default logical
system, you must include the
Logical System attribute in
your DTCP message. If the
subscriber is not using the
default routing instance, you
must include the Routing
Instance attribute in your
DTCP message.
Interface Identifier X-Interface-Id Trigger for subscribers that are

configured to use a specific
router interface. All subscribers
that use the interface have
their traffic mirrored.
Add this attribute as a text

string that identifies the
physical interface; for
example, ge-0/0/0.1 or
demux0.107472834.
NAS Port ID X-NAS-Port-Id Trigger that is based on the

NAS port ID of the subscriber.
Remote Circuit ID X-RM-Circuit-Id For DHCP subscribers, trigger

that is used with the Remote
Agent ID to specify the DHCP
option 82 that is associated
with this session to completely
specify a trigger.
For PPPoE subscribers, agent

circuit ID (ACI) in the PPPoE
Intermediate Agent (PPPoE
IA) tag.

Table 47: DTCP Mirroring Triggers for Use in ADD Messages (continued)
Remote Agent ID X-RM-Agent-Id For DHCP subscribers, trigger

that is used with the Remote
Circuit ID to specify the session
or by itself to completely
specify the trigger.
For PPPoE subscribers, agent

remote identifier (ARI) in the
PPPoE Intermediate Agent
(PPPoE IA) tag.
Logical System X-Logical-System Trigger attribute that you can

use with the IP Address or
Subscriber User Name triggers.
It is ignored for other triggers.
The value default is used if no

logical system exists for the
subscriber.
Routing Instance X-Router-Instance Trigger attribute that you can

use with the IP Address or
Subscriber User Name triggers.
It is ignored for other triggers.
The value default is used if no

routing instance exists for the
subscriber.
Subscriber User Name X-UserName Trigger based on a subscriber

username.
If you use the Subscriber User

Name trigger, and the
subscriber is not using the
default logical system, you
must include the Logical
System attribute in your DTCP
message. If the subscriber is
not using the default routing
instance, you must include the
Routing Instance attribute in
your DTCP message.
Triggering Subscriber Secure Policy for Subscribers on Dynamic Authenticated VLANs
BEST PRACTICE: When you have DHCPv4/DHCPv6 subscribers over VLANs,

two sessions are created for each subscriber—one for the Layer 2 VLAN, and
one for DHCP. In this case do not use a trigger, such as Remote Circuit ID
(ACI), that applies to both the VLAN and the DHCP sessions. If the DHCP and
VLAN sessions match the same trigger, the DHCP subscriber login fails and

subscriber secure policy is not triggered. You need to select a traffic mirroring
trigger that matches only one of these sessions.
Order in Which Trigger Attributes Are Processed

If a subscriber matches more than one of the DTCP mirroring triggers, the router processes
mirroring triggers in ADD messages in the following order:
1. Account Session ID
2. Calling Station ID
3. IP Address
4. Interface Identifier
5. NAS Port ID
6. Remote Agent ID
7. Subscriber User Name
8. Drop Policy Name
Related • Packet Header for Mirrored Traffic Sent to Mediation Device on page 418
Documentation
• Example: Using DTCP Messages to Trigger, Verify, and Disable Traffic Mirroring for
Terminating DTCP-Initiated Subscriber Traffic Mirroring Sessions
You can terminate DTCP-initiated traffic mirroring sessions by the following action:
• DTCP DELETE message receipt—Terminated upon receipt of a DTCP DELETE message.

The DTCP administrator configures the DELETE message to include the same mirroring
attributes that are used in the ADD message to initiate mirroring.
Related • DELETE DTCP on page 431

Documentation

CHAPTER 38
Configuring Intercept-Related Information

for Subscriber Secure Policy

• SNMP Traps for Subscriber Secure Policy LAES Compliance on page 409
• Configuring SNMPv3 Traps for Subscriber Secure Policy Mirroring on page 411
• Example: SNMPv3 Traps Configuration for Subscriber Secure Policy Mirroring on page 411
Intercept-Related Events Transmitted to the Mediation Device
You can use SNMPv3 traps to report intercept-related events to the mediation device.
These events include identifying information for subscribers, such as username or IP
address, and subscriber session events, such as login or logout events or mirroring session
activation or deactivation. The router sends the events to the mediation device in SNMP
traps. Using SNMPv3 provides secure traps that are visible only to authorized individuals
on the intended secure mediation device. The traps help support compliance with the
Communications Assistance for Law Enforcement Act (CALEA), which defines electronic
surveillance guidelines for telecommunications companies.
The supported SNMPv3 traps map to messages defined by the Lawfully Authorized
Electronic Surveillance (LAES) for IP Network Access, American Nation Standard For
Telecommunications. “SNMP Traps for Subscriber Secure Policy LAES Compliance” on
page 409 describes the supported SNMPv3 traps and their related LAES messages.

Documentation
SNMP Traps for Subscriber Secure Policy LAES Compliance
Table 48 on page 410 describes the SNMPv3 traps that subscriber secure policy mirroring
uses to provide information that maps to messages defined in the Lawfully Authorized
Electronic Surveillance (LAES) for IP Network Access, American National Standard for

Telecommunications. These messages enable subscriber secure policy to comply with

the Communications Assistance for Law Enforcement Act (CALEA). The Juniper Packet
Mirroring MIB, jnx-js-packet-mirror.mib, provides the SNMP trap.
Table 48: Subscriber Secure Policy SNMPv3 Traps for LAES Messages
SNMPv3 Trap LAES Message Description
jnxPacketMirrorLiSubscriberLoggedIn • access-attempt (implied) A subscriber, who is identified to

• access-session-accept have a mirrored service that is
activated at login, has
• packet-data-session-start
successfully logged in.
jnxPacketMirrorSessionLiSubscriberLogInFailed • access-attempt (implied) A subscriber, who is identified to

• access-failed (all termination reasons have a mirrored service that is
except authentication-reject) activated at login, has failed to
log in.
• access-reject (termination reason is
authentication-reject)
jnxPacketMirrorInterfaceLiSubscriberLoggedOut • access-session-end A subscriber, who had an active

• packet-data-session-end mirrored service, has logged out.
jnxPacketMirrorInterfaceLiServiceActivated • packet-data-session-already-established A mirrored session has been

activated.
jnxPacketMirrorSessionLiServiceActivationFailed – A mirrored session for a

subscriber has failed.
jnxPacketMirrorSessionLiServiceDeactivated – A mirrored session for an

established subscriber has been
deactivated.
jnxPacketMirrorMirroringFailure – A mirrored service request failed

due to an invalid value in the
request.
Note: This trap is not related to

LAES messages.
jnxPacketMirrorTriggerType – The type of trigger that caused

the mirroring session to be
activated.
jnxPacketMirrorCallingStationIdentifier – The calling station ID of the

subscriber whose traffic is
currently being mirrored.
jnxPacketMirrorNasIdentifier – The NAS ID of the session in

which traffic is being mirrored.
jnxPacketMirrorTargetIPv6Address – The IPv6 address of the

subscriber interface that is being
mirrored.

Chapter 38: Configuring Intercept-Related Information for Subscriber Secure Policy
Related • Intercept-Related Events Transmitted to the Mediation Device on page 409

Documentation
Configuring SNMPv3 Traps for Subscriber Secure Policy Mirroring
This topic provides an overview of the SNMPv3 configuration process as it pertains to

subscriber secure policy.
To configure SNMPv3 trap support for subscriber secure policy and to send the trap
information to the mediation device:
1. Configure the MIB view.
See Configuring MIB Views.
2. Configure the trap notification and trap notification filter. See the following topics:
• Configuring the SNMPv3 Trap Notification
• Configuring the Trap Notification Filter
3. Configure the target device. The target device is the mediation device that receives
the trap information.
See Configuring SNMPv3 Traps on a Device Running Junos OS.
4. Configure the SNMPv3 user, authentication method and password, and privacy method
and password. See the following topics:
• Creating SNMPv3 Users
• Configuring the SNMPv3 Authentication Type
• Configuring the SNMPv3 Encryption Type
5. Configure user access privileges to management information.
See Defining Access Privileges for an SNMP Group.
Related • SNMPv3 Overview

Documentation
Example: SNMPv3 Traps Configuration for Subscriber Secure Policy Mirroring
This example shows an SNMP configuration that provides SNMPv3 trap support.
Configure the SNMPv3 trap support at the [edit snmp] hierarchy level.
[edit snmp]
v3 {
usm {

local-engine {
user mediation-device1 { ## Name of the mediation device
authentication-md5 {
authentication-key "yourAuthentictaionKey"; ## SECRET-DATA
}
privacy-des {
privacy-key "YourPrivacyKey"; ## SECRET-DATA
}
}
}
}
target-address london-1 {
address 172.19.87.240; ## Address of the mediation device receiving the traps
port 162;
tag-list mediation-8;
target-parameters tp1;
}
target-parameters tpi {
parameters {
message-processing-model v3;
security-model usm;
security-level authentication;
security-name mediation-device1; ## Name of the mediation device
}
notify-filter nf1;
}
notify n1 {
type trap;
tag mediation-8;
}
notify-filter nf1 {
oid .1 include;
}
}
view system {
oid 1.3.6.1.2.1.1 include;
}
view all {
oid .1 include;
}

Documentation
• Configuring SNMPv3 Traps for Subscriber Secure Policy Mirroring on page 411
• SNMPv3 Overview

CHAPTER 39
Configuring the Mediation Device for

Subscriber Secure Policy
• Using the Packet Header to Track Subscribers on the Mediation Device on page 413
• Packet Header for Mirrored Traffic Sent to Mediation Device on page 418
• Configuring the Mediation Device as a User on the Router on page 420
• Configuring the Mediation Device to Provision Traffic Mirroring on page 421
• Configuring a DTCP-over-SSH Connection to the Mediation Device on page 421
Using the Packet Header to Track Subscribers on the Mediation Device
When the router sends mirrored traffic to the mediation device, it encapsulates it in a
packet header. Figure 32 on page 413 is the mirrored packet header and payload that the
router sends to the mediation device.
Figure 32: Mirrored Packet Header and Payload
g017764
Table 49 on page 414 describes the fields in the packet header of mirrored packets.

Mediation Device
Field Value Length (Bits)
IP Header
Version 4 4
IHL 5 4
Type of Service 0 8
Total Length Dynamically computed 16
Identification Dynamically computed 16
Flags Dynamically computed 3
Fragment Offset Dynamically computed 13
Time to Live 255 8
Protocol 17 8
Header Checksum Dynamically computed 16
Source Address IP address of the router 32

interface that sends mirrored
traffic to the mediation
device
Destination Address IP address of the mediation 32

device to which mirrored
traffic is forwarded (VSA
26-60)
UDP Header
Source Port UDP port number on the 16

router from which mirrored
traffic is sent to the
mediation device
Destination Port UDP port on the mediation 16

traffic is forwarded (VSA
26-61)
Length Dynamically computed 16
Checksum 0 16

Chapter 39: Configuring the Mediation Device for Subscriber Secure Policy
Mediation Device (continued)
Mirror Header
V (mirror header value) 0 2
Intercept ID See “Format of the Mirror 30

Header Values Used to Track
Subscribers and Subscriber
Sessions” on page 416 for
details
Session-ID See “Format of the Mirror 32

Header Values Used to Track
Subscribers and Subscriber
Sessions” on page 416 for
details

Format of the Mirror Header Values Used to Track Subscribers and Subscriber Sessions
The packet header includes mirror header attributes that the mediation device can use
to track subscribers and subscriber sessions. The router creates values for these attributes
based on information that it receives from RADIUS. There are three mirror header
attributes in the packet header:
• V (mirror header value)—Used by the router to specify how the values of the Session
ID and Intercept ID are determined. The value received from RADIUS can be a 0 or a 1.
However, the value is always 0 in the packet header sent to the mediation device.
• Session ID—Used by the mediation device to identify the session of the mirrored
subscriber. The value is assigned to a subscriber session by the Junos OS. The Session
ID changes with each new session for a subscriber.
• Intercept ID—Used along with the Session ID by the mediation device to track a
subscriber across multiple login and logout events. The value is assigned to a subscriber
whose traffic is being intercepted. The Intercept ID is constant; it does not change as
a subscriber logs in and logs out of sessions.
The values of the Intercept ID and the Session ID are determined by the value that the
router receives in VSA 26-59. VSA 26-59 is declared as a hexadecimal string that can
be either 4 bytes or 8 bytes long. The mirror header value specifies whether a 4-byte
value or an 8-byte value is used to form the Intercept ID and the Session ID.
4-Byte Format
The 4-byte format allows you to manually specify the Intercept ID. The Session ID value
is automatically created based on the least significant 32 bits of the Acct-Session-ID
(RADIUS attribute 44).
To use the 4-byte format of VSA 26-59, you configure the first two most significant bits
of the VSA to a value of 1, which indicates a single word in the VSA. The remaining 30
bits of the word form the Intercept ID value.
For example, a value of 40000010 for VSA 26-59 configures the following fields in the
mirror header, as shown in Figure 33 on page 416:
• V=1
• Intercept ID = 0x10
Figure 33: 4-Byte Format of VSA 26-59

g017766
8-Byte Format
The 8-byte format of VSA 26-59 enables you to manually specify the both the Session-ID
value and the Intercept ID value.

To use the 8-byte format, you configure the first two most significant bits of the first
word of the VSA to a value of 0, which indicates two words in the VSA. The remaining
30 bits of the first word form the Intercept ID value, and the second word is the Session-ID
field. You cannot change the order of these two words.
For example, a value of 0000030000000090 in VSA 26-59 configures the following

fields in the mirror header, as shown in Figure 34 on page 417:
• V=0
• Intercept-ID = 0x300
• Session-ID = 0x90
Figure 34: 8-Byte Format of VSA 26-59
g017765
Documentation

Packet Header for Mirrored Traffic Sent to Mediation Device
When the router sends mirrored traffic to the mediation device, it encapsulates the
mirrored payload in a packet header before it sends the mirrored traffic to the mediation
device.
Figure 35 on page 418 is the mirrored packet header that the router sends to the mediation
device.
Figure 35: Mirrored Packet Header
g017868
Table 50 on page 418 describes the fields in the packet header of mirrored packets.
Table 50: Packet Header Field Descriptions

IP Header
Version 4 4
IHL 5 4
Type of Service 0 8
Total Length Dynamically computed 16
Identification Dynamically computed 16
Flags Dynamically computed 3
Fragment Offset Dynamically computed 13

Table 50: Packet Header Field Descriptions (continued)

Time to Live 255 8
Protocol 17 8
Header Checksum Dynamically computed 16
Source Address IP address of the router 32

interface that sends mirrored
traffic to the mediation
device
Destination Address IP address of the mediation 32

traffic is forwarded. This
value is taken from the
X-JTap-Cdest-Dest-Address
attribute that is sent to the
router in the DTCP ADD
command.
UDP Header
Source Port UDP port number on the 16

router from which mirrored
traffic is sent to the
mediation device
Destination Port UDP port on the mediation 16

traffic is forwarded. This
value is taken from the
X-JTap-Cdest-Dest-Port
attribute that is sent to the
router in the DTCP ADD
command.
Length Dynamically computed 16
Checksum 0 16
Mirror Header
V (mirror header value) 0 2
Intercept ID Value of the 30

X-MD-Intercept-Id that is
sent to the router in the
DTCP ADD command.


Documentation
Configuring the Mediation Device as a User on the Router
In order for the router to receive DTCP messages from the mediation device, you need
to configure the mediation device as a user on the router. To do so, create a login class
that provides flow-tap operation permission and then create a login account that uses
the login class.
To configure the mediation device as a user on the router:
1. Create the login class and configure flow-tap-operation permissions for the class.
a. Specify that you want to configure login properties.
[edit system]
user@host# edit login
b. Create and name the class.
[edit system login]

user@host# edit class class-name
c. Configure the flow-tap-operation permission for the class.
[edit system login class class-name]

user@host# set permissions flow-tap-operation
2. Create the user login account for the mediation device.
a. Create the user account.
[edit system login]

user@host# edit user username
b. Configure the user ID.
[edit system login user username]

user@host# set uid uid-value
c. Configure the class for the user account.

user@host# set class class-name
d. Configure the authentication for the user account.

user@host# set authentication encrypted-password password

Configuring the Mediation Device to Provision Traffic Mirroring
To set up the mediation device to provision traffic mirroring on the router, use the following
DTCP messages:
• To configure traffic-mirroring triggers, use the ADD DTCP message.
• To remove an existing traffic-mirroring trigger, use the DELETE DTCP message.
• To show existing traffic-mirroring triggers, use the LIST DTCP message.
For an example of how to use the DTCP messages, see “Example: Using DTCP Messages
to Trigger, Verify, and Disable Traffic Mirroring for Subscribers” on page 423.
Related • Configuring DTCP-Initiated Subscriber Secure Policy Mirroring Overview on page 398
Documentation
Configuring a DTCP-over-SSH Connection to the Mediation Device
DTCP-initiated subscriber secure policy requires a DTCP-over-SSH connection for the

flow-tap service. This connection is used to send provisioning information from the
mediation device to the router.
To enable the DTCP-over-SSH flow-tap service to support subscriber secure policy

mirroring:
1. Access the flow-tap-dtcp service.
[edit system services]

user@host# edit flow-tap-dtcp
2. Enable SSH support for DTCP.
[edit system services flow-tap-dtcp]

user@host# set ssh
3. (Optional) Configure maximum number of established connections allowed for the

DTCP service.
[edit system services flow-tap-service ssh]

user@host# set connection-limit limit
4. (Optional) Configure the maximum number of connection attempts allowed per

minute for DTCP.
[edit system services flow-tap-service ssh]

user@host# set rate-limit limit
Related • Configuring DTCP-Initiated Subscriber Secure Policy Mirroring Overview on page 398
Documentation


CHAPTER 40
Monitoring and Managing DTCP Messages
• ADD DTCP
• DELETE DTCP
• DISABLE DTCP
• ENABLE DTCP
• LIST DTCP
Example: Using DTCP Messages to Trigger, Verify, and Disable Traffic Mirroring for
Subscribers
This example shows how to create DTCP messages to do the following:
• Trigger traffic mirroring for two subscribers based on interface ID.
• Trigger a drop policy if one does not already exist.
• Remove an existing drop policy.
• Verify that subscriber traffic on the two interfaces is being mirrored.
• Disable traffic mirroring on the two subscriber interfaces.
• Verify that traffic mirroring was stopped on the two subscriber interfaces.
In this example, SSH is being used to communicate with the router.
Creating DTCP ADD Messages to Trigger Traffic Mirroring

This section shows examples of DTCP ADD messages on a mediation device that use
the interface ID to trigger traffic mirroring on interfaces demux0.30010002 and
demux0.30010001.
ADD DTCP/0.7
Csource-ID: dtcp1
Cdest-ID: cd1
Priority: 2
X-JTap-Cdest-Dest-Address: 192.0.40.168
X-JTap-Cdest-Dest-Port: 65535
X-JTap-Cdest-Source-Address: 198.15.0.10
X-JTap-Cdest-Source-Port: 50000

X-JTap-Cdest-TTL: 64
X-Interface-Id: demux0.30010002 /*Used as trigger*/
X-MD-Intercept-Id: 0x0101010130010002
Flags: BOTH
Seq: 7
Authentication-Info: c16d2d9d1679facf0c4a66683af6114d341e4033
DTCP/0.7 200 OK
SEQ: 7
CRITERIA-ID: 2
TIMESTAMP: 2011-02-13 15:56:49.609
AUTHENTICATION-INFO: 4880de4b8cead98c95813fd9b95e240b107d4693
ADD DTCP/0.7
Csource-ID: dtcp1
Cdest-ID: cd1
Priority: 2
X-JTap-Cdest-TTL: 64
X-Interface-Id: demux0.30010001 /*Used as trigger*/
X-MD-Intercept-Id: 0x0101010130010001
Flags: STATIC
Seq: 8
Authentication-Info: dc3c55481a3810c7dd29fdc1b4681d978ff4e7c4
DTCP/0.7 200 OK
SEQ: 8
CRITERIA-ID: 3
TIMESTAMP: 2011-02-13 15:57:20.640
AUTHENTICATION-INFO: 4b31ef1311647e5ba52d2d5d4237b9e5beaa47b7
ADD DTCP/0.7
Csource-ID: ft-user1
Cdest-ID: cd1
Priority: 2
X-Username: testuser
X-MD-Intercept-Id: 55667789
Flags: STATIC
DTCP/0.7 200 OK
SEQ: 100
CRITERIA-ID: 1

Chapter 40: Monitoring and Managing DTCP Messages
Creating DTCP ENABLE Messages to Trigger Traffic Mirroring

This section shows an example of DTCP ENABLE messages on a mediation device that
use the interface ID to trigger traffic mirroring on interfaces demux0.30010002 and
demux0.30010001.
ENABLE DTCP/0.8
Cdest-ID: cd1
X-Drop-Policy: vod
Flags: STATIC
Creating DTCP DISABLE Messages to Trigger Traffic Mirroring

This section shows examples of DTCP DISABLE messages on a mediation device that
use the interface ID to trigger traffic mirroring on interfaces demux0.30010002 and
demux0.30010001. Whether you used DTCP ADD plus a policy or DTCP ADD and DTCP
ENABLE, you can turn the policy off with DTCP DISABLE.
DISABLE DTCP/0.8
Criteria-ID: 1
X-Drop-Policy: vod
Flags: STATIC
DISABLE DTCP/0.8
Cdest-ID: cd1
X-Drop-Policy: vod
Flags: STATIC
Using LIST Messages to Verify That Subscriber Traffic Is Being Mirrored

This section shows examples of a LIST message on the mediation device. The LIST
message requests information about the subscribers being mirrored. The information is
returned in a LIST response. The response shows that traffic for the two
interfaces—demux0.30010002 and demux0.30010001—is being mirrored.
LIST DTCP/0.7
Csource-ID: dtcp1
Cdest-ID: cd1
Seq: 9
Authentication-Info: f6dd64643021debb167ce2fb2d3c7b6622a87e09
DTCP/0.7 200 OK
SEQ: 9
TIMESTAMP: 2011-02-13 15:57:47.667
CRITERIA-ID: 2
CSOURCE-ID: dtcp1
CDEST-ID: cd1
CSOURCE-ADDRESS: 10.10.4.224
FLAGS: BOTH
X-JTAP-CDEST-DEST-ADDRESS: 192.0.40.168
X-JTAP-CDEST-DEST-PORT: 65535
X-JTAP-CDEST-SOURCE-ADDRESS: 198.15.0.10
X-JTAP-CDEST-SOURCE-PORT: 50000

X-JTAP-CDEST-TTL: 64
X-INTERFACE-ID: demux0.30010002 /*subscriber interface*/
X-MD-INTERCEPT-ID: 0x0101010130010002
CRITERIA-NUM: 1
CRITERIA-COUNT: 0
CRITERIA-ID: 3
CSOURCE-ID: dtcp1
CDEST-ID: cd1
FLAGS: BOTH
X-INTERFACE-ID: demux0.30010001 /*subscriber interface*/
CRITERIA-NUM: 2
CRITERIA-COUNT: 2
AUTHENTICATION-INFO: 361171ccb24dde6afe8ef66021287f9b8ac16028
Using DELETE Messages to Remove Traffic Mirroring Triggers

This section shows examples of DELETE messages used to remove traffic mirroring
triggers on demux0.30010001 and demux0.30010002. DTCP DELETE can use either
Criteria-ID to delete only that criteria or Cdest-ID to delete everything with cdest-ID that
you previously created.
DELETE DTCP/0.7
Csource-ID: dtcp1
CRITERIA-ID: 2
Flags: STATIC
Seq: 10
Authentication-Info: 7e84ae871b12f2da023b038774115bb8d955f17e
DTCP/0.7 200 OK
SEQ: 10
CRITERIA-COUNT: 1
TIMESTAMP: 2011-02-13 16:00:02.802
AUTHENTICATION-INFO: 2834ff32ec07d84753a046cfb552e072cc27d50b
DELETE DTCP/0.7
Csource-ID: dtcp1
CRITERIA-ID: 3
Flags: STATIC
Seq: 12
Authentication-Info: 7653fd94659a7183a990bdea654a1b97c0895348
DTCP/0.7 200 OK
SEQ: 12
CRITERIA-COUNT: 1
TIMESTAMP: 2011-02-13 16:01:35.895
AUTHENTICATION-INFO: 7cd8171057a327434e1b2d9b35f43b88305f9a74

Verifying That Traffic Mirroring Was Stopped on the Subscriber Interfaces

This section shows an example of a LIST message used to show that traffic mirroring on
demux0.30010001 and demux0.30010002 is disabled.
LIST DTCP/0.7
Csource-ID: dtcp1
Cdest-ID: cd1
Seq: 13
Authentication-Info: 7c9f825427cfeaecebb0d13ea3842af1021c7d26
DTCP/0.7 430 Unknown Content Destination

SEQ: 13
AUTHENTICATION-INFO: 5ca2eec65106354fe59c878b4c36b7de3c511acd

Documentation

ADD DTCP
Syntax ADD DTCP/0.7

Csource-ID: user-name
Cdest-ID: variable
Priority: priority-number
X-Drop-Policy: policy-name
X-JTap-Cdest-Dest-Address: ipv4-address
X-JTap-Cdest-Dest-Port: udp-port
X-JTap-Cdest-Source-Address: ipv4-address
X-JTap-Cdest-Source-Port: port-number
X-JTap-Cdest-TTL: time-to-live
X-MD-Intercept-Id: 8-byte-id
Dtcp-trigger: trigger-value
Dtcp-attribute: attribute-value
Flags: flag
Seq: sequence-number
Authentication-Info: ssh-authentication-string
Description Specify the DTCP attributes used in ADD messages to cause the router to trigger traffic
mirroring and provide instructions to populate fields in the encapsulation header for
packets sent to the mediation device.
The DTCP ADD message can be sent either before or after subscribers log in through the
interface.
The following attributes are added to the packet header of mirrored packets that the
router sends to the mediation device. These attributes are required in the DTCP ADD
message.
• X-JTap-Cdest-Dest-Address
• X-JTap-Cdest-Dest-Port
• X-MD-Intercept-Id
Options Csource-ID: user-name—Username on the router. This username must be configured as

a DTCP user on the router using the set system login class or set system login user
statements.
Cdest-ID: variable—ID of the mediation device.
Flags: flag—STATIC is the only flag supported.
Priority: priority-number—This implementation of DTCP does not use the priority number.
X-Drop-Policy policy-name—Name of the policy used to determine which mirrored packets

are no longer sent to the mediation device.
X-JTap-Cdest-Dest-Address: ipv4-address—Destination IPv4 address of the mediation

device to which intercepted packets are sent. You must include this attribute in your
ADD messages.. It is used in the header of mirrored traffic that is sent to the mediation
device.

X-JTap-Cdest-Dest-Port: udp-port—Destination port of the mediation device to which

intercepted packets are sent. You must include this attribute in your ADD messages.
It is used in the header of mirrored traffic that is sent to the mediation device.
X-JTap-Cdest-Source-Address: ipv4-address—Source IPv4 address. You must include

this attribute in your ADD messages. If the value entered does not match the value
configured on the router using the set services radius-flow-tap source-ipv4-address
source-ipv4-address statement, it is replaced by configured value.
X-JTap-Cdest-Source-Port: port-number—Source port. You must include this attribute in

your ADD messages. If the value entered does not match the value of
X-Jtap-Cdest-Dest-Port, it is ignored.
X-JTap-Cdest-TTL: time-to-live—TTL value to be used in the forwarded packet.
X-MD-Intercept-Id 8-byte-id—An Id that is used to identify a subscriber. You must include

this attribute in your ADD messages. This ID is used in the header of mirrored traffic
that is sent to the mediation device to allow the device to track a subscriber. The
X-MD-Intercept-ID attribute must consist of 8-bytes, and the first two bits must be
00.
Dtcp-trigger: trigger-value—DTCP attribute used to trigger traffic mirroring. “DTCP Traffic

Mirroring Triggers” on page 405 lists the DTCP attributes that you can use in DTCP
ADD messages to trigger traffic mirroring.
Dtcp-attribute: attribute-value—DTCP attribute included in the ADD messages. “DTCP

Traffic Mirroring Triggers” on page 405 lists the DTCP attributes that you can use in
ADD messages.
Seq: sequence-number—Number added by the mediation device. DTCP messages contain

a monotonically increasing sequence number for each successive message.
Authentication-Info: ssh-authentication-string—String used when you are using SSH to

connect to the router.
Required Privilege Not applicable.

Level
Related • DTCP Traffic Mirroring Triggers on page 405

Documentation
Sample Output
ADD DTCP/0.7
Cdest-ID: cd1
Priority: 2

X-Interface-Id: ge-0/0/2.1
X-MD-Intercept-Id: 55667788
Flags: STATIC
Seq: 1
DTCP/0.7 200 OK
SEQ: 7
CRITERIA-ID: 2
TIMESTAMP: 2011-02-13 15:56:49.609

DELETE DTCP
Syntax DELETE DTCP/0.7

CRITERIA-ID: criteria-id
Cdest-ID: variable
Flags: flag
Authentication-Info:ssh-authentication-string
Description Disable traffic mirroring for a subscriber. Mirroring of the existing subscriber is stopped.
Options Csource-ID: user-name—Username on the router. This name must be configured on the
router.
CRITERIA-ID: criteria-id—ID that DTCP assigns for the mirrored session when you create
a DTCP ADD message. Use this ID in your DELETE messages to disable the intercept
for a specific subscriber. To view the ID, use the DTCP LIST message. The CRITERIA-ID
and the Cdest-ID are mutually exclusive in DELETE messages.
Cdest-ID: variable—ID of the mediation device. Use this ID in your DELETE messages to
remove all mirroring sessions associated with a mediation device. The Cdest-ID and
the CRITERIA-ID are mutually exclusive in DELETE messages.



Level

Documentation
List of Sample Output DELETE DTCP on page 432
Sample Output
The following sample shows how to disable mirroring for a specific subscriber by using
the CRITERIA-ID.

DELETE DTCP
DELETE DTCP/0.7
Csource-ID: dtcp1
CRITERIA-ID: 2
Flags: STATIC
Seq: 10
Authentication-Info: 7e84ae871b12f2da023b038774115bb8d955f17e
DTCP/0.7 200 OK
SEQ: 10
CRITERIA-COUNT: 1
TIMESTAMP: 2011-02-13 16:00:02.802
AUTHENTICATION-INFO: 2834ff32ec07d84753a046cfb552e072cc27d50b

DISABLE DTCP
Syntax DISABLE DTCP/0.7

Criteria-ID: variable
X-Drop-Policy: variable
Flags: flags
Release Information Command introduced in Junos OS Release 12.3.
Description Specify the DTCP ENABLE message to remove a drop policy that exists because of a
prior DTCP ADD or DTCP ENABLE command
The DTCP DISABLE message can only be issued on a Criteria-ID that was returned in a
response to a previous DTCP ADD. The policy applies to any new subscribers that match
the trigger corresponding to the Criteria-ID. Any existing mirroring remains in place, the
policy is not be applied to them.

statements.
Criteria-ID: variable—Identifies the subscriber on which the policy update occurs.
X-Drop-Policy: variable—Name of the policy that determines which mirrored packets are
no longer sent to the mediation device.

Level
Related • ENABLE DTCP on page 434

Documentation
Sample Output
DISABLE DTCP/0.7
Criteria-ID: 1
X-Drop: T1
Flags: STATIC
Seq: 1
DTCP/0.7 200 OK
SEQ: 7
CRITERIA-ID: 2
TIMESTAMP: 2011-02-13 15:56:49.609

ENABLE DTCP
Syntax ENABLE DTCP/0.7

Criteria-ID: variable
X-Drop-Policy: variable
Flags: flags
Description Specify the DTCP attributes used in ENABLE messages to cause the router to trigger a
drop policy if one does not already exist from a prior DTCP ADD or DTCP ENABLE
command.
The DTCP ENABLE message can only be issued on a Criteria-ID that was returned in a
response to a previous DTCP ADD command. The policy applies to any new subscribers
who match the trigger corresponding to the Criteria-ID. Any existing mirroring remains in
place and the policy is not be applied to them. The DTCP ENABLE command stops only
the traffic that is identified by the specified policy from being sent to the mediation device.

statements.
Criteria-ID: variable—Value returned from a prior DTCP ADD that identifies the trigger on
which to disable this drop policy.
X-Drop-Policy: variable—Name of the policy that determines which mirrored packets are
no longer sent to the mediation device.

Level
Related • DISABLE DTCP on page 433

Documentation
Sample Output
ENABLE DTCP/0.7
Criteria-ID: 1
X-Drop: T1
Flags: STATIC
Seq: 1
DTCP/0.7 200 OK
SEQ: 7
CRITERIA-ID: 2
TIMESTAMP: 2011-02-13 15:56:49.609

LIST DTCP
Syntax LIST DTCP/0.7

Cdest-ID: variable
Flags: BOTH
Authentication-Info:ssh-authentication-string
Description Request information that is returned in a LIST response. The response lists triggers only.
It does not return sessions that are being mirrored.
Options Csource-ID: user-name—Username on the router. This name must be configured on the
router.
Cdest-ID: variable—ID of the mediation device.

If a LIST DTCP command is sent with multiple Cdest-IDs, the error 400 Bad Request
is displayed.
Flags: flag—BOTH is the only flag supported. This field must be included in the LIST
message.



Level

Documentation
List of Sample Output LIST DTCP on page 435
Sample Output
LIST DTCP
LIST DTCP/0.7
Csource-ID: dtcp1
Cdest-ID: cd1
Flags: BOTH
Seq: 9
Authentication-Info: f6dd64643021debb167ce2fb2d3c7b6622a87e09
DTCP/0.7 200 OK
SEQ: 9

TIMESTAMP: 2011-02-13 15:57:47.667

CRITERIA-ID: 2
CSOURCE-ID: dtcp1
CDEST-ID: cd1
FLAGS: BOTH
X-INTERFACE-ID: demux0.30010002
CRITERIA-NUM: 1
CRITERIA-COUNT: 0
CRITERIA-ID: 3
CSOURCE-ID: dtcp1
CDEST-ID: cd1
FLAGS: BOTH
X-INTERFACE-ID: demux0.30010001
CRITERIA-NUM: 2
CRITERIA-COUNT: 2
AUTHENTICATION-INFO: 361171ccb24dde6afe8ef66021287f9b8ac16028

PART 6
Troubleshooting
• Contacting Juniper Networks Technical Support on page 439
• CoS System Log Messages on page 443


CHAPTER 41
Contacting Juniper Networks Technical

Support
• Collecting Subscriber Access Logs Before Contacting Juniper Networks Technical

Support on page 439
Collecting Subscriber Access Logs Before Contacting Juniper Networks Technical

Support
Problem Description: When you experience a subscriber access problem in your network, we
recommend that you collect certain logs before you contact Juniper Networks Technical
Support. This topic shows you the most useful logs for a variety of network
implementations. In addition to the relevant log information, you must also collect
standard troubleshooting information and send it to Juniper Networks Technical Support
in your request for assistance.
Solution To collect standard troubleshooting information:
• Redirect the command output to a file.
user@host> request support information | save rsi-1

To configure logging to assist Juniper Networks Technical Support:
1. Review the following blocks of statements to determine which apply to your

configuration.
[edit]
set system syslog archive size 100m files 25
set system auto-configuration traceoptions file filename
set system auto-configuration traceoptions file filename size 100m files 25
set protocols ppp-service traceoptions file filename size 100m files 25
set protocols ppp-service traceoptions level all
set protocols ppp-service traceoptions flag all
set protocols ppp traceoptions file filename size 100m files 25
set protocols ppp traceoptions level all
set protocols ppp traceoptions flag all
set protocols ppp monitor-session all
set interfaces pp0 traceoptions flag all
set demux traceoptions file filename size 100m files 25
set demux traceoptions level all
set demux traceoptions flag all
set system processes dhcp-service traceoptions file filename
set system processes dhcp-service traceoptions file size 100m
set system processes dhcp-service traceoptions file files 25
set system processes dhcp-service traceoptions flag all
set class-of-service traceoptions file filename
set class-of-service traceoptions file size 100m
set class-of-service traceoptions flag all
set class-of-service traceoptions file files 25
set routing-options traceoptions file filename
set routing-options traceoptions file size 100m
set routing-options traceoptions flag all
set routing-options traceoptions file files 25
set interfaces traceoptions file filename
set interfaces traceoptions file size 100m
set interfaces traceoptions flag all
set interfaces traceoptions file files 25
set system processes general-authentication-service traceoptions file filename
set system processes general-authentication-service traceoptions file size 100m
set system processes general-authentication-service traceoptions flag all
set system processes general-authentication-service traceoptions file files 25
2. Copy the relevant statements into a text file and modify the log filenames as you
want.
3. Copy the statements from the text file and paste them into the CLI on your router to
configure logging.
4. Commit the logging configuration to begin collecting information.
NOTE: The maximum file size for DHCP local server and DHCP relay log files
is 1 GB. The maximum number of log files for DHCP local server and DHCP
relay is 1000.

Chapter 41: Contacting Juniper Networks Technical Support
BEST PRACTICE: Enable these logs only to collect information when

troubleshooting specific problems. Enabling these logs during normal
operations can result in reduced system performance.
Related • Compressing Troubleshooting Logs from /var/logs to Send to Juniper Networks Technical
Documentation Support


CHAPTER 42
CoS System Log Messages
This chapter describes messages with the COSD prefix. They are generated by the
class-of-service (CoS) process (cosd), which enables the routing platform to provide
different levels of service to applications based on packet classifications.
COSD_AGGR_CONFIG_INVALID
System Log Message Error: Cannot have config error-message interface-name
Description The class-of-service (CoS) process (cosd) did not apply the config on this interface
because it was not valid in this case.
Type Error: An error occurred
Severity error
Facility LOG_DAEMON
Cause One possible cause is if any Class-of-Service is configured on an interface which is a part
of an aggregated interface
Action Remove or change the config from/on the interface.
COSD_CHASSIS_SCHED_MAP_INVALID
System Log Message Chassis scheduler map incorrectly applied to interface interface-name: error-message
Description The class-of-service (CoS) process (cosd) did not apply a chassis scheduler map to the
indicated interface, because the configuration used to apply the scheduler map was
invalid.
Severity error
Facility LOG_DAEMON
Cause One possible cause is that the chassis scheduler map is applied to a specific interface.
For most interface types, a scheduler map must be applied to all interfaces on the PIC;
therefore, a wildcard must be used to specify the interfaces. One exception to this rule
is the Gigabit Ethernet IQ PIC.

Action Correct the configuration used to apply the chassis scheduler map to the interface.
COSD_CLASSIFIER_NO_SUPPORT_LSI
System Log Message Cannot support classifier type classifier-type on lsi interface interface-name
Description The Differentiated Services code point (DSCP) classifier and the 802.1p classifier are
only supported on I-Chip based Flexible PIC Concentrators (FPCs).
Severity error
Facility LOG_DAEMON
Action Remove the DSCP or the 802.1p classifier configuration from the routing instance
COSD_CLASS_8021P_UNSUPPORTED
System Log Message ieee-802.1 classifier is not valid on interface interface-name
Description The IEEE 802.1p classifier is not supported on the indicated interface.
Severity warning
Facility LOG_DAEMON
Action Remove the 802.1p classifier configuration from the interface, or configure an interface
encapsulation type that supports 802.1p classifiers.
COSD_CLASS_NO_SUPPORT_IFD
System Log Message BA/Fixed Classifier or Rewrite on Physical Interface is not allowed when ethernet switching
family is configured: interace interface-name
Description The Rewrite is not supported on this interface when ethernet switching is enabled
Severity error
Facility LOG_DAEMON
Action Remove the classifier configuration from the interface, instead apply it on the logical
interface where ethernet switching family is enabled
Action Remove the Rewrite configuration from the interface, instead apply it on the logical
interface where ethernet switching family is enabled

Chapter 42: CoS System Log Messages
COSD_CLASS_NO_SUPPORT_L3_IFL
System Log Message BA/Fixed Classifier or Rewrite config is not allowed on logical interface (interface-name)
with inet/inet6 family
Description The Rewrite is not supported on this logical interface
Severity error
Facility LOG_DAEMON
Action Remove the classifier configuration from the logical interface, instead apply it on the
main interface if inet/inet6 is configured on one of its logical interfaces
Action Remove the Rewrite configuration from the logical interface, instead apply it on the main
interface if inet/inet6 is configured on one of its logical interfaces
COSD_CONF_OPEN_FAILURE
System Log Message Unable to open: filename, using default CoS forwarding classes, do 'commit full' in cli to
avoid this message
Description The class-of-service (CoS) process (cosd) could not read configuration data.
Severity error
Facility ANY
Cause All of the following resons: mgd -I fails after upgrade-the file cosd.conf does not exist
and is not created because of the mgd -I failure The first commit is 'commit' and not
'commit full'-the file cosd.conf does not commit and is not created automatically
[class-of-service forwarding-classes] does not exist-the file cosd.conf does not get
exported with plain 'commit'
Action Do a 'commit full'
COSD_DB_OPEN_FAILED
System Log Message Unable to open configuration database: error-message(name)
Description The class-of-service (CoS) process (cosd) could not read configuration data for the
indicated reason.
Severity error
Facility LOG_DAEMON
Cause The specified database does not exist

Action Contact your technical support representative.
COSD_EXACT_RATE_UNSUPP_INTERFACE
System Log Message Unable to apply scheduler map scheduler-map to interface interface-name because it
does not support exact-rate transmission
Description The class-of-service (CoS) process (cosd) did not apply the indicated scheduler map
to the indicated interface, because a scheduler named in the scheduler map specifies
exact transmission rate. The interface is housed on a type of PIC that does not support
exact transmission rate, such as an IQ2 PIC. In terms of configuration, the 'exact' statement
is included in the scheduler definition at the [edit class-of-service schedulers
<scheduler-name> transmit-rate (<rate> | percent <percentage>)] hierarchy level. The
scheduler is included in the scheduler map that is applied to the interface.
Severity error
Facility LOG_DAEMON
Action Remove the 'exact' statement from the scheduler in the scheduler map applied to the
interface.
COSD_EXACT_RATE_UNSUPP_SESSION
System Log Message Unable to apply CoS to L2TP session session-id, because scheduler map scheduler-map
specifies exact rate transmission
Description The class-of-service (CoS) process (cosd) did not apply CoS settings to the indicated
Layer 2 Tunneling Protocol (L2TP) session, because the scheduler map specified by the
RADIUS server for the session is configured for exact transmission rate. Exact transmission
rate is not supported for L2TP sessions on the type of PIC that houses the interface, such
as an IQ2 PIC. In terms of configuration, the 'exact' statement is included in a scheduler
definition at the [edit class-of-service schedulers <scheduler-name> transmit-rate
(<rate> | percent <percentage>)] hierarchy level. The scheduler is included in a scheduler
map that is associated with a traffic control profile. The traffic control profile is named
by an attribute in the RADIUS server's configuration file, which makes the profile apply
to the session.
Severity error
Facility LOG_DAEMON
Action Remove the 'exact' statement from the scheduler in the scheduler map applied to the
session.
COSD_EXP_RW_L2_IFL_NOT_SUPPORTED
System Log Message EXP Rewrite on IFL is not allowed when ethernet switching family is configured: interace
interface-name

Description EXP rewrite is not supported on this logical interface.
Severity error
Facility LOG_DAEMON
Action Remove the exp rewrite configuration from the logical interface.
COSD_FRAGMENTATION_MAP_CONFLICT
System Log Message Interface compression-device matches wildcard wildcard-interface-name, but
fragmentation map fragmentation-map was not applied because interface is compression
device for link interface link-interface-name
Description The indicated fragmentation map is normally applied to interfaces that match the
indicated wildcard. The class-of-service (CoS) process (cosd) did not apply the
fragmentation map to the indicated interface, even though it matches the wildcard,
because the interface is acting as a compression device for the indicated link interface.
Severity warning
Facility LOG_DAEMON
Action Correct the configuration of the fragmentation map.
COSD_HIGH_PRIO_QUEUES_INTERFACE
System Log Message Unable to apply scheduler map scheduler-map to interface interface-name, because
multiple schedulers in map have "high,""medium-high," or "strict-high" priority
to the indicated interface, because the map includes more than one scheduler that has
high, medium-high, or strict-high priority. For interfaces that are housed by certain PICs,
such as an IQ2 PIC, the scheduler map can include only one scheduler that specifies one
of those three priority levels. In terms of configuration, the 'priority' statement at the [edit
class-of-service schedulers <scheduler-name>] hierarchy level has the value 'high, '
'medium-high, ' or 'strict-high' for more than one of the schedulers in the map.
Severity error
Facility LOG_DAEMON
Action Correct the configuration so that the scheduler map includes only one scheduler with
high, medium-high, or strict-high priority.

COSD_HIGH_PRIO_QUEUES_SESSION
System Log Message Unable to apply CoS to L2TP session session-id, because multiple schedulers in scheduler
map scheduler-map have "high,""medium-high," or "strict-high" priority
Layer 2 Tunneling Protocol (L2TP) session because the scheduler map specified by the
RADIUS server for the session includes more than one scheduler that has high,
medium-high, or strict-high priority. For interfaces that are housed by certain Physical
Interface Cards (PICs), such as an IQ2 PIC, the scheduler map can include only one
scheduler that specifies one of those three priority levels. In terms of configuration, the
'priority' statement at the [edit class-of-service schedulers <scheduler-name>] hierarchy
level has the value 'high, ' 'medium-high, ' or 'strict-high' for more than one of the
schedulers in the map. The map is associated with a traffic control profile that is named
by an attribute in the RADIUS server's configuration file, which makes the profile apply
to the session.
Severity error
Facility LOG_DAEMON
Action Correct the configuration so that the scheduler map includes only one scheduler with
high, medium-high, or strict-high priority.
COSD_IFD_OUTPUT_SHAPING_RATE_ERR
System Log Message Traffic shaping not supported on interface device interface-name
Description The class-of-service (CoS) process (cosd) did not apply the shaping rate that is configured
for the indicated interface.
Severity error
Facility LOG_DAEMON
Cause Shaping rate is valid only for interfaces housed by IQ and IQ2 PICs, and the interface is
on a different type of PIC.
Action Remove the shaping rate configuration from the interface.
COSD_IFD_SHAPER_ERR
System Log Message port shaper not allowed on interface interface-name
Description The non-queuing dense port concentrators (DPCs) did not support the specified shaping
rate.

Severity error
Facility LOG_DAEMON
Cause The port shaper was not supported on the non-queuing DPCs.
Action Remove the shaping rate configuration from the interface.
COSD_INTERFACE_NO_MEDIA
System Log Message Unable to obtain media information for interface interface-name
Description The message sent by the kernel for the indicated interface did not include required media
information.
Severity error
Facility LOG_DAEMON
Cause An internal software failure occurred.
COSD_L2TP_COS_NOT_CONFIGURED
System Log Message Unable to apply CoS to L2TP session session-id because session-aware CoS is not enabled
for interface interface-name
Layer 2 Tunneling Protocol (L2TP) session on the indicated interface, because the
interface is not configured to support session-aware CoS for L2TP. In terms of
configuration, the 'per-session-scheduler' statement is not included at the [edit interfaces
<interface-name> unit <logical-unit-number>] hierarchy level.
Severity error
Facility LOG_DAEMON
Action Include the 'per-session-scheduler' statement in the configuration for the interface.
COSD_L2TP_COS_NOT_SUPPORTED
System Log Message Unable to apply CoS to L2TP session session-id on interface interface-name: it does not
support CoS
Layer 2 Tunneling Protocol (L2TP) session on the indicated interface. The interface is
configured to support session-aware CoS for L2TP, but is not on a PIC that supports that
feature, such as an IQ2 PIC. In terms of configuration, the 'per-session-scheduler'

statement is included at the [edit interfaces <interface-name> unit

<logical-unit-number>] hierarchy level.
Severity error
Facility LOG_DAEMON
Action Determine whether the interface is on an PIC that supports session-aware CoS; if not,
remove the 'per-session-scheduler' statement.
COSD_L2TP_SHAPING_NOT_CONFIGURED
System Log Message Unable to apply CoS to L2TP session session-id because session-aware shaping is not
enabled for interface interface-name
Layer 2 Tunneling Protocol (L2TP) session on the indicated interface, because
session-aware traffic shaping for L2TP is not configured on the PIC that houses the
interface. In terms of configuration, the 'session-shaping' statement is not included at
the [edit chassis fpc <slot-number> pic <pic-number> traffic-manager mode] hierarchy
level.
Severity error
Facility LOG_DAEMON
Action Include the 'session-shaping' statement in the configuration for the PIC.
COSD_LARGE_DELAY_BUFFER_INVALID
System Log Message Error for interface interface-name error-message
Description The class-of-service (CoS) process (cosd) did not apply the large delay buffer setting
that is configured for the indicated interface.
Severity error
Facility LOG_DAEMON
Cause The interface is not housed on one of the PIC types that support large delay buffer.
Action Remove the large delay buffer configuration from the interface.
COSD_MALLOC_FAILED
System Log Message malloc failed: error-message

Description The class-of-service (CoS) process (cosd) could not dynamically allocate memory for
the indicated reason.
Severity error
Facility LOG_DAEMON
Cause A software bug caused a memory leak or the Routing Engine did not have sufficient
memory.
Action Contact your technical support representative. For more information, see
http://kb.juniper.net/InfoCenter/index?page=content&id=KB18862.
COSD_MAX_FORWARDING_CLASSES_ABC
System Log Message exceeding max 4 forwarding-class support.
Description User configuration exceeds the maximum number of forwarding class that is supported.
Severity warning
Facility LOG_DAEMON
Action Configure only four forwarding classes
COSD_MPLS_DSCP_CLASS_NO_SUPPORT
System Log Message Cannot support MPLS DSCP classifier on ifl interface-name
Description The MPLS Differentiated Services code point (DSCP) classifier is only supported on I-Chip
based Flexible PIC Concentrators (FPCs). It is not supported on Q2 PICs.
Severity error
Facility LOG_DAEMON
Action Remove the MPLS DSCP classifier configuration from the logical interface.
COSD_MULTILINK_CLASS_CONFLICT
System Log Message Fragmentation map fragmentation-map for wildcard wildcard-interface-name specified
multilink class class-name for queue queue-number on interface interface-name, which
exceeds configured limit of limit
Description The indicated fragmentation map is normally applied to interfaces that match the
indicated wildcard, and specifies the indicated multilink class setting for queues on those
interfaces. The class-of-service (CoS) process (cosd) did not apply the fragmentation

map to the indicated interface, even though it matches the wildcard, because the setting
in the map exceeds the indicated class limit, which is configured on the interface itself.
Severity warning
Facility LOG_DAEMON
Action Correct the configuration so that the multilink class setting in the fragmentation map
does not exceed the class limit for the interface.
COSD_NULL_INPUT_ARGUMENT
System Log Message NULL input argument : error-message
Description The pointer that was passed to this function was NULL.
Severity error
Facility LOG_DAEMON
COSD_OUT_OF_DEDICATED_QUEUES
System Log Message Queue usage count for interface interface-name is at percentage-value percent
Description The class-of-service (CoS) process (cosd) is running out of dedicated queues.
Type Event: This message reports an event, not an error
Severity warning
Facility LOG_DAEMON
COSD_RATE_LIMIT_INVALID
System Log Message Unable to apply scheduler map scheduler-map to interface interface-name. description.
to the indicated interface, because the number of rate limited queues in the scheduler
map exceeded the limit supported by this interface or the priority is not supported. The
interface is housed in a type of PIC that does not support the number of configured rate
limited queues or the priority is not supported. In terms of configuration, the 'rate-limit'
statement is included in the scheduler definition at the [edit class-of-service schedulers
<scheduler-name> transmit-rate <rate> | percent <percentage>] hierarchy level. The
scheduler is included in the scheduler map applied to the interface.
Severity error
Facility LOG_DAEMON

Action Either limit the number of rate-limited schedulers in this scheduler map to the allowed
maximum for this PIC and interface type or check the allowed priority for rate-limited
queues
COSD_RATE_LIMIT_NOT_SUPPORTED
System Log Message Unable to apply scheduler map scheduler-map to interface interface-name because it
does not support rate limiting
to the indicated interface, because a scheduler named in the scheduler map is configured
for rate limiting. The interface is housed in a type of PIC that does not support rate limiting.
In terms of configuration, the 'rate-limit' statement is included in the scheduler definition
at the [edit class-of-service schedulers <scheduler-name> transmit-rate <rate> | percent
<percentage>] hierarchy level. The scheduler is included in the scheduler map applied
to the interface.
Severity error
Facility LOG_DAEMON
Action Remove the 'rate-limit' statement from the scheduler in the scheduler map applied to
the interface.
COSD_REWRITE_RULE_LIMIT_EXCEEDED
System Log Message Number of rewrite rules applied to interface interface-name exceeds limit
(maximum-value)
Description The class-of-service (CoS) process (cosd) determined that the number of rewrite rules
applied to the indicated interface exceeds the indicated limit for the interface. In terms
of configuration, too many rewrite rules are included at the [edit class-of-service interfaces
<interface-name> unit <logical-unit-number> rewrite-rules] hierarchy level.
Severity error
Facility LOG_DAEMON
Action Remove rewrite rules from the configuration for the interface.
COSD_RL_IFL_NEEDS_SHAPING
System Log Message "rate-limit" configured in scheduler-map, but ifl interface-name does not have output
shaper configured. It will use the ifd-shaping rate/ifd-transmit rate for implementation
of rate-limit.
Description The 'rate-limit' statement is configured in one or more schedulers that are part of the
indicated scheduler map. In order to apply this scheduler map to the indicated interface,

output shaping rate should be configured on the interface. Since no output shaping rate
is configured, the transmit rate or shaping rate of the parent interface will be used instead.
Severity warning
Facility LOG_DAEMON
Action Configure output shaping rate for the indicataed interface
COSD_SCHEDULER_MAP_CONFLICT
System Log Message Forwarding classes "first-forwarding-class" and "second-forwarding-class" in scheduler
map scheduler-map both map to queue queue-number
Description Both of the indicated forwarding classes, which are defined in the indicated scheduler
map, map to the same indicated queue. The double mapping is invalid.
Severity error
Facility LOG_DAEMON
Action Map only one forwarding class to the queue.
COSD_SCHED_AVG_CONST_UNSUPPORTED
System Log Message Averaging constant not supported on interface interface-name. Value set in scheduler-map
scheduler-map (scheduler name) will be ignored.
Description Configuring averaging constant is not supported on the indicated interface. Value set in
the indicated scheduler will be ignored.
Severity warning
Facility LOG_DAEMON
Action Remove the averaging-constant configuration from the indicated scheduler.
COSD_SCHED_MAP_GROUP_CONFLICT
System Log Message Interface interface-name cannot be bound to scheduler-map scheduler-map. It will be
bound to default scheduler-map
Description Interfaces belonging to a group cannot be bound to different scheduler maps. They will
be bound to the default scheduler map.
Severity error

Facility LOG_DAEMON
Action Map only one scheduler map to all the interfaces of a group.
COSD_SHAPER_GROUP_CONFLICT
System Log Message Interface interface-name cannot be bound to configured shaping-rate. It will be bound
to default rate
Description Interfaces belonging to a group cannot be bound to different shaping rates. They will be
bound to the default shaping rate.
Severity error
Facility LOG_DAEMON
Action Map only one shaping rate to all interfaces of a group.
COSD_STREAM_IFD_CREATE_FAILURE
System Log Message Unable to create special master interface device for interface-name
Description The class-of-service (CoS) process (cosd) could not create the indicated internal interface
device, which it needs for application of a chassis scheduler map.
Severity error
Facility LOG_DAEMON
COSD_TIMER_ERROR
System Log Message Unable to set retry timer for rtsock write operation: error-message
Description The class-of-service (CoS) process (cosd) used a routine from the rtsock library to write
to the kernel, but the kernel did not accept the request. The cosd process could not set
the retry timer for the request, for the indicated reason.
Severity error
Facility LOG_DAEMON

COSD_TRICOLOR_ALWAYS_ON
System Log Message tri-color is always enabled in this platform. There is no need to explicitly set it.
Description Tri-color marking is always enabled on this platform. There is no need to explicitly set it.
Severity warning
Facility LOG_DAEMON
Action Remove the 'tri-color' configuration statement
COSD_TRICOLOR_NOT_SUPPORTED
System Log Message Unable to apply scheduler scheduler-map to interface interface-name, because it does
not support tricolor marking
to the indicated interface, because a scheduler included in the map specifies a packet
loss priority (PLP) that is supported only with tricolor marking (TCM). The interface does
not support TCM, either because TCM is not enabled or the interface is on a router that
does not support TCM. In terms of configuration, the value 'medium-high' or 'medium-low'
is specified for the 'loss-priority' statement in a scheduler definition at the [edit
class-of-service schedulers <scheduler-name> drop-profile-map] hierarchy level. The
scheduler is included in the scheduler map applied to the interface, but the 'tri-color'
statement is either not included at the [edit class-of-service] hierarchy level, or is not
supported.
Severity error
Facility LOG_DAEMON
Action Change the value of the 'loss-priority' statement in the scheduler or include the 'tri-color'
statement to enable TCM on the router.
COSD_TX_QUEUE_RATES_TOO_HIGH
System Log Message Unable to apply scheduler map scheduler-map to interface interface-name: sum of
scheduler transmission rates exceeds interface shaping or transmission rate
to the indicated interface, because the sum of the queue transmission rates defined in
the schedulers in the scheduler map exceeds the shaping or transmission rate for the
interface. In terms of configuration, the 'transmit-rate' statement is specified for each
scheduler at the [edit class-of-service schedulers <scheduler-name>] hierarchy level.
The sum of the configured transmission rates exceeds the transmission or shaping rate
of the interface.

Severity error
Facility LOG_DAEMON
Action Decrease the value of one or more 'transmit-rate' statements so that the sum is less
than the interface transmission or shaping rate.
COSD_UNKNOWN_CLASSIFIER
System Log Message classifier type classifier-type is invalid
Description The class-of-service (CoS) process (cosd) did not recognize the indicated classifier type
from the rtsock library.
Severity warning
Facility LOG_DAEMON
COSD_UNKNOWN_REWRITE
System Log Message rtsock rewrite type type is invalid
Description The class-of-service (CoS) process (cosd) did not recognize the indicated rewrite type
from the rtsock library.
Severity warning
Facility LOG_DAEMON
COSD_UNKNOWN_TRAFFIC_CLASS_MAP
System Log Message traffic-class-map type traffic-class-map-type is invalid
Description The class-of-service (CoS) process (cosd) did not recognize the indicated
traffic-class-map type from the rtsock library.
Severity warning
Facility LOG_DAEMON

COSD_UNKNOWN_TRANSLATION_TABLE
System Log Message rtsock translation table type translation-table-type is invalid
Description The class-of-service (CoS) process (cosd) did not recognize the indicated translation
table type from the rtsock library.
Severity warning
Facility LOG_DAEMON
Action For more information, see

http://kb.juniper.net/InfoCenter/index?page=content&id=KB18866.

PART 7
Configuration Statements and

Operational Commands
• Configuration Statements on page 461
• Operational Commands on page 689


CHAPTER 43
Configuration Statements
• [edit class-of-service] Hierarchy Level on page 466

• [edit dynamic-profiles] Hierarchy Level on page 471
• [edit services captive-portal-content-delivery] Hierarchy Level on page 478
• [edit services radius-flow-tap] Hierarchy Level on page 479
• accounting (Dynamic IGMP Interface) on page 480
• accounting (Dynamic MLD Interface) on page 480
• action on page 481
• adf (Dynamic Firewalls) on page 482
• adjust-minimum (Dynamic Shaping and Scheduling) on page 484
• adjust-percent (Dynamic Schedulers) on page 485
• aggregate (Hierarchical Policer) on page 486
• ancp (Adjustment Control Profiles) on page 487
• application (Captive Portal Content Delivery) on page 488
• apply-groups (Subscriber Secure Policy) on page 489
• apply-groups-except (Subscriber Secure Policy) on page 489
• authentication (Login) on page 490
• authentication-order on page 491
• authentication-server on page 492
• bandwidth (Tunnel Services) on page 493
• bandwidth-limit (Policer) on page 495
• bandwidth-percent on page 497
• buffer-size (Dynamic Scheduling) on page 499
• burst-size-limit (Hierarchical Policer) on page 500
• burst-size-limit (Policer) on page 501
• bytes (Dynamic Traffic Shaping) on page 503
• captive-portal-content-delivery (Captive Portal Content Delivery) on page 504

• cell-mode (Dynamic Traffic Shaping) on page 505

• class (Assigning a Class to an Individual User) on page 506
• class (Defining Login Classes) on page 507
• class-of-service (Dynamic Profiles) on page 508
• classifiers (Dynamic CoS Application) on page 508
• color-aware on page 509
• color-blind on page 510
• committed-burst-size on page 511
• committed-information-rate on page 513
• connection-limit on page 515
• delay-buffer-rate (Dynamic Traffic Shaping) on page 516
• destination-address (Captive Portal Content Delivery) on page 517
• destination-address (Subscriber Secure Policy) on page 517
• destination-prefix-list (Captive Portal Content Delivery) on page 518
• destination-port (Subscriber Secure Policy) on page 518
• disable (Dynamic IGMP) on page 519
• disable (Dynamic MLD) on page 519
• drop-policy (Subscriber Secure Policy) on page 520
• drop-profile (Dynamic Schedulers) on page 521
• drop-profile-map (Dynamic Schedulers) on page 522
• dscp (Dynamic Classifiers) on page 523
• dscp (Dynamic Rewrite Rules) on page 524
• dscp (Subscriber Secure Policy) on page 524
• dscp-ipv6 (Dynamic Classifiers) on page 525
• dscp-ipv6 (Dynamic Rewrite Rules) on page 525
• dynamic-class-of-service-options (Dynamic Traffic Shaping) on page 526
• dynamic-profiles on page 527
• effective-shaping-rate on page 534
• enhanced-mode on page 535
• enhanced-mode-override on page 537
• excess-burst-size on page 539
• excess-priority (Dynamic Schedulers) on page 540
• excess-rate (Dynamic Schedulers) on page 541
• excess-rate (Dynamic Traffic Shaping) on page 542
• excess-rate-high (Dynamic Traffic Shaping) on page 543
• excess-rate-low (Dynamic Traffic Shaping) on page 544

Chapter 43: Configuration Statements
• exclude (Dynamic MLD Interface) on page 545

• fail-filter (Dynamic Profiles) on page 545
• family (Dynamic Firewalls) on page 546
• family (Dynamic Standard Interface) on page 548
• fast-update-filter (Dynamic Firewalls) on page 550
• filter (Configuring) on page 551
• filter (Dynamic Firewalls) on page 552
• filter (Dynamic Interface Unit) on page 553
• filter-specific on page 554
• firewall (Dynamic Firewalls) on page 555
• flow-tap-dtcp on page 557
• forwarding-class (Dynamic Scheduler Maps) on page 557
• forwarding-class (Subscriber Secure Policy) on page 558
• fpc (MX Series 3D Universal Edge Routers) on page 559
• frame-mode (Dynamic Traffic Shaping) on page 561
• from (Captive Portal Content Delivery) on page 562
• from (Subscriber Secure Policy) on page 563
• group (Dynamic IGMP Interface) on page 564
• group (Dynamic MLD Interface) on page 565
• group-count (Dynamic MLD Interface) on page 566
• group-increment (Dynamic MLD Interface) on page 566
• group-limit (Dynamic IGMP Interface) on page 567
• group-limit (Dynamic MLD Interface) on page 568
• group-policy (Dynamic IGMP Interface) on page 568
• group-policy (Dynamic MLD Interface) on page 569
• guaranteed-rate (Dynamic Traffic Shaping) on page 570
• hierarchical-policer on page 571
• ieee-802.1 (Dynamic Classifiers) on page 574
• ieee-802.1 (Dynamic Rewrite Rules) on page 575
• if-exceeding (Hierarchical Policer) on page 576
• if-exceeding (Policer) on page 577
• igmp (Dynamic Profiles) on page 578
• immediate-leave (Dynamic IGMP Interface) on page 579
• immediate-leave (Dynamic MLD Interface) on page 580
• inet (Subscriber Secure Policy) on page 581
• inet-precedence (Dynamic Classifiers) on page 582

• inet-precedence (Dynamic Rewrite Rules) on page 582

• inet6 (Subscriber Secure Policy) on page 583
• input (Dynamic Service Sets) on page 584
• interface (Dynamic IGMP) on page 585
• interface (Dynamic Interface Sets) on page 586
• interface (Dynamic MLD) on page 587
• interface (Dynamic Routing Options) on page 588
• interface-set (Dynamic CoS) on page 589
• interface-shared on page 590
• interface-specific (Dynamic Firewalls) on page 590
• interfaces (Dynamic CoS Definition) on page 591
• interfaces (Static and Dynamic Subscribers) on page 592
• interfaces (Subscriber Secure Policy) on page 596
• logical-bandwidth-policer on page 596
• logical-interface-fpc-redundancy (Aggregated Ethernet Subscriber
Interfaces) on page 597
• logical-interface-policer on page 598
• login on page 599
• loss-priority (Dynamic Schedulers) on page 600
• loss-priority high then discard (Three-Color Policer) on page 601
• match-direction (Captive Portal Content Delivery) on page 602
• max-queues-per-interface on page 602
• match-order (Dynamic Firewalls) on page 603
• mld (Dynamic Profiles) on page 604
• multicast (Dynamic Routing Options) on page 605
• multicast-interception (Subscriber Secure Policy) on page 606
• no-accounting on page 606
• no-qos-adjust (Dynamic Routing Options) on page 607
• oif-map (Dynamic IGMP Interface) on page 607
• oif-map (Dynamic MLD Interface) on page 608
• output (Dynamic Service Sets) on page 609
• output-traffic-control-profile (Dynamic CoS Definition) on page 610
• passive (Dynamic IGMP Interface) on page 612
• passive (Dynamic MLD Interface) on page 613
• peak-burst-size on page 614
• peak-information-rate on page 616

• permissions on page 617

• physical-interface-policer on page 618
• policer (Configuring) on page 619
• policy (Subscriber Secure Policy) on page 621
• policy-options (Dynamic Profiles) on page 622
• post-service-filter (Dynamic Service Sets) on page 623
• pppoe-tags (Adjustment Control Profiles) on page 624
• precedence on page 625
• premium (Hierarchical Policer) on page 626
• priority (Dynamic Schedulers) on page 627
• profile (Access) on page 628
• promiscuous-mode (Protocols IGMP) on page 631
• protocol (Dynamic Schedulers) on page 632
• protocol (Subscriber Secure Policy) on page 632
• radius (Access Profile) on page 633
• radius-coa (Adjustment Control Profiles) on page 635
• radius-flow-tap on page 636
• radius-server on page 637
• rate-limit on page 638
• rebalance-periodic (Aggregated Ethernet Subscriber Interfaces) on page 639
• rewrite-rules (Dynamic CoS Interfaces) on page 640
• routing-options (Dynamic Profiles) on page 641
• rpf-check (Dynamic Profiles) on page 642
• rule (Captive Portal Content Delivery) on page 643
• rule-set (Captive Portal Content Delivery) on page 644
• scheduler (Dynamic Scheduler Maps) on page 644
• scheduler-map (Dynamic Traffic Shaping) on page 645
• scheduler-maps (Dynamic CoS Definition) on page 646
• schedulers (Dynamic CoS Definition) on page 647
• service (Dynamic Service Sets) on page 648
• service-filter (Dynamic Service Sets) on page 649
• service-set (Dynamic Service Sets) on page 650
• services (Captive Portal Content Delivery) on page 651
• shaping-rate (Dynamic Traffic Shaping and Scheduling) on page 652
• shared-name on page 653
• single-rate on page 654
• source (Dynamic IGMP Interface) on page 655

• source (Dynamic MLD Interface) on page 655

• source-address (Subscriber Secure Policy) on page 656
• source-count (Dynamic MLD Interface) on page 656
• source-increment (Dynamic MLD Interface) on page 657
• source-ipv4-address on page 657
• source-port (Subscriber Secure Policy) on page 658
• ssh on page 659
• ssm-map (Dynamic IGMP Interface) on page 660
• ssm-map (Dynamic MLD Interface) on page 660
• static (Dynamic IGMP Interface) on page 661
• static (Dynamic MLD Interface) on page 662
• subscriber-leave-timer on page 663
• targeted-distribution (Dynamic Demux Interfaces over Aggregated Ethernet) on page 663
• targeted-distribution (Static Interfaces over Aggregated Ethernet) on page 664
• term (Captive Portal Content Delivery) on page 665
• term (Dynamic Profiles) on page 666
• then (Captive Portal Content Delivery) on page 668
• three-color-policer (Configuring) on page 670
• traceoptions (Captive Portal Content Delivery) on page 672
• traffic-control-profiles (Dynamic CoS Definition) on page 674
• transmit-rate (Dynamic Schedulers) on page 675
• tunnel-services (Chassis) on page 676
• two-rate on page 677
• uid (Dynamic Profiles) on page 678
• uid-reference on page 678
• unit (Dynamic Profiles Standard Interface) on page 679
• unit (Dynamic Traffic Shaping) on page 682
• user (Access) on page 683
• vendor-specific-tags (Dynamic Traffic Shaping) on page 684
• version (Dynamic IGMP Interface) on page 685
• version (Dynamic MLD Interface) on page 686
• vlan-tag (Dynamic Classifiers) on page 686
• vlan-tag (Dynamic Rewrite Rules) on page 687
[edit class-of-service] Hierarchy Level
This topic shows the complete configuration for class of service (CoS) statements for
the [edit class-of-service] hierarchy level, listing all possible configuration statements
and showing their level in the configuration hierarchy. When you are configuring the Junos

OS, your current hierarchy level is shown in the banner on the line preceding the
user@host# prompt.
adjustment-control-profiles {
profile-name {
application {
ancp;
radius-coa;
pppoe-tags;
}
}
}
classifiers {
(dscp | dscp-ipv6 | exp | ieee-802.1 | inet-precedence) classifier-name {
import (classifier-name | default);
forwarding-class class-name {
loss-priority level code-points [ aliases ] [ bit-patterns ];
}
}
}
code-point-aliases {
(dscp | dscp-ipv6 | exp | ieee-802.1 | inet-precedence) {
alias-name bits;
}
}
copy-plp-all;
drop-profiles {
profile-name {
fill-level percentage drop-probability percentage;
interpolate {
drop-probability [ values ];
fill-level [ values ];
}
}
}
fabric {
scheduler-map {
priority (high | low) scheduler scheduler-name;
}
}
class class-name queue-num queue-number priority (high | low);
queue queue-number class-name priority (high | low) [ policing-priority (premium |
normal) ];
}
forwarding-class-map forwarding-class-map-name {
class class-name queue-num queue-number [ restricted-queue queue-number ];
}
forwarding-policy {
next-hop-map map-name {
next-hop [ next-hop-name ];
lsp-next-hop [ lsp-regular-expression ];
non-lsp-next-hop;

discard;
}
}
class class-name {
classification-override {
forwarding-class class-name;
}
}
}
fragmentation-maps {
map-name {
drop-timeout milliseconds;
fragment-threshold bytes;
multilink-class number;
no-fragmentation;
}
}
}
host-outbound-traffic {
dscp-code-point value;
ieee-802.1 {
default value;
rewrite-rules;
}
}
interfaces {
interface-name {
classifiers {
dscp (classifier-name | default);
ieee-802.1 (classifier-name | default) vlan-tag (inner | outer | classifier-name);
inet-precedence (classifier-name | default);
}
input-scheduler-map map-name;
input-shaping-rate rate;
irb {
unit logical-unit-number {
classifiers {
dscp (classifier-name | default) {
family [ inet mpls ];
}
dscp-ipv6 (classifier-name | default) {
family [ inet mpls ];
exp (classifier-name | default);
ieee-802.1 (classifier-name | default) vlan-tag (inner | outer | transparent);
}
rewrite-rules {
dscp (rewrite-name | default);
dscp-ipv6 (rewrite-name | default);
exp (rewrite-name | default)protocol protocol-types;
ieee-802.1 (rewrite-name | default) vlan-tag (outer | outer-and-inner);
inet-precedence (rewrite-name | default);
}
}

}
output-forwarding-class-map forwarding-class-map-name;
member-link-scheduler (replicate | scale);
rewrite-rules {
ieee-802.1 (rewrite-name | default) vlan-tag (outer);
}
}
scheduler-map-chassis map-name;
shaping-rate rate;
classifiers {
(dscp | dscp-ipv6 | exp | ieee-802.1 | inet-precedence) (classifier-name | default)
family (mpls | inet);
}
fragmentation-map map-name;
input-scheduler-map map-name;
input-shaping-rate (percent percentage | rate);
input-traffic-control-profile profile-name shared-instance instance-name;
loss-priority-maps {
frame-relay-de (name | default);
}
loss-priority-rewrites {
frame-relay-de (name | default);
}
output-traffic-control-profile profile-name shared-instance instance-name;
per-session-scheduler;
rewrite-rules {
dscp (rewrite-name | default)protocol protocol-types;
exp (rewrite-name | default)protocol protocol-types;
exp-push-push-push default;
exp-swap-push-push default;
inet-precedence (rewrite-name | default)protocol protocol-types;
}
shaping-rate rate;
translation-table (to-dscp-from-dscp | to-dscp-ipv6-from-dscp-ipv6 |
to-exp-from-exp | to-inet-precedence-from-inet-precedence) table-name;
}
}
}
loss-priority-maps {
frame-relay-de (Defining Loss Priority Maps)name {
loss-priority levelcode-points [alias | bits ];
}
}
loss-priority-rewrites {
frame-relay-de (Defining Loss Priority Maps)name {
loss-priority levelcode-point (alias | bits );
}
}

restricted-queues {
forwarding-class class-name queue queue-number;
}
rewrite-rules {
(dscp | dscp-ipv6 | exp | ieee-802.1 | ieee-802.1ad | inet-precedence) rewrite-name {
import (rewrite-name | default);
loss-priority level code-point (alias | bits);
}
}
}
routing-instances routing-instance-name {
classifiers {
exp (classifier-name | default);
dscp-ipv6 (classifier-name | default);
}
}
scheduler-maps {
map-name {
}
}
schedulers {
scheduler-name {
buffer-size (percent percentage | remainder | temporal microseconds);
drop-profile-map loss-priority (any | low | medium-low | medium-high | high)protocol
(any | non-tcp | tcp) drop-profile profile-name;
excess-priority (low | high);
excess-rate percent percentage;
excess-rate (percent percentage | proportion value);
transmit-rate (rate | percent percentage | remainder) <exact | rate-limit>;
}
}
system-defaults {
classifiers (classifier-name | exp)
traffic-control-profiles profile-name {
excess-rate (percent percentage | proportion value);
overhead-accounting (frame-mode | cell-mode) <bytes byte-value>;
shaping-rate (percent percentage | rate);
}
translation-table {
(to-dscp-from-dscp | to-dscp-ipv6-from-dscp-ipv6 | to-exp-from-exp |
to-inet-precedence-from-inet-precedence) table-name {
to-code-point value from-code-points (* | [ values ]);
}
}
tri-color;

On Juniper Networks MX Series 3D Universal Edge Routers with Enhanced Queuing DPCs,
you can configure the following CoS statements at the [edit class-of-service interfaces]
hierarchy level:
excess-bandwidth-share (proportional value | equal);
internal-node;
traffic-control-profiles profile-name;
output-traffic-control-profile-remaining profile-name;
}
[edit dynamic-profiles] Hierarchy Level
dynamic-profiles {
profile-name {
class-of-service {
interfaces {
interface-name {
classifiers {
type (classifier-name | default);
}
output-traffic-control-profile (profile-name |
$junos-cos-traffic-control-profile);
rewrite-rules {
}
}
}
}
}
scheduler-maps {
map-name {
}
}
schedulers {
(scheduler-name) {
buffer-size (percent percentage | remainder | temporal microseconds |
$junos-cos-scheduler-bs);
drop-profile-map loss-priority (any | low | medium-low | medium-high | high)
protocol (any | non-tcp | tcp) drop-profile (profile-name | predefined-variable);
excess-priority (low | high | $junos-cos-scheduler-excess-priority);
excess-rate (percent percentage | percent $junos-cos-scheduler-excess-rate);
overhead-accounting (shaping-mode) <bytes (byte-value>;
priority (priority-level | $junos-cos-scheduler-priority);
shaping-rate (rate | predefined-variable);
transmit-rate (rate | percent percentage | remainder | percent percentage
$junos-cos-scheduler-tx) <exact | rate-limit>;
}
}


excess-rate (percent percentage | proportion value | percent
$junos-cos-excess-rate);
shaping-rate (percent percentage | rate | predefined-variable);
}
}
firewall {
family family {
interface-specific;
match-order [match-order];
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
only-at-create;
filter filter-name {
interface-specific;
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
}
policer policer-name {
filter-specific;
if-exceeding {
(bandwidth-limit bps | bandwidth-percent percentage);
burst-size-limit bytes;
}
logical-bandwidth-policer;
logical-interface-policer;
physical-interface-policer;
then {
policer-action;
}
}
hierarchical-policer policer-name {
aggregate {
if-exceeding {
bandwidth-limit-limit bps;
}
then {
policer-action;
}

}
premium {
if-exceeding {
bandwidth-limit bps;
}
then {
policer-action;
}
}
}
three-color-policer policer-name {
action {
loss-priority high then discard;
}
single-rate {
(color-aware | color-blind);
committed-burst-size bytes;
committed-information-rate bps;
excess-burst-size bytes;
}
two-rate {
peak-burst-size bytes;
peak-information-rate bps;
}
}
}
}
policy-options {
prefix-listname {
ip-addresses;
dynamic-db;
}
}
interfaces {
interface-name {
family family {
access-concentrator name;
address address;
direct-connect;
duplicate-protection;
dynamic-profile profile-name;
filter {
adf {
counter;
input-precedence precedence;
not-mandatory;
output-precedence precedence;
rule rule-value;
}
input filter-name {

shared-name filter-shared-name;
}
output filter-name {
}
}
max-sessions number;
max-sessions-vsa-ignore;
rpf-check {
fail-filter filter-name;
mode loose;
}
service {
input {
service-set service-set-name {
service-filter filter-name;
}
post-service-filter filter-name;
}
output {
}
}
}
service-name-table table-name;
short-cycle-protection <lockout-time-min minimum-seconds lockout-time-max
maximum-seconds>;
unnumbered-address interface-name <preferred-source-address address>;
}
ppp-options {
chap;
pap;
}
vlan-id number;
}
vlan-tagging;
}
interface interface-name {
}
}
demux0 {
demux-options {
underlying-interface interface-name
}
demux-source {
source-prefix;
}
family family {
address address;

direct-connect;
filter {
input filter-name;
output filter-name;
}
mac-validate (loose | strict):
service-name-table table-name;
maximum-seconds>;
}
}
}
pp0 {
keepalives interval seconds;
no-keepalives;
pppoe-options {
underlying-interface interface-name;
server;
}
ppp-options {
authentication [ authentication-protocols ];
chap {
challenge-length minimum minimum-length maximum maximum-length;
}
pap;
}
family inet {
unnumbered-address interface-name;
address address;
service {
input {
}
}
output {
}
}
}
filter {
input filter-name {
}
}
}

}
}
}
}
protocols {
igmp {
accounting;
disable;
group-policy;
immediate-leave
no-accounting;
promiscuous-mode;
ssm-map ssm-map-name;
static {
group group {
source source;
}
}
version version;
}
mld {
disable;
(accounting | no-accounting);
group-policy;
immediate-leave;
oif-map;
passive;
static {
group multicast-group-address {
exclude;
group-count number;
group-increment increment;
source ip-address {
source-count number;
source-increment increment;
}
}
}
version version;
}
}
router-advertisement {
current-hop-limit number;
default-lifetime seconds;
(managed-configuration | no-managed-configuration);
max-advertisement-interval seconds;
min-advertisement-interval seconds;
(other-stateful-configuration | no-other-stateful-configuration);
prefix prefix {
(autonomous | no-autonomous);
(on-link | no-on-link);
preferred-lifetime seconds;

valid-lifetime seconds;
}
reachable-time milliseconds;
retransmit-timer milliseconds;
}
}
}
}
}
interface interface-name;
routing-options {
access {
route prefix {
next-hop next-hop;
metric route-cost;
preference route-distance;
tag route-tag;
}
}
access-internal {
route subscriber-ip-address {
qualified-next-hop underlying-interface {
mac-address address;
}
}
}
multicast {
no-qos-adjust;
}
}
}
rib routing-table-name {
access {
route prefix {
next-hop next-hop;
metric route-cost;
tag route-tag;
}
}
access-internal {
}
}
}
}
}
routing-options {
access {
route prefix {
next-hop next-hop;
metric route-cost;

tag route-tag;
}
}
access-internal {
}
}
}
multicast {
no-qos-adjust;
}
}
}
variables {
variable-name {
default-value default-value;
equals expression;
mandatory;
uid;
uid-reference;
}
}
}

Documentation
• Two-Color Policer Configuration Overview
• Three-Color Policer Configuration Overview
• Hierarchical Policer Configuration Overview
• Guidelines for Applying Traffic Policers
[edit services captive-portal-content-delivery] Hierarchy Level
services {
rule rule-name {
match-direction (input | output | input-output);
term term-name {
from {
application [junos-http, junos-https, junos-httpproxy];
destination-address address <except>;
destination-prefix-list list-name <except>;
}
then {

accept;
redirect <url>;
rewrite <destination-address address> <destination-port port-number>;
syslog;
}
}
}
rule-set rule-set-name {
[rule rule-name];
}
}
}
Related • Notational Conventions Used in Junos OS Configuration Hierarchies

Documentation
• [edit services] Hierarchy Level
[edit services radius-flow-tap] Hierarchy Level
services {
radius-flow-tap {
interfaces interface-name;
multicast-interception;
policy policy-name {
inet {
drop-policyrule-name {
from {
apply-groups group-name;
apply-groups-except group-name;
destination-address address;
destination-port port-number;
dscp dscp-value;
protocol protocol;
source-address address;
source-port port-number;
}
}
}
inet6 {
from {
dscp dscp-value;
protocol protocol;
}
}
}
}
source-ipv4-address ipv4-address;

)
}

Documentation
accounting (Dynamic IGMP Interface)
Syntax (accounting | no-accounting);
Hierarchy Level [edit dynamic-profiles profile-name protocols igmp interface interface-name],
Release Information Statement introduced in Junos OS Release 9.2.
Description Enable or disable the collection of IGMP join and leave event statistics for dynamically
created IGMP interfaces.
Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Documentation
• Recording IGMP Join and Leave Events
accounting (Dynamic MLD Interface)
Syntax (accounting | no-accounting);
Hierarchy Level [edit dynamic-profiles profile-name protocols mld interface interface-name]
Description Enable or disable the collection of MLD join and leave event statistics for a dynamic
interface.

Related • Dynamic MLD Configuration Overview on page 343

Documentation
• Dynamic IGMP Configuration Overview on page 337
• Example: Recording MLD Join and Leave Events

action
Syntax action {
}
Hierarchy Level [edit dynamic-profiles profile-name firewall three-color-policer name],

[edit firewall three-color-policer name],
[edit logical-systems logical-system-name firewall three-color-policer name]

Logical systems support introduced in Junos OS Release 9.3.
Support at the [edit dynamic-profiles ... three-color-policer] hierarchy level introduced in
Junos OS Release 11.4.
Statement introduced in Junos OS Release 12.3R2 for EX Series switches.
Description Discard traffic on a logical interface using tricolor marking policing.
NOTE: This statement is supported only on IQ2 interfaces.
The remaining statement is explained separately.
Required Privilege firewall—To view this statement in the configuration.

Level firewall-control—To add this statement to the configuration.
Related • Three-Color Policer Configuration Overview

Documentation
• Basic Single-Rate Three-Color Policers
• Basic Two-Rate Three-Color Policers
• Two-Color and Three-Color Logical Interface Policers
• Two-Color and Three-Color Physical Interface Policers
• Two-Color and Three-Color Policers at Layer 2
• loss-priority high then discard on page 601

adf (Dynamic Firewalls)
Syntax adf {
counter;
not-mandatory;
rule rule-value;
}
Hierarchy Level [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number family
family filter]

Option not-mandatory introduced in Junos OS Release 12.2.
Description Configure an Ascend-Data-Filter that the dynamic profile applies to a subscriber session.
Options counter—Enable a counter that increments each time the Ascend-Data-Filter rule is used.
Typically used for testing purposes.
not-mandatory—Suppress router from reporting an error when the RADIUS reply message
does not include the $junos-adf-rule-v4 or $junos-adf-rule-v6 variable that is
configured for the Ascend-Data-Filter in the dynamic profile. In this circumstance,
the Ascend-Data-Filter is not created.
precedence—Precedence value that sets the order in which dynamic service filters are
applied on the interface. The lower the precedence value, the higher the precedence
that is given. The precedence setting is used in conjunction with the precedence
settings of all dynamic service filters configured (not only Ascend-Data-Filters) on
the same interface to establish the order. For example, the order also includes any
configured input filter-name precedence precedence and output filter-name precedence
precedence statements.
Range: 0 through 255
Default: 0
rule-value—Ascend-Data-Filter rule. You can specify either a Junos predefined variable

that maps the Ascend-Data-Filter actions to Junos filter functionality or you can
manually configure the Ascend-Data-Filter rule. The router supports two predefined
variables depending on family type: $junos-adf-rule-v4 for family inet and
$junos-adf-rule-v6 for family inet6.
Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Documentation

• Guidelines for Configuring Service Filters
adjustment-control-profiles
Syntax adjustment-control-profiles {
profile-name {
application {
ancp;
radius-coa;
pppoe-tags;
}
}
}
Hierarchy Level [edit class-of-service]
Description Configure the CoS adjustment control profile.
Options profile-name—Name of the adjustment control profile.
The remaining statements are explained separately.
Required Privilege interfaces—To view this statement in the configuration.


Documentation

adjust-minimum (Dynamic Shaping and Scheduling)
Syntax adjust-minimum (rate | $junos-cos-adjust-minimum);
Hierarchy Level [edit dynamic-profiles profile-name class-of-service schedulers scheduler-name],

traffic-control-profile-name]
Description For adjustments performed by the ANCP or multicast applications on EQ DPCs and
MPC/MIC interfaces, specify the minimum shaping rate for an adjusted scheduler node.
The node is associated with a traffic-control profile.
For adjustments performed by the multicast application on MPC/MIC interfaces, specify

the minimum shaping rate for an adjusted queue. The queue is associated with a
scheduler.
Options rate—Minimum shaping rate for a node or a queue, in Mbps
$junos-cos-adjust-minimum—Junos OS predefined variable that is replaced with the

minimum shaping rate for a node that is obtained from the RADIUS server when a
subscriber authenticates over the interface to which the dynamic profile is attached.
Use this variable at the [edit dynamic-profiles profile-name class-of-service
traffic-control-profiles] hierarchy level.

Related • Configuring a Dynamic Minimum Adjusted Shaping Rate on Scheduler Nodes on page 102
Documentation
• Configuring a Dynamic Shaping-Rate Adjustment for Queues on page 103

adjust-percent (Dynamic Schedulers)
Syntax adjust-percent percentage;
Hierarchy Level [edit dynamic-profiles profile-name class-of-service schedulers scheduler-name]
Description For a MPC/MIC interface, determine the percentage of adjustment for the shaping rate
of a queue.
Options percentage—Percentage of the shaping rate to adjust.

Range: 0 through 100 percent

Related • Configuring a Dynamic Shaping-Rate Adjustment for Queues on page 103

Documentation

aggregate (Hierarchical Policer)
Syntax aggregate {
if-exceeding {
bandwidth-limit bandwidth;
burst-size-limit burst;
}
then {
discard;
}
}
Hierarchy Level [edit dynamic-profiles profile-name firewall hierarchical-policer name],

[edit firewall hierarchical-policer]

Support at the [edit dynamic-profiles ... hierarchical-policer name] hierarchy level
introduced in Junos OS Release 11.4.
Description On M40e, M120, and M320 edge routers with Flexible PIC Concentrator (FPC) input as
FFPC and FPC output as SFPC, and on MX Series, T320, T640, and T1600 edge routers
with Enhanced Intelligent Queuing (IQE) PICs, T4000 routers with Type 5 FPC and
Enhanced Scaling Type 4 FPC, configure an aggregate hierarchical policer.

Related • Hierarchical Policer Configuration Overview

Documentation
• Hierarchical Policers
• bandwidth-limit (Hierarchical Policer)
• premium on page 626

ancp (Adjustment Control Profiles)
Syntax ancp {
priority priority;
algorithm algorithm;
}
Hierarchy Level [edit class-of-service adjustment-control-profiles profile-name application]
Description Configure the shaping rate adjustment controls for the ANCP application.
Options priority—Priority of the ANCP application in the adjustment control profile.

Range: 1 through 10; 1 being the highest priority.
Default: 1
algorithm—Rate adjustment algorithm used by the ANCP application.

Values:
• adjust-never—Do not perform rate adjustments.
• adjust-always—Adjust the shaping rate unconditionally.
• adjust-less—Adjust the shaping rate if it is less than the configured value.
• adjust-less-or equal—Adjust the shaping rate if it is less than or equal to the

configured value.
• adjust-greater—Adjust the shaping rate if it is greater than the configured value.
• adjust-greater-or-equal—Adjust the shaping rate if it is greater than or equal to

the configured value.
Default: adjust-always


Documentation

application (Adjustment Control Profiles)
Syntax application {
ancp;
radius-coa;
pppoe-tags;
}
Hierarchy Level [edit class-of-service adjustment-control-profiles profile-name]
Description Configure which applications in the adjustment control profile can make shaping rate
adjustments.


Documentation
application (Captive Portal Content Delivery)
Syntax application application-name;
Hierarchy Level [edit services captive-portal-content-delivery rule rule-name term term-name from (Captive
Portal Content Delivery)]
Description Identify the application for inclusion in a rule.
Options application-name—Application for rule to match, junos-http, junos-https, or junos-httpproxy.


Documentation

apply-groups (Subscriber Secure Policy)
Syntax apply-groups group-name;
Hierarchy Level [edit services radius-flow-tap policy policy-name inet drop-policy rule-name from],
[edit services radius-flow-tap policy policy-name inet6 drop-policy rule-name from]
Description Specify groups from which to inherit configuration data for the radius-flow-tap policy.
Options group-name— Name of the group that inherits the configuration data.
Required Privilege flow-tap—To view this statement in the configuration.

Level flow-tap-control—To add this statement to the configuration.

Documentation
apply-groups-except (Subscriber Secure Policy)
Syntax apply-groups-except group-name;
Description Specify groups from which to inherit configuration data for the radius-flow-tap policy.
Options group-name— Name of the group that does not inherit the configuration data.


Documentation

authentication (Login)
Syntax authentication {
(encrypted-password "password" | plain-text-password);
load-key-file URL filename;
ssh-dsa "public-key";
ssh-ecdsa "public-key";
ssh-rsa "public-key";
}
Hierarchy Level [edit system login user username]
Release Information Statement introduced before Junos OS Release 7.4.

Statement introduced in Junos OS Release 9.0 for EX Series switches.
Description Authentication methods that a user can use to log in to the router or switch. You can
assign multiple authentication methods to a single user.
Options encrypted-password "password"—Message Digest 5 (MD5) or other encrypted

authentication. Specify the MD5 or other password. You can specify only one
encrypted password for each user.
You cannot configure a blank password for encrypted-password using blank quotation
marks (" "). You must configure a password whose number of characters range from
1 through 128 characters and enclose the password in quotation marks.
load-key-file URL filename—Load previously-generated RSA (SSH version 1 and SSH

version 2) and DSA (SSH version 2) public keys from a named file at a specified URL
location. The file contains one or more SSH keys.
plain-text-password—When using this option, the command-line interface (CLI) prompts

you for the password and then encrypts it.
ssh-dsa "public-key"—SSH version 2 authentication. Specify the DSA public key. You can
specify one or more public keys for each user.
ssh-ecdsa "public-key"—SSH version 2 authentication. Specify the ECDSA public key.

You can specify one or more public keys for each user.
ssh-rsa "public-key"—SSH version 1 and SSH version 2 authentication. Specify the RSA
public key. You can specify one or more public keys for each user.
Required Privilege admin—To view this statement in the configuration.

Level admin-control—To add this statement to the configuration.
Related • Configuring Junos OS User Accounts by Using a Configuration Group

Documentation
• root-authentication

authentication-order
Syntax authentication-order [ authentication-methods ];
Hierarchy Level [edit access profile profile-name]

none option added in Junos OS Release 11.2.
Description Set the order in which the Junos OS tries different authentication methods when verifying
that a client can access the router or switch. For each login attempt, the software tries
the authentication methods in order, from first to last.
Default password
Options authentication-methods
• none—Grants authentication without examining the client credentials. Can be used,

for example, when the Diameter function Gx-Plus is employed for notification during
subscriber provisioning.
• password—Verify the client using the information configured at the [edit access profile
profile-name client client-name] hierarchy level.
• radius—Verify the client using RADIUS authentication services.
NOTE: For subscriber access management, you must always specify the
radius method. Subscriber access management does not support the
password option (the default), and authentication fails when no method
is specified.

Related • Example: Configuring CHAP Authentication with RADIUS

Documentation
• Specifying the Authentication and Accounting Methods for Subscriber Access
• Configuring Access Profiles for L2TP or PPP Parameters

authentication-server
Syntax authentication-server [ ip-address ];
Hierarchy Level [edit access profile profile-name radius]
Description Specify a list of the RADIUS authentication servers used to authenticate DHCP, L2TP,
and PPP clients. The servers in the list are also used as RADIUS dynamic-request servers,
from which the router accepts and processes RADIUS disconnect requests, CoA requests,
and dynamic service activations and deactivations.
Options ip-address—IPv4 address.

Related • Configuring RADIUS Server Parameters for Subscriber Access

Documentation

bandwidth (Tunnel Services)
Syntax bandwidth bandwidth-value;
Hierarchy Level [edit chassis fpc slot-number pic number tunnel-services]
Description (MX Series 3D Universal Edge Routers and T4000 Core Routers only) Specify the amount
of bandwidth in gigabits per second to reserve for tunnel services.
Options bandwidth-value—Define the amount of bandwidth in gigabits per second to reserve for
tunnel services. On MX Series routers, the bandwidth values can be 1g, 10g, 20g, or
40g. On T4000 routers, the bandwidth values are multiples of 10g up to 100g.
NOTE: The bandwidth that you specify determines the port number of the
tunnel interfaces that are created. When you specify a bandwidth of 1g, the
port number is always 10. When you specify any other bandwidth, the port
number is always 0.
NOTE: If you specify a bandwidth that is not compatible with the type of
DPCs or MPCs and their respective Packet Forwarding Engine, tunnel services
are not activated. For example, you cannot specify 1 gigabit per second
bandwidth for a Packet Forwarding Engine on a 10-Gigabit Ethernet 4-port
DPC.
NOTE: Bandwidth rates of 20 gigabits per second and 40 gigabits per second
require use of an MX Series router with the MPC3E and the 100-Gigabit CFP
MIC.

Related • Example: Configuring Tunnel Interfaces on a Gigabit Ethernet 40-Port DPC

Documentation
• Configuring Tunnel Interfaces on MX Series Routers
• Configuring Tunnel Interfaces on T4000 Routers
• Example: Configuring Tunnel Interfaces on a 10-Gigabit Ethernet 4-Port DPC
• Example: Configuring Tunnel Interfaces on the MPC3E
• Configuring Layer 3 Tunnel Services Interfaces on an MX Series Router with a DPC

• tunnel-services (Chassis) on page 676
• [edit chassis] Hierarchy Level

bandwidth-limit (Policer)
Syntax bandwidth-limit bps;
Hierarchy Level [edit dynamic-profiles profile-name firewall policer policer-name if-exceeding],

[edit firewall policer policer-name if-exceeding],
[edit logical-systems logical-system-name policer policer-name if-exceeding]

Support at the [edit dynamic-profiles ... if-exceeding] hierarchy level introduced in Junos
OS Release 11.4.
Description For a single-rate two-color policer, configure the bandwidth limit as a number of bits per
second. Single-rate two-color policing uses the single token bucket algorithm to measure
traffic-flow conformance to a two-color policer rate limit.
Traffic at the interface that conforms to the bandwidth limit is categorized green. Traffic
that exceeds the specified rate is also categorized as green provided that sufficient tokens
remain in the single token bucket. Packets in a green flow are implicitly marked with low
packet loss priority (PLP) and then passed through the interface.
Traffic that exceeds the specified rate when insufficient tokens remain in the single token
bucket is categorized red. Depending on the configuration of the two-color policer, packets
in a red traffic flow might be implicitly discarded; or the packets might be re-marked with
a specified forwarding class, a specified PLP, or both, and then passed through the
interface.
NOTE: This statement specifies the bandwidth limit as an absolute number

of bits per second. Alternatively, 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 configured logical interface shaping rate.
Single-rate two-color policing allows bursts of traffic for short periods, whereas single-rate
and two-rate three-color policing allows more sustained bursts of traffic.
Hierarchical policing is a form of two-color policing that applies different policing actions
based on whether the packets are classified for expedited forwarding (EF) or for a lower
priority. You apply a hierarchical policer to ingress Layer 2 traffic to allows bursts of EF
traffic for short period and bursts of non-EF traffic for short periods, with EF traffic always
taking precedence over non-EF traffic.
Options bps—You can specify the number of bits per second either as a decimal number or as a
decimal number followed by the abbreviation k (1000), m (1,000,000), or g
(1,000,000,000).
Range: (M Series, MX Series, and T Series routers) 8000 through 100,000,000,000

Default: None.

Related • Two-Color Policer Configuration Overview

Documentation
• Policer Bandwidth and Burst-Size Limits
• Policer Color-Marking and Actions
• Single Token Bucket Algorithm
• Determining Proper Burst Size for Traffic Policers

bandwidth-percent
Syntax bandwidth-percent percentage;


OS Release 11.4.
Description For a single-rate two-color policer, configure the bandwidth limit as a percentage value.
Single-rate two-color policing uses the single token bucket algorithm to measure
traffic-flow conformance to a two-color policer rate limit.
packet loss priority and then passed through the interface.
interface.
NOTE: This statement specifies the bandwidth limit as a percentage of either

the physical interface port speed or the configured logical interface shaping
rate. Alternatively, you can use the bandwidth-limit bps statement to specify
the bandwidth limit as an absolute number of bits per second.
The function of the bandwidth limit is extended by the burst size (configured using the
burst-size-limit bytes statement) to allow bursts of traffic up to a limit based on the
overall traffic load:
• When a single-rate two-color policer is applied to the input or output traffic at an

interface, the initial capacity for traffic bursting is equal to the number of bytes specified
by this statement.
• During periods of relatively low traffic (traffic that arrives at or departs from the interface
at overall rates below the token arrival rate), unused tokens accumulate in the bucket,
but only up to the configured token bucket depth.

Options percentage—Traffic rate as a percentage of either the physical interface media rate or
the logical interface configured shaping rate. You can configure a shaping rate on a
logical interface by using class-of-service statement.
NOTE: You cannot rate-limit based on bandwidth percentage for tunnel or

software interfaces. The bandwidth percentage policer also cannot be used
for forwarding table filters. Bandwidth percentage policers can only be used
for interface-specific filters. Bandwidth percentage policers applied on an
aggregated Ethernet bundle or an aggregated SONET bundle do match the
effective bandwidth and burst-size to user-configured values by default and
do not require shared-bandwidth-policer configuration.

Default: None.


Documentation
• Bandwidth Policers

buffer-size (Dynamic Scheduling)
Syntax buffer-size (percent (percentage | $junos-cos-scheduler-bs) | remainder | temporal

(microseconds | $junos-cos-scheduler-bs));

The $junos-cos-scheduler-bs predefined variable introduced in Junos OS Release 9.4.
Description Specify buffer size.
Default If you do not include this statement, the default scheduler transmission rate and buffer
size percentages for queues 0 through 7 are 95, 0, 0, 5, 0, 0, 0, and 0 percent.
Options percent percentage—Buffer size as a percentage of total buffer.
remainder—Remaining buffer available.
temporal microseconds—Buffer size as a temporal value. The queuing algorithm starts

dropping packets when it queues more than a computed number of bytes. This
maximum is computed by multiplying the logical interface speed by the configured
temporal value.
Range: The ranges vary by platform as follows:
• For IQ PICs on M320 routers: 1 through 50,000 microseconds.
• For IQ PICs on other M Series routers: 1 through 100,000 microseconds.
• For other M Series routers: 1 through 200,000 microseconds.
$junos-scheduler-bs—Junos predefined variable that is replaced with the buffer size

obtained from the RADIUS server when a subscriber authenticates over the interface
to which the dynamic profile is attached.

Documentation

burst-size-limit (Hierarchical Policer)
Syntax burst-size-limit bytes;
Hierarchy Level [edit dynamic-profiles profile-name firewall hierarchical-policer aggregate if-exceeding],

[editdynamic-profiles profile-name firewall hierarchical-policer premium if-exceeding],
[edit firewall hierarchical-policer aggregate if-exceeding],
[edit firewall hierarchical-policer premium if-exceeding]

Support at the [edit dynamic-profiles ... if exceeding] hierarchy level introduced in Junos
OS Release 11.4.
Description On M40e, M120, and M320 (with FFPC and SFPC) edge routers; on MPCs hosted on MX
Series routers; on T320, T640, and T1600 core routers with Enhanced Intelligent Queuing
(IQE) PICs; and on T4000 routers with Type 5 FPC and Enhanced Scaling Type 4 FPC,
configure the burst-size limit for premium or aggregate traffic in a hierarchical policer.
Options bytes—Burst-size limit in bytes. The minimum recommended value is the maximum
transmission unit (MTU) of the IP packets being policed. You can specify the value
either as a complete decimal number or as a decimal number followed by the
abbreviation k (1000), m (1,000,000), or g (1,000,000,000).
Range: 1500 through 2,147,450,880 (1500 through 100,000,000,000 on MPCs hosted
on MX Series routers)


Documentation

burst-size-limit (Policer)
Syntax burst-size-limit bytes;


OS Release 11.4.
Description For a single-rate two-color policer, configure the burst size as a number of bytes. The
burst size allows for short periods of traffic bursting (back-to-back traffic at average
rates that exceed the configured bandwidth limit). Single-rate two-color policing uses
the single token bucket algorithm to measure traffic-flow conformance to a two-color
policer rate limit.
packet loss priority and then passed through the interface.
interface.
The burst size extends the function of the bandwidth limit (configured using either the
bandwidth-limit bps statement or the bandwidth-percent percentage statement) to allow
bursts of traffic up to a limit based on the overall traffic load:
• When a single-rate two-color policer is applied to the input or output traffic at an

interface, the initial capacity for traffic bursting is equal to the number of bytes specified
by this statement.
• During periods of relatively low traffic (traffic that arrives at or departs from the interface
at overall rates below the token arrival rate), unused tokens accumulate in the bucket,
but only up to the configured token bucket depth.

Table 51 on page 502 summarizes the relationship between the bandwidth-limit and the
token arrival rate. This information is useful in calculating the minimum burst-size-limit.
Table 51: Bandwidth Limits and Token Rates

Bandwidth Limit Token Rate
0-333 Mbps low (262 µs)
334-666 Mbps high (8.2 µs)
667-1333 Mbps low
1334 Mbps and above high
The burst-size limit enforced is based on the burst-size limit you configure. For a
rate-limited logical interface, the Packet Forwarding Engine calculates the optimum
burst-size-limit values and then applies the value closest to the burst-size-limit value
specified in the policer configuration.
On MX Series routers and EX Series switches, the burst-size limit is not as freely
configurable as it is on other platforms. Junos OS does not support an unlimited
combination of policer bandwidth and burst-size limits on MX Series routers and EX
Series switches. For a single-rate two-color policer on an MX Series router and on an EX
Series switch, the minimum supported burst-size limit is equivalent to the amount of
traffic allowed by the policer bandwidth limit in a time span of 1 millisecond. For example,
for a policer configured with a bandwidth-limit value of 1 Gbps, the minimum supported
value for burst-size-limit on an MX Series router is 125 KB. If you configure a value that is
smaller than the minimum, Junos OS overrides the configuration and applies the actual
minimum.
Options bytes—Burst-size limit in bytes. The minimum recommended value is the maximum
transmission unit (MTU) of the IP packets being policed. You can specify the value
Range: 1500 through 100,000,000,000
Default: None



Documentation
bytes (Dynamic Traffic Shaping)
Syntax bytes bytes | $junos-cos-byte-adjust;
Hierarchy Level [edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name

overhead-accounting],
[edit class-of-service traffic-control-profiles profile-name overhead-accounting]
Description Configure the number of overhead bytes.
Options bytes—Byte adjustment value for the cell-mode or frame-mode shaping options. This can
be the predefined variable $junos-cos-byte-adjust, which is the variable for byte
adjustment that is replaced with a value obtained from the RADIUS server when a
subscriber authenticates over the interface to which the dynamic profile is attached.
BEST PRACTICE: We recommend using the cell-mode cell-mode-bytes

cell-mode-bytes option or the frame-mode frame-mode-bytes frame-mode-bytes
option rather than the bytes option.


Documentation
• egress-shaping-overhead

captive-portal-content-delivery (Captive Portal Content Delivery)
Syntax captive-portal-content-delivery {
rule rule-name {
term term-name {
from {
}
then {
accept;
redirect <url>;
syslog;
}
}
}
[rule rule-name];
}
}
Hierarchy Level [edit services]
Description Configure the HTTP redirect service by specifying the location to which a subscriber's
initial Web browser session is redirected, enabling initial provisioning and service selection
for the subscriber.
Required Privilege services—To view this statement in the configuration.

Level services–control—To add this statement to the configuration.

Documentation

cell-mode (Dynamic Traffic Shaping)
Syntax cell-mode (bytes bytes | $junos-cos-byte-adjust | cell-mode-bytes cell-mode-bytes

|$junos-cos-byte-adjust-cell);

[edit class-of-service traffic-control-profiles profile-name overhead-accounting],

Variable $junos-cos-byte-adjust-cell introduced in Junos OS Release 13.1.
Description Configure the mode to shape downstream ATM traffic as cells.
Options bytes—Byte adjustment value for the cell-mode or frame-mode shaping options.
$junos-cos-byte-adjust—Predefined variable for byte adjustment that is replaced with a

value obtained from the RADIUS server when a subscriber authenticates over the
interface to which the dynamic profile is attached.
cell-mode-bytes cell-mode-bytes—Shaping is based on the number of bytes in cells, and

accounts for the ATM cell encapsulation and padding overhead. The resulting traffic
stream conforms to the policing rates configured in downstream ATM switches,
reducing the number of packet drops in the Ethernet network.
$junos-cos-byte-adjust-cell—Predefined variable for the cell mode shaping. This variable

can not be used when the overhead-accounting bytes bytes option is configured.
BEST PRACTICE: We recommend using the cell-mode-bytes cell-mode-bytes

option rather than the bytes option.
Range: –120 through 124 bytes
NOTE: If you specify a value for the bytes bytes option, you cannot specify a
value for either the cell-mode-bytes option.
NOTE: Cell mode is supported only on logical interfaces and interface sets;
it is not supported on physical interfaces (ifd or ifd-remaining).
Default: The default is frame-mode.



Documentation

• bytes on page 503
• frame-mode on page 561
class (Assigning a Class to an Individual User)
Syntax class class-name;
Hierarchy Level [edit system login user username]

Description Assign a user to a login class. You must assign each user to a login class.
Options class-name—One of the classes defined at the [edit system login class] hierarchy level.


Documentation

class (Defining Login Classes)
Syntax class class-name {

allow-commands "regular-expression";
( allow-configuration | allow-configuration-regexps) “regular expression 1” “regular
expression 2”;
configuration-breadcrumbs;
deny-commands "regular-expression";
( deny-configuration | deny-configuration-regexps ) “regular expression 1” “regular expression
2 ”;
idle-timeout minutes;
login-script filename;
login-tip;
permissions [ permissions ];
}
Hierarchy Level [edit system login]

Description Define a login class.
Options class-name—A name you choose for the login class.

Related • Defining Junos OS Login Classes

Documentation
• user on page 683

class-of-service (Dynamic Profiles)
Syntax class-of-service { ... }
Hierarchy Level [edit dynamic-profiles profile-name]
Description Configure Junos OS CoS features in a dynamic profile.
Default If you do not configure any CoS features, all packets are transmitted from output
transmission queue 0.

Documentation
classifiers (Dynamic CoS Application)
Syntax classifiers {
ieee-802.1 (classifier-name | default) vlan-tag (inner | outer)
}
Hierarchy Level [edit dynamic-profiles profile-name class-of-service interfaces interface-name unit

Description Apply a CoS behavior aggregate classifier to a dynamic interface. You can apply a default
classifier or one that is previously defined.
Options The remaining statements are explained separately.

Documentation
• classifiers (Definition)

color-aware
Syntax color-aware;
Hierarchy Level [edit dynamic-profiles profile-name firewall three-color-policer name single-rate],

[edit dynamic-profiles profile-name firewall three-color-policer name two-rate],
[edit firewall three-color-policer policer-name single-rate],
[edit firewall three-color-policer policer-name two-rate]

Support at the [edit dynamic-profiles ... single-rate] and [edit dynamic-profiles ... two-rate]
hierarchy levels introduced in Junos OS Release 11.4.
Description For a three-color policer, configure the way preclassified packets are metered. In
color-aware mode, the local router can assign a higher packet loss priority, but cannot
assign a lower packet loss priority.
For example, suppose an upstream router assigned medium-high packet loss priority to
a packet because the packet exceeded the committed information rate on the upstream
router interface.
• If the local router applies color-aware policing to the packet, the router cannot change
the packet loss priority to low, even if the packet conforms to the configured committed
information route on the local router interface.
• If the local router applies color-blind policing to the packet, the router can change the
packet loss priority to low if the packet conforms to the configured committed
NOTE: A color-aware policer cannot be applied to Layer 2 traffic.
Default If you omit the color-aware statement, the default behavior is color-aware mode.


Documentation
• Color Modes for Three-Color Policers

color-blind
Syntax color-blind;


Description For a three-color policer, configure the way preclassified packets are metered. In
color-blind mode, the local router ignores the preclassification of packets and can assign
a higher or lower packet loss priority.
For example, suppose an upstream router assigned medium-high packet loss priority to
a packet because the packet exceeded the committed information rate on the upstream
router interface.
• If the local router applies color-aware policing to the packet, the router cannot change
the packet loss priority to low, even if the packet conforms to the configured committed
NOTE: A color-aware policer cannot be applied to Layer 2 traffic.
• If the local router applies color-blind policing to the packet, the router can change the
packet loss priority to low if the packet conforms to the configured committed
Default If you omit the color-blind statement, the default behavior is color-aware mode.


Documentation
• Color Modes for Three-Color Policers

committed-burst-size
Syntax committed-burst-size bytes;


Description For a three-color policer, configure the committed burst size (CBS) as a number of bytes.
NOTE: When you include the committed-burst-size statement in the

configuration, you must also include the committed-information-rate
statement at the same hierarchy level.
In three-color policing, a committed information rate (CIR) defines the guaranteed

bandwidth for traffic arriving at or departing from the interface under normal line
conditions. A flow of traffic at an average rate that conforms to the CIR is categorized
green.
During periods of average traffic rates below the CIR, any unused bandwidth capacity
accumulates up to a maximum amount defined by the CBS. Short periods of bursting
traffic (back-to-back traffic at averages rates that exceed the CIR) are also categorized
as green provided that unused bandwidth capacity is available.
Traffic that exceeds both the CIR and the CBS is considered nonconforming.
Single-rate three-color policers use a dual token bucket algorithm to measure traffic
against a single rate limit. Nonconforming traffic is categorized as yellow or red, based
on the excess-burst-size statement included in the policer configuration.
Two-rate three-color policers use a dual-rate dual token bucket algorithm to measure
traffic against two rate limits. Nonconforming traffic is categorized as yellow or red based
on the peak-information-rate and peak-burst-rate statements included in the policer
configuration.
Options bytes—Number of bytes. You can specify a value in bytes either as a complete decimal
number or as a decimal number followed by the abbreviation k (1000),
m (1,000,000), or g (1,000,000,000).
Range: 1500 through 100,000,000,000 bytes



Documentation
• Dual Token Bucket Algorithms

committed-information-rate
Syntax committed-information-rate bps;


Description For a three-color policer, configure the committed information rate as a number of bits
per second. The committed information rate (CIR) is the guaranteed bandwidth for traffic
arriving at or departing from the interface under normal line conditions.
NOTE: When you include the committed-information-rate statement in the

configuration, you must also include the committed-burst-size statement at
the same hierarchy level.
In three-color policing, a CIR defines the guaranteed bandwidth for traffic arriving at or
departing from the interface under normal line conditions. A flow of traffic at an average
rate that conforms to the CIR is categorized green.
During periods of average traffic rates below the CIR, any unused bandwidth capacity
accumulates up to a maximum amount defined by the committed burst size (CBS). Short
periods of bursting traffic (back-to-back traffic at averages rates that exceed the CIR)
are also categorized as green provided that unused bandwidth capacity is available.
Single-rate three-color policers use a dual token bucket algorithm to measure traffic
against a single rate limit. Nonconforming traffic is categorized as yellow or red, based
traffic against two rate limits. Nonconforming traffic is categorized as yellow or red based
on the peak-information-rate and peak-burst-rate statements included in the policer
configuration.
Options bps—Number of bits per second. You can specify a value in bits per second either as a
complete decimal number or as a decimal number followed by the abbreviation
k (1000), m (1,000,000), or g (1,000,000,000).
Range: 1500 through 100,000,000,000 bps



Documentation

connection-limit
Syntax connection-limit limit;
Hierarchy Level [edit system services finger],

[edit system services ftp],
[edit system services netconf ssh],
[edit system services ssh],
[edit system services telnet],
[edit system services xnm-clear-text],
[edit system services xnm-ssl]

Statement introduced in Junos OS Release 11.1 for the QFX Series.
Description Configure the maximum number of connections sessions for each type of system services
(finger, ftp, ssh, telnet, xnm-clear-text, or xnm-ssl) per protocol (either IPv6 or IPv4).
Options limit—(Optional) Maximum number of established connections per protocol (either IPv6
or IPv4).
Default: 75
NOTE: The actual number of maximum connections depends on the

availability of system resources, and might be fewer than the configured
connection-limit value if the system resources are limited.
Required Privilege system—To view this statement in the configuration.

Level system-control—To add this statement to the configuration.
Related • Configuring clear-text or SSL Service for Junos XML Protocol Client Applications
Documentation
• Configuring DTCP-over-SSH Service for the Flow-Tap Application
• Configuring Finger Service for Remote Access to the Router
• Configuring FTP Service for Remote Access to the Router or Switch
• Configuring SSH Service for Remote Access to the Router or Switch
• Configuring Telnet Service for Remote Access to a Router or Switch

delay-buffer-rate (Dynamic Traffic Shaping)
Syntax delay-buffer-rate (percent percentage | rate | $junos-cos-delay-buffer-rate);
Hierarchy Level [edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name]

The $junos-cos-delay-buffer-rate variable introduced in Junos OS Release 9.4.
Description Base the delay-buffer calculation on a delay-buffer rate.
Default If you do not include this statement, the delay-buffer calculation is based on the
guaranteed rate if one is configured, or the shaping rate if no guaranteed rate is configured.
Options rate—Delay-buffer rate, in bits per second (bps). You can specify a value in bits per second
Range: 1000 through 6,400,000,000,000 bps
$junos-cos-delay-buffer-rate—Junos predefined variable that is replaced with the

delay-buffer rate obtained from the RADIUS server when a subscriber authenticates
over the interface to which the dynamic profile is attached.

Documentation
• output-traffic-control-profile on page 610

destination-address (Captive Portal Content Delivery)
Syntax destination-address address <except>;
Hierarchy Level [edit services captive-portal-content-delivery rule rule-name term term-name from (Captive
Portal Content Delivery)]
Description Specify the destination address for rule matching.
Options address—Destination IPv4 or IPv6 address or prefix value.
except—(Optional) Exclude the specified prefix list from rule matching.


Documentation
destination-address (Subscriber Secure Policy)
Syntax destination-address address;
Description Specify destination IP address or prefix value for radius-flow-tap policy rule mapping.
Options address— IPv4 or IPv6 address for the radius-flow-tap policy.


Documentation

destination-prefix-list (Captive Portal Content Delivery)
Syntax destination-prefix-list list-name <except>;
Hierarchy Level [edit services captive-portal-content-delivery rule rule-name term term-name from]
Description Specify the destination prefix list for rule matching. You configure the prefix list by including
the prefix-list statement at the [edit policy-options] hierarchy level.
Options list-name—Destination prefix list.
except—(Optional) Exclude the specified prefix list from rule matching.


Documentation
• Understanding Prefix Lists for Use in Routing Policy Match Conditions
destination-port (Subscriber Secure Policy)
Syntax destination-port port-number;
Description Specify the destination IP address for the radius-flow-tap policy.
Options port-number— Number of the IPv4 or IPv6 destination port for the radius-flow-tap policy.


Documentation

disable (Dynamic IGMP)
Syntax "disable:$junos-igmp-enable";
Description Disable IGMP on the interface.
NOTE: Though the purpose of this statement is to disable IGMP on interfaces,

under the dynamic-profiles hierarchy you can use this statement and an enable
variable (disable:$junos-igmp-enable) to ensure that IGMP is not disabled by
a AAA-based authentication and management method (RADIUS).


Documentation
• Disabling IGMP
disable (Dynamic MLD)
Syntax disable;
Description Disable MLD on the dynamic interface.


Documentation
• Disabling MLD

drop-policy (Subscriber Secure Policy)
Syntax drop-policy rule-name {

from {
dscp dscp-value;
protocol protocol;
}
}
Hierarchy Level [edit services radius-flow-tap policy policy-name inet| inet6]
Description Specify the drop-policy that is applied to mirrored packets sent to a mediation device.
Options rule-name–Define the term name.


Documentation

drop-profile (Dynamic Schedulers)
Syntax drop-profile (profile-name | predefined-variable);
Hierarchy Level [edit dynamic-profiles profile-name class-of-service schedulers scheduler-name

drop-profile-map loss-priority (any | low | medium-low | medium-high | high) protocol
(any | non-tcp | tcp)]

The $junos-cos-scheduler-dropfile-low, $junos-cos-scheduler-dropfile-medium-low,
$junos-cos-scheduler-dropfile-medium-high, $junos-cos-scheduler-dropfile-high, and
$junos-cos-scheduler-dropfile-any predefined variable introduced in Junos OS Release
9.4.
Description Within the drop-profile map, specify the name of the drop profile to use for random early
detection (RED) for a specific packet-loss priority (PLP) level and protocol type. A drop
profile maps a fill level (fullness of a queue) to a drop probability (probability that a
packet will be dropped). When a packet arrives, RED checks the queue fill level. If the fill
level corresponds to a nonzero drop probability, the RED algorithm determines whether
to drop the arriving packet.
You enable RED by applying a drop profile to a scheduler.
You configure drop profiles statically (at the [edit class-of-service drop-profiles] hierarchy
level).
Options profile-name—Name of the drop profile.
predefined-variable—One of the following Junos predefined variable that is replaced with

a value obtained from the RADIUS server when a subscriber authenticates over the
interface to which the dynamic profile is attached:
• $junos-cos-scheduler-dropfile-low—Name of the drop profile for PLP level low and

protocol any, specified for a scheduler configured in a dynamic profile for subscriber
access.
• $junos-cos-scheduler-dropfile-medium-low—Name of the drop profile for PLP level

medium-low and protocol any, specified for a scheduler configured in a dynamic profile
• $junos-cos-scheduler-dropfile-medium-high—Name of the drop profile for PLP level

medium-high and protocol any, specified for a scheduler configured in a dynamic profile
• $junos-cos-scheduler-dropfile-high—Name of the drop profile for PLP level high and

access.
• $junos-cos-scheduler-dropfile-lny—Name of the drop profile for PLP level any and

access.


Documentation
• Configuring Drop Profile Maps for Schedulers
drop-profile-map (Dynamic Schedulers)
Syntax drop-profile-map loss-priority (any | low | medium-low | medium-high | high) protocol (any
| non-tcp | tcp) drop-profile (profile-name | predefined-variable);
Description Define loss priority value for drop profile.
The statements are explained separately.

Documentation

dscp (Dynamic Classifiers)
Syntax dscp (classifier-name | default);

Description For IPv4 traffic, apply a Differentiated Services (DiffServ) code point (DSCP) classifier
to a subscriber interface in a dynamic profile.
Options classifier-name—Name of a classifier mapping configured at the [edit class-of-service

classifier dscp] hierarchy level.
default—The default mapping.

Documentation

dscp (Dynamic Rewrite Rules)
Syntax dscp (rewrite-name | default);

Description For IPv4 traffic, apply a Differentiated Services (DiffServ) code point (DSCP) rewrite rule
Options rewrite-name—Name of a rewrite-rules mapping configured at the [edit class-of-service

rewrite-rules dscp] hierarchy level.

Documentation
page 219
• rewrite-rules
dscp (Subscriber Secure Policy)
Syntax dscp value;
Description Specify the DSCP value for the radius-flow-tap policy.
Options dscp-value— IPv4 or IPv6 dscp value for the radius-flow-tap policy.


Documentation

dscp-ipv6 (Dynamic Classifiers)
Syntax dscp-ipv6 (classifier-name | default);

Description For IPv6 traffic, apply a Differentiated Services (DiffServ) code point (DSCP) classifier

classifier ieee-802.1] hierarchy level.

Documentation
dscp-ipv6 (Dynamic Rewrite Rules)
Syntax dscp-ipv6 (rewrite-name | default);

Release Information Statement introduced before Junos OS Release10.1.
Description For IPv6 traffic, apply a DSCP rewrite rule to a subscriber interface in a dynamic profile.

rewrite-rules dscp-ipv6] hierarchy level.

Documentation
• rewrite-rules

dynamic-class-of-service-options (Dynamic Traffic Shaping)
Syntax dynamic-class-of-service-options {
vendor-specific-tags access-loop-encapsulation;
vendor-specific-tags actual-data-rate-downstream;
}
Hierarchy Level [edit dynamic-profiles profile-name class-of-service ]
Description Configure the shaping-rate and overhead-accounting class-of-service attributes based

on access line parameters in PPPoE discovery packets on dynamic subscriber interfaces.
Options vendor-specific-tags—Use Vendor-Specific Point-to-Point Protocol over Ethernet (PPPoE)

Tags [TR-101] to set the rate-shaping and overhead-accounting class-of-service
attributes.



dynamic-profiles
Syntax dynamic-profiles {
profile-name {
class-of-service {
interfaces {
interface-name ;
}
classifiers {
}
output-traffic-control-profile (profile-name | $junos-cos-traffic-control-profile);
rewrite-rules {
}
}
}
}
scheduler-maps {
map-name {
}
}
schedulers {
(scheduler-name) {
buffer-size (seconds | percent percentage | remainder | temporal microseconds);
drop-profile-map loss-priority (any | low | medium-low | medium-high | high)
protocol (any | non-tcp | tcp) drop-profile profile-name;
excess-priority (low | high | $junos-cos-scheduler-excess-priority);
transmit-rate (percent percentage | rate | remainder) <exact | rate-limit>;
}
}
delay-buffer-rate (percent percentage | rate | $junos-cos-delay-buffer-rate);
excess-rate (percent percentage | proportion value | percent $junos-cos-excess-rate);
guaranteed-rate (percent percentage | rate | $junos-cos-guaranteed-rate);
}
}
firewall {
family family {
interface-specific;

term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
only-at-create;
}
}
filter uid {
enhanced-mode-override;
interface-shared;
interface-specific;
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
}
}
}
policer uid {
filter-specific;
if-exceeding {
}
then {
policer-action;
}
}
hierarchical-policer uid {
aggregate {
if-exceeding {
}
then {
policer-action;
}
}
premium {
if-exceeding {
}
then {
policer-action;

}
}
}
three-color-policer uid {
action {
}
single-rate {
}
two-rate {
}
}
}
}
policy-options {
prefix-list uid {
ip-addresses;
dynamic-db;
}
}
interfaces interface-name {
unit logical unit number {
advisory-options {
downstream-rate rate;
upstream-rate rate;
}
}
}
}
auto-configure {
agent-circuit-identifier {
}
}
encapsulation (atm-ccc-cell-relay | atm-ccc-vc-mux | atm-cisco-nlpid |
atm-tcc-vc-mux | atm-mlppp-llc | atm-nlpid | atm-ppp-llc | atm-ppp-vc-mux |
atm-snap | atm-tcc-snap | atm-vc-mux | ether-over-atm-llc |
ether-vpls-over-atm-llc | ether-vpls-over-fr | ether-vpls-over-ppp | ethernet |
frame-relay-ccc | frame-relay-ppp | frame-relay-tcc | frame-relay-ether-type |
frame-relay-ether-type-tcc | multilink-frame-relay-end-to-end | multilink-ppp |
ppp-over-ether | ppp-over-ether-over-atm-llc | vlan-bridge | vlan-ccc | vlan-vci-ccc
| vlan-tcc | vlan-vpls);
family family {

address address;
filter {
adf {
counter;
not-mandatory;
rule rule-value;
}
input filter-name (
}
}
}
rpf-check {
mode loose;
}
service {
input {
}
}
input-vlan-map {
inner-tag-protocol-id tpid;
inner-vlan-id number;
(push | swap);
tag-protocol-id tpid;
vlan-id number;
}
output {
}
}
output-vlan-map {
(pop | swap);
vlan-id number;
}
}
}
ppp-options {
chap;
pap;
}
vlan-id number;
vlan-tags outer [tpid].vlan-id [inner [tpid].vlan-id];
}

}
interfaces {
demux0 {...}
}
interfaces {
pp0 {...}
}
protocols {
igmp {
accounting;
disable;
group-policy;
immediate-leave
no-accounting;
promiscuous-mode;
static {
group group {
source source;
}
}
version version;
}
mld {
interfaceinterface-name {
disable;
group-policy;
immediate-leave;
oif-map;
passive;
static {
exclude;
group-count number;
source ip-address {
}
}
}
version version;
}
}
router-advertisement {
current-hop-limit number;
default-lifetime seconds;
(managed-configuration | no-managed-configuration);
max-advertisement-interval seconds;
min-advertisement-interval seconds;
(other-stateful-configuration | no-other-stateful-configuration);
prefix prefix;

reachable-time milliseconds;
retransmit-timer milliseconds;
}
}
}
}
interface interface-name;
routing-options {
access {
route prefix {
next-hop next-hop;
metric route-cost;
tag route-tag;
}
}
access-internal {
}
}
}
multicast {
no-qos-adjust;
}
}
}
access {
route prefix {
next-hop next-hop;
metric route-cost;
tag route-tag;
}
}
access-internal {
}
}
}
}
}
routing-options {
access {
route prefix {
next-hop next-hop;
metric route-cost;
tag route-tag;
}

}
access-internal {
}
}
}
multicast {
no-qos-adjust;
}
}
}
variables {
variable-name {
default-value default-value;
equals expression;
mandatory;
uid;
uid-reference;
}
}
}
}
Hierarchy Level [edit]

Support at the filter, policer, hierarchical-policer, three-color-policer, and policy options
Description Create dynamic profiles for use with DHCP or PPP client access.
Options profile-name—Name of the dynamic profile; string of up to 80 alphanumeric characters.


Documentation

effective-shaping-rate
Syntax effective-shaping-rate;
Hierarchy Level [edit chassis]
Description Specify that the Cos-Effective-Shaping-Rate VSA [26–177] included in RADIUS Acct-Start,
Acct-Stop, and Interim-Acct messages reports the actual rate of the downstream traffic
for a subscriber, in kilobits per second.

Related • Reporting the Effective Shaping Rate for Subscribers on page 127
Documentation

enhanced-mode
Syntax enhanced-mode;
Hierarchy Level [edit firewall filter filter-name],

[edit firewall family family-name filter filter-name],
[edit logical-systems logical-system-name firewall filter filter-name],
[edit logical-systems logical-system-name firewall family family-name filter filter-name]

Description Limit static service filters or API-client filters to term-based filter format only for inet or
inet6 families when enhanced network services mode is configured at the [edit chassis
network-services] hierarchy level. When used with one of the chassis enhanced network
services modes, firewall filters are generated in term-based format for use with MPC
modules.
If enhanced network services are not configured for the chassis, the enhanced-mode
statement is ignored and any enhanced mode firewall filters are generated in both
term-based and, the default, compiled format. Only term-based (enhanced) firewall
filters will be generated, regardless of the setting of the enhanced-mode statement at
the [edit chassis network-services] hierarchy level, if any of the following are true:
• Flexible filter match conditions are configured at the [edit firewall family family-name
filter filter-name term term-name from] or [edit firewall filter filter-name term term-name
from] hierarchy levels.
• A tunnel header push or pop action, such as GRE encapsulate or decapsulate is

configured at the [edit firewall family family-name filter filter-name term term-name
then] hierarchy level.
• Payload-protocol match conditions are configured at the [edit firewall family

family-name filter filter-name term term-name from] or [edit firewall filter filter-name
term term-name from] hierarchy levels.
• An extension-header match is configured at the [edit firewall family family-name filter

filter-name term term-name from] or [edit firewall filter filter-name term term-name
from] hierarchy levels.
• A match condition is configured that only works with MPC cards, such as firewall bridge
filters for IPv6 traffic.
NOTE: You cannot attach enhanced mode filters to local loopback,

management, or MS-DPC interfaces. These interfaces are processed by the
Routing Engine and DPC modules and can accept only compiled firewall filter
format. In cases where both filter formats are needed for dynamic service
filters, you can use the enhanced-mode-override statement on the specific
filter definition to override the default filter term-based only format of chassis
network-service enhanced IP mode.

NOTE: Do not use enhanced mode for firewall filters that are intended for
control plane traffic. Control plane filtering is handled by the Routing Engine
kernel, which cannot use the term-based format of the enhanced mode filters.
For packets sourced from the Routing Engine, the Routing Engine processes
Layer 3 packets by applying output filters to the packets and forwards Layer
2 packets to the Packet Forwarding Engine for transmission. By configuring
the enhanced mode filter, you explicitly specify that only the term-based
filter format is used, which also implies that the Routing Engine cannot use
this filter.
NOTE: The enhanced-mode and the enhanced-mode-override statements are

mutually exclusive; you can define the filter with either enhanced-mode or
enhanced-mode-override, but not both.

Related • enhanced-mode-override on page 537

Documentation

enhanced-mode-override
Syntax enhanced-mode-override;
Hierarchy Level [edit firewall filter filter-name],

[edit firewall family family-name filter filter-name],
[edit logical-systems logical-system-name firewall filter filter-name],
[edit logical-systems logical-system-name firewall family family-name filter filter-name]
Description Overrides the default filter enhanced-mode of dynamic service filters when the chassis
is running in network-services enhanced IP mode. It functions similarly to the
enhanced-mode statement used to override the default IP mode of static filters when
the chassis is running in network-services enhanced IP mode.
When the chassis is running in network-service enhanced IP mode, all dynamic service
inet and inet6 firewall filters are automatically generated in term-based filter format
only. For any dynamic service filter that must be generated in both term-based and
compiled formats, you must specifically configure the enhanced-mode-override statement
for that filter definition.
Similar to how the filter enhanced-mode statement functions, if the chassis is not running
in network-services enhanced IP mode, then the enhanced-mode-override statement is
ignored.
NOTE: The enhanced-mode and the enhanced-mode-override statements are

mutually exclusive; you can define the filter with either enhanced-mode or
enhanced-mode-override, but not both.

Related • enhanced-mode on page 535

Documentation

enhanced-policer
Syntax enhanced-policer
Release Information Statement introduced in Junos OS Release 12.3 for MX Series.
Description Collect additional statistics to be displayed using show commands. An FPC restart is
required after changing this configuration.
When you commit a configuration that contains the enhanced-policer statement at the
[edit chassis] hierarchy level, a warning message is displayed stating that all the FPCs
in the router need to be rebooted for the configuration changes to become effective. At
this point, you must confirm that you want to proceed with the reboot of the FPCs. If you
do not reboot the FPCs, the FPCs return all 0s (zeros) when you perform a query for the
retrieval of detailed statistics—for example, when you issue the show firewall detail
command.

Related • Router Chassis Configuration Statements

Documentation
• show policer
• show firewall on page 746

excess-burst-size
Syntax excess-burst-size bytes;

[edit firewall three-color-policer policer-name single-rate]

Support at the [edit dynamic-profiles ... single-rate] hierarchy level introduced in Junos
Release OS 11.4.
Description For a single-rate three-color policer, configure the excess burst size (EBS) as a number
of bytes. The EBS allows for moderate periods of bursting traffic that exceeds both the
committed information rate (CIR) and the committed burst size (CBS).
NOTE: When you include the excess-burst-size statement in the configuration,

you must also include the committed-burst-size and
committed-information-rate statements at the same hierarchy level.
Single-rate three-color policing uses a dual token bucket algorithm to measure traffic
against a single rate limit. Nonconforming traffic is categorized as yellow or red based
During periods of traffic that conforms to the CIR, any unused portion of the guaranteed
bandwidth capacity accumulates in the first token bucket, up to the maximum number
of bytes defined by the CBS. If any accumulated bandwidth capacity overflows the first
bucket, the excess accumulates in a second token bucket, up to the maximum number
of bytes defined by the EBS.
A nonconforming traffic flow is categorized yellow if its size conforms to bandwidth

capacity accumulated in the first token bucket. Packets in a yellow flow are marked with
medium-high packet loss priority (PLP) and then passed through the interface.
A nonconforming traffic flow is categorized red if its size exceeds the bandwidth capacity
accumulated in the second token bucket. Packets in a red traffic flow are marked with
high PLP and then either passed through the interface or optionally discarded.
m (1,000,000), or g (1,000,000,000).



Documentation
excess-priority (Dynamic Schedulers)
Syntax excess-priority (low | high | $junos-cos-scheduler-excess-priority | none);

none option added in Junos OS Release 11.4.
Description Determine the priority of excess bandwidth traffic on a scheduler in a dynamic profile.
Options low—Excess traffic for this scheduler has low priority.
high—Excess traffic for this scheduler has high priority.
$junos-cos-scheduler-excess-priority—Variable for the excess-priority that is replaced

with a value obtained from the RADIUS server when a subscriber authenticates over
the interface to which the dynamic profile is attached.
none—System does not demote the priority of guaranteed traffic when the bandwidth
exceeds the shaping rate or the guaranteed rate.

Related • Managing Excess Bandwidth Distribution for Dynamic CoS on MIC and MPC Interfaces
• scheduler on page 644

excess-rate (Dynamic Schedulers)
Syntax excess-rate percent (percentage | $junos-cos-scheduler-excess-rate);
Description Determine the percentage of excess bandwidth traffic to share.
Options percentage—Percentage of the excess bandwidth to share.

$junos-cos-scheduler-excess-rate—Variable for the excess rate that is specified for a

scheduler. The variable is replaced with a value obtained from the RADIUS server
when a subscriber authenticates over the interface to which the dynamic profile is
attached.

Documentation
on page 138

excess-rate (Dynamic Traffic Shaping)
Syntax excess-rate (percent percentage | $junos-cos-excess-rate) | proportion value);
Description For an MPC interface, determine the percentage or proportion of excess bandwidth traffic
to share for all priorities of traffic.

value—Proportion of the excess bandwidth to share.

$junos-cos-excess-rate—Variable for the excess rate that is specified for the logical
interface. The variable is replaced with a value obtained from the RADIUS server
when a subscriber authenticates over the interface to which the dynamic profile is
attached.

Documentation
on page 138

excess-rate-high (Dynamic Traffic Shaping)
Syntax excess-rate-high ((percent percentage | $junos-cos-excess-rate-high) | proportion value);
Description For an MPC/MIC interface, determine the percentage of excess bandwidth for high-priority
traffic to share.


$junos-cos-excess-rate-high—Variable for the excess rate that is specified for high-priority

traffic on the logical interface. The variable is replaced with a value obtained from
the RADIUS server when a subscriber authenticates over the interface to which the
dynamic profile is attached.

Documentation
on page 138

excess-rate-low (Dynamic Traffic Shaping)
Syntax excess-rate-low ((percent percentage | $junos-cos-excess-rate-low) | proportion value);
Description For an MPC/MIC interface, determine the percentage of excess bandwidth for low-priority
traffic to share.


$junos-cos-excess-rate-low—Variable for the excess rate that is specified for low-priority

traffic on the logical interface. The variable is replaced with a value obtained from
the RADIUS server when a subscriber authenticates over the interface to which the
dynamic profile is attached.

Documentation
on page 138

exclude (Dynamic MLD Interface)
Syntax exclude;
Hierarchy Level [edit dynamic-profiles profile-name protocols mld interface interface-name static group
multicast-group-address]
Description Configure the group to operate in exclude mode on the dynamic interface. In exclude
mode all sources except the address configured are accepted for the group. By default,
the group operates in include mode.
Required Privilege view-level—To view this statement in the configuration.

Level control-level—To add this statement to the configuration.

Documentation
• Enabling MLD Static Group Membership
fail-filter (Dynamic Profiles)
Syntax fail-filter filter-name;
Hierarchy Level [edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number family family
rpf-check],
[edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number family
family rpf-check]
Description Specify a filter that evaluates packets that fail a unicast RPF check. The filter determines
what action to take with the failed packets. If the fail filter is not configured, the failed
packets are silently discarded.
Options filter-name—Name of the filter that evaluates packets that fail the RPF check.

Related • Configuring Unicast RPF

Documentation
• Configuring a Fail Filter for Unicast RPF in Dynamic Profiles for Subscriber Interfaces
on page 305

family (Dynamic Firewalls)
Syntax family family {

interface-specific;
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
only-at-create;
}
}
filter uid {
interface-shared;
interface-specific;
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
}
}
}
Hierarchy Level [edit dynamic-profiles profile-name firewall]
Description Configure fast update filters or parameterized filters for a protocol family.
Options family—Protocol family:
• inet—Internet Protocol version 4 suite
• inet6—Internet Protocol version 6 suite
uid—You must assign a variable UID as the name of parameterized filters.



Documentation

family (Dynamic Standard Interface)
Syntax family family {

address address;
direct-connect;
filter {
adf {
counter;
not-mandatory;
rule rule-value;
}
input filter-name {
}
}
}
mac-validate (loose | strict);
rpf-check {
mode loose;
}
service {
input {
}
}
output {
}
}
}
service-name-table table-name
maximum-seconds>;
}
Hierarchy Level [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number]

pppoe option added in Junos OS Release 11.2.

Description Configure protocol family information for the logical interface.
NOTE: Not all subordinate stanzas are available to every protocol family.
Options family—Protocol family:
• inet—IP version 4 suite
• inet6—IP version 6 suite
• pppoe—(MX Series routers with MPCs only) Point-to-Point Protocol over Ethernet
• vpls—Virtual private LAN service

Related • Example: Configuring Static Routing on Logical Systems

Documentation
• Configuring the Protocol Family

fast-update-filter (Dynamic Firewalls)
Syntax fast-update-filter filter-name {

interface-specific;
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
only-at-create;
}
}
Hierarchy Level [edit dynamic-profiles profile-name firewall family family]
Description Configure fast update firewall filters in a dynamic profile.
Options filter-name—Name that identifies the filter. The name can contain letters, numbers, and
hyphens (-) and can be up to 64 characters long. To include spaces in the name,
enclose it in quotation marks (“ ”).
The statements are explained separately.


Documentation

filter (Configuring)
Syntax filter filter-name {

accounting-profile name;
enhanced-mode;
interface-shared;
interface-specific;
physical-interface-filter;
term term-name {
... term configuration ...
}
}
Hierarchy Level [edit dynamic-profiles profile-name firewall family family-name],

[edit firewall family family-name],
[edit logical-systems logical-system-name firewall family family-name]

physical-interface-filter statement introduced in Junos OS Release 9.6.
Support at the [edit dynamic-profiles ... family family-name] hierarchy level introduced
in Junos OS Release 11.4.
Support for the interface-shared statement introduced in Junos OS Release 12.2.
Description Configure firewall filters.
Options filter-name—Name that identifies the filter. This must be a non-reserved string of not
more than 64 characters. To include spaces in the name, enclose it in quotation
marks (“ ”). Firewall filter names are restricted from having the form __.*__ (beginning
and ending with underscores) or __.* (beginning with an underscore.

Related • Guidelines for Configuring Firewall Filters

Documentation
• Configuring Multifield Classifiers
• Using Multifield Classifiers to Set Packet Loss Priority
• simple-filter (Configuring)

filter (Dynamic Firewalls)
Syntax filter {
adf {
counter;
not-mandatory;
rule rule-value;
}
input filter-name {
}
}
}
family],
[edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number family
family],
[edit dynamic-profiles profile-name interfaces pp0 unit “$junos–interface–unit” family
family]

Support at the [edit dynamic-profiles profile-name interfaces pp0 unit
“$junos-interface-unit” family family] hierarchy level introduced in Junos OS Release 10.1.
shared-name statement added in Junos OS Release 12.2.
Description Apply a dynamic filter to an interface. You can configure filters for either family inet or
family inet6, and the filters can be classic filters, fast update filters, or (for the adf
statement) Ascend-Data-Filters. Only the Internet Protocol version 4 (IPv4) protocol
family is currently supported for dynamic PPPoE logical interfaces.
Options input filter-name—Name of one filter to evaluate when packets are received on the
interface.
output filter-name—Name of one filter to evaluate when packets are transmitted on the
interface.

Related • Firewall Filters Overview

Documentation

filter (Dynamic Interface Unit)
Syntax filter {
input filter-name;
output filter-name;
}
Hierarchy Level [edit dynamic-profiles profile-name interfaces interface-name unit logical-unit-number],

[edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number],
Description Apply a dynamic filter to an interface, regardless of its family type.
Options input filter-name—Name of one filter to evaluate when packets are received on the
interface.
output filter-name—Name of one filter to evaluate when packets are transmitted on the
interface.


Documentation

filter-specific
Syntax filter-specific;
Hierarchy Level [edit dynamic-profiles profile-name firewall policer policer-name],

[edit firewall family inet prefix-action name],
[edit firewall policer policer-name],
[edit logical-systems logical-system-name firewall policer policer-name],
[edit logical-systems logical-system-name firewall family inet prefix-action name]

Support at the [edit dynamic-profiles ... policer policer-name] hierarchy level introduced
Description Set the prefix-specific action or policer to operate in filter-specific mode, meaning that
a single policer and counter are shared by all filter terms that reference the prefix-specific
action or policer. By default, the prefix-specific action or policer operates in term-specific
mode, meaning that a separate policer and counter are used for each filter term that
references the prefix-specific action or policer.

Related • Filter-Specific Policer Overview

Documentation
• Prefix-Specific Counting and Policing Overview
• Filter-Specific Counter and Policer Set Overview

firewall (Dynamic Firewalls)
Syntax firewall {
family family {
interface-specific;
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
only-at-create;
}
}
}
filter uid {
interface-shared;
interface-specific;
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
}
}
hierarchical-policer uid {
aggregate {
if-exceeding {
}
then {
policer-action;
}
}
premium {
if-exceeding {
}
then {
policer-action;
}
}
}
policer uid {

filter-specific;
if-exceeding {
}
then {
policer-action;
}
}
three-color-policer uid {
action {
}
single-rate {
}
two-rate {
}
}
}

The filter, hierarchical-policer, policer, and three-color-policer statements introduced in
Description Configure firewall filters and policers in a dynamic profile.
Options uid—You must assign a variable UID as the name of firewall filters and policers.

Documentation
• Configuring Fast Update Filters on page 288

flow-tap-dtcp
Syntax flow-tap-dtcp {
ssh {
connection-limit limit;
rate-limit limit;
}
}
Hierarchy Level [edit system services]
Description Configure Dynamic Tasking Control Protocol (DTCP) sessions to run over SSH in support
of the flow-tap application. Note that the flow-tap feature is not supported on outbound,
or egress, traffic. Only inbound, or ingress, traffic is supported.
Options connection-limit limit—(Optional) Maximum number of connections allowed.

Default: 75
rate-limit limit—(Optional) Maximum number of connection attempts allowed per minute.

Default: 150

Related • Configuring DTCP-over-SSH Service for the Flow-Tap Application

Documentation
forwarding-class (Dynamic Scheduler Maps)
Syntax forwarding-class class-name;
Hierarchy Level [edit dynamic-profiles profile-name class-of-service scheduler-maps map-name]
Description Associate a scheduler with a scheduler map.
Options class-name—Name of the forwarding class.

Documentation

forwarding-class (Subscriber Secure Policy)
Syntax forwarding-class class-name;
Hierarchy Level [edit services radius-flow-tap]
Description Specify forwarding class that is applied to mirrored packets sent to a mediation device.
Options class-name—Name of the forwarding class.


Documentation

fpc (MX Series 3D Universal Edge Routers)
Syntax fpc slot-number {

inline-services {
flow-table-size {
ipv4-flow-table-size units;
ipv4-flow-table-size units;
ipv6-extended-attrib;
}
}
ir-mode (R | IR);
pic number {
inline-services {
bandwidth (1g | 10g);
}
port-mirror-instance port-mirroring-instance-name-pic-level;
tunnel-services {
bandwidth (1g | 10g)
}
}
port-mirror-instance port-mirroring-instance-name-fpc-level;
}

port-mirror-instance option added in Junos OS Release 9.3.
ipv6-extended-attrib option added in Junos OS Release 14.2 for MX Series routers.
Description Configure properties for the DPC or MPC and corresponding Packet Forwarding Engines
to create tunnel interfaces.
(MX Series Virtual Chassis only) When you configure chassis properties for MPCs installed
in a Virtual Chassis member router, statements included at the [edit chassis member
member-id fpc slot slot-number] hierarchy level apply to the MPC in the specified slot
number only on the specified member router in the Virtual Chassis. Statements included
at the [edit chassis fpc slot slot-number] hierarchy level apply to the MPCs in the specified
slot number on each member router in the Virtual Chassis.
BEST PRACTICE: To ensure that the statement you use to configure MPC
chassis properties in an MX Series Virtual Chassis applies to the intended
member router and MPC, we recommend that you always include the member
member-ID option before the fpc statement, where member-id is 0 or 1 for a
two-member MX Series Virtual Chassis.
Options fpc slot-number—Specify the slot number of the DPC.

Range: 0 through 11

pic number—Specify the number of the Packet Forwarding Engine. Each DPC includes
four Packet Forwarding Engines.
Range: 0 through 4
port-mirror-instance port-mirroring-instance-name-fpc-level—Associate a port-mirroring

instance with the DPC and its corresponding PICs. The port-mirroring instance is
configured under the [edit forwarding-options port-mirroring] hierarchy level.

Related • Configuring Port-Mirroring Instances on MX Series 3D Universal Edge Routers

Documentation
• Enabling Inline Service Interfaces
• Virtual Chassis Components Overview

frame-mode (Dynamic Traffic Shaping)
Syntax frame-mode (bytes | $junos-cos-byte-adjust | frame-mode-bytes frame-mode-bytes

|$junos-cos-byte-adjust-frame);

[edit class-of-service traffic-control-profiles profile-name overhead-accounting],

Variable $junos-cos-byte-adjust-frame introduced in Junos OS Release 13.1.
Description Configure the mode to shape downstream ATM traffic based as frames.
Default The default is frame-mode.
Options bytes—Byte adjustment value for the cell-mode or frame-mode shaping options.
$junos-cos-byte-adjust—Predefined variable for byte adjustment that is replaced with a

value obtained from the RADIUS server when a subscriber authenticates over the
frame-mode-bytes frame-mode-bytes—Overhead bytes when in frame-mode. Traffic

shaping is based on the number of bytes in the frame, without regard to cell
encapsulation or padding overhead.
$junos-cos-byte-adjust-frame—Predefined variable for frame mode shaping. This variable

can not be used when the overhead-accounting bytes bytes option is configured.
BEST PRACTICE: We recommend using the frame-mode-bytes

frame-mode-bytes option rather than the bytes option.
Range: –120 through 124 bytes
NOTE: If you specify a value for the bytes bytes option, you cannot specify a
value for either the frame-mode-bytes option.


Documentation


• bytes on page 503
• cell-mode on page 505
from (Captive Portal Content Delivery)
Syntax from {
}
Hierarchy Level [edit services captive-portal-content-delivery rule rule-name term term-name]
Description Specify input conditions for a captive portal term.


Documentation
• Firewall Filter Match Conditions Based on Address Fields

from (Subscriber Secure Policy)
Syntax from {
dscp dscp-value;
protocol protocol;
}
Hierarchy Level [edit services radius-flow-tappolicy policy-name inet| inet6]
Description Define the match criteria for the drop-policy rule.


Documentation

group (Dynamic IGMP Interface)
Syntax For group configuration with a source, use the following syntax:
group ip-address {
source ip-address;
}
For group configuration without a source, use the following syntax:
group group;
Hierarchy Level [edit dynamic-profiles profile-name protocols igmp interface interface-name static],
Description When configuring with a source address, configure the IGMP multicast group address
that receives data on an interface and a source address for certain packets. For
configuration without a source address, configure only the IGMP multicast group address
that receives data on an interface.
Options ip-address—Group IP address.
group—Name of group.
NOTE: You must specify a unique address for each group.


Documentation
• Enabling IGMP Static Group Membership

group (Dynamic MLD Interface)
Syntax group multicast-group-address {

exclude;
group-count number;
source ip-address {
}
}
Hierarchy Level [edit dynamic-profiles profile-name protocols mld interface interface-name static]
Description The MLD multicast group address and (optionally) the source address for the multicast
group being dynamically configured on an interface.
Options multicast-group-address—Address of the group.
NOTE: You must specify a unique address for each group.


Documentation

group-count (Dynamic MLD Interface)
Syntax group-count number;
Description Configure the number of static groups to be created over the dynamic interface.
Options number—Number of static groups.

Default: 1


Documentation
group-increment (Dynamic MLD Interface)
Syntax group-increment increment;
multicast-group-address source]
Description Configure the number of times the address should be incremented for each static group
created on a dynamic interface. The increment is specified in a format similar to an IPv6
address.
Options increment—Number of times the address should be incremented.

Default: ::1
Range: ::1 through ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:


Documentation

group-limit (Dynamic IGMP Interface)
Syntax group-limit limit;
Description Configure a limit for the number of multicast groups (or [S,G] channels in IGMPv3)
allowed on a dynamic logical interface. After this limit is reached, new reports will be
ignored and all related flows are not flooded on the logical interface.
Default By default, there is no limit to the number of multicast groups that can join the interface.
Options limit—group limit value for the interface.



Documentation
• Limiting the Number of IGMP Multicast Group Joins on Logical Interfaces

group-limit (Dynamic MLD Interface)
Syntax group-limit limit;
Description Configure a limit for the number of multicast groups (or [S,G] channels in MLDv2) allowed
on a dynamic logical interface. After this limit is reached, new reports will be ignored and
all related flows are not flooded on the logical interface.
Default By default, there is no limit to the number of multicast groups that can join the interface.
Options limit—group limit value for the interface.



Documentation
• Configuring the Number of MLD Multicast Group Joins on Logical Interfaces
group-policy (Dynamic IGMP Interface)
Syntax group-policy policy-name;
Hierarchy Level [edit dynamic-profiles profile-name protocols igmp interface interface-name]
Description Compare the IGMPv2 or IGMPv3 group against the specified group policy, after receiving
an IGMP report, and perform the action configured in that policy (for example, reject the
report).
Options policy-name—Name of the group policy.


Documentation
• Filtering Unwanted IGMP Reports at the IGMP Interface Level

group-policy (Dynamic MLD Interface)
Syntax group-policy policy-name;
Description Compare the MLDv1 or MLDv2 group against the specified group policy, after receiving
an MLD report, and perform the action configured in that policy (for example, reject the
report).
Options policy-name—Name of the group policy.


Documentation
• Filtering Unwanted MLD Reports at the MLD Interface Level

guaranteed-rate (Dynamic Traffic Shaping)
Syntax guaranteed-rate (rate | $junos-cos-guaranteed-rate) <burst-size [ bytes |

$junos-cos-guaranteed-rate-burst]>;

The $junos-cos-guaranteed-rate variable introduced in Junos OS Release 9.4.
Option burst-size introduced in Junos OS Release 11.4.
Description Configure a guaranteed minimum rate for a logical interface.
Default If you do not include this statement and you do not include the delay-buffer-rate
statement, the logical interface receives a minimal delay-buffer rate and minimal
bandwidth equal to 2 MTU-sized packets.
Options rate—Guaranteed rate in bits per second (bps). You can specify a value in bits per second
$junos-cos-guaranteed-rate—Junos predefined variable that is replaced with the

guaranteed rate obtained from the RADIUS server when a subscriber authenticates
burst-size bytes—(Optional) Maximum burst size, in bytes.

Range: 0 through 1,000,000,000
$junos-cos-guaranteed-rate-burst—(Optional) Variable for the burst-size that is specified

for the guaranteed rate. Use this variable at the [edit dynamic-profiles profile-name
class-of-service traffic-control-profile] hierarchy level.

Documentation

hierarchical-policer
Syntax hierarchical-policer hierarchical-policer-name | uid {

aggregate {
if-exceeding {
}
then {
discard;
}
}
premium {
if-exceeding {
}
then {
discard;
}
}
}
Hierarchy Level [edit dynamic-profiles profile-name firewall],

[edit firewall]

Support at the [edit dynamic-profiles ... firewall] hierarchy level introduced in Junos OS
Release 11.4.
Description Specify a hierarchical policer on Enhanced Intelligent Queuing (IQE) PICs and SONET
interfaces hosted on M120 and M320 edge routers with incoming Flexible PIC
Concentrators (FPCs) as SFPC and outgoing FPCs as FFPC; on MPCs hosted on MX
Series routers; on T320, T640, and T1600 core routers with Enhanced Intelligent Queuing
(IQE) PICs; and on T4000 routers with Type 5 FPC and Enhanced Scaling Type 4 FPC.
Options hierarchical-policer-name—Name that identifies the policer. The name can contain letters,
numbers, and hyphens (-), and can be up to 255 characters long. To include spaces
in the name, enclose it in quotation marks (“ ”).
uid—When you configure a hierarchical policer at the [edit dynamic-profiles] hierarchy

level, you must assign a variable UID as the policer name.


Documentation


hierarchical-scheduler (Subscriber Interfaces on MX Series Routers)
Syntax hierarchical-scheduler {
implicit-hierarchy;
maximum–hierarchy–levels number;
}
Hierarchy Level [edit interfaces interface-name]

implicit-hierarchy option added in Junos OS Release 13.1.
Support on GRE tunnel interfaces configured on physical interfaces on MICs or MPCs in
MX Series routers added in Junos OS Release 13.3.
Description Configure hierarchical scheduling options on the interface.
The statement is supported on the following interfaces:
• MIC and MPC interfaces in MX Series routers
• GRE tunnel interfaces configured on physical interfaces hosted on MIC or MPC line
cards in MX Series routers
To enable hierarchical scheduling on MX Series routers, configure the

hierarchical-scheduler statement at each member physical interface level of a particular
aggregated Ethernet interface as well as at that aggregated Ethernet interface level. On
other routing platforms, it is enough if you include this statement at the aggregated
Ethernet interface level.
Options implicit-hierarchy—Configure three-level hierarchical scheduling. When you include the

implicit-hierarchy option, a hierarchical relationship is formed between the CoS
scheduler nodes at level 1, level 2, and level 3. The implicit-hierarchy option is
supported only on MPC/MIC subscriber interfaces and interface sets running over
aggregated Ethernet on MX Series routers.
maximum-hierarchy-levels number—Configure two-level hierarchical scheduling. Specify

the maximum number of hierarchical scheduling levels allowed for node scaling.
The only supported value is 2. The maximum-hierarchy-levels option is supported
on MPC/MIC or EQ DPC subscriber interfaces and interface sets running over
aggregated Ethernet on MX Series routers.
• If you include the maximum-hierarchy-levels option, interface sets are allowed only at
level 3; they are not allowed at level 2. In this case, if you configure a level 2 interface
set, you generate Packet Forwarding Engine errors.
• If you do not include the maximum-hierarchy-levels option, interface sets can be at

either level 2 or level 3, depending on whether the member logical interfaces within
the interface set have a traffic control profile. If any member logical interface has a
traffic control profile, then the interface set is a level 2 CoS scheduler node. If no member
logical interface has a traffic control profile, the interface set is at level 3.

Required Privilege view-level—To view this statement in the configuration.

Level control-level—To add this statement to the configuration.

on page 35
ieee-802.1 (Dynamic Classifiers)
Syntax ieee-802.1 (classifier-name | default) vlan-tag (inner | outer);

Description Apply an IEEE-802.1 classifier to a subscriber interface in a dynamic profile.


Documentation

ieee-802.1 (Dynamic Rewrite Rules)
Syntax ieee-802.1 (rewrite-name | default) vlan-tag (outer | outer-and-inner);

Description Apply an IEEE-802.1 rewrite rule to a subscriber interface in a dynamic profile.

rewrite-rules ieee-802.1] hierarchy level.

Documentation
page 219
• rewrite-rules

if-exceeding (Hierarchical Policer)
Syntax if-exceeding {
}
Hierarchy Level [edit dynamic-profiles profile-name firewall hierarchical-policer aggregate],

[edit dynamic-profiles profile-name firewall hierarchical-policer premium],
[edit firewall hierarchical-policer aggregate],
[edit firewall hierarchical-policer premium]

Support at the [edit dynamic-profiles ... aggregate] and [edit dynamic-profiles ... premium]
hierarchy level introduced in Junos OS Release 11.4.
Description For M40e, M120, and M320 (with FFPC and SFPC) edge routers and T320, T640, and
T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs, T4000 routers with
Type 5 FPC and Enhanced Scaling Type 4 FPC, specify bandwidth and burst limits for a
premium or aggregate component of a hierarchical policer.


Documentation

if-exceeding (Policer)
Syntax if-exceeding {
(bandwidth-limit bps | bandwidth-percent number);
}

[edit logical-systems logical-system-name firewall policer policer-name]

Description Configure rate limits for a single-rate two-color policer.


Documentation
• Basic Single-Rate Two-Color Policers
• Bandwidth Policers
• Filter-Specific Counters and Policers
• Prefix-Specific Counting and Policing Actions
• Multifield Classification
• Policer Overhead to Account for Rate Shaping in the Traffic Manager

igmp (Dynamic Profiles)
Syntax igmp {
accounting;
disable;
group-limit policy-name;
group-policy;
immediate-leave;
no-accounting;
oif-map map-name;
passive <allow-receive> <send-general-query> <send-group-query>;
promiscuous-mode;
static {
group group {
source source;
}
}
version version;
}
}
Hierarchy Level [edit dynamic-profiles profile-name protocols]
Description Enable IGMP on the router. IGMP must be enabled for the router to receive multicast
packets.
Default IGMP is disabled on the router. IGMP is automatically enabled on all broadcast interfaces
when you configure Protocol Independent Multicast (PIM) or Distance Vector Multicast
Routing Protocol (DVMRP).
Options The statements are explained separately.


Documentation
• Understanding IGMP
• Enabling IGMP

immediate-leave (Dynamic IGMP Interface)
Syntax immediate-leave;
Description Enable the routing device to leave the multicast group immediately after the last host
leaves the multicast group.


Documentation
• Specifying Immediate-Leave Host Removal for IGMP

immediate-leave (Dynamic MLD Interface)
Syntax immediate-leave;
Description The immediate leave setting is useful for minimizing the leave latency of MLD
memberships. When this setting is enabled, the routing device leaves the multicast group
immediately after the last host leaves the multicast group.
The immediate-leave setting enables host tracking, meaning that the device keeps track
of the hosts that send join messages. This allows MLD to determine when the last host
sends a leave message for the multicast group.
When the immediate leave setting is enabled, the device removes an interface from the
forwarding-table entry without first sending MLD group-specific queries to the interface.
The interface is pruned from the multicast tree for the multicast group specified in the
MLD leave message. The immediate leave setting ensures optimal bandwidth
management for hosts on a switched network, even when multiple multicast groups are
being used simultaneously.
When immediate leave is disabled and one host sends a leave group message, the routing
device first sends a group query to determine if another receiver responds. If no receiver
responds, the routing device removes all hosts on the interface from the multicast group.
Immediate leave is disabled by default for both MLD version 1 and MLD version 2.
NOTE: Although host tracking is enabled for IGMPv2 and MLDv1 when you
enable immediate leave, use immediate leave with these versions only when
there is one host on the interface. The reason is that IGMPv2 and MLDv1 use
a report suppression mechanism whereby only one host on an interface sends
a group join report in response to a membership query. The other interested
hosts suppress their reports. The purpose of this mechanism is to avoid a
flood of reports for the same group. But it also interferes with host tracking,
because the router only knows about the one interested host and does not
know about the others.


Documentation
• Specifying Immediate-Leave Host Removal for MLD

inet (Subscriber Secure Policy)
Syntax inet {
drop-policy rule-name {
from {
dscp dscp-value;
protocol protocol;
}
}
}
Hierarchy Level [edit services radius-flow-tap policy policy-name]
Description Specify the inet family for the policy that is applied to mirrored packets sent to a mediation
device.


Documentation

inet-precedence (Dynamic Classifiers)
Syntax inet-precedence (classifier-name | default);

Description Apply a IPv4 precedence classifier to a subscriber interface in a dynamic profile.


Documentation
inet-precedence (Dynamic Rewrite Rules)
Syntax inet-precedence (rewrite-name | default);

Description Apply a IPv4 precedence rewrite rule.

rewrite-rules inet-precedence] hierarchy level.
default—The default mapping. By default, IP precedence rewrite rules alter the first three
bits on the type of service (ToS) byte while leaving the last three bits unchanged.

Documentation
page 219
• rewrite-rules

inet6 (Subscriber Secure Policy)
Syntax inet6 {
from {
dscp dscp-value;
protocol protocol;
}
}
}
Hierarchy Level [edit services radius-flow-tap policy policy-name]
Description Specify the inet6 family for the policy that is applied to mirrored packets sent to a
mediation device.


Documentation

input (Dynamic Service Sets)
Syntax input {
}
}
family service],
family service]

“$junos-interface-unit” family family service] hierarchy level introduced in Junos OS
Release 10.1.
Description Define the input service sets and filters to be applied to traffic by a dynamic profile. Only
the Internet Protocol version 4 (IPv4) protocol family is currently supported for dynamic
PPPoE logical interfaces.


Documentation

interface (Dynamic IGMP)
Syntax interface interface-name {

accounting;
disable;
group-policy;
immediate-leave
no-accounting;
oif-map;
passive;
promiscuous-mode;
static {
group group {
source source;
}
}
version version;
}
Hierarchy Level [edit dynamic-profiles profile-name protocols igmp]
Description Enable IGMP on an interface and configure interface-specific properties.
Options interface-name—Variable for the interface. Specify the interface variable

($junos-interface-name) to indicate that the dynamic profile chooses an interface
for the accessing DHCP client.


Documentation
• Enabling IGMP

interface (Dynamic Interface Sets)
Syntax interface interface-name {

advisory-options {
upstream-rate rate;
}
}
}
Hierarchy Level [edit dynamic-profiles profile-name interfaces interface-set interface-set-name]
Description Add a subscriber interface to a dynamic interface set.
In a dynamic profile that defines an agent circuit identifier (ACI) interface set, observe
the following guidelines when you use the interface statement:
• Use the predefined dynamic interface variable $junos-interface-ifd-name to represent

the interface name. Do not use a specific interface name, such as demux0, when defining
an ACI interface set.
• Do not include the unit logical-unit-number statement.
Options interface-name–Either the specific name of the interface to include in the interface set,
or the predefined dynamic interface variable $junos-interface-ifd-name. The interface
variable is dynamically replaced with the interface that the DHCP or PPPoE subscriber
accesses when connecting to the router.

Related • Defining Agent Circuit Identifier Interface Sets

Documentation
• Agent Circuit Identifier-Based Dynamic VLANs Components Overview

interface (Dynamic MLD)
Syntax interfaceinterface-name {
disable;
group-policy;
immediate-leave;
oif-map;
passive;
static {
exclude;
group-count number;
source ip-address {
}
}
}
version version;
}
Hierarchy Level [edit dynamic-profiles profile-name protocols mld]
Description Enable MLD on a dynamic interface and configure interface-specific properties.
Options interface-name—Variable for the interface. Specify the interface variable

($junos-interface-name) to indicate that the dynamic profile chooses an interface
for the accessing client.


Documentation
• Enabling MLD

interface (Dynamic Routing Options)
Syntax interface interface-names {

no-qos-adjust;
}
Hierarchy Level [edit dynamic-profiles profile-name routing-options multicast],

[edit dynamic-profiles profile-name routing-instances routing-instance-name routing-options
multicast]
Description Define the maximum bandwidth for a dynamic interface on which you want to apply
bandwidth management.
Options interface-name—Names of the physical or logical interface. For details about specifying
interfaces, see Types of Interfaces Overview.

Related • Configuring Dynamic Access Routes for Subscriber Management

Documentation
• Configuring Dynamic Access-Internal Routes for DHCP Subscriber Management

interface-set (Dynamic CoS)
Syntax interface-set interface-set-name {

}
}
Hierarchy Level [edit dynamic-profiles profile-name interfaces]
Description For MX Series routers with enhanced queuing DPCs or MPC/MIC modules, configure an
interface set for dynamic CoS.
Options interface-set interface-set-name—Name of the scheduler to be configured or one of the

following Junos OS predefined variables:
• $junos-interface-set-name—Predefined variable that, when used, is replaced with the

interface-set obtained from the RADIUS server when a subscriber authenticates over
the interface to which the dynamic profile is attached.
• $junos-svlan-interface-set-name—Locally generated interface set name for use by

dual-tagged VLAN interfaces based on the outer tag of the dual-tagged VLAN. The
format of the generated variable is physical_interface_name - outer_VLAN_tag.
• $junos-tagged-vlan-interface-set-name—Locally generated interface set name used

for grouping logical interfaces stacked over logical stacked VLAN demux interfaces
for either a 1:1 (dual-tagged; individual client) VLAN or N:1 (single tagged; service) VLAN.
The format of the generated variable differs with VLAN type. For dual-tagged (client)
VLANs, the format of the generated variable is physical_interface_name - outer_VLAN_tag
- inner_VLAN_tag. For single tagged (service) VLAN, the format of the generated variable
is physical_interface_name - VLAN_tag.

Related • CoS for Interface Sets of Subscribers Overview on page 195

Documentation

Profile on page 211

interface-shared
Syntax interface-shared;
Hierarchy Level [edit firewall family family-name filter filter-name],

[edit dynamic-profiles profile-namefirewall family family-name filter filter-name]
Description Set the interface-shared attribute for a firewall filter.


Documentation
interface-specific (Dynamic Firewalls)
Syntax interface-specific;
Hierarchy Level [edit dynamic-profiles profile-name firewall family family fast-update-filter filter-name]
Description Configure interface-specific names for firewall counters that are based on fast update
filters.


Documentation

interfaces (Dynamic CoS Definition)
Syntax interfaces {
interface-name {
classifiers {
ieee-802.1 (classifier-name | default) vlan-tag (inner | outer)
}
rewrite-rules {
}
}
}
}
Hierarchy Level [edit dynamic-profiles profile-name class-of-service]
Description Configure interface-specific CoS properties for incoming packets.
Options interface-name—Either the specific name of the interface you want to assign to the
dynamic profile or the interface variable ($junos-interface-ifd-name). The interface
variable is dynamically replaced with the interface the client accesses when
connecting to the router.

Documentation
on page 217

interfaces (Static and Dynamic Subscribers)
Syntax interfaces {
interface-name {
auto-configure {
}
}
family family {
address address;
direct-connect;
filter {
adf {
counter;
not-mandatory;
rule rule-value;
}
input filter-name (
}
precedence precedence;shared-name filter-shared-name;
}
}
rpf-check {
mode loose;
}
service {
input {
}
}
output {
}
}
}
maximum-seconds>;

}
filter {
input filter-name;
output filter-name;
}
ppp-options {
chap;
pap;
}
proxy-arp;
vlan-id;
}
vlan-tagging;
}
advisory-options {
upstream-rate rate;
}
}
}
pppoe-underlying-options {
}
}
demux0 {
demux-options {
underlying-interface interface-name
}
family family {
address address;
direct-connect;
demux-source {
source-prefix;
}
filter{
input filter-name (
}
}
}
mac-validate (loose | strict):

rpf-check {
mode loose;
}
maximum-seconds>;
}
filter {
input filter-name;
output filter-name;
}
vlan-id number;
}
}
pp0 {
keepalives interval seconds;
no-keepalives;
pppoe-options {
underlying-interface interface-name;
server;
}
ppp-options {
authentication [ authentication-protocols ];
chap {
challenge-length minimum minimum-length maximum maximum-length;
}
pap;
}
family inet {
unnumbered-address interface-name;
address address;
service {
input {
}
}
output {
}
}
}
filter {
input filter-name {
}

}
}
}
}
}
}
Description Define interfaces for dynamic profiles.
Options interface-name—The interface variable ($junos-interface-ifd-name). The interface variable

is dynamically replaced with the interface the DHCP client accesses when connecting
to the router.
NOTE: Though we do not recommend it, you can also enter the specific name
of the interface you want to assign to the dynamic profile.

Related • Configuring Dynamic Subscriber Interfaces Using IP Demux Interfaces in Dynamic Profiles
Documentation
• Configuring Dynamic PPPoE Subscriber Interfaces Using Dynamic Profiles
• DHCP Subscriber Interface Overview
• Configuring Subscribers over Static Interfaces
• Demultiplexing Interface Overview

interfaces (Subscriber Secure Policy)
Syntax interfaces interface-name;
Description Specify tunnel interfaces that are used to send mirrored packets to a mediation device.
Options interface-name—Name of the interface.


Documentation
logical-bandwidth-policer
Syntax logical-bandwidth-policer;

[edit logical-systems logical-system-name firewall policer policer-name]

Description For a policer with a bandwidth limit configured as a percentage (using the
bandwidth-percent statement), specify that the percentage be based on the shaping
rate defined on the logical interface, rather than on the media rate of the physical interface.

Related • Bandwidth Policers

Documentation
• Configuring Logical Bandwidth Policers
• bandwidth-percent on page 497 statement
• interface-specific statement

logical-interface-fpc-redundancy (Aggregated Ethernet Subscriber Interfaces)
Syntax logical-interface-fpc-redundancy;
Hierarchy Level [edit interfaces aenumber aggregated-ether-options]

Description Provide module redundancy for demux subscribers on aggregated Ethernet bundles
configured with targeted distribution. Backup links for a subscriber are chosen on a
different EQ DPC or MPC from the primary link, based on the link with the fewest number
of subscribers among the links on different modules. If all links are on a single module
when this is configured, backup links are not provisioned.
By default, link redundancy is provided for the aggregated Ethernet bundle.

Related • Configuring Link and Module Redundancy for Demux Subscribers in an Aggregated
Documentation Ethernet Interface on page 146
• Configuring Module Redundancy for a Virtual Chassis

logical-interface-policer
Syntax logical-interface-policer;

[edit dynamic-profiles profile-name firewall three-color-policer name],
[edit firewall atm-policeratm-policer-name]
[edit firewall policer policer-template-name],
[edit firewall three-color-policer policer-name],
[edit logical-systems logical-system-name firewall policer policer-name],
[edit logical-systems logical-system-name firewall three-color-policer name]

Support at the [edit firewall three-color-policer policer-name] hierarchy level introduced
Support at the [edit dynamic-profiles ... policer policer-name] and [edit dynamic-profiles
... three-color-policer name] hierarchy levels introduced in Junos OS Release 11.4.
Description Configure a logical interface policer.
NOTE: Starting in Junos OS Release 12.2R2, on T Series Core Routers only,

you can configure an MPLS LSP policer for a specific LSP to be shared across
different protocol family types. You must include the logical-interface-policer
statement to do so.

Related • Two-Color and Three-Color Logical Interface Policers

Documentation
• Traffic Policer Types
• Configuring Tricolor Marking Policers
• Configuring Gigabit Ethernet Two-Color and Tricolor Policers
• action

login
Syntax login {
announcement text;
class class-name {
allow-commands "regular-expression";
allow-configuration-regexps "regular expression 1" "regular expression 2";
configuration-breadcrumbs;
deny-commands "regular-expression";
( deny-configuration | deny-configuration-regexps ) “regular expression 1” “regular
expression 2 ”;
idle-timeout minutes;
login-script filename;
login-tip;
permissions [ permissions ];
}
message text;
password {
change-type (set-transitions | character-set);
format (md5 | sha1 | des);
maximum-length length;
minimum-changes number;
minimum-length length;
}
retry-options {
backoff-threshold number;
backoff-factor seconds;
minimum-time seconds;
tries-before-disconnect number;
}
user username {
full-name complete-name;
uid uid-value;
class class-name;
authentication authentication;
ssh-rsa "public-key";
ssh-dsa "public-key";
}
}
Hierarchy Level [edit system]

Description Configure user access to the router or switch.
NOTE: The remaining statements are explained separately.


Related • Defining Junos OS Login Classes

Documentation
loss-priority (Dynamic Schedulers)
Syntax loss-priority (any | low | medium-low | medium-high | high);

drop-profile-map]
Description Specify a loss priority to which to apply a drop profile in a dynamic profile. The drop profile
map sets the drop profile for a specific PLP and protocol type. The inputs for the map
are the PLP designation and the protocol type. The output is the drop profile.
Options any—The drop profile applies to packets with any PLP.
high—The drop profile applies to packets with high PLP.
medium-high—The drop profile applies to packets with medium-high PLP.
medium-low—The drop profile applies to packets with medium-low PLP.
low—The drop profile applies to packets with low PLP.

Documentation

loss-priority high then discard (Three-Color Policer)
Syntax loss-priority high then discard;
Hierarchy Level [edit dynamic-profiles profile-name firewall three-color-policer name action],

[edit firewall three-color-policer policer-name action],
[edit logical-systems logical-system-name firewall three-color-policer policer-name action]

Support at the [edit dynamic-profiles ... action] hierarchy level introduced in Junos OS
Release 11.4.
Description For packets with high loss priority, discard the packets. The loss priority setting is implicit
and is not configurable. Include this statement if you do not want the local router to
forward packets that have high packet loss priority.
For single-rate three-color policers, the Junos OS assigns high loss priority to packets
that exceed the committed information rate and the excess burst size.
For two-rate three-color policers, the Junos OS assigns high loss priority to packets that
exceed the peak information rate and the peak burst size.


Documentation

match-direction (Captive Portal Content Delivery)
Syntax match-direction (input | output | input-output);
Hierarchy Level [edit services captive-portal-content-delivery rule (Captive Portal Content Delivery)
rule-name]
Description Specify the direction in which the rule match is applied.
Options input—Apply the rule match on the input side of the interface.
output—Apply the rule match on the output side of the interface.
input-output—Apply the rule match bidirectionally.


Documentation
max-queues-per-interface
Syntax max-queues-per-interface (8 | 4);
Hierarchy Level [edit chassis fpc slot-number pic pic-number],

[edit chassis lcc number fpc slot-number pic pic-number] (Routing Matrix)

Support for TX Matrix and TX Matrix Plus added in Junos OS Release 9.6.
On MIC or MPC interfaces on MX Series routers, configure eight egress queues.
Description On IQ, MPC, and DPC interfaces on M120, T320, T640, T1600, TX Matrix, and TX Matrix
Plus routers, or on MIC or MPC interfaces on MX Series routers, configure eight egress
queues.

Related • Configuring the Junos OS to Support Eight Queues on IQ Interfaces for T Series and M320
Documentation Routers
• Configuring Up to 16 Forwarding Classes
• Enabling Eight Queues on ATM Interfaces
• Configuring the Maximum Number of Queues for Trio MPC/MIC Interfaces on page 94

match-order (Dynamic Firewalls)
Syntax match-order [match-order];
Hierarchy Level [edit dynamic-profiles profile-name firewall family family fast-update-filter filter-name]
Description Specify the match conditions and the order in which the conditions are examined. Enclose
a string of multiple conditions in brackets. The router examines only the conditions you
specify, and examines them in the specified order.
Options match-order—One or more of the following conditions. “Fast Update Filter Match
Conditions” on page 292 describes the match conditions.
• destination-address
• destination-port
• dscp (IPv4 only)
• protocol (IPv4 only)
• source-address
• source-port


Documentation

mld (Dynamic Profiles)
Syntax mld {
interfaceinterface-name {
disable;
group-policy;
immediate-leave;
oif-map;
passive;
static {
exclude;
group-count number;
source ip-address {
}
}
}
version version;
}
}
Hierarchy Level [edit dynamic-profiles profile-name protocols]
Description Configure interface-specific MLD values on dynamic interfaces.
Options The statements are explained separately.


Documentation
• Enabling MLD

multicast (Dynamic Routing Options)
Syntax multicast {
no-qos-adjust;
}
}
Hierarchy Level [edit dynamic-profiles profile-name routing-options],

[edit dynamic-profiles profile-name routing-instances routing-instance-name routing-options]
NOTE: You cannot apply a scope policy to a specific routing instance. That
is, all scoping policies are applied to all routing instances. However, the scope
statement does apply individually to a specific routing instance.
Description Dynamically configure interface-specific multicast routing options properties.

Related • Example: Configuring the Multicast Forwarding Cache

Documentation
• Example: Configuring a Multicast Flow Map
• Example: Configuring Source-Specific Multicast Groups with Any-Source Override

multicast-interception (Subscriber Secure Policy)
Syntax multicast-interception;
Description Enables subscriber secure policy to mirror IPv4 multicast traffic sent to subscribers. It
enables the mirroring of multicast traffic for all subscribers on the chassis.
Mirroring of multicast traffic is supported only for subscribers in the default logical system.


Documentation
• Subscriber Secure Policy Support for IPv4 Multicast Traffic on page 395
no-accounting
Syntax no-accounting;
Description Disable the collection of IGMP join and leave event statistics on a per-interface basis.


Documentation
• Recording IGMP Join and Leave Events

no-qos-adjust (Dynamic Routing Options)
Syntax no-qos-adjust;
Hierarchy Level [edit dynamic-profiles profile-name routing-options multicast interface interface-name]
Description Disable hierarchical bandwidth adjustment for all dynamically created subscriber
interfaces that are identified by their MLD or IGMP request from a specific multicast
interface.

Related • Example: Configuring Multicast with Subscriber VLANs

Documentation
oif-map (Dynamic IGMP Interface)
Syntax oif-map map-name;
Description Associates an OIF map to the IGMP interface using a dynamic profile. The OIF map is a
routing policy statement that can contain multiple terms.
Options map-name—Name of the OIF map.


Documentation

oif-map (Dynamic MLD Interface)
Syntax oif-map map-name;
Description Associate an outgoing interface (OIF) map to a dynamic MLD logical interface. The OIF
map is a routing policy statement that can contain multiple terms.
Options map-name—Name of the OIF map.


Documentation

output (Dynamic Service Sets)
Syntax output {
}
}
family service],
family service]

Support of the [edit dynamic-profiles profile-name interfaces pp0 unit
“$junos-interface-unit” family family service] hierarchy level introduced in Junos OS
Release 10.1.
Description Define the output service sets and filters to be applied to traffic by a dynamic profile.
Only the Internet Protocol version 4 (IPv4) protocol family is currently supported for
dynamic PPPoE logical interfaces.
Options service-set-name—Name of the service set.


Documentation

output-traffic-control-profile (Dynamic CoS Definition)
Syntax output-traffic-control-profile (profile-name | $junos-cos-traffic-control-profile);


Variable $junos-cos-traffic-control-profile introduced in Junos OS Release 11.2.
Description Apply an output traffic scheduling and shaping profile to the logical interface.
Options profile-name—Name of the traffic-control profile to be applied to this interface
$junos-cos-traffic-control-profile—Variable for the traffic-control profile that is specified

for the logical interface. The variable is replaced with the traffic-control profile when
the subscriber is authenticated at login.

Documentation
on page 217
• Using the CLI to Modify Traffic-Control Profiles That Are Currently Applied to Subscribers
• traffic-control-profiles on page 674

overhead-accounting (Dynamic Traffic Shaping)
Syntax overhead-accounting {
bytes bytes;
cell-mode cell-mode-bytes cell-mode-bytes;
frame-mode frame-mode-bytes frame-mode-bytes;
}
Description Configure the mode to shape downstream ATM traffic based on either frames or cells.
Default The default is frame-mode.


Documentation

passive (Dynamic IGMP Interface)
Syntax passive <allow-receive> <send-general-query> <send-group-query>;

allow-receive, send-general-query, and send-group-query options were introduced in
Description Dynamically specify that IGMP run on the interface and either not send and receive control
traffic or selectively send and receive control traffic such as IGMP reports, queries, and
leaves.
NOTE: You can selectively activate up to two out of the three available
options for the passive statement while keeping the other functions passive
(inactive). Activating all three options would be equivalent to not using the
passive statement.
Options allow-receive—(Optional) Enables IGMP to receive control traffic on the interface.
send-general-query—(Optional) Enables IGMP to send general queries on the interface.
send-group-query—(Optional) Enables IGMP to send group-specific and

group-source-specific queries on the interface.


Documentation
• Configuring IGMP

passive (Dynamic MLD Interface)
Syntax passive <allow-receive> <send-general-query> <send-group-query>;
Description Specify that MLD run on the interface and either not send and receive control traffic or
selectively send and receive control traffic such as MLD reports, queries, and leaves.
NOTE: You can selectively activate up to two out of the three available
options for the passive statement while keeping the other functions passive
(inactive). Activating all three options would be equivalent to not using the
passive statement.
Options allow-receive—(Optional) Enables MLD to receive control traffic on the interface.
send-general-query—(Optional) Enables MLD to send general queries on the interface.
send-group-query—(Optional) Enables MLD to send group-specific and

group-source-specific queries on the interface.


Documentation

peak-burst-size
Syntax peak-burst-size bytes;
Hierarchy Level [edit dynamic-profiles profile-name firewall three-color-policer name two-rate],


Support at the [edit dynamic-profiles ... two-rate] hierarchy level introduced in Junos OS
Release 11.4.
Description For a two-rate three-color policer, configure the peak burst size (PBS) as a number of
bytes. The PBS defines the maximum number of bytes of unused peak bandwidth capacity
that can be accumulated. The accumulated bandwidth allows for moderate periods of
bursting traffic that exceeds the peak information rate (PIR) and the committed burst
size (CBS).
NOTE: When you include the peak-burst-size statement in the configuration,

you must also include the committed-burst-size and peak-information-rate
statements at the same hierarchy level.
traffic against two rate limits.
• A traffic flow is categorized green if it conforms to both the committed information

rate (CIR) and the CBS-bounded accumulation of available committed bandwidth
capacity.
• A traffic flow is categorized yellow if exceeds the CIR and CBS but conforms to the
PIR. Packets in a yellow flow are marked with medium-high packet loss priority (PLP)
and then passed through the interface.
• A traffic flow is categorized red if exceeds the PIR and the PBS-bounded accumulation
of available peak bandwidth capacity. Packets in a red traffic flow are marked with
m (1,000,000), or g (1,000,000,000).


Documentation


peak-information-rate
Syntax peak-information-rate bps;
Hierarchy Level [edit dynamic-profiles profile-name firewall three-color-policer name two-rate],


Support at the [edit dynamic-profiles ... two-rate] hierarchy level introduced in Junos OS
Release 11.4.
Description For a two-rate three-color policer, configure the peak information rate (PIR) as a number
of bits per second. The PIR is the maximum rate for traffic arriving at or departing from
the interface under peak line conditions. Traffic that exceeds the committed information
rate (CIR) and the committed burst size (CBS) is metered to the PIR.
NOTE: When you include the peak-information-rate statement in the

configuration, you must also include the committed-information-rate and
peak-burst-size statements at the same hierarchy level.
traffic against two rate limits.
• A traffic flow is categorized green if it conforms to both the CIR and the CBS-bounded
accumulation of available committed bandwidth capacity.
• A traffic flow is categorized yellow if exceeds the CIR and CBS but conforms to the
PIR. Packets in a yellow flow are marked with medium-high packet loss priority (PLP)
and then passed through the interface.
• A traffic flow is categorized red if exceeds the PIR and the PBS-bounded accumulation
of available peak bandwidth capacity. Packets in a red traffic flow are marked with
Options bps—Number of bits per second. You can specify a value in bits per second either as a
k (1000), m (1,000,000), or g (1,000,000,000).


Documentation

permissions
Syntax permissions [ permissions ];
Hierarchy Level [edit system login class]

Description Configure the login access privileges to be provided on the router or switch.
Options permissions—Privilege type. For a list of permission flag types, see Understanding Junos
OS Access Privilege Levels.

Related • Configuring Access Privilege Levels

Documentation
• user on page 683

physical-interface-policer
Syntax physical-interface-policer;

[edit logical-system logical-system-name firewall policer policer-name],
[edit logical-system logical-system-name three-color-policer policer-name],
[edit routing-instances routing-instance-name firewall 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
policer policer-name],
[edit logical-systems logical-system-name routing-instances routing-instance-name firewall
three-color-policer policer-name]

in Junos Release OS 11.4.
Description Configure an aggregate policer for a physical interface.
A physical interface policer can be a two-color or three-color policer. When you apply
physical interface policer, to different protocol families on the same logical interface, the
protocol families share the same policer instance. This means that rate limiting 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
different protocol families on the same physical interface. If you want a policer instance
to be associated with a protocol family, the corresponding physical interface filter needs
to be applied to that protocol family. The policer is not automatically applied to all
protocol families configured on the physical interface.
In contrast, with logical interface policers there are multiple separate policer instances.

Related • Two-Color and Three-Color Physical Interface Policers

Documentation
• physical-interface-filter

policer (Configuring)
Syntax policer policer-name {

filter-specific;
if-exceeding {
bandwidth-percent number;
}
shared-bandwidth-policer;
then {
policer-action;
}
}

[edit firewall],
[edit logical-systems logical-system-name firewall]

The out-of-profile policer action added in Junos OS Release 8.1.
The logical-bandwidth-policer statement added in Junos OS Release 8.2.
The physical-interface-policer statement introduced in Junos OS Release 9.6.
The shared-bandwidth-policer statement added in Junos OS Release 11.2
Release 11.4.
Description Configure policer rate limits and actions. When included at the [edit firewall] hierarchy
level, the policer statement creates a template, and you do not have to configure a policer
individually for every firewall filter or interface. To activate a policer, you must include
the policer-action modifier in the then statement in a firewall filter term or on an interface.
Options policer-action—One or more actions to take:
• discard—Discard traffic that exceeds the rate limits.
• forwarding-class class-name—Specify the particular forwarding class.
• loss-priority—Set the packet loss priority (PLP) to low, medium-low, medium-high,

or high.
policer-name—Name that identifies the policer. The name can contain letters, numbers,
and hyphens (-), and can be up to 255 characters long. To include spaces in the
name, enclose it in quotation marks (“ ”). Policer names cannot begin with an
underscore in the form __.*.
then—Actions to take on matching packets.


Related • Bandwidth Policer Overview

Documentation
• Configuring Firewall Filters and Policers for VPLS
• Configuring Multifield Classifiers
• Logical Interface (Aggregate) Policer Overview
• Physical Interface Policer Overview
• Statement Hierarchy for Configuring Policers
• Single-Rate Two-Color Policer Overview
• Using Multifield Classifiers to Set Packet Loss Priority
• filter (Configuring) on page 551
• priority (Schedulers)

policy (Subscriber Secure Policy)
Syntax policy policy-name {

inet {
from {
dscp dscp-value;
protocol protocol;
}
}
}
inet6 {
from {
dscp dscp-value;
protocol protocol;
}
}
}
}
Description Specify the policy that is applied to mirrored packets sent to a mediation device.
Options policy-name—Name of the policy from which to drop traffic.


Documentation

policy-options (Dynamic Profiles)
Syntax policy-options {
prefix-list uid {
ip-addresses;
dynamic-db;
}
}
Description Define a list of IPv4 or IPv6 address prefixes for use in a dynamic firewall filter or in an
HTTP redirect configuration.
You can configure up to 85,325 prefixes in each prefix list. To configure more than 85,325
prefixes, configure multiple prefix lists and apply them to multiple firewall filter terms.
Options uid—Unique identifier of the prefix list. You must assign a UID as the prefix list name.
ip-addresses—List of IPv4 or IPv6 address prefixes, one IP address per line in the
configuration.
dynamic-db—Specify that the routing policy and policy objects reference policies
configured in the dynamic database at the [edit dynamic] hierarchy level.

Related • Example: Using Routing Policy in an ISP Network

Documentation

post-service-filter (Dynamic Service Sets)
Syntax post-service-filter filter-name;
family service input],
family service input]

“$junos-interface-unit” family family service input] hierarchy level introduced in Junos OS
Release 10.1.
Description Define the filter to be applied to traffic after service processing. The filter is applied only
if a service set is configured and selected. You can configure a postservice filter on the
input side of the interface only. Only the Internet Protocol version 4 (IPv4) protocol family
is currently supported for dynamic PPPoE logical interfaces.
Options filter-name—Identifier for the post-service filter.


Documentation

pppoe-tags (Adjustment Control Profiles)
Syntax pppoe-tags {
priority priority;
}
Description Configure the shaping rate adjustment controls for the Point-to-Point Protocol over
Ethernet (PPPoE) Tags application.
Options priority—Priority of the Point to Point Protocol over Ethernet IA Tags application in the
adjustment control profile.
Default: 2
algorithm—Rate adjustment algorithm used by the Point to Point Protocol over Ethernet
(PPPoE) IA Tags application.
Values:

configured value.

Default: adjust-less


Documentation

precedence
Syntax precedence precedence;
family filter input filter-name],
family filter output filter-name],
[edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number family family
filter input filter-name],
[edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number family family
filter output filter-name],
family filter input filter-name],
family filter output filter-name]

The [edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” family
inet filter input filter-name] hierarchy level and [edit dynamic-profiles profile-name
interfaces pp0 unit “$junos-interface-unit” family inet filter output filter-name] hierarchy
level introduced in Junos OS Release 10.1.
Description Apply a precedence to a dynamic filter. Only the Internet Protocol version 4 (IPv4) protocol
family is currently supported for dynamic PPPoE logical interfaces.
Options precedence—Precedence value for the filter. The lower the precedence value, the higher
the precedence.
Default: 0

Related • Firewall Filters Overview

Documentation
• Basic Fast Update Filter Syntax on page 287

premium (Hierarchical Policer)
Syntax premium {
if-exceeding {
bandwidth-limit bandwidth;
burst-size-limit burst;
}
then {
discard;
}
}
Hierarchy Level [edit dynamic-profiles profile-name firewall hierarchical-policer],

[edit firewall hierarchical-policer]

Support at the [edit dynamic-profiles ... hierarchical-policer name] hierarchy level
Description On M40e, M120, and M320 edge routers with FPC input as FFPC and FPC output as SFPC,
and on MX Series, T320, T640, and T1600 edge routers with Enhanced Intelligent Queuing
(IQE) PICs, T4000 routers with Type 5 FPC and Enhanced Scaling Type 4 FPC, specify
a premium level for a hierarchical policer.
Options Options are described separately.

Related • Applying Policers

Documentation
• Guidelines for Applying Traffic Policers

priority (Dynamic Schedulers)
Syntax priority (priority-level | $junos-cos-scheduler-priority);

The $junos-cos-scheduler-priority predefined variable introduced in Junos OS Release
9.4.
Description Specify packet-scheduling priority value in a dynamic profile.
Options priority-level—one of the following packet-scheduling priority values:
• low—Scheduler has low priority.
• medium-low—Scheduler has medium-low priority.
• medium-high—Scheduler has medium-high priority.
• high—Scheduler has high priority. Assigning high priority to a queue prevents the queue
from being underserved.
• strict-high—Scheduler has strictly high priority. Configure a high priority queue with
unlimited transmission bandwidth available to it. As long as it has traffic to send, the
strict-high priority queue receives precedence over low, medium-low, and medium-high
priority queues, but not high priority queues. You can configure strict-high priority on
only one queue per interface.
$junos-cos-scheduler-priority—Junos predefined variable that is replaced with the

packet-scheduling priority value obtained from the RADIUS server when a subscriber

Documentation

profile (Access)
Syntax profile profile-name {

accounting {
address-change-immediate-update
accounting-stop-on-access-deny;
accounting-stop-on-failure;
ancp-speed-change-immediate-update;
coa-immediate-update;
coa-no-override service-class-attribute;
duplication;
duplication-vrf {
access-profile-name profile-name;
vrf-name vrf-name;
}
immediate-update;
order [ accounting-method ];
send-acct-status-on-config-change;
statistics (time | volume-time);
update-interval minutes;
wait-for-acct-on-ack;
}
authentication-order [ authentication-methods ];
client client-name {
chap-secret chap-secret;
group-profile profile-name;
ike {
allowed-proxy-pair {
remote remote-proxy-address local local-proxy-address;
}
pre-shared-key (ascii-text character-string | hexadecimal hexadecimal-digits);
ike-policy policy-name;
interface-id string-value;
}
l2tp {
aaa-access-profile profile-name;
interface-id interface-id;
lcp-renegotiation;
local-chap;
maximum-sessions-per-tunnel number;
multilink {
drop-timeout milliseconds;
fragment-threshold bytes;
}
ppp-authentication (chap | pap);
ppp-profile profile-name;
shared-secret shared-secret;
}
pap-password pap-password;
ppp {
cell-overhead;
encapsulation-overhead bytes;
framed-ip-address ip-address;
framed-pool framed-pool;

idle-timeout seconds;
interface-id interface-id;
keepalive seconds;
primary-dns primary-dns;
primary-wins primary-wins;
secondary-dns secondary-dns;
secondary-wins secondary-wins;
}
user-group-profile profile-name;
}
domain-name-server;
domain-name-server-inet;
domain-name-server-inet6;
preauthentication-order preauthentication-method;
provisioning-order (gx-plus | jsrc);
radius {
accounting-server [ ip-address ];
attributes {
exclude {
...
}
ignore {
framed-ip-netmask;
input-filter;
logical-system:routing-instance;
output-filter;
}
}
authentication-server [ ip-address ];
options {
accounting-session-id-format (decimal | description);
calling-station-id-delimiter delimiter-character;
calling-station-id-format {
agent-circuit-id;
agent-remote-id;
interface-description;
nas-identifier;
}
client-accounting-algorithm (direct | round-robin);
client-authentication-algorithm (direct | round-robin);
coa-dynamic-variable-validation;
ethernet-port-type-virtual;
interface-description-format {
exclude-adapter;
exclude-sub-interface;
}
juniper-dsl-attributes;
nas-identifier identifier-value;
nas-port-extended-format {
adapter-width width;
ae-width width;
port-width width;
slot-width width;
stacked-vlan-width width;
vlan-width width;
atm {

port-width width:
slot-width width;
vci-width width:
vpi-width width;
}
}
nas-port-id-delimiter delimiter-character;
nas-port-id-format {
agent-circuit-id;
agent-remote-id;
nas-identifier;
}
nas-port-type {
ethernet {
port-type;
}
}
revert-interval interval;
vlan-nas-port-stacked-format;
}
preauthentication-server ip-address;
}
radius-server server-address {
accounting-port port-number;
accounting-retry number;
accounting-timeout seconds;
dynamic-request-port
port port-number;
retry attempts;
routing-instance routing-instance-name;
secret password;
max-outstanding-requests value;
source-address source-address;
timeout seconds;
}
service {
accounting-order (activation-protocol | radius);
}
session-options {
client-group [ group-names ];
client-idle-timeout minutes;
client-session-timeoutminutes;
}
}
Hierarchy Level [edit access]

dynamic-request-port option added in Junos OS Release 14.2R1 for MX Series routers.
Description Configure PPP CHAP, or a profile and its subscriber access, L2TP, or PPP properties.

Options profile-name—Name of the profile.
For CHAP, the name serves as the mapping between peer identifiers and CHAP secret
keys. This entity is queried for the secret key whenever a CHAP challenge or response
is received.

Related • Configuring the PPP Authentication Protocol

Documentation
• Configuring Access Profiles for L2TP or PPP Parameters
• Configuring L2TP Properties for a Client-Specific Profile
• Configuring an L2TP LNS with Inline Service Interfaces
• Configuring PPP Properties for a Client-Specific Profile
• Configuring Service Accounting with JSRC
• AAA Service Framework Overview
• show network-access aaa statistics
• clear network-access aaa statistics
promiscuous-mode (Protocols IGMP)
Syntax promiscuous-mode;

[edit logical-systems logical-system-name protocols igmp interface interface-name],
[edit protocols igmp interface interface-name]

Statement introduced in Junos OS Release 9.2 for dynamic profiles.
Description Specify that the interface accepts IGMP reports from hosts on any subnetwork. Note
that when enabling promiscuous-mode, all routing devices on the ethernet segment
must be configured with the promiscuous mode statement. Otherwise, only the interface
configured with lowest IPv4 address acts as the querier for IGMP for this Ethernet segment.


Documentation
• Accepting IGMP Messages from Remote Subnetworks

protocol (Dynamic Schedulers)
Syntax protocol (any | non-tcp | tcp);

drop-profile-map]
Description Specify the protocol type for the specified scheduler in a dynamic profile.
Options any—Accept any protocol type.
non-tcp—Accept any protocol type other than TCP/IP.
tcp—Accept only TCP/IP protocol.
NOTE: Protocol types non-tcp and tcp are not supported on MX Series routers.

Documentation
protocol (Subscriber Secure Policy)
Syntax protocol protocol;
Description Specify the match IP protocol type for the radius-flow-tap policy.
Options protocol—Protocol for the IPv4 or IPv6 address for the radius-flow-tap policy.


Documentation

radius (Access Profile)
Syntax radius {
accounting-server [ ip-address ];
attributes {
exclude
...
}
ignore {
framed-ip-netmask;
input-filter;
logical-system-routing-instance;
output-filter;
}
}
authentication-server [ ip-address ];
options {
accounting-session-id-format (decimal | description);
calling-station-id-delimiter delimiter-character;
calling-station-id-format {
agent-circuit-id;
agent-remote-id;
nas-identifier;
}
client-accounting-algorithm (direct | round-robin);
client-authentication-algorithm (direct | round-robin);
coa-dynamic-variable-validation;
ethernet-port-type-virtual;
interface-description-format {
exclude-adapter;
exclude-sub-interface;
}
ip-address-change-notify message;
juniper-dsl-attributes;
nas-identifier identifier-value;
nas-port-extended-format {
ae-width width;
port-width width;
slot-width width;
stacked-vlan-width width;
vlan-width width;
atm {
port-width width:
slot-width width;
vci-width width:
vpi-width width;
}
}
nas-port-id-delimiter delimiter-character;
nas-port-id-format {
agent-circuit-id;

agent-remote-id;
nas-identifier;
}
nas-port-type {
ethernet {
port-type;
}
}
revert-interval interval;
vlan-nas-port-stacked-format;
}
preauthentication-server ip-address;
}
Hierarchy Level [edit access profile profile-name]

Description Configure the RADIUS parameters that the router uses for AAA authentication and
accounting for subscribers.

Related • Configuring RADIUS Server Parameters for Subscriber Access

Documentation
• RADIUS Server Options for Subscriber Access

radius-coa (Adjustment Control Profiles)
Syntax radius-coa {
priority priority;
}
Description Configure the shaping rate adjustment controls for the RADIUS CoA application.
Options priority—Priority of the RADIUS CoA application in the adjustment control profile.
Default: 1
algorithm—Rate adjustment algorithm used by the RADIUS CoA application.

Values:

configured value.

Default: adjust-always


Documentation

radius-flow-tap
Syntax radius-flow-tap {
interfaces interface-name;
multicast-interception;
policy policy-name {
inet {
from {
dscp dscp-value;
protocol protocol;
}
}
}
inet6 {
from {
dscp dscp-value;
protocol protocol;
}
}
}
}
source-ipv4-address ipv4-address;
)
Hierarchy Level [edit services]
Description Assign parameters that are used with subscriber secure policy mirroring.


Documentation

radius-server
Syntax radius-server server-address {

accounting-port port-number;
accounting-retry number;
accounting-timeout seconds;
dynamic-request-port
port port-number;
retry attempts;
routing-instance routing-instance-name;
secret password;
max-outstanding-requests value;
source-address source-address;
timeout seconds;
}
Hierarchy Level [edit access],


dynamic-request-port option added in Junos OS Release 14.2R1 for MX Series routers.
Description Configure RADIUS for subscriber access management, L2TP, or PPP.
To configure multiple RADIUS servers, include multiple radius-server statements. The

servers are tried in order and in a round-robin fashion until a valid response is received
from one of the servers or until all the configured retry limits are reached.
Options server-address—Address of the RADIUS authentication server.

Related • Configuring RADIUS Authentication for L2TP

Documentation
• Configuring the PPP Authentication Protocol
• Configuring RADIUS Server Authentication
• Configuring Authentication and Accounting Parameters for Subscriber Access
• show network-access aaa statistics
• clear network-access aaa statistics

rate-limit
Syntax rate-limit limit;
Hierarchy Level [edit system services finger],

[edit system services ftp],
[edit system services netconf ssh],
[edit system services ssh],
[edit system services telnet],
[edit system services xnm-clear-text],
[edit system services xnm-ssl]

Description Configure the maximum number of connections attempts per protocol (either IPv6 or
IPv4) on an access service.
Default 150 connections
Options rate-limit limit—(Optional) Maximum number of connection attempts allowed per minute,
per IP protocol (either IPv4 or IPv6).
Default: 150

Related • Configuring clear-text or SSL Service for Junos XML Protocol Client Applications
Documentation

rebalance-periodic (Aggregated Ethernet Subscriber Interfaces)
Syntax rebalance-periodic time hour:minute <interval hours>
Hierarchy Level [edit interfaces ae number aggregated-ether-options]
Description Configure periodic rebalancing of distribution of subscribers on an aggregated Ethernet

bundle.
Options hour:minute—Time at which the rebalancing occurs, in military time.
hours—Interval at which the rebalancing occurs, in hours. Default: 24 hours.

Related • Configuring Periodic Rebalancing of Subscribers in an Aggregated Ethernet Interface


rewrite-rules (Dynamic CoS Interfaces)
Syntax rewrite-rules {
}
}

Description Associate a rewrite-rules configuration or default mapping with a specific interface in a

dynamic profile.

rewrite-rules] hierarchy level.

Documentation
• rewrite-rules

routing-options (Dynamic Profiles)
Syntax routing-options {
access {
route prefix {
metric route-cost;
next-hop next-hop;
tag route-tag;
}
}
access-internal {
}
}
}
multicast {
no-qos-adjust;
}
}
access {
route prefix {
metric route-cost;
next-hop next-hop;
tag route-tag;
}
}
access-internal {
}
}
}
}
}
Hierarchy Level [edit dynamic-profiles profile-name],

[edit dynamic-profiles profile-name routing-instances $junos-routing-instance]

Support at the [edit dynamic-profiles profile-name routing-instances
$junos-routing-instance] hierarchy level introduced in Junos OS Release 10.1.
Description Configure protocol-independent routing properties in a dynamic profile.


Related • Configuring Dynamic Access Routes for Subscriber Management

Documentation
• Configuring Dynamic Access-Internal Routes for DHCP Subscriber Management
rpf-check (Dynamic Profiles)
Syntax rpf-check {
mode loose;
}
family]
Description Check whether traffic is arriving on an expected path. You can include this statement
with the inet protocol family only.

Related • Configuring Unicast RPF

Documentation
• Configuring Unicast RPF and Fail Filters in Dynamic Profiles for Subscriber Interfaces
on page 304

rule (Captive Portal Content Delivery)
Syntax rule rule-name {

term term-name {
from {
}
then {
accept;
redirect <url>;
syslog;
}
}
}
Hierarchy Level [edit services captive-portal-content-delivery (Captive Portal Content Delivery)]
Description Specify the rule the router uses when applying this service.
Options rule-name—Identifier for the collection of terms that constitute this rule.
Required Privilege services—To view this statement in the configuration.

Level services–control—To add this statement to the configuration.

Documentation

rule-set (Captive Portal Content Delivery)
Syntax rule-set rule-set-name {

[rule rule-name];
}
Description Define a set of captive portal content delivery rules that the router uses when applying
this service.
Options rule-set-name—Identifier for the collection of rules that constitute this rule set.
rule rule-name–Name of a rule defined at the [edit services captive-portal-content-delivery]

hierarchy level.


Documentation
scheduler (Dynamic Scheduler Maps)
Syntax scheduler scheduler-name;
Hierarchy Level [edit dynamic-profiles profile-name class-of-service scheduler-maps map-name

forwarding-class class-name]
Description Associate a scheduler with a scheduler map in a dynamic profile.
Options scheduler-name—Either the specific name of the scheduler configuration block or the
scheduler variable ($junos-cos-scheduler).

Documentation

scheduler-map (Dynamic Traffic Shaping)
Syntax scheduler-map (map-name);

The $junos-cos-scheduler-map variable introduced in Junos OS Release 9.4.
Description Associate a scheduler map name with a traffic-control profile in a dynamic profile.
The scheduler map can be defined dynamically (at the [edit dynamic-profiles profile-name
class-of-service scheduler-maps] hierarchy level) or statically (at the [edit class-of-service
scheduler-maps] hierarchy level).
Options map-name—Name of the scheduler map or the Junos predefined variable

($junos-cos-scheduler-map). When you specify the variable, the scheduler-map
name is obtained from the RADIUS server when a subscriber authenticates over the

Documentation

scheduler-maps (Dynamic CoS Definition)
Syntax scheduler-maps {
map-name {
}
}

Support at the [edit dynamic-profiles profile-name] hierarchy level introduced in Junos
OS Release 9.3.
Description Specify a scheduler map name in a dynamic profile and associate it with the scheduler
configuration and forwarding class.
Options map-name—Name of the scheduler map.

Documentation

schedulers (Dynamic CoS Definition)
Syntax schedulers {
scheduler-name{
adjust-minimum rate;
adjust-percent percentage;
buffer-size (percent percentage | remainder | temporal microseconds |
$junos-cos-scheduler-bs);
drop-profile-map loss-priority (any | low | medium-low | medium-high | high) protocol
(any | non-tcp | tcp) drop-profile (profile-name | predefined-variable);
excess-priority (low | high | $junos-cos-scheduler-excess-priority | none);
priority (priority-level | $junos-cos-scheduler-priority);
shaping-rate (rate | predefined-variable) <burst-size bytes>;
transmit-rate (rate | percent percentage | remainder | percent percentage
}
}

The $junos-cos-scheduler predefined variable introduced in Junos OS Release 9.4.
Description Specify scheduler name and parameter values in a dynamic profile.
Options scheduler-name—Name of the scheduler to be configured or the Junos OS predefined

variable ($junos-cos-scheduler). The predefined variable is replaced with the
scheduler name obtained from the RADIUS server when a subscriber authenticates

Documentation

service (Dynamic Service Sets)
Syntax service {
input {
}
}
output {
}
}
}
family],
family]

“$junos-interface-unit” family family] hierarchy level introduced in Junos OS Release 10.1.
Description Define the service sets and filters to be applied to an interface. This statement is not
supported for family inet6.


Documentation

service-filter (Dynamic Service Sets)
Syntax service-filter filter-name;
family service input service-set service-set-name],
family service output service-set service-set-name],
[edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” family family
service input service-set service-set-name],
service output service-set service-set-name]

“$junos-interface-unit” family family service input service-set service-set-name] and [edit
dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” family family
service output service-set service-set-name] hierarchy levels introduced in Junos OS
Release 10.1.
Description Define the filter to be applied to traffic before it is accepted for service processing.
Configuration of a service filter is optional; if you include the service-set statement without
a service-filter definition, the router software assumes that the match condition is true
and selects the service set for processing automatically. Only the Internet Protocol version
4 (IPv4) protocol family is currently supported for dynamic PPPoE logical interfaces.
Options filter-name—Identifies the filter to be applied in service processing.


Documentation

service-set (Dynamic Service Sets)
Syntax service-set service-set-name {

}
family service input],
family service output],
service input],
service output]

“$junos-interface-unit” family family service input] and [edit dynamic-profiles profile-name
interfaces pp0 unit “$junos-interface-unit” family family service output] hierarchy levels
Description Define one or more service sets in a dynamic profile. Service sets are applied to an
interface. If you define multiple service sets, the router software evaluates the filters in
the order in which they appear in the configuration. Only the Internet Protocol version 4
(IPv4) protocol family is currently supported for dynamic PPPoE logical interfaces.
Options service-set-name—Name of the service set.


Documentation

services (Captive Portal Content Delivery)
Syntax services {
...
rule rule-name {
term term-name {
from {
}
then {
accept;
redirect <url>;
syslog;
}
}
}
[rule rule-name];
}
}
...
}
Hierarchy Level [edit]
Description Define the captive portal and content delivery set of the rules statements to be applied
to traffic.


Documentation

shaping-rate (Dynamic Traffic Shaping and Scheduling)
Syntax shaping-rate (rate | predefined-variable) <burst-size bytes | $junos-cos-shaping-rate-burst>;
Hierarchy Level [edit dynamic-profiles profile-name class-of-service traffic-control-profiles profile-name],


The $junos-cos-shaping-rate variable for traffic-control profiles introduced in Junos OS
Release 9.4.
The $junos-cos-scheduler-shaping-rate variable for schedulers introduced in Junos OS
Release 10.2.
Option burst-size introduced in Junos OS Release 11.4.
Description Configure a shaping rate for a logical interface or a scheduler. The sum of the shaping
rates for all logical interfaces on the physical interface can exceed the physical interface
bandwidth. This practice is known as oversubscription of the peak information rate (PIR).
Options rate—Peak rate in bits per second (bps). You can specify the value as a complete decimal
m (1,000,000), or g (1,000,000,000).
predefined-variable—One of the following Junos predefined variables. The variable is

replaced with a value obtained from the RADIUS server when a subscriber
• $junos-cos-shaping-rate—Variable for the shaping rate that is specified for the logical
interface. Use this variable at the [edit dynamic-profiles profile-name class-of-service
traffic-control-profiles profile-name] hierarchy level.
• $junos-cos-scheduler-shaping-rate—Variable for the shaping rate that is specified for

a scheduler. Use this variable at the [edit dynamic-profiles profile-name class-of-service
schedulers scheduler-name] hierarchy level.
burst-size bytes—(Optional) Maximum burst size, in bytes.

Range: 0 through 1,000,000,000
$junos-cos-shaping-rate-burst—(Optional) Variable for the burst-size that is specified

for the shaping rate. Use this variable at the [edit dynamic-profiles profile-name
class-of-service traffic-control-profile] hierarchy level.

Documentation

shared-name
Syntax shared-name filter-shared-name;
family-name filter [input | output] filter-name]
Description Apply a filter shared name to a dynamic filter.
Options filter-shared-name— Name of the specific shared filter or $junos-interface-set-name.


Documentation

single-rate
Syntax single-rate {
}

[edit logical-systems logical-system-name firewall three-color-policer policer-name]

Support at the [edit dynamic-profiles ... three-color-policer name] hierarchy level
Description Configure a single-rate three-color policer in which marking is based on the committed
information rate (CIR), committed burst size (CBS), and excess burst size (EBS).
Packets that conform to the CIR or the CBS are assigned low loss priority (green). Packets
that exceed the CIR and the CBS but are within the EBS are assigned medium-high loss
priority (yellow). Packets that exceed the EBS are assigned high loss priority (red).
Green and yellow packets are always forwarded; this action is not configurable. You can
configure red packets to be discarded. By default, red packets are forwarded.


Documentation
• two-rate on page 677

source (Dynamic IGMP Interface)
Syntax source source;
Hierarchy Level [edit dynamic-profiles profile-name protocols igmp interface interface-name static]
Description Specify the IP version 4 (IPv4) unicast address to send data on an interface.
Options source—IPv4 unicast address.


Documentation
source (Dynamic MLD Interface)
Syntax source ip-address {

}
Description IP version 6 (IPv6) unicast source address for the multicast group being configured on
a dynamic interface.
Options ip-address—One or more IPv6 unicast addresses.


Documentation

source-address (Subscriber Secure Policy)
Syntax source-address address;
Description Specify source IP address or prefix value from which to inherit configuration data for
radius-flow-tap policy rule mapping.
Options address— IPv4 or IPv6 address for the radius-flow-tap policy.


Documentation
source-count (Dynamic MLD Interface)
Syntax source-count number;
Description Configure the number of multicast source addresses that should be accepted for each
static group created on dynamic interfaces.
Options number—Number of source addresses.

Default: 1


Documentation

source-increment (Dynamic MLD Interface)
Syntax source-increment increment;
Hierarchy Level [edit dynamic-profile profile-name protocols mld interface interface-name static group
Description Configure the number of times the address should be incremented for each static group
created on the dynamic interface. The increment is specified in a format similar to an
IPv6 address.
Options increment—Number of times the source address should be incremented.

Default: ::1
Range: ::1 through ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:


Documentation
source-ipv4-address
Syntax source-ipv4-address ipv4-address;
Description Specify the source IP address used in the IP header that is prepended to mirrored packets
sent to a mediation device.
Options ipv4-address—IPv4 address.


Documentation

source-port (Subscriber Secure Policy)
Syntax source-port port-number;
Description Specify the match source port for the radius-flow-tap policy.
Options port-number— Number of the IPv4 or IPv6 source port for the radius-flow-tap policy.


Documentation

ssh
Syntax ssh {
authentication-order [authentication-methods];
ciphers [ cipher-1 cipher-2 cipher-3 ...];
client-alive-count-max seconds;
client-alive-interval seconds;
connection-limit limit;
hostkey-algorithm <algorithm|no-algorithm>;
key-exchange <algorithm>;
macs <algorithm>;
max-sessions-per-connection <number>;
no-passwords;
no-tcp-forwarding;
protocol-version [v1 v2];
rate-limit limit;
root-login (allow | deny | deny-password);
}
Hierarchy Level [edit system services]

client-alive-interval and client-alive-max-count statements introduced in Junos OS Release
12.2.
no-passwords statement introduced in Junos OS Release 13.3.
Description Allow SSH requests from remote systems to the local router or switch.

Related • Configuring SSH Service for Remote Access to the Router or Switch
Documentation

ssm-map (Dynamic IGMP Interface)
Syntax ssm-map ssm-map-name;
Description Apply an SSM map to an IGMP interface.
Options ssm-map-name—Name of SSM map.


Documentation
• Source-Specific Multicast Groups Overview
ssm-map (Dynamic MLD Interface)
Syntax ssm-map ssm-map-name;
Description Apply an SSM map to a dynamic MLD interface.
Options ssm-map-name—Name of SSM map.


Documentation
• Example: Configuring SSM Mapping

static (Dynamic IGMP Interface)
Syntax static {
group group;
group group {
source source;
}
}
Description Test multicast forwarding on an interface without a receiver host.
Required Privilege routing and trace—To view this statement in the configuration.
Level routing-control and trace-control—To add this statement to the configuration.

Documentation

static (Dynamic MLD Interface)
Syntax static {
exclude;
group-count number;
source ip-address {
}
}
}
Description Test multicast forwarding on an interface.

Documentation

subscriber-leave-timer
Syntax subscriber-leave-timer seconds;
Hierarchy Level [edit logical-systems logical-system-name routing-instances routing-instance-name

routing-options multicast interface interface-name],
[edit logical-systems logical-system-name routing-options multicast
interface interface-name],
[edit routing-instances routing-instance-name routing-options multicast
interface interface-name],
[edit routing-options multicast interface interface-name]

Statement introduced in Junos OS Release 12.3 for ACX Series routers.
Description Length of time before the multicast VLAN updates QoS data (for example, available
bandwidth) for subscriber interfaces after it receives an IGMP leave message.
Options seconds—Length of time before the multicast VLAN updates QoS data (for example,
available bandwidth) for subscriber interfaces after it receives an IGMP leave
message. Specifying a value of 0 results in an immediate update. This is the same
as if the statement were not configured.
Range: 0 through 30
Default: 0 seconds

targeted-distribution (Dynamic Demux Interfaces over Aggregated Ethernet)
Syntax targeted-distribution;
Hierarchy Level [edit dynamic-profiles profile-name interfaces demux0 unit logical-unit-number]
Description Configure egress data for a dynamic logical interface to be sent across a single member
link in an aggregated Ethernet bundle. A backup link is provisioned with CoS scheduling
resources in the event that the primary assigned link goes down. The aggregated Ethernet
interface must be configured without link protection.


targeted-distribution (Static Interfaces over Aggregated Ethernet)
Syntax targeted-distribution;
Hierarchy Level [edit interfaces demux0 unit logical-unit-number],

[edit interfaces pp0 unit logical-unit-number]

Description Configure egress data for a logical interface to be sent across a single member link in an
aggregated Ethernet bundle. A backup link is provisioned with CoS scheduling resources
in the event that the primary assigned link goes down. The aggregated Ethernet interface
must be configured without link protection.


Documentation
• Verifying the Distribution of PPPoE Subscribers in an Aggregated Ethernet Interface

on page 158
• Targeted Traffic Distribution on Aggregated Ethernet Interfaces in a Virtual Chassis
• Configuring Module Redundancy for a Virtual Chassis
• Configuring Chassis Redundancy for a Virtual Chassis

term (Captive Portal Content Delivery)
Syntax term term-name{

from {
}
then {
accept;
redirect <url>;
syslog;
}
}
Hierarchy Level [edit services captive-portal-content-delivery rule rule-name]
Description Define the term match and action properties for the captive portal content delivery rule.
Options term-name—Identifier for the term.


Documentation

term (Dynamic Profiles)
Syntax term term-name {

from {
match-conditions;
}
then {
action;
action-modifiers;
}
only-at-create;
}
Hierarchy Level [edit dynamic-profiles profile-name firewall family family-name fast-update-filter

filter-name],
[edit dynamic-profiles profile-name firewall family family-name filter filter-name]

Support at the [edit dynamic-profiles ... filter filter-name] hierarchy level introduced in
Description Define terms for fast update filters.
Options action—(Optional) An action to take if conditions match. If you do not specify an action,
the packets that match the conditions in the from statement are accepted.
action-modifiers—(Optional) One or more actions to perform on a packet.
from—(Optional) Match packet fields to values. If not included, all packets are considered
to match and the actions and action modifiers in the then statement are taken.
match-conditions—One or more conditions to make a match.
only-at-create—(Optional) Specify that the term is added only when the fast update
filter is first created. No subsequent changes can be made to the term in the filter.
Use this option only for terms that do not include subscriber-specific data in their
match conditions, such as common or default terms (for example, counting the
default drop packets).
term-name—Name that identifies the term. The name can contain letters, numbers, and
hyphens (-), and can be up to 64 characters long. To include spaces in the name,
enclose it in quotation marks (“ ”).
then—(Optional) Actions to take on matching packets. If not included and a packet

matches all the conditions in the from statement, the packet is accepted.


Documentation


then (Captive Portal Content Delivery)
Syntax then {
accept;
redirect <url>;
syslog;
}
Hierarchy Level [edit services captive-portal-content-delivery rule rule-name term term-name]
Description Define the term actions and any optional action modifiers for the captive portal content
delivery rule.
Options action—Actions to accept, redirect, or rewrite packets and all subsequent packets in flows
that match the rules.
• accept—Accept the packets and all subsequent packets in flows that match the
rules.
• redirect—Redirect the packet and all subsequent packets in flows that match the
rules. You can optionally configure the following action modifier:
• url—(Optional) URL destination for the redirected packet. The URL must begin
with http:// or https://.
• rewrite— Rewrite the packet and all subsequent packets in flows that match the
rules. You can optionally configure one or both of the following action modifiers:
• destination-address address—(Optional) Destination address for the rewritten

packet.
• destination-port port-number—(Optional) Destination port for the rewritten

packet.
• syslog— Log information about the packet to a system log file.
action-modifiers (Optional)—Additional actions to accept, redirect, or rewrite packets

and all subsequent packets in flows that match the rules.
• destination-address—(Optional) Destination address of the rewrite packet.
• destination-port —(Optional) Destination address and destination port of the

rewrite packet.
• url—(Optional) URL of the redirect packet.



Documentation
• Firewall Filter Match Conditions Based on Address Fields

three-color-policer (Configuring)
Syntax three-color-policer policer-name | uid {

action {
}
filter-specific;
shared-bandwidth-policer;
single-rate {
}
two-rate {
}
}

[edit firewall],
[edit logical-systems logical-system-name firewall]

The action and single-rate statements added in Junos OS Release 8.2.
Release 11.4.
Description Configure a three-color policer.
Options policer-name—Name of the three-color policer. Reference this name when you apply the
policer to an interface.
uid—When you configure a policer at the [edit dynamic-profiles] hierarchy level, you must
assign a variable UID as the policer name.

Related • Statement Hierarchy for Configuring Policers

Documentation
• Configuring Tricolor Marking Policers
• Three-Color Policer Configuration Guidelines


traceoptions (Captive Portal Content Delivery)
Syntax traceoptions {
file filename <files number> <match regular-expression> <size size> <world-readable |
no-world-readable>;
flag flag;
no-remote-trace;
}
Description Define tracing operations for captive-portal-content-delivery processes.
Options file filename—Name of the file to receive the output of the tracing operation. Enclose the
name within quotation marks. All files are placed in the directory /var/log. Ensure
that filenames are unique for each logical system or routing instance in which Mobile
IP is configured.
NOTE: Global messages (common to all logical systems and routing

instances) are always saved in /var/log/mipd. Messages that are specific to
a logical system or routing instance are never saved in /var/log/mipd. If you
do not configure a trace filename for a logical system or routing instance,
then nothing is traced for that entity.
size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),
or gigabytes (GB). If you specify a maximum file size, you also must specify a
maximum number of trace files with the files option.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through 1 GB
Default: 128 KB
files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and
so on, until the maximum number of trace files is reached. Then the oldest trace file
is overwritten. If you specify a maximum number of files, you also must specify a
maximum file size with the size option.
Default: 3 files
flag flag—Tracing operation to perform. To specify more than one tracing operation,
include multiple flag statements. You can include the following flags:
• all—Trace all operations.
• clicommand—Trace CLI command operations.

• configuration—Trace home agent state machine operations.
• general—Trace general operations.
• gres—Trace graceful routing switchover operations.
• ipc—Trace Inter-Process Communication (IPC) messages between the PIC and the
Routing Engine.
• rtsock—Trace routing socket operations.
• rules—Trace rules operations.
• ssets—Trace service sets operations.
• statistics—Trace statistics operations.
Required Privilege trace—To view this statement in the configuration.

Level trace-control—To add this statement to the configuration.

Documentation

traffic-control-profiles (Dynamic CoS Definition)
Syntax traffic-control-profiles profile-name {

adjust-minimum rate;
excess-rate (percent percentage | proportion value | percent $junos-cos-excess-rate);
excess-rate-high (percent percentage | proportion value);
excess-rate-low (percent percentage | proportion value);
guaranteed-rate (percent percentage | rate) <burst-size bytes>;
overhead-accounting (frame-mode | cell-mode) <bytes byte-value>;
shaping-rate (percent percentage | rate | predefined-variable) <burst-size bytes>;
}
Description Configure traffic shaping and scheduling profiles.
Options profile-name—Name of the traffic-control profile.

Documentation
• Using the CLI to Modify Traffic-Control Profiles That Are Currently Applied to Subscribers

transmit-rate (Dynamic Schedulers)
Syntax transmit-rate (rate | percent percentage | remainder | percent percentage


The $junos-cos-scheduler-tx predefined variable introduced in Junos OS Release 9.4.
Description Specify the transmit rate or percentage for a scheduler in a dynamic profile.
Default If you do not include this statement, the default scheduler transmission rate and buffer
size percentages for queues 0 through 7 are 95, 0, 0, 5, 0, 0, 0, and 0 percent.
Options rate—Transmission rate, in bps. You can specify a value in bits per second either as a
k (1000), m (1,000,000), or g (1,000,000,000).
percent percentage—Percentage of transmission capacity. A percentage of zero drops

all packets in the queue.
remainder—Use remaining rate available.
$junos-cos-scheduler-tx—Junos predefined variable that is replaced with the transmission

rate obtained from the RADIUS server when a subscriber authenticates over the
exact—(Optional) Enforce the exact transmission rate. Under sustained congestion, a

rate-controlled queue that goes into negative credit fills up and eventually drops
packets. Make sure this value never exceeds the rate-controlled amount.
rate-limit—(Optional) Limit the transmission rate to the rate-controlled amount during

congestion. In contrast to the exact option, when there is no congestion, the scheduler
with the rate-limit option shares unused bandwidth above the rate-controlled amount.

Documentation

tunnel-services (Chassis)
Syntax tunnel-services {
bandwidth (1g | 10g | 20g | 40g);
tunnel-only;
}
Hierarchy Level [edit chassis fpc slot-number pic number]
Description For MX Series 3D Universal Edge Routers, configure the amount of bandwidth for tunnel
services.
For M7i, M10i, M120, M320, T Series and TX Matrix routers with IQ2 PICs and IQ2E PICs,
configure support for per unit scheduling for GRE tunnels. You can specify the IQ2 and
IQ2E PICs to work exclusively in tunnel mode or as a regular PIC. The default setting uses
IQ2 and IQ2E PICs as a regular PIC. If you do not configure the tunnel-only option, the IQ2
and IQ2 PICs operate as regular PICs. For M7i, M10i, M120, M320, T Series and TX Matrix
routers with IQ2 PICs and IQ2E PICs, you can use the tunnel-only option to specify that
an IQ2 or IQ2E PIC work in tunnel mode only.
NOTE: Bandwidth rates of 20 gigabits per second and 40 gigabits per second
require use of an MX Series router with the 100-Gigabit Ethernet Modular
Port Concentrator (MPC) and the 100-Gigabit CFP MIC.
NOTE: On MX80 routers and MX Series routers with Trio-based FPCs, when
ingress queuing is enabled for a PIC, tunnel services and inline services are
not supported on the same PIC.
Options tunnel–only (Optional)—For M7i, M10i, M120, M320, T Series and TX Matrix routers with
IQ2 PICs and IQ2E PICs, specify that an IQ2 or IQ2E PIC work in tunnel mode only.

Related • Example: Configuring Tunnel Interfaces on a Gigabit Ethernet 40-Port DPC

Documentation
• Example: Configuring Tunnel Interfaces on a 10-Gigabit Ethernet 4-Port DPC
• Example: Configuring Tunnel Interfaces on the MPC3E
• bandwidth (Tunnel Services) on page 493
• [edit chassis] Hierarchy Level

• Configuring Layer 3 Tunnel Services Interfaces on an MX Series Router with a DPC
two-rate
Syntax two-rate {
}

[edit logical-systems logical-system-name firewall three-color-policer policer-name]

Support at the [edit dynamic-profiles ... three-color-policer name hierarchy levels introduced
Description Configure a two-rate three-color policer in which marking is based on the committed
information rate (CIR), committed burst size (CBS), peak information rate (PIR), and
peak burst size (PBS).
Packets that conform to the CIR or the CBS are assigned low loss priority (green). Packets
that exceed the CIR and the CBS but are within the PIR or the PBS are assigned
medium-high loss priority (yellow). Packets that exceed the PIR and the PBS are assigned
high loss priority (red).
Green and yellow packets are always forwarded; this action is not configurable. You can
configure red packets to be discarded. By default, red packets are forwarded.


Documentation
• single-rate on page 654

uid (Dynamic Profiles)
Syntax uid;
Hierarchy Level [edit dynamic-profiles profile-name variables variable-name]
Description Configure a unique ID for parameterized filters in a dynamic profile created for services.
The values that the system uses for these variables are applied when the subscriber
authenticates.

Related • Dynamic Variables Overview

Documentation
uid-reference
Syntax uid-reference;
Hierarchy Level [edit dynamic-profiles profile-name variables variable-name]
Description When you configure a unique ID (UID) variable, include this statement to specify that the
value for the UID is supplied by RADIUS when the subscriber authenticates.

Related • Unique Identifiers for Firewall Variables on page 250

Documentation
• Configuring Unique Identifiers for Parameterized Filters on page 252

unit (Dynamic Profiles Standard Interface)
Syntax unit logical-unit-number {

auto-configure {
}
}
dial-options {
ipsec-interface-id name;
l2tp-interface-id name;
(shared | dedicated);
}
encapsulation (atm-ccc-cell-relay | atm-ccc-vc-mux | atm-cisco-nlpid | atm-tcc-vc-mux
| atm-mlppp-llc | atm-nlpid | atm-ppp-llc | atm-ppp-vc-mux | atm-snap | atm-tcc-snap
| atm-vc-mux | ether-over-atm-llc | ether-vpls-over-atm-llc | ether-vpls-over-fr |
ether-vpls-over-ppp | ethernet | frame-relay-ccc | frame-relay-ppp | frame-relay-tcc |
frame-relay-ether-type | frame-relay-ether-type-tcc | multilink-frame-relay-end-to-end
| multilink-ppp | ppp-over-ether | ppp-over-ether-over-atm-llc | vlan-bridge | vlan-ccc |
vlan-vci-ccc | vlan-tcc | vlan-vpls);
family family {
address address;
direct-connect;
filter {
adf {
counter;
not-mandatory;
rule rule-value;
}
input filter-name (
}
}
}
rpf-check {
mode loose;
}
service {
input {
}
}

input-vlan-map {
(push | swap);
vlan-id number;
}
output {
}
}
output-vlan-map {
(pop | swap);
vlan-id number;
}
}
maximum-seconds>;
filter {
input filter-name;
output filter-name;
}
keepalives {
interval seconds;
}
ppp-options {
chap;
pap;
}
vlan-id number;
}
}
Hierarchy Level [edit dynamic-profiles profile-name interfaces interface-name]
Description Configure a logical interface on the physical device. You must configure a logical interface
to be able to use the physical device.

Options logical-unit-number—The specific unit number of the interface you want to assign to the
dynamic profile, or one of the following Junos OS predefined variables:
• $junos-underlying-interface-unit—For static VLANs, the unit number variable. The static

unit number variable is dynamically replaced with the client unit number when the
client session begins. The client unit number is specified by the DHCP when it accesses
the subscriber network.
• $junos-interface-unit—The unit number variable on a dynamic underlying VLAN interface

for which you want to enable the creation of dynamic VLAN subscriber interfaces based
on agent circuit identifier information.

Related • Configuring Dynamic Underlying VLAN Interfaces to Use Agent Circuit Identifier Information
Documentation
• Configuring Static Underlying VLAN Interfaces to Use Agent Circuit Identifier Information
• Agent Circuit Identifier-Based Dynamic VLANs Components Overview

unit (Dynamic Traffic Shaping)
Syntax unit logical-unit-number {

classifiers {
}
rewrite-rules {
}
}
}
Hierarchy Level [edit dynamic-profiles profile-name class-of-service interfaces interface-name],

[edit dynamic-profiles profile-name interfaces interface-set interface-set-name interface
interface-name]

Support at the [edit dynamic-profiles profile-name class-of-service interfaces interface-set
interface-set-name] hierarchy level introduced in Junos OS Release 10.4.
Description Configure a logical interface on the physical device. You must configure a logical interface
to be able to use the physical device.
Options logical-unit-number—One of the following options:
• $junos-underlying-interface-unit—For static VLANs, the unit number variable. The static

unit number variable is dynamically replaced with the client unit number when the
client session begins. The client unit number is specified by the DHCP when it accesses
the subscriber network.
• $junos-interface-unit—For dynamic demux and dynamic PPPoE interfaces, the unit

number variable. The static unit number variable is dynamically replaced with the client
unit number when the client session begins. The client unit number is specified by the
DHCP or PPP when it accesses the subscriber network.
• value—Specific unit number of the interface you want to assign to the dynamic-profile
Range: 0 through 16385. For demux and PPPoE interfaces, the unit numbers can range
from 0 through 1,073,741,823.
The remaining statements are explained separately. The classifiers,

output-traffic-control-profile, and rewrite-rules statements are not supported for
interface sets.


Documentation
on page 217
user (Access)
Syntax user username {

authentication {
class class-name;
full-name complete-name;
load-key-file URL filename;
ssh-dsa “public-key” <from hostname>;
ssh-rsa “public-key” <from hostname>;
uid uid-value;
}
}
Hierarchy Level [edit system login]

Description Configure access permission for individual users.


Documentation
• class on page 506

vendor-specific-tags (Dynamic Traffic Shaping)
Syntax vendor-specific-tags actual-data-rate-downstream;

vendor-specific-tags access-loop-encapsulation;
Hierarchy Level [edit dynamic-profiles profile-name class-of-service dynamic-class-of-service-options]
Description Set the shaping-rate and overhead-accounting class-of-service attributes based on

Vendor-Specific Point-to-Point Protocol over Ethernet (PPPoE) Tags [TR-101].
Options vendor-specific-tags can be set to one or both of the following:
• access-loop-encapsulation—Set the overhead-accounting class-of-service attribute

based on access line parameters in PPPoE discovery packets on dynamic subscriber
interfaces.
• actual-data-rate-downstream—Set the shaping-rate class-of-service attribute based

on the actual-data-rate-downstream attribute.



version (Dynamic IGMP Interface)
Syntax version version;
Hierarchy Level [edit dynamic-profiles profile-name protocols igmpinterface interface-name]
Description Specify the version of IGMP.
Options version—IGMP version number.

Range: 1, 2, or 3
Default: IGMP version 2
NOTE: Routers running different versions of IGMP negotiate the lowest

common version of IGMP that is supported by hosts on their subnet and
operate in that version.
If you have already configured the router to use IGMP version 1 and then
configure it to use IGMP version 2, the router continues to use IGMP version
1 for up to 6 minutes and then uses IGMP version 2.


Documentation
• Changing the IGMP Version

version (Dynamic MLD Interface)
Syntax version version;
Description Configure the MLD version explicitly on the dynamic interface. MLD version 2 (MLDv2) is
used only to support source-specific multicast (SSM).
Options version—MLD version to run on the interface.

Range: 1 or 2
Default: 1 (MLDv1)

Documentation
• Modifying the MLD Version
vlan-tag (Dynamic Classifiers)
Syntax vlan-tag (inner | outer);

logical-unit-number classifiers ieee-802.1]
Description Apply this IEEE-802.1 classifier to the inner or outer VLAN tags in a dynamic profile.
Default If you do not include this statement, the classifier applies to the outer VLAN tag only.
Options inner—Apply the classifier to the inner VLAN tag only.
outer—Apply the classifier to the outer VLAN tag only.

Documentation

vlan-tag (Dynamic Rewrite Rules)
Syntax vlan-tag (outer | outer-and-inner);

logical-unit-number rewrite-rules ieee-802.1]
Description Apply this IEEE-802.1 rewrite rule to the outer or outer and inner VLAN tags in a dynamic
profile.
Default If you do not include this statement, the rewrite rule applies to the outer VLAN tag only.
Options outer—Apply the rewrite rule to the outer VLAN tag only.
outer-and-inner—Apply the rewrite rule to both the outer and inner VLAN tags.

Documentation
page 219
• rewrite-rules


CHAPTER 44
Operational Commands
• clear firewall
• clear igmp membership
• clear igmp statistics
• clear mld membership
• clear mld statistics
• clear services captive-portal-content-delivery statistics
• request interface rebalance (Aggregated Ethernet for Subscriber Management)
• show class-of-service
• show class-of-service adjustment-control-profile
• show class-of-service interface
• show class-of-service interface-set
• show class-of-service scheduler-hierarchy interface
• show class-of-service scheduler-hierarchy interface-set
• show class-of-service scheduler-map
• show class-of-service traffic-control-profile
• show firewall
• show firewall log
• show firewall templates-in-use
• show igmp group
• show igmp interface
• show igmp statistics
• show interfaces targeting (Aggregated Ethernet for Subscriber Management)
• show mld group
• show mld interface
• show mld statistics
• show services captive-portal-content-delivery
• show services service-sets summary

• show subscribers
• show subscribers summary

Chapter 44: Operational Commands
clear firewall
List of Syntax Syntax on page 691

Syntax (EX Series Switches) on page 691
Syntax clear firewall (all | counter counter-name | filter filter-name | log (all | logical-system-name
) | logical-system logical-system-name)
Syntax (EX Series clear firewall (all | counter counter-name | filter filter-name | log (all | logical-system-name)
Switches) | policer counter (all | counter-id counter-index))
Release Information Command introduced before Junos OS Release 7.4.

Command introduced in Junos OS Release 9.0 for EX Series switches.
logical-system option introduced in Junos OS Release 9.3.
log option introduced before Junos OS Release 11.4.
Description Clear statistics about configured firewall filters.
When you clear the counters of a filter, this impacts not only the counters shown by the
CLI, but also the ones tracked by SNMP2.
Subscriber management uses firewall filters to capture and report the volume-based
service accounting counters that are used for subscriber billing. The clear firewall
command also clears the service accounting counters that are reported to the RADIUS
accounting server. For this reason, you must be cautious in specifying which firewall
statistics you want to clear.
NOTE: The clear firewall command cannot be used to clear the Routing Engine
filter counters on a backup Routing Engine that is enabled for graceful Routing
Engine switchover (GRES).
If you clear statistics for firewall filters that are applied to Trio-based DPCs and that also
use the prefix-action action on matched packets, wait at least 5 seconds before you enter
the show firewall prefix-action-stats command. A 5-second pause between issuing the
clear firewall and show firewall prefix-action-stats commands avoids a possible timeout
of the show firewall prefix-action-stats command.
Options all—Clear the packet and byte counts for all filters. On EX Series switches, this option
also clears the packet counts for all policer counters.
counter counter-name—Clear the packet and byte counts for a filter counter that has been
configured with the counter firewall filter action.
filter filter-name—Clear the packet and byte counts for the specified firewall filter.
log (all | logical-system-name)—Clear log entries for IPv4 firewall filters that have then
log as an action. Use log all to clear all log entries or log logical-system-name to clear
log entries for the specified logical system.

logical-system logical-system-name—Clear the packet and byte counts for the specified
logical system.
policer counter (all | counter-id counter-index)—(EX8200 switches only) Clear all policer
counters using the policer counter all command, or clear a specific policer counter
using the policer counter counter-id counter-index command. The value of
counter-index can be 0, 1, or 2.
Required Privilege clear

Level
Related • show firewall on page 746

Documentation
List of Sample Output clear firewall all on page 692

clear firewall (counter counter-name) on page 692
clear firewall (filter filter-name) on page 692
clear firewall (policer counter all) (EX8200 Switch) on page 692
clear firewall (policer counter counter-id counter-index) (EX8200 Switch) on page 692
Sample Output
clear firewall all
clear firewall (counter counter-name)

user@host> clear firewall counter port-filter-counter
clear firewall (filter filter-name)

user@host> clear firewall filter ingress-port-filter
clear firewall (policer counter all) (EX8200 Switch)

user@switch> clear firewall policer counter all
clear firewall (policer counter counter-id counter-index) (EX8200 Switch)

user@switch> clear firewall policer counter counter-id 0

clear igmp membership

Syntax (EX Series Switch and the QFX Series) on page 693
Syntax clear igmp membership

<group address-range>
<interface interface-name>
<logical-system (all | logical-system-name)>
Syntax (EX Series clear igmp membership

Switch and the QFX <group address-range>
Series) <interface interface-name>

Command introduced in Junos OS Release 11.3 for the QFX Series.
Description Clear Internet Group Management Protocol (IGMP) group members.
Options none—Clear all IGMP members on all interfaces and for all address ranges.
group address-range—(Optional) Clear all IGMP members that are in a particular address
range. An example of a range is 224.2/16. If you omit the destination prefix length,
the default is /32.
interface interface-name—(Optional) Clear all IGMP group members on an interface.
logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical

systems or on a particular logical system.

Level
Related • show igmp group on page 758

Documentation
• show igmp interface on page 762
List of Sample Output clear igmp membership on page 693

clear igmp membership interface on page 694
clear igmp membership group on page 695
Output Fields See show igmp group for an explanation of output fields.
Sample Output
clear igmp membership
The following sample output displays IGMP group information before and after the clear
igmp membership command is entered:
user@host> show igmp group

Interface Group Last Reported Timeout

so-0/0/0 224.2.127.253 10.1.128.1 186
so-0/0/0 224.2.127.254 10.1.128.1 186
so-0/0/0 239.255.255.255 10.1.128.1 187
so-0/0/0 224.1.127.255 10.1.128.1 188
local 224.0.0.6 (null) 0
local 224.0.0.5 (null) 0
local 224.2.127.254 (null) 0
local 239.255.255.255 (null) 0
local 224.0.0.2 (null) 0
local 224.0.0.13 (null) 0
user@host> clear igmp membership

Clearing Group Membership Info for so-0/0/0

local 224.0.0.6 (null) 0
local 224.0.0.5 (null) 0
local 224.2.127.254 (null) 0
local 239.255.255.255 (null) 0
local 224.0.0.2 (null) 0
local 224.0.0.13 (null) 0
clear igmp membership interface
igmp membership interface command is issued:

so-0/0/0 224.2.127.253 10.1.128.1 210
so-0/0/0 239.255.255.255 10.1.128.1 210
so-0/0/0 224.1.127.255 10.1.128.1 215
so-0/0/0 224.2.127.254 10.1.128.1 216
local 224.0.0.6 (null) 0
local 224.0.0.5 (null) 0
local 224.2.127.254 (null) 0
local 239.255.255.255 (null) 0
local 224.0.0.2 (null) 0
local 224.0.0.13 (null) 0
user@host> clear igmp membership interface so-0/0/0


local 224.0.0.6 (null) 0
local 224.0.0.5 (null) 0
local 224.2.127.254 (null) 0
local 239.255.255.255 (null) 0
local 224.0.0.2 (null) 0
local 224.0.0.13 (null) 0

clear igmp membership group
igmp membership group command is entered:

so-0/0/0 224.2.127.253 10.1.128.1 210
so-0/0/0 239.255.255.255 10.1.128.1 210
so-0/0/0 224.1.127.255 10.1.128.1 215
so-0/0/0 224.2.127.254 10.1.128.1 216
local 224.0.0.6 (null) 0
local 224.0.0.5 (null) 0
local 224.2.127.254 (null) 0
local 239.255.255.255 (null) 0
local 224.0.0.2 (null) 0
local 224.0.0.13 (null) 0
user@host> clear igmp membership group 239.225/16

Clearing Group Membership Range 239.225.0.0/16 on so-0/0/0

so-0/0/0 224.1.127.255 10.1.128.1 231
so-0/0/0 224.2.127.254 10.1.128.1 233
so-0/0/0 224.2.127.253 10.1.128.1 236
local 224.0.0.6 (null) 0
local 224.0.0.5 (null) 0
local 224.2.127.254 (null) 0
local 239.255.255.255 (null) 0
local 224.0.0.2 (null) 0
local 224.0.0.13 (null) 0

clear igmp statistics

Syntax clear igmp statistics

Syntax (EX Series clear igmp statistics

Switches) <interface interface-name>

Description Clear Internet Group Management Protocol (IGMP) statistics.
Options none—Clear IGMP statistics on all interfaces.
interface interface-name—(Optional) Clear IGMP statistics for the specified interface

only.


Level
Related • show igmp statistics on page 766

Documentation
List of Sample Output clear igmp statistics on page 696
Output Fields See show igmp statistics for an explanation of output fields.
Sample Output
clear igmp statistics
The following sample output displays IGMP statistics information before and after the
clear igmp statistics command is entered:
user@host> show igmp statistics

IGMP packet statistics for all interfaces
IGMP Message type Received Sent Rx errors
Membership Query 8883 459 0
V1 Membership Report 0 0 0
DVMRP 19784 35476 0
PIM V1 18310 0 0
Cisco Trace 0 0 0
Group Leave 0 0 0
Mtrace Response 0 0 0

Mtrace Request 0 0 0
Domain Wide Report 0 0 0
Other Unknown types 0
IGMP v3 unsupported type 0
IGMP v3 source required for SSM 0
IGMP v3 mode not applicable for SSM 0
IGMP Global Statistics

Bad Length 0
Bad Checksum 0
Bad Receive If 0
Rx non-local 1227
user@host> clear igmp statistics

DVMRP 0 0 0
PIM V1 0 0 0
Cisco Trace 0 0 0
Group Leave 0 0 0
Bad Length 0
Bad Checksum 0
Bad Receive If 0
Rx non-local 0

clear mld membership
Syntax clear mld membership

<group group-name> | <interface interface-name>
Description Clear Multicast Listener Discovery (MLD) group membership.
Options none—Clear all MLD memberships.
group group-name—(Optional) Clear MLD membership for the specified group.
interface interface-name—(Optional) Clear MLD group membership for the specified

interface.

Required Privilege view

Level
Related • show mld group on page 771

Documentation
List of Sample Output clear mld membership on page 698
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
clear mld membership
user@host> clear mld membership

clear mld statistics
Syntax clear mld statistics

Description Clear Multicast Listener Discovery (MLD) statistics.
Options none—(Same as logical-system all) Clear MLD statistics for all interfaces.
interface interface-name—(Optional) Clear MLD statistics for the specified interface.


Level
Related • show mld statistics on page 779

Documentation
List of Sample Output clear mld statistics on page 699
Sample Output
clear mld statistics
user@host> clear mld statistics

clear services captive-portal-content-delivery statistics
Syntax clear services captive-portal-content-delivery statistics

<interface pic-name>
Description Clear captive portal content delivery statistics.
Options interface—Clear statistics by PIC name.

Level
Related • show services captive-portal-content-delivery on page 782

Documentation
Output Fields When you enter this command, you receive feedback on the status of your request.
clear services captive-portal-content-delivery statistics

user@host> clear services captive-portal-content-delivery statistics interface ms-5/0/0

0 0
Note that the stats are cleared.

request interface rebalance (Aggregated Ethernet for Subscriber Management)
Syntax request interface rebalance interface interface-name
Description Manually rebalance the subscribers on an aggregated Ethernet bundle with targeted
distribution enabled.
Options interface-name—Aggregated Ethernet logical interface number.

Level
List of Sample Output request interface rebalance on page 701
Sample Output
request interface rebalance
user@host >request interface rebalance interface ae0

show class-of-service
Syntax show class-of-service

Description Display the entire class-of-service (CoS) configuration, including system-chosen defaults.
Executing this command is equivalent to executing all show class-of-service commands
in succession.
Options This command has no options.

Level
List of Sample Output show class-of-service on page 702
Output Fields See the output field descriptions for the commands.
Sample Output
show class-of-service
user@host> show class-of-service
Forwarding class Queue
best-effort 0
expedited-forwarding 1
assured-forwarding 2
network-control 3
Code point type: dscp
Alias Bit pattern
af11 001010
af12 001100
af13 001110
...
Code point type: dscp-ipv6
Alias Bit pattern
af11 001010
af12 001100
af13 001110
...
Code point type: exp
Alias Bit pattern
af11 100
af12 101
be 000
...
Code point type: ieee-802.1
Alias Bit pattern
af11 100
af12 101
be 000
...
Classifier: dscp-default, Code point type: dscp, Index: 6
Code point Forwarding class Loss priority
000000 best-effort low


....
Classifier: dscp-ipv6-default, Code point type: dscp-ipv6, Index: 7
...
Loss-priority-map: frame-relay-de-default, Code point type: frame-relay-de, Index:
12
Code point Loss priority
0 low
1 high
Rewrite rule: dscp-default, Code point type: dscp, Index: 23

Forwarding class Loss priority Code point
best-effort low 000000
best-effort high 000000
expedited-forwarding low 101110
...
Rewrite rule: dscp-ipv6-default, Code point type: dscp-ipv6, Index: 24
best-effort low 000000
best-effort high 000000
...
....
Drop profile: <default-drop-profile>, Type: discrete, Index: 1
Fill level Drop probability
100 100
Scheduler: <default-be>, Forwarding class: best-effort, Index: 16

Transmit rate: 95 percent, Rate Limit: none, Buffer size: 95 percent, Priority:
low
Drop profiles:
Low any 1 <default-drop-profile>
Medium low any 1 <default-drop-profile>
Medium high any 1 <default-drop-profile>
High any 1 <default-drop-profile>
...
Physical interface: fe-0/0/0, Index: 137
Logical interface: fe-0/0/0.0, Index: 69

Adaptive-shaper fr-shaper 35320
Physical interface: fe-0/0/1, Index: 138

...

show class-of-service adjustment-control-profile
Syntax show class-of-service adjustment-control-profile

<profile-name>
Release Information Command introduced in Junos OS Release 13.1 for MX Series Routers.
Description For MPC/MIC interfaces only, display the adjustment control profiles.
Options none—Display all profiles.
profile-name—(Optional) Display information about a single profile.

Level
Related • Verifying the CoS Adjustment Control Profile Configuration on page 185
Documentation
List of Sample Output show class-of-service adjustment-control-profile on page 705
Output Fields Table 52 on page 704 describes the output fields for the show class-of-service
adjustment-control-profile command. Output fields are listed in the approximate order
in which they appear.
Table 52: show class-of-service adjustment-control-profile Output Fields

Field Name Field Description
Name Name of the adjusting application. Possible values:
• RADIUS-CoA—RADIUS CoA aapplication.

• ANCP—ANCP application.
• PPPoE IA tags—PPPoE IA tag application.
Priority Priority of the adjusting application. Possible values are1 through 10; 1 being the highest priority.
The lower the priority value, the higher the priority
Algorithm Algorithm the adjusting application uses to make adjustments.
• adjust-never—Never perform rate adjustments.

• adjust-less-or equal—Adjust the shaping rate if it is less than or equal to the configured value.
• adjust-greater-or-equal—Adjust the shaping rate if it is greater than or equal to the configured value.

Sample Output
show class-of-service adjustment-control-profile
user@host> show class-of-service adjustment-control-profile
name: ANCP, priority: 1, algorithm: less

name: RADIUS CoA, priority: 1, algorithm: always
name: PPPoE IA tags, priority: 2, algorithm: less

show class-of-service interface
Syntax show class-of-service interface

<comprehensive | detail> <interface-name>

Forwarding class map information added in Junos OS Release 9.4.
Command introduced in Junos OS Release 12.1 for the PTX Series Packet Transport
Routers.
Command introduced in Junos OS Release 12.2 for the ACX Series Universal Access
routers.
Options detail and comprehensive introduced in Junos OS Release 11.4.
Description Display the logical and physical interface associations for the classifier, rewrite rules, and
scheduler map objects.
Options none—Display CoS associations for all physical and logical interfaces.
comprehensive—(M Series, MX Series, and T Series routers) (Optional) Display

comprehensive quality-of-service (QoS) information about all physical and logical
interfaces.
detail—(M Series, MX Series, and T Series routers) (Optional) Display QoS and CoS
information based on the interface.
If the interface interface-name is a physical interface, the output includes:
• Brief QoS information about the physical interface
• Brief QoS information about the logical interface
• CoS information about the physical interface
• Brief information about filters or policers of the logical interface
• Brief CoS information about the logical interface
If the interface interface-name is a logical interface, the output includes:
• Brief QoS information about the logical interface
• Information about filters or policers for the logical interface
• CoS information about the logical interface
interface-name—(Optional) Display class-of-service (CoS) associations for the specified

interface.

Level
List of Sample Output show class-of-service interface (Physical) on page 718

show class-of-service interface (Logical) on page 718

show class-of-service interface (Gigabit Ethernet) on page 718
show class-of-service interface (ANCP) on page 718
show class-of-service interface (PPPoE Interface) on page 718
show class-of-service interface (T4000 Routers with Type 5 FPCs) on page 719
show class-of-service interface detail on page 719
show class-of-service interface comprehensive on page 720
show class-of-service interface (ACX Series Routers) on page 731
Output Fields Table 53 on page 707 describes the output fields for the show class-of-service interface
command. Output fields are listed in the approximate order in which they appear.
Table 53: show class-of-service interface Output Fields

Physical interface Name of a physical interface.
Index Index of this interface or the internal index of this object.
Dedicated Queues Status of dedicated queues configured on an interface. Supported only on Trio MPC/MIC interfaces
on MX Series routers.
Queues supported Number of queues you can configure on the interface.
Maximum usable Maximum number of queues you can use.

queues
Queues in use Number of queues currently configured.
Total non-default Number of queues created in addition to the default queues. Supported only on Trio MPC/MIC
queues created interfaces on MX Series routers.
Rewrite Input IEEE (QFX Series only) IEEE 802.1p code point (priority) rewrite value. Incoming traffic from the Fibre
Code-point Channel (FC) SAN is classified into the forwarding class specified in the native FC interface (NP_Port)
fixed classifier and uses the priority specified as the IEEE 802.1p rewrite value.
Shaping rate Maximum transmission rate on the physical interface. You can configure the shaping rate on the
physical interface, or on the logical interface, but not on both. Therefore, the Shaping rate field is
displayed for either the physical interface or the logical interface.
Scheduler map Name of the output scheduler map associated with this interface.
Scheduler map (QFX Series only) Name of the fabric forwarding class set scheduler map associated with a QFabric
forwarding class sets system Interconnect device interface.
Input shaping rate For Gigabit Ethernet IQ2 PICs, maximum transmission rate on the input interface.
Input scheduler map For Gigabit Ethernet IQ2 PICs, name of the input scheduler map associated with this interface.
Chassis scheduler map Name of the scheduler map associated with the packet forwarding component queues.
Rewrite Name and type of the rewrite rules associated with this interface.

Table 53: show class-of-service interface Output Fields (continued)

Classifier Name and type of classifiers associated with this interface.
Forwarding-class-map Name of the forwarding map associated with this interface.
Congestion-notification (QFX Series only) Congestion notification state, enabled or disabled.
Logical interface Name of a logical interface.
Object Category of an object: Classifier, Fragmentation-map (for LSQ interfaces only), Scheduler-map, Rewrite,
Translation Table (for IQE PICs only), or traffic-class-map (for T4000 routers with Type 5 FPCs).
Name Name of an object.
Type Type of an object: dscp, dscp-ipv6, exp, ieee-802.1, ip, inet-precedence, or ieee-802.1ad (for traffic class
map on T4000 routers with Type 5 FPCs)..
Link-level type Encapsulation on the physical interface.
MTU MTU size on the physical interface.
Speed Speed at which the interface is running.
Loopback Whether loopback is enabled and the type of loopback.
Source filtering Whether source filtering is enabled or disabled.
Flow control Whether flow control is enabled or disabled.
Auto-negotiation (Gigabit Ethernet interfaces) Whether autonegotiation is enabled or disabled.
Remote-fault (Gigabit Ethernet interfaces) Remote fault status.
• Online—Autonegotiation is manually configured as online.

• Offline—Autonegotiation is manually configured as offline.


Device flags The Device flags field provides information about the physical device and displays one or more of the
following values:
• Down—Device has been administratively disabled.

• Hear-Own-Xmit—Device receives its own transmissions.
• Link-Layer-Down—The link-layer protocol has failed to connect with the remote endpoint.
• Loopback—Device is in physical loopback.
• Loop-Detected—The link layer has received frames that it sent, thereby detecting a physical loopback.
• No-Carrier—On media that support carrier recognition, no carrier is currently detected.
• No-Multicast—Device does not support multicast traffic.
• Present—Device is physically present and recognized.
• Promiscuous—Device is in promiscuous mode and recognizes frames addressed to all physical
addresses on the media.
• Quench—Transmission on the device is quenched because the output buffer is overflowing.
• Recv-All-Multicasts—Device is in multicast promiscuous mode and therefore provides no multicast
filtering.
• Running—Device is active and enabled.
Interface flags The Interface flags field provides information about the physical interface and displays one or more
of the following values:
• Admin-Test—Interface is in test mode and some sanity checking, such as loop detection, is disabled.
• Disabled—Interface is administratively disabled.
• Down—A hardware failure has occurred.
• Hardware-Down—Interface is nonfunctional or incorrectly connected.
• Link-Layer-Down—Interface keepalives have indicated that the link is incomplete.
• No-Multicast—Interface does not support multicast traffic.
• No-receive No-transmit—Passive monitor mode is configured on the interface.
• Point-To-Point—Interface is point-to-point.
• Pop all MPLS labels from packets of depth—MPLS labels are removed as packets arrive on an
interface that has the pop-all-labels statement configured. The depth value can be one of the
following:
• 1—Takes effect for incoming packets with one label only.
• 2—Takes effect for incoming packets with two labels only.
• [ 1 2 ]—Takes effect for incoming packets with either one or two labels.
• Promiscuous—Interface is in promiscuous mode and recognizes frames addressed to all physical

addresses.
• Recv-All-Multicasts—Interface is in multicast promiscuous mode and provides no multicast filtering.
• SNMP-Traps—SNMP trap notifications are enabled.
• Up—Interface is enabled and operational.


Flags The Logical interface flags field provides information about the logical interface and displays one or
more of the following values:
• ACFC Encapsulation—Address control field Compression (ACFC) encapsulation is enabled

(negotiated successfully with a peer).
• Device-down—Device has been administratively disabled.
• Disabled—Interface is administratively disabled.
• Down—A hardware failure has occurred.
• Clear-DF-Bit—GRE tunnel or IPsec tunnel is configured to clear the Don't Fragment (DF) bit.
• Hardware-Down—Interface protocol initialization failed to complete successfully.
• PFC—Protocol field compression is enabled for the PPP session.
• Point-To-Point—Interface is point-to-point.
• SNMP-Traps—SNMP trap notifications are enabled.
• Up—Interface is enabled and operational.
Encapsulation Encapsulation on the logical interface.
Admin Administrative state of the interface (Up or Down)
Link Status of physical link (Up or Down).
Proto Protocol configured on the interface.
Input Filter Names of any firewall filters to be evaluated when packets are received on the interface, including
any filters attached through activation of dynamic service.
Output Filter Names of any firewall filters to be evaluated when packets are transmitted on the interface, including
any filters attached through activation of dynamic service.
Link flags Provides information about the physical link and displays one or more of the following values:
• ACFC—Address control field compression is configured. The Point-to-Point Protocol (PPP) session
negotiates the ACFC option.
• Give-Up—Link protocol does not continue connection attempts after repeated failures.
• Loose-LCP—PPP does not use the Link Control Protocol (LCP) to indicate whether the link protocol
is operational.
• Loose-LMI—Frame Relay does not use the Local Management Interface (LMI) to indicate whether
the link protocol is operational.
• Loose-NCP—PPP does not use the Network Control Protocol (NCP) to indicate whether the device
is operational.
• Keepalives—Link protocol keepalives are enabled.
• No-Keepalives—Link protocol keepalives are disabled.
• PFC—Protocol field compression is configured. The PPP session negotiates the PFC option.
Hold-times Current interface hold-time up and hold-time down, in milliseconds.
CoS queues Number of CoS queues configured.


Last flapped Date, time, and how long ago the interface went from down to up. The format is Last flapped:
year-month-day hour:minute:second:timezone (hour:minute:second ago). For example, Last flapped:
2002-04-26 10:52:40 PDT (04:33:20 ago).
Statistics last cleared Number and rate of bytes and packets received and transmitted on the physical interface.
• Input bytes—Number of bytes received on the interface.

• Output bytes—Number of bytes transmitted on the interface.
• Input packets—Number of packets received on the interface.
• Output packets—Number of packets transmitted on the interface.
IPv6 transit statistics Number of IPv6 transit bytes and packets received and transmitted on the logical interface if IPv6
statistics tracking is enabled.
Input errors Input errors on the interface. The labels are explained in the following list:
• Errors—Sum of the incoming frame aborts and FCS errors.

• Drops—Number of packets dropped by the input queue of the I/O Manager ASIC. If the interface is
saturated, this number increments once for every packet that is dropped by the ASIC's RED
mechanism.
• Framing errors—Number of packets received with an invalid frame checksum (FCS).
• Runts—Number of frames received that are smaller than the runt threshold.
• Giants—Number of frames received that are larger than the giant threshold.
• Bucket Drops—Drops resulting from the traffic load exceeding the interface transmit or receive
leaky bucket configuration.
• Policed discards—Number of frames that the incoming packet match code discarded because they
were not recognized or not of interest. Usually, this field reports protocols that Junos OS does not
handle.
• L3 incompletes—Number of incoming packets discarded because they failed Layer 3 (usually IPv4)
sanity checks of the header. For example, a frame with less than 20 bytes of available IP header is
discarded. Layer 3 incomplete errors can be ignored by configuring the ignore-l3-incompletes
statement.
• L2 channel errors—Number of times the software did not find a valid logical interface for an incoming
frame.
• L2 mismatch timeouts—Number of malformed or short packets that caused the incoming packet
handler to discard the frame as unreadable.
• HS link CRC errors—Number of errors on the high-speed links between the ASICs responsible for
handling the router interfaces.
• HS link FIFO overflows—Number of FIFO overflows on the high-speed links between the ASICs
responsible for handling the router interfaces.


Output errors Output errors on the interface. The labels are explained in the following list:
• Carrier transitions—Number of times the interface has gone from down to up. This number does not
normally increment quickly, increasing only when the cable is unplugged, the far-end system is
powered down and up, or another problem occurs. If the number of carrier transitions increments
quickly (perhaps once every 10 seconds), the cable, the far-end system, or the PIC is malfunctioning.
• Errors—Sum of the outgoing frame aborts and FCS errors.
• Drops—Number of packets dropped by the output queue of the I/O Manager ASIC. If the interface
is saturated, this number increments once for every packet that is dropped by the ASIC's RED
mechanism.
NOTE: Due to accounting space limitations on certain Type 3 FPCs (which are supported in M320
and T640 routers), the Drops field does not always use the correct value for queue 6 or queue 7
for interfaces on 10-port 1-Gigabit Ethernet PICs.
• Aged packets—Number of packets that remained in shared packet SDRAM so long that the system
automatically purged them. The value in this field should never increment. If it does, it is most likely
a software bug or possibly malfunctioning hardware.
• HS link FIFO underflows—Number of FIFO underflows on the high-speed links between the ASICs
responsible for handling the router interfaces.
• MTU errors—Number of packets whose size exceeds the MTU of the interface.
Egress queues Total number of egress queues supported on the specified interface.
Queue counters CoS queue number and its associated user-configured forwarding class name.
• Queued packets—Number of queued packets.

• Transmitted packets—Number of transmitted packets.
• Dropped packets—Number of packets dropped by the ASIC's RED mechanism.
and T640 routers), the Dropped packets field does not always display the correct value for queue 6
or queue 7 for interfaces on 10-port 1-Gigabit Ethernet PICs.
SONET alarms (SONET) SONET media-specific alarms and defects that prevent the interface from passing packets.
When a defect persists for a certain period, it is promoted to an alarm. Based on the router
SONET defects configuration, an alarm can ring the red or yellow alarm bell on the router or light the red or yellow
alarm LED on the craft interface. See these fields for possible alarms and defects: SONET PHY,
SONET section, SONET line, and SONET path.
SONET PHY Counts of specific SONET errors with detailed information.
• Seconds—Number of seconds the defect has been active.

• Count—Number of times that the defect has gone from inactive to active.
• State—State of the error. A state other than OK indicates a problem.
The SONET PHY field has the following subfields:
• PLL Lock—Phase-locked loop

• PHY Light—Loss of optical signal


SONET section Counts of specific SONET errors with detailed information.

The SONET section field has the following subfields:
• BIP-B1—Bit interleaved parity for SONET section overhead

• SEF—Severely errored framing
• LOS—Loss of signal
• LOF—Loss of frame
• ES-S—Errored seconds (section)
• SES-S—Severely errored seconds (section)
• SEFS-S—Severely errored framing seconds (section)
SONET line Active alarms and defects, plus counts of specific SONET errors with detailed information.

The SONET line field has the following subfields:
• BIP-B2—Bit interleaved parity for SONET line overhead

• REI-L—Remote error indication (near-end line)
• RDI-L—Remote defect indication (near-end line)
• AIS-L—Alarm indication signal (near-end line)
• BERR-SF—Bit error rate fault (signal failure)
• BERR-SD—Bit error rate defect (signal degradation)
• ES-L—Errored seconds (near-end line)
• SES-L—Severely errored seconds (near-end line)
• UAS-L—Unavailable seconds (near-end line)
• ES-LFE—Errored seconds (far-end line)
• SES-LFE—Severely errored seconds (far-end line)
• UAS-LFE—Unavailable seconds (far-end line)


SONET path Active alarms and defects, plus counts of specific SONET errors with detailed information.

The SONET path field has the following subfields:
• BIP-B3—Bit interleaved parity for SONET section overhead

• REI-P—Remote error indication
• LOP-P—Loss of pointer (path)
• AIS-P—Path alarm indication signal
• RDI-P—Path remote defect indication
• UNEQ-P—Path unequipped
• PLM-P—Path payload (signal) label mismatch
• ES-P—Errored seconds (near-end STS path)
• SES-P—Severely errored seconds (near-end STS path)
• UAS-P—Unavailable seconds (near-end STS path)
• ES-PFE—Errored seconds (far-end STS path)
• SES-PFE—Severely errored seconds (far-end STS path)
• UAS-PFE—Unavailable seconds (far-end STS path)
Received SONET Values of the received and transmitted SONET overhead:

overhead
• C2—Signal label. Allocated to identify the construction and content of the STS-level SPE and for
Transmitted SONET PDI-P.
overhead • F1—Section user channel byte. This byte is set aside for the purposes of users.
• K1 and K2—These bytes are allocated for APS signaling for the protection of the multiplex section.
• J0—Section trace. This byte is defined for STS-1 number 1 of an STS-N signal. Used to transmit a
1-byte fixed-length string or a 16-byte message so that a receiving terminal in a section can verify
its continued connection to the intended transmitter.
• S1—Synchronization status. The S1 byte is located in the first STS-1 number of an STS-N signal.
• Z3 and Z4—Allocated for future use.
Received path trace SONET/SDH interfaces allow path trace bytes to be sent inband across the SONET/SDH link. Juniper
Networks and other router manufacturers use these bytes to help diagnose misconfigurations and
Transmitted path trace network errors by setting the transmitted path trace message so that it contains the system hostname
and name of the physical interface. The received path trace value is the message received from the
router at the other end of the fiber. The transmitted path trace value is the message that this router
transmits.
HDLC configuration Information about the HDLC configuration.
• Policing bucket—Configured state of the receiving policer.

• Shaping bucket—Configured state of the transmitting shaper.
• Giant threshold—Giant threshold programmed into the hardware.
• Runt threshold—Runt threshold programmed into the hardware.


Packet Forwarding Information about the configuration of the Packet Forwarding Engine:
Engine configuration
• Destination slot—FPC slot number.
• PLP byte—Packet Level Protocol byte.
CoS information Information about the CoS queue for the physical interface.
• CoS transmit queue—Queue number and its associated user-configured forwarding class name.
• Bandwidth %—Percentage of bandwidth allocated to the queue.
• Bandwidth bps—Bandwidth allocated to the queue (in bps).
• Buffer %—Percentage of buffer space allocated to the queue.
• Buffer usec—Amount of buffer space allocated to the queue, in microseconds. This value is nonzero
only if the buffer size is configured in terms of time.
• Priority—Queue priority: low or high.
• Limit—Displayed if rate limiting is configured for the queue. Possible values are none and exact. If
exact is configured, the queue transmits only up to the configured bandwidth, even if excess
bandwidth is available. If none is configured, the queue transmits beyond the configured bandwidth
if bandwidth is available.
Forwarding classes Total number of forwarding classes supported on the specified interface.
Egress queues Total number of egress queues supported on the specified interface.
Queue Queue number.
Forwarding classes Forwarding class name.
Queued Packets Number of packets queued to this queue.
Queued Bytes Number of bytes queued to this queue. The byte counts vary by PIC type.
Transmitted Packets Number of packets transmitted by this queue. When fragmentation occurs on the egress interface,
the first set of packet counters shows the postfragmentation values. The second set of packet counters
(displayed under the Packet Forwarding Engine Chassis Queues field) shows the prefragmentation
values.
Transmitted Bytes Number of bytes transmitted by this queue. The byte counts vary by PIC type.
Tail-dropped packets Number of packets dropped because of tail drop.


RED-dropped packets Number of packets dropped because of random early detection (RED).
• (M Series and T Series routers only) On M320 and M120 routers and the T Series routers, the total
number of dropped packets is displayed. On all other M Series routers, the output classifies dropped
packets into the following categories:
• Low, non-TCP—Number of low-loss priority non-TCP packets dropped because of RED.
• Low, TCP—Number of low-loss priority TCP packets dropped because of RED.
• High, non-TCP—Number of high-loss priority non-TCP packets dropped because of RED.
• High, TCP—Number of high-loss priority TCP packets dropped because of RED.
• (MX Series routers with enhanced DPCs, and T Series routers with enhanced FPCs only) The output
classifies dropped packets into the following categories:
• Low—Number of low-loss priority packets dropped because of RED.
• Medium-low—Number of medium-low loss priority packets dropped because of RED.
• Medium-high—Number of medium-high loss priority packets dropped because of RED.
• High—Number of high-loss priority packets dropped because of RED.
and T640 routers), this field does not always display the correct value for queue 6 or queue 7 for
interfaces on 10-port 1-Gigabit Ethernet PICs.
RED-dropped bytes Number of bytes dropped because of RED. The byte counts vary by PIC type.
• (M Series and T Series routers only) On M320 and M120 routers and the T Series routers, only the
total number of dropped bytes is displayed. On all other M Series routers, the output classifies
dropped bytes into the following categories:
• Low, non-TCP—Number of low-loss priority non-TCP bytes dropped because of RED.
• Low, TCP—Number of low-loss priority TCP bytes dropped because of RED.
• High, non-TCP—Number of high-loss priority non-TCP bytes dropped because of RED.
• High, TCP—Number of high-loss priority TCP bytes dropped because of RED.
and T640 routers), this field does not always display the correct value for queue 6 or queue 7 for
interfaces on 10-port 1-Gigabit Ethernet PICs.
Transmit rate Configured transmit rate of the scheduler. The rate is a percentage of the total interface bandwidth.
Rate Limit Rate limiting configuration of the queue. Possible values are :
• None—No rate limit.

• exact—Queue transmits at the configured rate.
Buffer size Delay buffer size in the queue.
Priority Scheduling priority configured as low or high.
Excess Priority Priority of the excess bandwidth traffic on a scheduler: low, medium-low, medium-high, high, or none.


Drop profiles Display the assignment of drop profiles.
• Loss priority—Packet loss priority for drop profile assignment.

• Protocol—Transport protocol for drop profile assignment.
• Index—Index of the indicated object. Objects that have indexes in this output include schedulers
and drop profiles.
• Name—Name of the drop profile.
• Type—Type of the drop profile: discrete or interpolated.
• Fill Level—Percentage fullness of a queue.
• Drop probability—Drop probability at this fill level.
Excess Priority Priority of the excess bandwidth traffic on a scheduler.
Drop profiles Display the assignment of drop profiles.
• Loss priority—Packet loss priority for drop profile assignment.

• Protocol—Transport protocol for drop profile assignment.
• Index—Index of the indicated object. Objects that have indexes in this output include schedulers
and drop profiles.
• Name—Name of the drop profile.
• Type—Type of the drop profile: discrete or interpolated.
• Fill Level—Percentage fullness of a queue.
• Drop probability—Drop probability at this fill level.
Adjustment information Display the assignment of shaping-rate adjustments on a scheduler node or queue.
• Adjusting application—Application that is performing the shaping-rate adjustment.

• The adjusting application can appear as ancp LS-0, which is the Junos OS Access Node Control
Profile process (ancpd) that performs shaping-rate adjustments on schedule nodes.
• The adjusting application can also appear as pppoe, which adjusts the shaping-rate and
overhead-accounting class-of-service attributes on dynamic subscriber interfaces in a broadband
access network based on access line parameters in Point-to-Point Protocol over Ethernet
(PPPoE) Tags [TR-101]. This feature is supported on MPC/MIC interfaces on MX Series routers.
The shaping rate is based on the actual-data-rate-downstream attribute. The overhead
accounting value is based on the access-loop-encapsulation attribute and specifies whether
the access loop uses Ethernet (frame mode) or ATM (cell mode).
• Adjustment type—Type of adjustment: absolute or delta.

• Configured shaping rate—Shaping rate configured for the scheduler node or queue.
• Adjustment value—Value of adjusted shaping rate.
• Adjustment target—Level of shaping-rate adjustment performed: node or queue.
• Adjustment overhead-accounting mode—Configured shaping mode: frame or cell.
• Adjustment overhead bytes—Number of bytes that the ANCP agent adds to or subtracts from the
actual downstream frame overhead before reporting the adjusted values to CoS.
• Adjustment target—Level of shaping-rate adjustment performed: node or queue.

Sample Output
show class-of-service interface (Physical)
user@host> show class-of-service interface so-0/2/3
Physical interface: so-0/2/3, Index: 135
Maximum usable queues: 8, Queues in use: 4
Total non—default queues created: 4
Logical interface: fe-0/0/1.0, Index: 68, Dedicated Queues: no

Shaping rate: 32000
Scheduler-map <default> 27
Rewrite exp-default exp 21
Classifier exp-default exp 5
Forwarding—class—map exp-default exp 5
show class-of-service interface (Logical)

user@host> show class-of-service interface so-0/2/3.0
Logical interface: so-0/2/3.0, Index: 68, Dedicated Queues: no
Shaping rate: 32000
Scheduler-map <default> 27
Rewrite exp-default exp 21
Forwarding—class—map exp-default exp 5
show class-of-service interface (Gigabit Ethernet)

user@host> show class-of-service interface ge-6/2/0
Input scheduler map: <default>, Index: 3
show class-of-service interface (ANCP)

user@host> show class-of-service interface pp0.1073741842
Logical interface: pp0.1073741842, Index: 341
Traffic-control-profile TCP-CVLAN Output 12408
Classifier dscp-ipv6-compatibility dscp-ipv6 9
Adjusting application: ancp LS-0

Adjustment type: absolute
Configured shaping rate: 4000000
Adjustment value: 11228000
Adjustment overhead-accounting mode: Frame Mode
Adjustment overhead bytes: 50
Adjustment target: node
show class-of-service interface (PPPoE Interface)

user@host> show class-of-service interface pp0.1

Logical interface: pp0.1, Index: 85

Traffic-control-profile tcp-pppoe.o.pp0.1 Output 2726446535
Adjusting application: PPPoE

Adjustment overhead-accounting mode: cell
Adjustment target: node
show class-of-service interface (T4000 Routers with Type 5 FPCs)

user@host> show class-of-service interface xe-4/0/0
Physical interface: xe-4/0/0, Index: 153
Shaping rate: 5000000000 bps
Congestion-notification: Disabled
Logical interface: xe-4/0/0.0, Index: 77

Object Name Type
Index
Classifier ipprec-compatibility ip
13
show class-of-service interface detail

user@host> show class-of-service interface ge-0/3/0 detail

Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online

Scheduler map: interface-schedular-map, Index: 58414
Input shaping rate: 10000 bps
878674 Input scheduler map: schedular-map, Index: 15103
Logical interface ge-0/3/0.0

inet
mpls
Interface Admin Link Proto Input Filter Output Filter
ge-0/3/0.0 up up inet
mpls
Interface Admin Link Proto Input Policer Output Policer
mpls
Logical interface: ge-0/3/0.0, Index: 68

Rewrite exp-default exp (mpls-any) 33

Logical interface ge-0/3/0.1

inet

show class-of-service interface comprehensive

user@host> show class-of-service interface ge-0/3/0 comprehensive
Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow
control: Enabled,
Auto-negotiation: Enabled, Remote fault: Online
Schedulers : 256
Current address: 00:14:f6:f4:b4:5d, Hardware address: 00:14:f6:f4:b4:5d
Last flapped : 2010-09-07 06:35:22 PDT (15:14:42 ago)
Traffic statistics:
IPv6 total statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Ingress traffic statistics at Packet Forwarding Engine:
Drop bytes : 0 0 bps
Drop packets: 0 0 pps
Label-switched interface (LSI) traffic statistics:
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3
incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0,
Resource errors: 0
Output errors:
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
Ingress queues: 4 supported, 5 in use
0 af3 0 0 0

1 af2 0 0 0
2 ef2 0 0 0
3 ef1 0 0 0

0 af3 0 0 0
1 af2 0 0 0
2 ef2 0 0 0
3 ef1 0 0 0
Active alarms : None

Active defects : None
Total octets 0 0
Total packets 0 0
Unicast packets 0 0
FIFO errors 0 0
Oversized frames 0
Jabber frames 0
Fragment frames 0
Code violations 0
Filter statistics:
Input DA rejects 0
Input SA rejects 0
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: Symmetric/Asymmetric, Remote fault:
OK
Local resolution:
Flow control: Symmetric, Remote fault: Link OK
Destination slot: 0
CoS information:
Direction : Output
Limit
% bps % usec
2 ef2 39 19500 0 120 high
none
Direction : Input


Limit
% bps % usec
0 af3 30 3000 45 0 low
none

Interface index: 138, SNMP ifIndex: 601
Forwarding classes: 16 supported, 5 in use
Ingress queues: 4 supported, 5 in use
Queue: 0, Forwarding classes: af3
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : Not Available
RED-dropped packets : 0 0 pps
RED-dropped bytes : 0 0 bps
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Queue: 2, Forwarding classes: ef2
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Forwarding classes: 16 supported, 5 in use
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
RL-dropped packets : 0 0 pps

RL-dropped bytes : 0 0 bps

Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Packet Forwarding Engine Chassis Queues:

Queues: 4 supported, 5 in use
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : Not Available
RED-dropped bytes : Not Available
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps


Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Queued:
Packets : 108546 0 pps
Bytes : 12754752 376 bps
Transmitted:
Packets : 108546 0 pps
Bytes : 12754752 376 bps

Scheduler map: interface-schedular-map, Index: 58414
Scheduler: ef2, Forwarding class: ef2, Index: 39155

Transmit rate: 39 percent, Rate Limit: none, Buffer size: 120 us, Buffer
Limit: none, Priority: high
Excess Priority: unspecified
Drop profiles:
Low any 1 < default-drop-profile>
Medium low any 1 < default-drop-profile>
Medium high any 1 < default-drop-profile>
High any 1 < default-drop-profile>
Drop profile: < default-drop-profile>, Type: discrete, Index: 1
100 100
100 100
100 100
100 100
Input shaping rate: 10000 bps
Input scheduler map: schedular-map
Scheduler map: schedular-map, Index: 15103
Scheduler: af3, Forwarding class: af3, Index: 35058

Transmit rate: 30 percent, Rate Limit: none, Buffer size: 45 percent, Buffer
Limit: none, Priority: low
Excess Priority: unspecified
Drop profiles:

Low any 40582 green

High any 18928 yellow
Drop profile: green, Type: discrete, Index: 40582
50 0
100 100
100 100
100 100
Drop profile: yellow, Type: discrete, Index: 18928
50 0
100 100
Chassis scheduler map: < default-drop-profile>
Scheduler map: < default-drop-profile>, Index: 4
Scheduler: < default-drop-profile>, Forwarding class: af3, Index: 25

Excess Priority: low
Drop profiles:
100 100
100 100
100 100
100 100
Scheduler: < default-drop-profile>, Forwarding class: af2, Index: 25

Drop profiles:
100 100
100 100


100 100
100 100
Scheduler: < default-drop-profile>, Forwarding class: ef2, Index: 25

Drop profiles:
100 100
100 100
100 100
100 100
Scheduler: < default-drop-profile>, Forwarding class: ef1, Index: 25

Drop profiles:
Drop profile: , Type: discrete, Index: 1
100 100
100 100
100 100
100 100
Forwarding class ID Queue Restricted queue Fabric
priority Policing priority
af3 0 0 0 low
normal
af2 1 1 1 low
normal
ef2 2 2 2 high
normal
ef1 3 3 3 high

normal
af1 4 4 0 low
normal
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:
Flags: Sendbcast-pkt-to-re
Input Filters: filter-in-ge-0/3/0.0-i,
Policer: Input: p1-ge-0/3/0.0-inet-i
Protocol mpls, MTU: 1488, Maximum labels: 3, Generation: 173, Route table: 0
Flags: Is-Primary
Output Filters: exp-filter,,,,,
Forwarding class ID Queue Restricted queue Fabric priority Policing priority

SPU priority
best-effort 0 0 0 low normal
low
Aggregate Forwarding-class statistics per forwarding-class

Aggregate Forwarding-class statistics:
Forwarding-class statistics:
Forwarding-class best-effort statistics:

Input unicast bytes: 0
Output unicast bytes: 0
Input unicast packets: 0
Output unicast packets: 0
Input multicast bytes: 0

Output multicast bytes: 0
Input multicast packets: 0
Output multicast packets: 0
Forwarding-class expedited-forwarding statistics:



IPv4 protocol forwarding-class statistics:





IPv6 protocol forwarding-class statistics:





Logical interface ge-0/3/0.0 (Index 68) (SNMP ifIndex 152)

Input packets : 0
Output packets: 0

ge-0/3/0.0 up up inet filter-in-ge-0/3/0.0-i
mpls exp-filter


ge-0/3/0.0 up up
inet p1-ge-0/3/0.0-inet-i
mpls
Filter: filter-in-ge-0/3/0.0-i
Counters:
Name Bytes Packets
count-filter-in-ge-0/3/0.0-i 0 0
Filter: exp-filter
Counters:
Name Bytes Packets
count-exp-seven-match 0 0
count-exp-zero-match 0 0
Policers:
Name Packets
p1-ge-0/3/0.0-inet-i 0

Rewrite exp-default exp (mpls-any) 33
Rewrite rule: exp-default, Code point type: exp, Index: 33

af3 low 000
af3 high 001
af2 low 010
af2 high 011
ef2 low 100
ef2 high 101
ef1 low 110
ef1 high 111
Classifier: exp-default, Code point type: exp, Index: 10

000 af3 low
001 af3 high
010 af2 low
011 af2 high
100 ef2 low
101 ef2 high
110 ef1 low
111 ef1 high
Classifier: ipprec-compatibility, Code point type: inet-precedence, Index: 13

000 af3 low
001 af3 high
010 af3 low
011 af3 high
100 af3 low
101 af3 high

110 ef1 low

111 ef1 high
af3 0 0 0 low
normal
af2 1 1 1 low
normal
ef2 2 2 2 high
normal
ef1 3 3 3 high
normal
af1 4 4 0 low
normal
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:
Flags: Sendbcast-pkt-to-re
Logical interface ge-0/3/0.1 (Index 69) (SNMP ifIndex 154)

Input packets : 0
Output packets: 0

ge-0/3/0.1 up up mpls
ge-0/3/0.1 up up
mpls

Classifier: ipprec-compatibility, Code point type: inet-precedence, Index: 13

000 af3 low
001 af3 high
010 af3 low
011 af3 high
100 af3 low
101 af3 high
110 ef1 low

111 ef1 high

af3 0 0 0 low
normal
af2 1 1 1 low
normal
ef2 2 2 2 high
normal
ef1 3 3 3 high
normal
af1 4 4 0 low
normal
show class-of-service interface (ACX Series Routers)

user@host-g11# show class-of-service interface
Physical interface: at-0/0/0, Index: 130
Logical interface: at-0/0/0.0, Index: 69
Physical interface: at-0/0/1, Index: 133


Rewrite dscp-default dscp 31
Classifier d1 dscp 11331
Classifier ci ieee8021p 583

Rewrite custom-exp exp (mpls-any) 46413



Rewrite ri ieee8021p (outer) 35392
Classifier ci ieee8021p 583


Rewrite custom-exp2 exp (mpls-any) 53581




Classifier d1 dscp 11331





[edit]
user@host-g11#

show class-of-service interface-set
Syntax show class-of-service interface-set

<interface-set-name>
Description Display the configured shaping rate and the adjusted shaping rate for each logical interface
set configured for hierarchical class of service (CoS).
Options none—Display CoS associations for all logical interface sets.
interface-set interface-set-name—(Optional) Display CoS associations for the specified

interface set.

Level
List of Sample Output show class-of-service interface-set on page 735
Output Fields Table 54 on page 734 describes the output fields for the show class-of-service interface-set
Table 54: show class-of-service interface-set Output Fields

Interface-set Name of a logical interface set composed of one or more logical interfaces for which hierarchical
scheduling is enabled.
Index Index number of this interface set or the internal index number of this object.
Physical interface Name of a physical interface.
Queues supported Number of queues you can configure on the interface.
Queues in use Number of queues currently configured.
Output traffic control Name of the output traffic-control profile attached to the logical interface set.
profile

Table 54: show class-of-service interface-set Output Fields (continued)

Adjusting application Name of the application that communicates shaping-rate adjustment information to the Junos OS
class-of-service process (cosd) on the broadband services router (BSR). The BSR uses the information
from this application to perform shaping-rate adjustments on the scheduler node that manages the
interface set. The adjusting application appears as ancp LS-0 which is the Junos OS Access Node
Control Profile process (ancpd) that performs shaping-rate adjustments on schedule nodes. The
nodes are logical interface sets configured to represent subscriber local loops. When the
synchronization speed of the DSL line changes, ancpd communicates the local loop speed to cosd
over the default logical system, LS-0, and then the BSR throttles the shaping rate on the scheduler
node to the loop speed.
The adjusting application can also appear as PPPoE, which adjusts the shaping-rate and
overhead-accounting class-of-service attributes on dynamic subscriber interfaces in a broadband
access network based on access line parameters in Point-to-Point Protocol over Ethernet (PPPoE)
Tags [TR-101]. This feature is supported on MPC/MIC interfaces on MX Series routers. The shaping
rate is based on the actual data rate downstream attribute. The overhead accounting value is based
on the access loop encapsulation attribute and specifies whether the access loop uses Ethernet
(frame mode) or ATM (cell mode).
Adjustment type Type of shaping-rate adjustment performed by the BSR on the scheduler node. The type of adjustment
appears as Adjustment type, meaning that the configured shaping rate is adjusted by an absolute
value as opposed to by a percentage of the configured rate.
Configured shaping rate The maximum transmission rate on the physical interface as configured by the output traffic-control
profile attached to the scheduler node.
Adjustment value Value of the shaping-rate adjustment information sent by the adjusting application to cosd.
Adjustment Configured shaping mode: frame or cell.

overhead-accounting
mode
Sample Output
show class-of-service interface-set
user@host> show class-of-service interface-set example-ifset-ge-4/0/0-7
Interface-set: example-ifset-ge-4/0/0–7, Index: 8
Output traffic control profile: example-tcp-basic-rate, Index: 11395
Adjusting application: ancp LS-0
Configured shaping rate: 50000000
Adjustment overhead-accounting mode: cell

show class-of-service scheduler-hierarchy interface
Syntax show class-of-service scheduler-hierarchy interface interface-name <detail>
Description For MPC/MIC interfaces only, display the scheduler hierarchy.
Options detail—(Optional) Display scheduler hierarchies based on the interface-set.
interface-name—Display information about a specific interface.

Level
Related
Documentation
List of Sample Output show class-of-service scheduler-hierarchy interface on page 736
scheduler-hierarchy interface command. Output fields are listed in the approximate order
in which they appear.
Table 55: show class-of-service scheduler-hierarchy interface Output Fields

interface Type of interface
resource Traffic resource associated with the logical interface
shaping-rate Actual shaping rate in bits per second
guaranteed rate Actual guaranteed rate in bits per second
guaranteed priority Actual queue priority in the guaranteed region (high, low, or none)
excess priority Actual queue priority in the excess region (high, low, or none)
queue weight Actual queue weight for excess CoS weighted round-robin
excess weight Actual interface unit per priority weights for excess weighted round-robin
Sample Output
show class-of-service scheduler-hierarchy interface
user@host> show class-of-service scheduler-hierarchy interface ge-1/0/0
--------------------------------------------------------------------------------
Interface/ shaping guarnteed guaranteed/ queue excess
resource name rate rate excess weight weight

kbits kbits priority high/low

--------------------------------------------------------------------------------
ge-1/0/0 100000
ge-1/0/0 RTP 100000 0 1 1
be 100000 1000 Low Low 1
da 9000 2000 Medium High 1
vi 100000 3000 Medium None 626
vo 100000 4000 High High 373
gt 100000 0 High High 1
ifset 75000 0 1 1
ifset RTP 100000 0 1 1
best-effort 100000 0 Low Low 950
vi 100000 0 Low Low 50
ge-1/0/0.50 100000 23000 1 1
be 100000 1000 Low Low 1
vo 100000 4000 High High 373
gt 100000 High High 1
ge-1/0/0.20 50000 40000 750 750
be 50000 1000 Low Low 1
vo 50000 4000 High High 373
gt 50000 Disabled High High 1
ge-1/0/0.32767 100000 2000 1 1
best-effort 100000 1900 Low Low 950
vi 100000 100 Low Low 50

show class-of-service scheduler-hierarchy interface-set
Syntax show class-of-service scheduler-hierarchy interface-set interface-set-name <detail>
Description For MPC/MIC interface sets only, display the scheduler hierarchy.
Options detail—(Optional) Display scheduler hierarchies based on the interface-set.
interface-set-name—Display information about a specific interface-set.

Level
Related • show interfaces queue

Documentation
List of Sample Output show class-of-service scheduler-hierarchy interface-set on page 738
scheduler-hierarchy interface-set command. Output fields are listed in the approximate
order in which they appear.
Table 56: show class-of-service scheduler-hierarchy interface-set Output Fields

interface Type of interface
resource Traffic resource associated with the logical interface
shaping-rate Actual shaping rate in bits per second
guaranteed rate Actual guaranteed rate in bits per second
guaranteed priority Actual queue priority in the guaranteed region (high, low, or none)
excess priority Actual queue priority in the excess region (high, low, or none)
queue weight Actual queue weight for excess CoS weighted round-robin
excess weight Actual interface-set per priority weights for excess weighted round-robin
Sample Output
show class-of-service scheduler-hierarchy interface-set
user@host> show class-of-service scheduler-hierarchy interface-set ifset
--------------------------------------------------------------------------------
Interface/ shaping guarnteed guaranteed/ queue excess
resource name rate rate excess weight weight

kbits kbits priority high/low

--------------------------------------------------------------------------------
ge-1/0/0 100000
ge-1/0/0 RTP 100000 0 1 1
be 100000 1000 Low Low 1
vo 100000 4000 High High 373
gt 100000 0 High High 1
ge-1/0/0.20 50000 40000 750 750
be 50000 1000 Low Low 1
vo 50000 4000 High High 373
gt 50000 Disabled High High 1

show class-of-service scheduler-map
Syntax show class-of-service scheduler-map

<name>

Description Display the mapping of schedulers to forwarding classes and a summary of scheduler
parameters for each entry.
Options none—Display all scheduler maps.
name—(Optional) Display a summary of scheduler parameters for each forwarding class

to which the named scheduler is assigned.

Level
List of Sample Output show class-of-service scheduler-map on page 741
scheduler-map command. Output fields are listed in the approximate order in which they
appear.
Table 57: show class-of-service scheduler-map Output Fields

Scheduler map Name of the scheduler map.
Index Index of the indicated object. Objects having indexes in this output include scheduler maps, schedulers,
and drop profiles.
Scheduler Name of the scheduler.
Forwarding class Classification of a packet affecting the forwarding, scheduling, and marking policies applied as the
packet transits the router.
Transmit rate Configured transmit rate of the scheduler (in bps). The rate is a percentage of the total interface
bandwidth, or the keyword remainder, which indicates that the scheduler receives the remaining
bandwidth of the interface.
Rate Limit Rate limiting configuration of the queue. Possible values are none, meaning no rate limiting, and exact,
meaning the queue only transmits at the configured rate.
Maximum buffer delay Amount of transmit delay (in milliseconds) or the buffer size of the queue. The buffer size is shown
as a percentage of the total interface buffer allocation, or by the keyword remainder to indicate that
the buffer is sized according to what remains after other scheduler buffer allocations.
Priority Scheduling priority: low or high.

Table 57: show class-of-service scheduler-map Output Fields (continued)

Excess priority Priority of excess bandwidth: low, medium-low, medium-high, high, or none.
Explicit Congestion (QFX Series only) Explicit congestion notification (ECN) state:
Notification
• Disable—ECN is disabled on the specified scheduler
• Enable—ECN is enabled on the specified scheduler
ECN is disabled by default.
Adjust minimum Minimum shaping rate for an adjusted queue, in bps.
Adjust percent Bandwidth adjustment applied to a queue, in percent.
Drop profiles Table displaying the assignment of drop profiles by name and index to a given loss priority and protocol
pair.
Loss priority Packet loss priority for drop profile assignment.
Protocol Transport protocol for drop profile assignment.
Name Name of the drop profile.
Sample Output
show class-of-service scheduler-map
user@host> show class-of-service scheduler-map
Scheduler map: dd-scheduler-map, Index: 84
Scheduler: aa-scheduler, Index: 8721, Forwarding class: aa-forwarding-class

Transmit rate: 30 percent, Rate Limit: none, Maximum buffer delay: 39 ms,
Priority: high
Drop profiles:
Low non-TCP 8724 aa-drop-profile
Low TCP 9874 bb-drop-profile
High non-TCP 8833 cc-drop-profile
High TCP 8484 dd-drop-profile
Scheduler: bb-scheduler, Forwarding class: aa-forwarding-class

Transmit rate: 40 percent, Rate limit: none, Maximum buffer delay: 68 ms,
Priority: high
Drop profiles:
Low non-TCP 8724 aa-drop-profile
Low TCP 9874 bb-drop-profile
High non-TCP 8833 cc-drop-profile
High TCP 8484 dd-drop-profile

show class-of-service traffic-control-profile
Syntax show class-of-service traffic-control-profile

<profile-name>

Command introduced in Junos OS Release 12.2 for ACX Series Routers.
Description For Gigabit Ethernet IQ PICs, Channelized IQ PICs, EQ DPCs, and Trio MPC/MIC interfaces
only, display traffic shaping and scheduling profiles.
(ACX Series routers) For ATM IMA pseudowire interfaces, display traffic shaping and
scheduling profiles.
Options none—Display all profiles.
profile-name—(Optional) Display information about a single profile.

Level
List of Sample Output show class-of-service traffic-control-profile on page 744

show class-of-service traffic-control-profile (MX Series routers with Clear Channel
Multi-Rate CE MIC) on page 744
show class-of-service traffic-control-profile (ACX Series routers with ATM IMA
pseudowire interfaces) on page 744
traffic-control-profile command. Output fields are listed in the approximate order in which
they appear.
Table 58: show class-of-service traffic-control-profile Output Fields

Traffic control profile Name of the traffic control profile.
Index Index number of the traffic control profile.
ATM Service (MX Series routers with ATM Multi-Rate CE MIC) Configured
category of ATM service. Possible values:
• cbr—Constant bit rate.

• rtvbr—Real time variable bit rate.
• nrtvbr—Non real time variable bit rate.
• ubr—Unspecified bit rate.
Maximum Burst Size Configured maximum burst size, in cells.
Peak rate Configured peak rate, in cps.

Table 58: show class-of-service traffic-control-profile Output

Fields (continued)
Sustained rate Configured sustained rate, in cps.
Shaping rate Configured shaping rate, in bps.
NOTE: (MX Series routers with ATM Multi-Rate CE MIC) Configured

peak rate, in cps.
Shaping rate burst Configured burst size for the shaping rate, in bytes.
NOTE: (MX Series routers with ATM Multi-Rate CE MIC) Configured

maximum burst rate, in cells.
Shaping rate priority high Configured shaping rate for high-priority traffic, in bps.
Shaping rate priority Configured shaping rate for medium-priority traffic, in bps.
medium
Shaping rate priority low Configured shaping rate for low-priority traffic, in bps.
Shaping rate excess high Configured shaping rate for high-priority excess traffic, in bps.
Shaping rate excess low Configured shaping rate for low-priority excess traffic, in bps.
Scheduler map Name of the associated scheduler map.
Delay Buffer rate Configured delay buffer rate, in bps.
Excess rate Configured excess rate, in percent or proportion.
Excess rate high Configured excess rate for high priority traffic, in percent or
proportion.
Excess rate low Configured excess rate for low priority traffic, in percent or
proportion.
Guaranteed rate Configured guaranteed rate, in bps or cps.
NOTE: (MX Series routers with ATM Multi-Rate CE MIC) This value
depends on the ATM service category chosen. Possible values:
• cbr—Guaranteed rate is equal to the configured peak rate in cps.

• rtvbr—Guaranteed rate is equal to the configured sustained rate
in cps.
• nrtvbr—Guaranteed rate is equal to the configured sustained rate
in cps.
Guaranteed rate burst Configured burst size for the guaranteed rate, in bytes.
adjust-minimum Configured minimum shaping rate for an adjusted queue, in bps.

Table 58: show class-of-service traffic-control-profile Output

Fields (continued)
overhead accounting mode Configured shaping mode: Frame Mode or Cell Mode.
Overhead bytes Configured byte adjustment value.
Sample Output
show class-of-service traffic-control-profile
Traffic control profile: Profile1, Index: 57625
Scheduler map: m1

Scheduler map: m2

Scheduler map: m3
.Excess rate high: proportion 4

Scheduler map: m4
..adjust-minimum 20000000
show class-of-service traffic-control-profile (MX Series routers with Clear Channel Multi-Rate CE MIC)
Traffic control profile: at-vbr1, Index: 11395
ATM Service: RTVBR
Scheduler map: m3
overhead accounting mode: Frame Mode
Shaping rate: 1000 cps
Shaping rate burst: 500 cells
Delay Buffer rate: 2000 cps
Guaranteed rate: 1000 cps
Traffic control profile: foo, Index: 38286

ATM Service: UBR
Scheduler map: m3
overhead accounting mode: Frame Mode
show class-of-service traffic-control-profile (ACX Series routers with ATM IMA pseudowire interfaces)
Traffic control profile: foo, Index: 38286
ATM Service: RTVBR
Shaping rate: 2000 cps

Shaping rate burst: 200 cells

Scheduler map: <default>
Delay Buffer rate: 1000 cps
Guaranteed rate: 1700 cps

show firewall

Syntax show firewall

<counter counter-name>
<detail>
<filter (filter-name | regex regular-expression)>
<log>
<terse>
Syntax (EX Series show firewall

Switches) <counter counter-name>
<detail>
<filter filter-name>
<log <(detail | interface interface-name)>>
<policer counters <(detail | counter-id counter-index <detail>)>>
<terse>

Option logical-system introduced in Junos OS Release 9.3.
Option terse introduced in Junos OS Release 9.4.
Option policer counters introduced in Junos OS Release 12.2 for EX Series switches.
Option detail introduced in Junos OS Release 12.3 for EX Series switches.
Option detail introduced in Junos OS Release 14.1 for MX Series routers.
Option regex regular-expression introduced in Junos OS Release 14.2.
Description Display enhanced statistics and counters for all configured firewall filters.
Options none—(Optional) Display statistics and counters for all configured firewall filters and
counters. For EX Series switches, this command also displays statistics about all
configured policers.
counter counter-name—(Optional) Name of a filter counter.
detail—(EX Series switches and MX Series routers only) (Optional) Display firewall filter
statistics and enhanced policer statistics and counters.
filter filter-name—(Optional) Name of a configured filter.
filter regex regular-expression—(Optional) Regular expression that matches the names

of a subset of filters.

log—(Optional) Display log entries for firewall filters.

log <(detail | interface interface-name)>—(EX Series switches only) (Optional) Display

detailed log entries of firewall activity or log information about a specific interface.
policer counters <(detail | counter-id counter-index <detail>)>—(EX8200 switches only)

(Optional) Display policer counter statistics in brief or in detail.
terse—(Optional) Display firewall filter names only.

Level
Related • clear firewall on page 691

Documentation
• show firewall log on page 753
• Verifying That Firewall Filters Are Operational
• Verifying That Policers Are Operational
• show policer
List of Sample Output show firewall filter (MX Series Router and EX Series Switch) on page 750
show firewall filter (non MX Series Router and EX Series Switch) on page 750
show firewall filter (Dynamic Input Filter) on page 750
show firewall (Logical Systems) on page 750
show firewall (counter counter-name) on page 751
show firewall log on page 751
show firewall policer counters (EX8200 Switch) on page 751
show firewall policer counters (detail) (EX8200 Switch) on page 751
show firewall policer counters (counter-id counter-index) (EX8200 Switch) on page 752
show firewall policer counters (counter-id counter-index detail) (EX8200
Switch) on page 752
show firewall detail on page 752
Output Fields Table 59 on page 748 lists the output fields for the show firewall command. Output fields
are listed in the approximate order in which they appear.

Table 59: show firewall Output Fields

Filter Name of a filter that has been configured with the filter statement at the [edit firewall] hierarchy
level.
Except on EX Series switches:
• When an interface-specific filter is displayed, the name of the filter is followed by the full
interface name and by either -i for an input filter or -o for an output filter.
• When dynamic filters are displayed, the name of the filter is followed by the full interface name
and by either -in for an input filter or -out for an output filter. When a logical system–specific
filter is displayed, the name of the filter is prefixed with two underscore (__) characters and the
name of the logical system (for example, __ls1/filter1).
• When a service filter is displayed that uses a service set, the separator between the service-set
name and the service-filter name is a semicolon (:).
NOTE: For bridge family filter, 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.
Counters Display filter counter information:
• Name—Name of a filter counter that has been configured with the counter firewall filter action.
• Bytes—Number of bytes that match the filter term under which the counter action is specified.
• Packets—Number of packets that matched the filter term under which the counter action is
specified.
NOTE: On M and T series routers, firewall filters cannot count ip-options packets on a per option
type and per interface basis. A limited work around is to use the show pfe statistics ip options
command to see ip-options statistics on a per Packet Forwarding Engine (PFE) basis. See show
pfe statistics ip for sample output.
Policers Display policer information:
• Name—Name of policer.
• Bytes—(For two-color policers on MX Series routers and EX Series switches, and for hierarchical
policers on MS-DPC, MIC, and MPC interfaces on MX Series routers) Number of bytes that
match the filter term under which the policer action is specified. This is only the number
out-of-specification (out-of-spec) byte counts, not all the bytes in all packets policed by the
policer.
For other combinations of policer type, device, and line card type, this field is blank.
• Packets—Number of packets that matched the filter term under which the policer action is
specified. This is only the number of out-of-specification (out-of-spec) packet counts, not all
packets policed by the policer.
Policer Counter Index (EX8200 switch only) Global management counter ID. The counter ID value (counter-index) can
be 0, 1, or 2.
Green (EX8200 switch only) Number of packets within the limits. The number of packets is smaller than
the committed information rate (CIR).
Yellow (EX8200 switch only) Number of packets partially within the limits. The number of packets is
greater than the CIR, but the burst size is within the excess burst size (EBS) limit.

Table 59: show firewall Output Fields (continued)

Discard (EX8200 switch only) Number of discarded packets.
Bytes (EX8200 switch only) Number of green, yellow, red, or discarded packets in bytes.
Packets (EX8200 switch only) Number of green, yellow, red, or discarded packets.
Filter name (EX8200 switch only) Name of the filter with a term associated to a policer.
Term name (EX8200 switch only) Name of the term associated with a policer.
Policer name (EX8200 switch only) Name of the policer that is associated with a global management counter.
P1-t1 • OOS packet statistics for packets that are marked out-of-specification (out-of-spec) by the
policer. Changes to all packets that have out-of-spec actions, such as discard, color marking,
or forwarding-class, are included in this counter.
• Offered packet statistics for traffic subjected to policing.
• Transmitted packet statistics for traffic that is not discarded by the policer. When the policer
action is discard, the statistics are the same as the in-spec statistics; when the policer action
is non-discard (loss-priority or forwarding-class), the statistics are included in this counter.

Sample Output
show firewall filter (MX Series Router and EX Series Switch)
user@host> show firewall filter test
Filter: test
Counters:
Name Bytes Packets
Counter-1 0 0
Counter-2 0 0
Policers:
Name Bytes Packets
Policer-1 2770 70
show firewall filter (non MX Series Router and EX Series Switch)

user@host> show firewall filter test
Filter: test
Counters:
Name Bytes Packets
Counter-1 0 0
Counter-2 0 0
Policers:
Name Bytes Packets
Policer-1 70
show firewall filter (Dynamic Input Filter)

user@host> show firewall filter dfwd-ge-5/0/0.1-in
Filter: dfwd-ge-5/0/0.1-in
Counters:
Name Bytes Packets
c1-ge-5/0/0.1-in 0 0
show firewall (Logical Systems)

Filter: __lr1/test
Counters:
Name Bytes Packets
icmp 420 5
Filter: __default_bpdu_filter__
Filter: __lr1/inet_filter1
Counters:
Name Bytes Packets
inet_tcp_count 0 0
inet_udp_count 0 0
Counters:
Name Bytes Packets
inet_icmp_count 0 0
inet_pim_count 0 0
Counters:
Name Bytes Packets
inet_tcp_count 0 0
inet_udp_count 0 0

show firewall (counter counter-name)

user@host> show firewall counter icmp-counter
Filter: ingress-port-voip-class-filter
Counters:
Name Bytes Packets
icmp-counter 0 0
show firewall log

user@host> show firewall log
Log :
Time Filter Action Interface Protocol Src Addr

Dest Addr
08:00:53 pfe R ge-1/0/1.0 ICMP 192.168.3.5
192.168.3.4
08:00:52 pfe R ge-1/0/1.0 ICMP 192.168.3.5
192.168.3.4
08:00:51 pfe R ge-1/0/1.0 ICMP 192.168.3.5
192.168.3.4
08:00:50 pfe R ge-1/0/1.0 ICMP 192.168.3.5
192.168.3.4
08:00:49 pfe R ge-1/0/1.0 ICMP 192.168.3.5
192.168.3.4
08:00:48 pfe R ge-1/0/1.0 ICMP 192.168.3.5
192.168.3.4
08:00:47 pfe R ge-1/0/1.0 ICMP 192.168.3.5
192.168.3.4
show firewall policer counters (EX8200 Switch)

user@switch> show firewall policer counters
Policer Counter Index 0:
Bytes Packets
Green: 73 15914
Yellow: 9 1962
Discard: 119 25942

Bytes Packets
Green: 0 0
Yellow: 0 0
Discard: 0 0

Bytes Packets
Green: 0 0
Yellow: 0 0
Discard: 0 0
show firewall policer counters (detail) (EX8200 Switch)

user@switch> show firewall policer counters detail
Bytes Packets
Green: 73 15914
Yellow: 9 1962
Discard: 119 25942

Filter name Term name Policer name

myfilter polcr-term-1 myfilter-polcr-1
inet-filter-ae ae-snmp policer-1
inet-filter-ae ae-ssh policer-2

Bytes Packets
Green: 0 0
Yellow: 0 0
Discard: 0 0

Bytes Packets
Green: 0 0
Yellow: 0 0
Discard: 0 0
show firewall policer counters (counter-id counter-index) (EX8200 Switch)

user@switch> show firewall policer counters counter-id 0
Bytes Packets
Green: 73 15914
Yellow: 9 1962
Discard: 119 25942
show firewall policer counters (counter-id counter-index detail) (EX8200 Switch)

user@switch> show firewall policer counters counter-id 0 detail
Bytes Packets
Green: 73 15914
Yellow: 9 1962
Discard: 119 25942

myfilter polcr-term-1 myfilter-polcr-1
inet-filter-ae ae-snmp policer-1
inet-filter-ae ae-ssh policer-2
show firewall detail

user@host> show firewall detail
Filter: __default_bpdu_filter__
Filter: foo
Counters:
Name Bytes Packets
c1 17652140 160474
Policers:
Name Bytes Packets
P1-t1
OOS 0 18286
Offered 0 18446744073709376546
Transmitted 0 18446744073709358260

show firewall log

Syntax show firewall log

<detail>
<logical-system (logical-system-name | all)>
Syntax (EX Series show firewall log

Switches) <detail>

logical-system option introduced in Junos OS Release 9.3.
Description Display log information about firewall filters.
Options none—Display log information about firewall filters.
detail—(Optional) Display detailed information.
interface interface-name—(Optional) Display log information about a specific interface.
logical-system (logical-system-name | all)—(Optional) Perform this operation on all logical

systems or on a particular system.

Level
List of Sample Output show firewall log on page 754

show firewall log detail on page 754
Output Fields Table 60 on page 753 lists the output fields for the show firewall log command. Output
fields are listed in the approximate order in which they appear.
Table 60: show firewall log Output Fields

Time of Log Time that the event occurred.
Filter • Displays the name of a configured firewall filter or service filter

only if the packet hit the filter’s log action in a kernel filter (in the
control plane). For any traffic that reaches the Routing Engine,
the packets hit the log action in the kernel.
• For all other logged packets (packet hit the filter’s log action in
the Packet Forwarding Engine), this field displays pfe instead of
a configured filter name.

Table 60: show firewall log Output Fields (continued)

Filter Action Filter action:
• A—Accept
• D—Discard
• R—Reject
Name of Interface • Displays a physical interface name if the packet arrived at a port
on a line card.
• Displays local if the packet was generated by the device's internal
Ethernet interface, em1 or fxp1, which connects the Routing Engine
with the router’s packet-forwarding components.
Name of protocol Packet’s protocol name: egp, gre, icmp, ipip, ospf, pim, rsvp, tcp, or
udp.
Packet length Length of the packet.
Source address Packet’s source address.
Destination address Packet’s destination address and port.
Sample Output
show firewall log
user@host>show firewall log
Time Filter Action Interface Protocol Src Addr Dest Addr
13:10:12 pfe D rlsq0.902 ICMP 180.1.177.2 180.1.177.1
13:10:11 pfe D rlsq0.902 ICMP 180.1.177.2 180.1.177.1
show firewall log detail

user@host> show firewall log detail
Time of Log: 2004-10-13 10:37:17 PDT, Filter: f, Filter action: accept, Name of
interface: fxp0.0Name of protocol: TCP, Packet Length: 50824, Source address:
172.17.22.108:829,
Destination address: 192.168.70.66:513
interface: fxp0.0
Name of protocol: TCP, Packet Length: 1020, Source address: 172.17.22.108:829,
interface: fxp0.0
interface: fxp0.0
interface: fxp0.0


interface: fxp0.0
....

show firewall templates-in-use
Syntax show firewall templates-in-use
Description Display the names of configured filter templates that are currently in use by dynamic
subscribers and the number of times each template is referenced.

Level
Related • clear firewall on page 691

Documentation
• show firewall log on page 753
List of Sample Output show firewall templates-in-use on page 757
Output Fields Table 61 on page 756 lists the output fields for the show firewall templates-in-use command.
Output fields are listed in the approximate order in which they appear.
Table 61: show firewall templates-in-use Output Fields

Filter Template Name of a filter that has been configured using the filter statement at either the [edit firewall] or [edit
dynamic-profiles profile-name firewall] hierarchy and is being used as a template for dynamic subscriber
filtering.
Reference Count Number of times the filter has been referenced by subscribers accessing the network.

Sample Output
show firewall templates-in-use
user@host> show firewall templates-in-use
Dynamic Subscribers Reference Counts
Filter Template
Reference Count
---------------
---------------
egressFilter
10
ingressFilter
10
dfilter
5
dfilter-pol
5

show igmp group

Syntax show igmp group

<brief | detail>
<group-name>
Syntax (EX Series show igmp group

Switch and the QFX <brief | detail>
Series) <group-name>

Description Display Internet Group Management Protocol (IGMP) group membership information.
Options none—Display standard information about membership for all IGMP groups.
brief | detail—(Optional) Display the specified level of output.
group-name—(Optional) Display group membership for the specified IP address only.


Level
Related • clear igmp membership on page 693

Documentation
List of Sample Output show igmp group (Include Mode) on page 759
show igmp group (Exclude Mode) on page 760
show igmp group brief on page 760
show igmp group detail on page 760
Output Fields Table 62 on page 758 describes the output fields for the show igmp group command.
Table 62: show igmp group Output Fields

Field Name Field Description Level of Output
Interface Name of the interface that received the IGMP membership report. A name of All levels
local indicates that the local routing device joined the group itself.
Group Group address. All levels
Group Mode Mode the SSM group is operating in: Include or Exclude. All levels

Table 62: show igmp group Output Fields (continued)

Source Source address. All levels
Source timeout Time remaining until the group traffic is no longer forwarded. The timer is detail
refreshed when a listener in include mode sends a report. A group in exclude
mode or configured as a static group displays a zero timer.
Last reported by Address of the host that last reported membership in this group. All levels
Timeout Time remaining until the group membership is removed. brief none
Group timeout Time remaining until a group in exclude mode moves to include mode. The timer detail
is refreshed when a listener in exclude mode sends a report. A group in include
Type Type of group membership: All levels
• Dynamic—Host reported the membership.

• Static—Membership is configured.
Sample Output
show igmp group (Include Mode)
Interface: t1-0/1/0.0
Group: 232.1.1.1
Group mode: Include
Source: 10.0.0.2
Group: 232.1.1.1
Group mode: Include
Source: 10.0.0.3
Group: 232.1.1.1
Group mode: Include
Source: 10.0.0.4
Group: 232.1.1.2
Group mode: Include
Source: 10.0.0.4
Interface: local
Group: 224.0.0.2
Source: 0.0.0.0

Group: 224.0.0.22
Source: 0.0.0.0
show igmp group (Exclude Mode)

Interface: local
Group: 224.0.0.2
Source: 0.0.0.0
Group: 224.0.0.22
Source: 0.0.0.0
show igmp group brief
The output for the show igmp group brief command is identical to that for the show igmp
group command.
show igmp group detail

user@host> show igmp group detail
Group: 232.1.1.1
Group mode: Include
Source: 10.0.0.2
Source timeout: 12
Group timeout: 0 Type: Dynamic
Group: 232.1.1.1
Group mode: Include
Source: 10.0.0.3
Source timeout: 12
Group: 232.1.1.1
Group mode: Include
Source: 10.0.0.4
Source timeout: 12
Group: 232.1.1.2
Group mode: Include
Source: 10.0.0.4
Source timeout: 12
Interface: local
Group: 224.0.0.2
Group mode: Exclude

Source: 0.0.0.0
Source timeout: 0
Group: 224.0.0.22
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0

show igmp interface

Syntax (EX Series Switches and the QFX Series) on page 762
Syntax show igmp interface

<brief | detail>
<interface-name>
Syntax (EX Series show igmp interface

Switches and the QFX <brief | detail>
Series) <interface-name>

Description Display information about Internet Group Management Protocol (IGMP)-enabled

interfaces.
Options none—Display standard information about all IGMP-enabled interfaces.
interface-name—(Optional) Display information about the specified IGMP-enabled

interface only.


Level
Related • clear igmp membership on page 693

Documentation
List of Sample Output show igmp interface on page 764

show igmp interface brief on page 765
show igmp interface detail on page 765
show igmp interface <interface-name> on page 765
Output Fields Table 63 on page 762 describes the output fields for the show igmp interface command.
Table 63: show igmp interface Output Fields

Interface Name of the interface. All levels
Querier Address of the routing device that has been elected to send membership queries. All levels

Table 63: show igmp interface Output Fields (continued)

State State of the interface: Up or Down. All levels
SSM Map Policy Name of the source-specific multicast (SSM) map policy that has been applied to the All levels
IGMP interface.
Timeout How long until the IGMP querier is declared to be unreachable, in seconds. All levels
Version IGMP version being used on the interface: 1 , 2 , or 3. All levels
Groups Number of groups on the interface. All levels
Group limit Maximum number of groups allowed on the interface. Any joins requested after the limit All levels
is reached are rejected.
Group threshold Configured threshold at which a warning message is generated. All levels
This threshold is based on a percentage of groups received on the interface. If the number
of groups received reaches the configured threshold, the device generates a warning
message.
Group log-interval Time (in seconds) between consecutive log messages. All levels
Immediate Leave State of the immediate leave option: All levels
• On—Indicates that the router removes a host from the multicast group as soon as the
router receives a leave group message from a host associated with the interface.
• Off—Indicates that after receiving a leave group message, instead of removing a host
from the multicast group immediately, the router sends a group query to determine if
another receiver responds.
Promiscuous Mode State of the promiscuous mode option: All levels
• On—Indicates that the router can accept IGMP reports from subnetworks that are not
associated with its interfaces.
• Off—Indicates that the router can accept IGMP reports only from subnetworks that
are associated with its interfaces.
Passive State of the passive mode option: All levels
• On—Indicates that the router can run IGMP on the interface but not send or receive
control traffic such as IGMP reports, queries, and leaves.
• Off—Indicates that the router can run IGMP on the interface and send or receive control
traffic such as IGMP reports, queries, and leaves.
The passive statement enables you to selectively activate up to two out of a possible
three available query or control traffic options. When enabled, the following options
appear after the on state declaration:
• send-general-query—The interface sends general queries.

• send-group-query—The interface sends group-specific and group-source-specific
queries.
• allow-receive—The interface receives control traffic.

Table 63: show igmp interface Output Fields (continued)

OIF map Name of the OIF map (if configured) associated with the interface. All levels
SSM map Name of the source-specific multicast (SSM) map (if configured) used on the interface. All levels
Configured Information configured by the user: All levels

Parameters
• IGMP Query Interval—Interval (in seconds) at which this router sends membership
queries when it is the querier.
• IGMP Query Response Interval—Time (in seconds) that the router waits for a report in
response to a general query.
• IGMP Last Member Query Interval—Time (in seconds) that the router waits for a report
in response to a group-specific query.
• IGMP Robustness Count—Number of times the router retries a query.
Derived Parameters Derived information: All levels
• IGMP Membership Timeout—Timeout period (in seconds) for group membership. If no

report is received for these groups before the timeout expires, the group membership
is removed.
• IGMP Other Querier Present Timeout—Time (in seconds) that the router waits for the
IGMP querier to send a query.
Sample Output
show igmp interface
user@host> show igmp interface
Interface: at-0/3/1.0
Querier: 10.111.30.1
State: Up Timeout: None Version: 2 Groups: 4
SSM Map Policy: ssm-policy-A
Interface: so-1/0/0.0
Querier: 10.111.10.1
SSM Map Policy: ssm-policy-B
Querier: 10.111.20.1
SSM Map Policy: ssm-policy-C
Immediate Leave: On
Promiscuous Mode: Off
Configured Parameters:
IGMP Query Interval: 125.0
IGMP Query Response Interval: 10.0
IGMP Last Member Query Interval: 1.0
IGMP Robustness Count: 2
Derived Parameters:
IGMP Membership Timeout: 260.0
IGMP Other Querier Present Timeout: 255.0

show igmp interface brief
The output for the show igmp interface brief command is identical to that for the show
igmp interface command. For sample output, see show igmp interface on page 764.
show igmp interface detail
The output for the show igmp interface detail command is identical to that for the show
igmp interface command. For sample output, see show igmp interface on page 764.
show igmp interface <interface-name>

user@host# show igmp interface ge-3/2/0.0
Querier: 20.1.1.1
Group limit: 8
Group threshold: 60
Group log-interval: 10
Immediate leave: Off
Promiscuous mode: Off

show igmp statistics

Syntax show igmp statistics

<brief | detail>
Syntax (EX Series show igmp statistics

Switch and the QFX <brief | detail>
Series) <interface interface-name>

Description Display Internet Group Management Protocol (IGMP) statistics.
Options none—Display IGMP statistics for all interfaces.
interface interface-name—(Optional) Display IGMP statistics about the specified interface

only.


Level
Related • clear igmp statistics on page 696

Documentation
List of Sample Output show igmp statistics on page 767

show igmp statistics interface on page 768
Output Fields Table 64 on page 766 describes the output fields for the show igmp statistics command.
Table 64: show igmp statistics Output Fields

IGMP packet statistics Heading for IGMP packet statistics for all interfaces or for the specified interface name.

Table 64: show igmp statistics Output Fields (continued)

IGMP Message type Summary of IGMP statistics:
• Membership Query—Number of membership queries sent and received.

• V1 Membership Report—Number of version 1 membership reports sent and received.
• DVMRP—Number of DVMRP messages sent or received.
• PIM V1—Number of PIM version 1 messages sent or received.
• Cisco Trace—Number of Cisco trace messages sent or received.
• V2 Membership Report—Number of version 2 membership reports sent or received.
• Group Leave—Number of group leave messages sent or received.
• Mtrace Response—Number of Mtrace response messages sent or received.
• Mtrace Request—Number of Mtrace request messages sent or received.
• Domain Wide Report—Number of domain-wide reports sent or received.
• V3 Membership Report—Number of version 3 membership reports sent or received.
• Other Unknown types—Number of unknown message types received.
• IGMP v3 unsupported type—Number of messages received with unknown and unsupported IGMP
version 3 message types.
• IGMP v3 source required for SSM—Number of IGMP version 3 messages received that contained no
source.
• IGMP v3 mode not applicable for SSM—Number of IGMP version 3 messages received that did not
contain a mode applicable for source-specific multicast (SSM).
Received Number of messages received.
Sent Number of messages sent.
Rx errors Number of received packets that contained errors.
IGMP Global Statistics Summary of IGMP statistics for all interfaces.
• Bad Length—Number of messages received with length errors so severe that further classification
could not occur.
• Bad Checksum—Number of messages received with a bad IP checksum. No further classification
was performed.
• Bad Receive If—Number of messages received on an interface not enabled for IGMP.
• Rx non-local—Number of messages received from senders that are not local.
• Timed out—Number of groups that timed out as a result of not receiving an explicit leave message.
• Rejected Report—Number of reports dropped because of the IGMP group policy.
• Total Interfaces—Number of interfaces configured to support IGMP.
Sample Output
show igmp statistics

DVMRP 0 0 0
PIM V1 0 0 0
Cisco Trace 0 0 0
Group Leave 0 0 0

Bad Length 0
Bad Checksum 0
Bad Receive If 0
Rx non-local 1227
Timed out 0
Rejected Report 0
Total Interfaces 2
show igmp statistics interface

user@host> show igmp statistics interface fe-1/0/1.0
IGMP interface packet statistics for fe-1/0/1.0

show interfaces targeting (Aggregated Ethernet for Subscriber Management)
Syntax show interfaces targeting aex
Description (MX Series routers only) Display status information about the distribution of subscribers
on different links in an aggregated Ethernet bundle.

Level
Output Fields Table 65 on page 769 lists the output fields for the show interfaces targeting command.
Table 65: show interfaces targeting Output Fields

Aggregated Ethernet Interface

Aggregated Name of the aggregated Ethernet bundle. All levels
interface
Redundancy mode Redundancy mechanism on the interface: Link Level Redundancy or FPC All levels
Redundancy.
Total number of Number of distributed links in the bundle. All levels

distributed
interfaces
Physical Interface
Physical interface Name of the physical interface and state of the interface. All levels
Link status Status of the link on the physical interface: up or down.
Number of primary Number of subscribers distributed on primary links. All levels

distributions
Number of backup Number of subscribers distributed on backup links. All levels

distributions
Sample Output
show interfaces targeting ae0
user@host> show interfaces targeting ae0
Aggregated interface: ae0
Redundancy mode: Link Level Redundancy
Total number of distributed interfaces: 3
Physical interface: ge-1/0/0, Link status: Up
Number of primary distributions: 200
Number of backup distributions: 200



show mld group
Syntax show mld group

<brief | detail>
<group-name>
Description Display information about Multicast Listener Discovery (MLD) group membership.
Options none—Display standard information about all MLD groups.
group-name—(Optional) Display MLD information about the specified group.


Level
Related • clear mld membership on page 698

Documentation
List of Sample Output show mld group (Include Mode) on page 772
show mld group (Exclude Mode) on page 773
show mld group brief on page 773
show mld group detail (Include Mode) on page 773
show mld group detail (Exclude Mode) on page 774
Output Fields Table 66 on page 771 describes the output fields for the show mld group command. Output
Table 66: show mld group Output Fields

Interface Name of the interface that received the MLD membership report; local means All levels
that the local router joined the group itself.
Group Group address. All levels
Source Source address. All levels
Group Mode Mode the SSM group is operating in: Include or Exclude. All levels
Last reported by Address of the host that last reported membership in this group. All levels

Table 66: show mld group Output Fields (continued)

Source timeout Time remaining until the group traffic is no longer forwarded. The timer is detail
refreshed when a listener in include mode sends a report. A group in exclude
Timeout Time remaining until the group membership is removed. brief none
Group timeout Time remaining until a group in exclude mode moves to include mode. The timer detail
is refreshed when a listener in exclude mode sends a report. A group in include
Type Type of group membership: All levels
• Dynamic—Host reported the membership.

• Static—Membership is configured.
Sample Output
show mld group
(Include Mode)
user@host> show mld group
Interface: fe-0/1/2.0
Group: ff02::1:ff05:1a67
Group mode: Include
Source: ::
Last reported by: fe80::2e0:81ff:fe05:1a67
Group: ff02::1:ffa8:c35e
Group mode: Include
Source: ::
Group: ff02::2:43e:d7f6
Group mode: Include
Source: ::
Group: ff05::2
Group mode: Include
Source: ::
Interface: local
Group: ff02::2
Source: ::
Group: ff02::16
Source: ::

show mld group (Exclude Mode)

user@host> show mld group
Group: ff02::6
Source: ::
Last reported by: fe80::21f:12ff:feb6:4b3a
Group: ff02::16
Source: ::
Interface: local
Group: ff02::2
Source: ::
Group: ff02::16
Source: ::
show mld group brief
The output for the show mld group brief command is identical to that for the show mld
group command. For sample output, see show mld group (Include Mode) on page 772
show mld group (Exclude Mode) on page 773.
show mld group detail (Include Mode)

user@host> show mld group detail
Group: ff02::1:ff05:1a67
Group mode: Include
Source: ::
Group: ff02::1:ffa8:c35e
Group mode: Include
Source: ::
Group: ff02::2:43e:d7f6
Group mode: Include
Source: ::
Group: ff05::2
Group mode: Include
Source: ::
Group: ff02::2
Group mode: Include
Source: ::
Last reported by: fe80::280:42ff:fe15:f445
Interface: local

Group: ff02::2
Group mode: Include
Source: ::
Group: ff02::16
Source: ::
show mld group detail (Exclude Mode)

user@host> show mld group detail
Group: ff02::6
Group mode: Exclude
Source: ::
Source timeout: 0
Group: ff02::16
Group mode: Exclude
Source: ::
Source timeout: 0
Interface: local
Group: ff02::2
Group mode: Exclude
Source: ::
Source timeout: 0
Group: ff02::16
Group mode: Exclude
Source: ::
Source timeout: 0

show mld interface
Syntax show mld interface

<brief | detail>
<interface-name>
Description Display information about Multicast Listener Discovery (MLD)-enabled interfaces.
Options none—Display standard information about all MLD-enabled interfaces.
interface-name—(Optional) Display information about the specified interface.


Level
Related • clear mld membership on page 698

Documentation
List of Sample Output show mld interface on page 777

show mld interface brief on page 777
show mld interface detail on page 778
show mld interface <interface-name> on page 778
Output Fields Table 67 on page 775 describes the output fields for the show mld interface command.
Table 67: show mld interface Output Fields

Interface Name of the interface. All levels
Querier Address of the router that has been elected to send membership queries. All levels
State State of the interface: Up or Down. All levels
SSM Map Policy Name of the source-specific multicast (SSM) map policy that has been applied All levels
to the interface.
SSM Map Policy Name of the source-specific multicast (SSM) map policy at the MLD interface. All levels
Timeout How long until the MLD querier is declared to be unreachable, in seconds. All levels
Version MLD version being used on the interface: 1 or 2. All levels

Table 67: show mld interface Output Fields (continued)

Groups Number of groups on the interface. All levels
Passive State of the passive mode option: All levels
• On—Indicates that the router can run IGMP or MLD on the interface but not
send or receive control traffic such as IGMP or MLD reports, queries, and
leaves.
• Off—Indicates that the router can run IGMP or MLD on the interface and send
or receive control traffic such as IGMP or MLD reports, queries, and leaves.
The passive statement enables you to selectively activate up to two out of a

possible three available query or control traffic options. When enabled, the
following options appear after the on state declaration:
• send-general-query—The interface sends general queries.

• send-group-query—The interface sends group-specific and
group-source-specific queries.
• allow-receive—The interface receives control traffic
OIF map Name of the OIF map associated to the interface. All levels
SSM map Name of the source-specific multicast (SSM) map used on the interface, if All levels
configured.
Group limit Maximum number of groups allowed on the interface. Any memberships All levels
requested after the limit is reached are rejected.
Group threshold Configured threshold at which a warning message is generated. All levels
This threshold is based on a percentage of groups received on the interface. If

the number of groups received reaches the configured threshold, the device
generates a warning message.
Group log-interval Time (in seconds) between consecutive log messages. All levels
Immediate Leave State of the immediate leave option: All levels
• On—Indicates that the router removes a host from the multicast group as
soon as the router receives a multicast listener done message from a host
associated with the interface.
• Off—Indicates that after receiving a multicast listener done message, instead
of removing a host from the multicast group immediately, the router sends
a group query to determine if another receiver responds.

Table 67: show mld interface Output Fields (continued)

Configured Information configured by the user. All levels

Parameters
• MLD Query Interval (.1 secs)—Interval at which this router sends membership
queries when it is the querier.
• MLD Query Response Interval (.1 secs)—Time that the router waits for a report
in response to a general query.
• MLD Last Member Query Interval (.1 secs)—Time that the router waits for a
report in response to a group-specific query.
• MLD Robustness Count—Number of times the router retries a query.
Derived Parameters Derived information. All levels
• MLD Membership Timeout (.1 secs)—Timeout period for group membership.

If no report is received for these groups before the timeout expires, the group
membership will be removed.
• MLD Other Querier Present Timeout (.1 secs)—Time that the router waits for
the IGMP querier to send a query.
Sample Output
show mld interface
user@host> show mld interface
Interface: fe-0/0/0
Querier: None
State: Up Timeout: 0 Version: 1 Groups: 0
SSM Map Policy: ssm-policy-A
Interface: at-0/3/1.0
Querier: 8038::c0a8:c345
SSM Map Policy: ssm-policy-B
Querier: ::192.168.195.73
SSM Map Policy: ssm-policy-C
SSM map: ipv6map1
Immediate Leave: On
Configured Parameters:
MLD Query Interval (.1 secs): 1250
MLD Query Response Interval (.1 secs): 100
MLD Last Member Query Interval (.1 secs): 10
MLD Robustness Count: 2
Derived Parameters:
MLD Membership Timeout (.1secs): 2600
MLD Other Querier Present Timeout (.1 secs): 2550
show mld interface brief
The output for the show mld interface brief command is identical to that for the show
mld interface command. For sample output, see show mld interface on page 777.

show mld interface detail
The output for the show mld interface detail command is identical to that for the show
mld interface command. For sample output, see show mld interface on page 777.
show mld interface <interface-name>

user@host# show mld interface ge-3/2/0.0
Querier: 20.1.1.1
Group limit: 8
Group threshold: 60
Group log-interval: 10
Immediate leave: Off
Promiscuous mode: Off

show mld statistics
Syntax show mld statistics

Description Display information about Multicast Listener Discovery (MLD) statistics.
Options none—Display MLD statistics for all interfaces.
interface interface-name—(Optional) Display statistics about the specified interface.


Level
Related • clear mld statistics on page 699

Documentation
List of Sample Output show mld statistics on page 780

show mld statistics interface on page 781
Output Fields Table 68 on page 779 describes the output fields for the show mld statistics command.
Table 68: show mld statistics Output Fields

Received Number of received packets.
Sent Number of transmitted packets.
Rx errors Number of received packets that contained errors.

Table 68: show mld statistics Output Fields (continued)

MLD Message type Summary of MLD statistics.
• Listener Query (v1/v2)—Number of membership queries sent and received.

• Listener Report (v1)—Number of version 1 membership reports sent
and received.
• Listener Done (v1/v2)—Number of Listener Done messages sent
and received.
• Listener Report (v2)—Number of version 2 membership reports sent
and received.
• Other Unknown types—Number of unknown message types received.
• MLD v2 source required for SSM—Number of MLD version 2 messages
received that contained no source.
• MLD v2 mode not applicable for SSM—Number of MLD version 2 messages
received that did not contain a mode applicable for source-specific
multicast (SSM).
MLD Global Statistics Summary of MLD statistics for all interfaces.
• Bad Length—Number of messages received with length errors so severe

that further classification could not occur.
• Bad Checksum—Number of messages received with an invalid IP
checksum. No further classification was performed.
• Bad Receive If—Number of messages received on an interface not enabled
for MLD.
• Rx non-local—Number of messages received from nonlocal senders.
• Timed out—Number of groups that timed out as a result of not receiving
an explicit leave message.
• Rejected Report—Number of reports dropped because of the MLD group
policy.
• Total Interfaces—Number of interfaces configured to support IGMP.
Sample Output
show mld statistics
user@host> show mld statistics
MLD packet statistics for all interfaces
MLD Message type Received Sent Rx errors
Listener Query (v1/v2) 0 2 0
Listener Report (v1) 0 0 0
Listener Done (v1/v2) 0 0 0
MLD v2 source required for SSM 2
MLD v2 mode not applicable for SSM 0
MLD Global Statistics

Bad Length 0
Bad Checksum 0
Bad Receive If 0
Rx non-local 0
Timed out 0

Rejected Report 0
Total Interfaces 2
show mld statistics interface

user@host> show mld statistics interface fe-1/0/1.0
MLD interface packet statistics for fe-1/0/1.0
MLD Message type Received Sent Rx errors
Listener Query (v1/v2) 0 2 0
Listener Done (v1/v2) 0 0 0
MLD v2 source required for SSM 2
MLD v2 mode not applicable for SSM 0
MLD Global Statistics

Bad Length 0
Bad Checksum 0
Bad Receive If 0
Rx non-local 0
Timed out 0
Rejected Report 0
Total Interfaces 2

Syntax show services captive-portal-content-delivery

<pic pic-name>
<profile profile-name>
<rule rule-name> <term term-name>
<ruleset ruleset-name>
<sset sset-name> <brief> <detail> <summary>
<statistics> <interface pic-name>
Description Display the current operational state of all captive portal interfaces.
Options brief—(Optional) Display brief service set database information.
detail—(Optional) Display detailed service set database information.
pic—Display the PIC database.
profile—Display the profile database.
rule—Display the rule database.
ruleset—Display the rule set database.
sset—Display the service set database.
statistics—Display captive portal and content delivery statistics about a PIC.
summary—(Optional) Display a summary of service set database information.
term—(Optional) Display term information for the rule database.

Level
Related • clear services captive-portal-content-delivery statistics on page 700

Documentation
List of Sample Output show services captive-portal-content-delivery on page 782
Sample Output
user@host> show services captive-portal-content-delivery pic ms-5/0/0
Name Index
ms-5/0/0 20
user@host> show services captive-portal-content-delivery profile

http-redirect 1
ipda-rewrite 1

user@host> show services captive-portal-content-delivery http-redirect

http-redirect 1
user@host> show services captive-portal-content-delivery rule

Rule Name Term Name
redirect t2
rewrite t1
user@host> show services captive-portal-content-delivery profile ipda-rewrite

ipda-rewrite 1
user@host> show services captive-portal-content-delivery rule redirect

Rule Name Term Name
redirect t2
user@host> show services captive-portal-content-delivery rule rewrite

Rule Name Term Name
rewrite t1
user@host> show services captive-portal-content-delivery rule rewrite term t1

Rule name: rewrite
Rule match direction: input-output
Term name: t1
Term action: rewrite
Term action option: null
user@host> show services captive-portal-content-delivery rule redirect term t2

Rule name: redirect
Rule match direction: input
Term name: t2
Term action: redirect
Term action option: http://www.google.net
user@host> show services captive-portal-content-delivery sset sset1 detail

Service Set Id Profile Compiled Rules
sset1 1 ipda-rewrite 1


5 3

show services service-sets summary
Syntax show services service-sets summary

Description Display service set summary information.
Options none—Display service set summary information for all adaptive services interfaces.
interface interface-name—(Optional) Display service set summary information for a

particular interface. On M Series and T Series routers, interface-name can be
ms-fpc/pic/port, sp-fpc/pic/port, or rspnumber.

Level
List of Sample Output show services service-sets summary on page 784

show services service-sets summary interface on page 785
Output Fields Table 69 on page 784 lists the output fields for the show services service-sets summary
Table 69: show services service-sets summary Output Fields

Interface Name of an adaptive services interface
Service type Type of adaptive service, such as stateful firewall (SFW), Network
Address Translation (NAT), intrusion detection service (IDS), Layer
2 Tunneling Protocol (L2TP), Compressed Real-Time Transport
Protocol (CRTP), or IP Security (IPsec)
Service sets configured Total number of service sets configured on the PIC that use internal
service set IDs and do not consume external service sets, including
CRTP and L2TP
Bytes used Bytes used by a particular service or all services
Policy bytes used Policy bytes used by a particular service or all services
CPU utilization Percentage of the CPU resources being used
Sample Output
show services service-sets summary
user@host> show services service-sets summary
Service sets CPU
Interface configured Bytes used Policy bytes used utilization

ms-4/0/0 1 14821556 ( 4.53 %) 855124 ( 0.40 %) N/A

ms-4/1/0 1 14691700 ( 4.49 %) 855068 ( 0.40 %) N/A
show services service-sets summary interface

user@host> show services service-sets summary interface sp-1/3/0
Interface: sp-1/3/0
Service sets CPU
Service type configured Bytes used utilization
SFW/NAT/IDS 1 54 ( 0.00 %) N/A
L2TP 1 58 ( 0.00 %) N/A
CRTP 1 58 ( 0.00 %) N/A
System 0 920831 ( 0.44 %) N/A
Idle 0 0 ( 0.00 %) N/A
Total 3 921001 ( 0.44 %) N/A

show subscribers
Syntax show subscribers

<detail | extensive | terse>
<aci-interface-set-name aci-interface-set-name>
<address address>
<agent-circuit-identifier agent-circuit-identifier-substring>
<client-type client-type>
<count>
<id>
<interface interface>
<logical-system logical-system>
<mac-address mac-address>
<physical-interface physical-interface-name>
<profile-name profile-name>
<routing-instance routing-instance>
<stacked-vlan-id stacked-vlan-id>
<subscriber-state subscriber-state>
<user-name user-name>
<vci vci-identifier>
<vpi vpi-identifier>
<vlan-id vlan-id>

client-type, mac-address, subscriber-state, and extensive options introduced in Junos OS
Release 10.2.
count option usage with other options introduced in Junos OS Release 10.2.
Options aci-interface-set-name and agent-circuit-identifier introduced in Junos OS Release
12.2.
The physical-interface and user-name options introduced in Junos OS Release 12.3.
Options vci and vpi introduced in Junos OS Release 12.3R3 and supported in later 12.3Rx
releases.
Options vci and vpi supported in Junos OS Release 13.2 and later releases. (Not supported
in Junos OS Release 13.1.)
Description Display information for active subscribers.
Options detail | extensive | terse—(Optional) Display the specified level of output.
aci-interface-set-name—(Optional) Display all dynamic subscriber sessions that use the

specified agent circuit identifier (ACI) interface set. Use the ACI interface set name
generated by the router, such as aci-1003-ge-1/0/0.4001, and not the actual ACI
value found in the DHCP or PPPoE control packets.
address—(Optional) Display subscribers whose IP address matches the specified address.

You must specify the IPv4 or IPv6 address prefix without a netmask (for example,
192.168.17.1). If you specify the IP address as a prefix with a netmask (for example,
192.168.17.1/32), the router displays a message that the IP address is invalid, and
rejects the command.

agent-circuit-identifier-substring—(Optional) Display all dynamic subscriber sessions

whose ACI value matches the specified substring.
client-type—(Optional) Display subscribers whose client type matches the specified

client type (DHCP, L2TP, PPP, PPPOE, VLAN, or static).
count—(Optional) Display the count of total subscribers and active subscribers for any
specified option. You can use the count option alone or with the address, client-type,
interface, logical-system, mac-address, profile-name, routing-instance, stacked-vlan-id,
subscriber-state, or vlan-id options.
id—(Optional) Display a specific subscriber session whose session id matches the specified
subscriber ID. You can display subscriber IDs by using the show subscribers extensive
or the show subscribers interface extensive commands.
interface—(Optional) Display subscribers whose interface matches the specified interface.
logical-system—(Optional) Display subscribers whose logical system matches the

specified logical system.
mac-address—(Optional) Display subscribers whose MAC address matches the specified

MAC address.
physical-interface-name—(M120, M320, and MX Series routers only) (Optional) Display

subscribers whose physical interface matches the specified physical interface.
profile-name—(Optional) Display subscribers whose dynamic profile matches the specified

profile name.
routing-instance—(Optional) Display subscribers whose routing instance matches the

specified routing instance.
stacked-vlan-id—(Optional) Display subscribers whose stacked VLAN ID matches the

specified stacked VLAN ID.
subscriber-state—(Optional) Display subscribers whose subscriber state matches the

specified subscriber state (ACTIVE, CONFIGURED, INIT, TERMINATED, or
TERMINATING).
user-name—(M120, M320, and MX Series routers only) (Optional) Display subscribers

whose username matches the specified subscriber name.
vci-identifier—(MX Series routers with MPCs and ATM MICs with SFP only) (Optional)
Display active ATM subscribers whose ATM virtual circuit identifier (VCI) matches
the specified VCI identifier. The range of values is 0 through 255.
vpi-identifier—(MX Series routers with MPCs and ATM MICs with SFP only) (Optional)
Display active ATM subscribers whose ATM virtual path identifier (VPI) matches the
specified VPI identifier. The range of values is 0 through 65535.
vlan-id—(Optional) Display subscribers whose VLAN ID matches the specified VLAN ID.

NOTE: Due to display limitations, logical system and routing instance output
values are truncated when necessary.

Level
Related • show subscribers summary on page 804

Documentation
• Verifying and Managing Agent Circuit Identifier-Based Dynamic VLAN Configuration
List of Sample Output show subscribers (IPv4) on page 792

show subscribers (IPv6) on page 792
show subscribers (IPv4 and IPv6 Dual Stack) on page 792
show subscribers (LNS on MX Series Routers) on page 793
show subscribers (L2TP Switched Tunnels) on page 793
show subscribers client-type dhcp detail on page 793
show subscribers count on page 793
show subscribers address detail (IPv6) on page 793
show subscribers detail (IPv4) on page 794
show subscribers detail (IPv6) on page 794
show subscribers detail (IPv6 Static Demux Interface) on page 795
show subscribers detail (L2TP LNS Subscribers on MX Series Routers) on page 795
show subscribers detail (L2TP Switched Tunnels) on page 795
show subscribers detail (Tunneled Subscriber) on page 796
show subscribers detail (IPv4 and IPv6 Dual Stack) on page 796
show subscribers detail (ACI Interface Set Session) on page 797
show subscribers detail (PPPoE Subscriber Session with ACI Interface Set) on page 797
show subscribers extensive on page 797
show subscribers extensive (RPF Check Fail Filter) on page 798
show subscribers extensive (L2TP LNS Subscribers on MX Series Routers) on page 798
show subscribers extensive (IPv4 and IPv6 Dual Stack) on page 798
show subscribers extensive (Effective Shaping-Rate) on page 799
show subscribers aci-interface-set-name detail (Subscriber Sessions Using Specified
ACI Interface Set) on page 800
show subscribers agent-circuit-identifier detail (Subscriber Sessions Using Specified
ACI Substring) on page 800
show subscribers interface extensive on page 801
show subscribers logical-system terse on page 801
show subscribers physical-interface count on page 802
show subscribers routing-instance inst1 count on page 802
show subscribers stacked-vlan-id detail on page 802
show subscribers stacked-vlan-id vlan-id detail (Combined Output) on page 802
show subscribers stacked-vlan-id vlan-id interface detail (Combined Output for a
Specific Interface) on page 802
show subscribers user-name detail on page 802
show subscribers vlan-id on page 803

show subscribers vlan-id detail on page 803

show subscribers vpi vci extensive (PPPoE-over-ATM Subscriber Session) on page 803
Output Fields Table 70 on page 789 lists the output fields for the show subscribers command. Output
Table 70: show subscribers Output Fields

Interface Interface associated with the subscriber. The router or switch displays subscribers whose interface
matches or begins with the specified interface.
The * character indicates a continuation of addresses for the same session.
IP Address/VLAN ID Subscriber IP address or VLAN ID associated with the subscriber in the form tpid.vlan-id
No IP address or VLAN ID is assigned to an L2TP tunnel-switched session. For these subscriber sessions
the value is Tunnel-switched.
User Name Name of subscriber.
LS:RI Logical system and routing instance associated with the subscriber.
Type Subscriber client type (DHCP, L2TP, PPP, PPPoE, STATIC-INTERFACE, VLAN).
IP Address Subscriber IPv4 address.
IP Netmask Subscriber IP netmask.
Primary DNS Address IP address of primary DNS server.
Secondary DNS Address IP address of secondary DNS server.
Primary WINS Address IP address of primary WINS server.
Secondary WINS IP address of secondary WINS server.

Address
IPv6 Address Subscriber IPv6 address, or multiple addresses.
IPv6 Prefix Subscriber IPv6 prefix. If you are using DHCPv6 prefix delegation, this is the delegated prefix.
IPv6 User Prefix IPv6 prefix obtained through ND/RA.
IPv6 Address Pool Subscriber IPv6 address pool. The IPv6 address pool is used to allocate IPv6 prefixes to the DHCPv6
clients.
IPv6 Network Prefix Length of the network portion of the IPv6 address.
Length
IPv6 Prefix Length Length of the subscriber IPv6 prefix.

Table 70: show subscribers Output Fields (continued)

Logical System Logical system associated with the subscriber.
Routing Instance Routing instance associated with the subscriber.
Interface Type Whether the subscriber interface is Static or Dynamic.
Interface Set Internally generated name of the dynamic ACI interface set used by the subscriber session.
Interface Set Type Interface type of the ACI interface set: Dynamic. This is the only ACI interface set type currently
supported.
Interface Set Session ID Identifier of the dynamic ACI interface set entry in the session database.
Underlying Interface Name of the underlying interface for the subscriber session.
Dynamic Profile Name Dynamic profile used for the subscriber.
Dynamic Profile Version Version number of the dynamic profile used for the subscriber.
MAC Address MAC address associated with the subscriber.
State Current state of the subscriber session (Init, Configured, Active, Terminating, Tunneled).
L2TP State Current state of the L2TP session, Tunneled or Tunnel-switched. When the value is Tunnel-switched,
two entries are displayed for the subscriber; the first entry is at the LNS interface on the LTS and the
second entry is at the LAC interface on the LTS.
Tunnel switch Profile Name of the L2TP tunnel switch profile that initiates tunnel switching.
Name
Local IP Address IP address of the local gateway (LAC).
Remote IP Address IP address of the remote peer (LNS).
VLAN Id VLAN ID associated with the subscriber in the form tpid.vlan-id.
Stacked VLAN Id Stacked VLAN ID associated with the subscriber in the form tpid.vlan-id.
RADIUS Accounting ID RADIUS accounting ID associated with the subscriber.
Agent Circuit ID Option 82 agent circuit ID associated with the subscriber. The ID is displayed as an ASCII string unless
the value has nonprintable characters, in which case it is displayed in hexadecimal format.
Agent Remote ID Option 82 agent remote ID associated with the subscriber. The ID is displayed as an ASCII string unless
the value has nonprintable characters, in which case it is displayed in hexadecimal format.
DHCP Relay IP Address IP address used by the DHCP relay agent.


ATM VPI (MX Series routers with MPCs and ATM MICs with SFP only) ATM virtual path identifier (VPI) on the
subscriber’s physical interface.
ATM VCI (MX Series routers with MPCs and ATM MICs with SFP only) ATM virtual circuit identifier (VCI) for
each VPI configured on the subscriber interface.
Login Time Date and time at which the subscriber logged in.
Effective shaping-rate Actual downstream traffic shaping rate for the subscriber, in kilobits per second.
IPv4 rpf-check Fail Filter Name of the filter applied by the dynamic profile to IPv4 packets that fail the RPF check.
Name
IPv6 rpf-check Fail Filter Name of the filter applied by the dynamic profile to IPv6 packets that fail the RPF check.
Name
DHCP Options len = number of hex values in the message. The hex values specify the type, length, value (TLV) for
DHCP options, as defined in RFC 2132.
Session ID ID number for a subscriber service session.
Underlying Session ID For DHCPv6 subscribers on a PPPoE network, displays the session ID of the underlying PPPoE interface.
Service Sessions Number of service sessions (that is, a service activated using RADIUS CoA) associated with the
subscribers.
Service Session Name Service session profile name.
Session Timeout Number of seconds of access provided to the subscriber before the session is automatically terminated.
(seconds)
Idle Timeout (seconds) Number of seconds subscriber can be idle before the session is automatically terminated.
IPv6 Delegated Address Name of the pool used for DHCPv6 prefix delegation.
Pool
IPv6 Delegated Network Length of the prefix configured for the IPv6 delegated address pool.
Prefix Length
IPv6 Interface Address Address assigned by the Framed-Ipv6-Prefix AAA attribute.
IPv6 Framed Interface Interface ID assigned by the Framed-Interface-Id AAA attribute.

Id
ADF IPv4 Input Filter Name assigned to the Ascend-Data-Filter (ADF) interface IPv4 input filter (client or service session).
Name The filter name is followed by the rules (in hexadecimal format) associated with the ADF filter and
the decoded rule in Junos OS filter style.


ADF IPv4 Output Filter Name assigned to the Ascend-Data-Filter (ADF) interface IPv4 output filter (client or service session).
ADF IPv6 Input Filter Name assigned to the Ascend-Data-Filter (ADF) interface IPv6 input filter (client or service session).
ADF IPv6 Output Filter Name assigned to the Ascend-Data-Filter (ADF) interface IPv6 output filter (client or service session).
IPv4 Input Filter Name Name assigned to the IPv4 input filter (client or service session).
IPv4 Output Filter Name Name assigned to the IPv4 output filter (client or service session).
IPv6 Input Filter Name Name assigned to the IPv6 input filter (client or service session).
IPv6 Output Filter Name Name assigned to the IPv6 output filter (client or service session).
IFL Input Filter Name Name assigned to the logical interface input filter (client or service session).
IFL Output Filter Name Name assigned to the logical interface output filter (client or service session).
Sample Output
show subscribers (IPv4)
user@host> show subscribers
Interface IP Address/VLAN ID User Name LS:RI
ge-1/3/0.1073741824 100 default:default
demux0.1073741824 100.0.0.10 WHOLESALER-CLIENT default:default
demux0.1073741825 101.0.0.3 RETAILER1-CLIENT test1:retailer1
show subscribers (IPv6)

ge-1/0/0.0 2001::c0:0:0:0/74 WHOLESALER-CLIENT default:default
* 2002::1/128 subscriber-25 default:default
show subscribers (IPv4 and IPv6 Dual Stack)

Interface IP Address/VLAN ID User Name
LS:RI
demux0.1073741834 0x8100.1002 0x8100.1
default:default
demux0.1073741835 0x8100.1001 0x8100.1
default:default
pp0.1073741836 61.1.1.1 dualstackuser1@ISP1.com

default:ASP-1
* 2041:1:1::/48
* 2061:1:1:1::/64
pp0.1073741837 23.1.1.3 dualstackuser2@ISP1.com
default:ASP-1
* 2001:1:2:5::/64
show subscribers (LNS on MX Series Routers)

si-4/0/0.1 192.168.4.1 xyz@example.com default:default
show subscribers (L2TP Switched Tunnels)

si-2/1/0.1073741842 Tunnel-switched ap@lts.com default:default
si-2/1/0.1073741843 Tunnel-switched ap@lts.com default:default
show subscribers client-type dhcp detail

user@host> show subscribers client-type dhcp detail
Type: DHCP
IP Address: 100.20.9.7
IP Netmask: 255.255.0.0
Dynamic Profile Name: dhcp-demux-prof
MAC Address: 00:10:95:00:00:98
State: Active
Radius Accounting ID: jnpr :2304
Login Time: 2009-08-25 14:43:52 PDT
Type: DHCP
IP Address: 100.20.10.7
IP Netmask: 255.255.0.0
MAC Address: 00:10:94:00:01:f3
State: Active
Login Time: 2009-08-25 14:43:56 PDT
show subscribers count

user@host> show subscribers count
Total Subscribers: 188, Active Subscribers: 188
show subscribers address detail (IPv6)

user@host> show subscribers address 100.16.12.137 detail

Type: PPPoE
User Name: pppoeTerV6User1Svc
IP Address: 100.16.12.137
IP Netmask: 255.0.0.0
IPv6 User Prefix: 1016:0:0:c88::/64
Interface: pp0.1073745151
Underlying Interface: demux0.8201
Dynamic Profile Name: pppoe-client-profile
MAC Address: 00:0d:02:01:00:01
Session Timeout (seconds): 31622400
Idle Timeout (seconds): 86400
State: Active
Radius Accounting ID: jnpr demux0.8201:6544
Session ID: 6544
Agent Circuit ID: ifl3720
Agent Remote ID: ifl3720
Login Time: 2012-05-21 13:37:27 PDT
Service Sessions: 1
show subscribers detail (IPv4)

user@host> show subscribers detail
Type: DHCP
IP Netmask: 255.255.0.0
Primary DNS Address: 192.168.17.1
Secondary DNS Address: 192.168.17.2
Primary WINS Address: 192.168.22.1
Secondary WINS Address: 192.168.22.2
MAC Address: 00:10:95:00:00:98
State: Active
Idle Timeout (seconds): 600
Login Time: 2009-08-25 14:43:52 PDT
DHCP Options: len 52
35 01 01 39 02 02 40 3d 07 01 00 10 94 00 00 08 33 04 00 00
00 3c 0c 15 63 6c 69 65 6e 74 5f 50 6f 72 74 20 2f 2f 36 2f
33 2d 37 2d 30 37 05 01 06 0f 21 2c
Service Sessions: 2
show subscribers detail (IPv6)

Type: DHCP
User Name: pd-user1
IPv6 Prefix: 2002:db2:ffff:1::/64
MAC Address: 00:51:ff:ff:00:03
State: Active

Session ID: 1
Login Time: 2011-08-25 12:12:26 PDT
00 08 00 02 00 00 00 01 00 0a 00 03 00 01 00 51 ff ff 00 03
00 06 00 02 00 19 00 19 00 0c 00 00 00 00 00 00 00 00 00 00
00 00
show subscribers detail (IPv6 Static Demux Interface)

Type: STATIC-INTERFACE
User Name: demux0.1@jnpr.net
IPv6 Prefix: 1:2:3:4:5:6:7:aa/128
Interface: demux0.1
Dynamic Profile Name: junos-default-profile
State: Active
Login Time: 2010-05-18 14:33:56 EDT
show subscribers detail (L2TP LNS Subscribers on MX Series Routers)

Type: L2TP
User Name: user1@jnpr.net
IP Netmask: 255.255.0.0
Interface: si-5/2/0.1073749824
Dynamic Profile Name: dyn-lns-profile2
Dynamic Profile Version: 1
State: Active
Session ID: 8001
Login Time: 2011-04-25 20:27:50 IST
show subscribers detail (L2TP Switched Tunnels)

Type: L2TP
User Name: ap@example.com
Interface: si-2/1/0.1073741842
Dynamic Profile Name: dyn-lts-profile
State: Active
L2TP State: Tunnel-switched
Tunnel switch Profile Name: ce-lts-profile
Local IP Address: 10.50.1.1
Remote IP Address: 192.168.20.3
Session ID: 21
Login Time: 2013-01-18 03:01:11 PST
Type: L2TP
User Name: ap@example.com


Interface: si-2/1/0.1073741843
Dynamic Profile Name: dyn-lts-profile
State: Active
L2TP State: Tunnel-switched
Tunnel switch Profile Name: ce-lts-profile
Local IP Address: 10.30.1.1
Remote IP Address: 172.20.1.10
Session ID: 22
Login Time: 2013-01-18 03:01:14 PST
show subscribers detail (Tunneled Subscriber)

Type: PPPoE
User Name: user1@example.com
Interface: pp0.1
State: Active, Tunneled
show subscribers detail (IPv4 and IPv6 Dual Stack)

Type: VLAN
Dynamic Profile Name: svlanProfile
State: Active
Session ID: 1
VLAN Id: 0x8100.1
Login Time: 2011-11-30 00:18:04 PST
Type: PPPoE
User Name: dualstackuser1@ISP1.com
IPv6 Prefix: 2041:1:1::/48
IPv6 User Prefix: 2061:1:1:1::/64
Routing Instance: ASP-1
Dynamic Profile Name: dualStack-Profile1
MAC Address: 00:00:64:03:01:02
State: Active
Session ID: 2
Login Time: 2011-11-30 00:18:05 PST
Type: DHCP
IPv6 Prefix: 2041:1:1::/48
MAC Address: 00:00:64:03:01:02

State: Active
Session ID: 3
Underlying Session ID: 2
Login Time: 2011-11-30 00:18:35 PST
00 08 00 02 0b b8 00 01 00 0a 00 03 00 01 00 00 64 03 01 02
00 06 00 02 00 19 00 19 00 0c 00 00 00 00 00 00 00 00 00 00
00 00
show subscribers detail (ACI Interface Set Session)

Type: VLAN
Interface: ge-1/0/0
Interface Set: aci-1001-ge-1/0/0.2800
Interface Set Session ID: 0
Underlying Interface: ge-1/0/0.2800
Dynamic Profile Name: aci-vlan-set-profile-2
State: Active
Session ID: 1
Agent Circuit ID: aci-ppp-dhcp-20
Login Time: 2012-05-26 01:54:08 PDT
show subscribers detail (PPPoE Subscriber Session with ACI Interface Set)
Type: PPPoE
User Name: ppphint2
Interface Set: aci-1001-demux0.1073741824
Interface Set Type: Dynamic
Underlying Interface: demux0.1073741824
Dynamic Profile Name: aci-vlan-pppoe-profile
MAC Address: 00:00:64:39:01:02
State: Active
Session ID: 3
Agent Circuit ID: aci-ppp-dhcp-dvlan-50
Login Time: 2012-03-07 13:46:53 PST
show subscribers extensive

Type: DHCP
User Name: pd-user1
IPv6 Prefix: 2002:db2:ffff:1::/64
MAC Address: 00:51:ff:ff:00:03

State: Active
Session ID: 1
Login Time: 2011-08-25 12:12:26 PDT
00 08 00 02 00 00 00 01 00 0a 00 03 00 01 00 51 ff ff 00 03
00 06 00 02 00 19 00 19 00 0c 00 00 00 00 00 00 00 00 00 00
00 00
IPv6 Address Pool: pd_pool
IPv6 Network Prefix Length: 48
show subscribers extensive (RPF Check Fail Filter)

...
Type: VLAN
Interface: ae0.1073741824
Dynamic Profile Name: vlan-prof
State: Active
Session ID: 9
VLAN Id: 100
Login Time: 2011-08-26 08:17:00 PDT
IPv4 rpf-check Fail Filter Name: rpf-allow-dhcp
IPv6 rpf-check Fail Filter Name: rpf-allow-dhcpv6
...
show subscribers extensive (L2TP LNS Subscribers on MX Series Routers)

Type: L2TP
User Name: user1@jnpr.net
IP Netmask: 255.255.0.0
Interface: si-5/2/0.1073749824
Dynamic Profile Name: dyn-lns-profile2
State: Active
Session ID: 8001
Login Time: 2011-04-25 20:27:50 IST
IPv4 Input Filter Name: classify-si-5/2/0.1073749824-in
IPv4 Output Filter Name: classify-si-5/2/0.1073749824-out
show subscribers extensive (IPv4 and IPv6 Dual Stack)

Type: VLAN
Dynamic Profile Name: svlanProfile
State: Active
Session ID: 1
VLAN Id: 0x8100.1

Login Time: 2011-11-30 00:18:04 PST
Type: PPPoE
User Name: dualstackuser1@ISP1.com
IPv6 Prefix: 2041:1:1::/48
IPv6 User Prefix: 2061:1:1:1::/64
Dynamic Profile Name: dualStack-Profile1
MAC Address: 00:00:64:03:01:02
State: Active
Session ID: 2
Login Time: 2011-11-30 00:18:05 PST
IPv6 Delegated Network Prefix Length: 48
IPv6 Interface Address: 2061:1:1:1::1/64
IPv6 Framed Interface Id: 1:1:2:2
IPv4 Input Filter Name: FILTER-IN-pp0.1073741825-in
IPv4 Output Filter Name: FILTER-OUT-pp0.1073741825-out
IPv6 Input Filter Name: FILTER-IN6-pp0.1073741825-in
IPv6 Output Filter Name: FILTER-OUT6-pp0.1073741825-out
Type: DHCP
IPv6 Prefix: 2041:1:1::/48
MAC Address: 00:00:64:03:01:02
State: Active
Session ID: 3
Underlying Session ID: 2
Login Time: 2011-11-30 00:18:35 PST
00 08 00 02 0b b8 00 01 00 0a 00 03 00 01 00 00 64 03 01 02
00 06 00 02 00 19 00 19 00 0c 00 00 00 00 00 00 00 00 00 00
00 00
IPv6 Delegated Network Prefix Length: 48
show subscribers extensive (Effective Shaping-Rate)

Type: VLAN
Interface Set: ifset-1
Underlying Interface: ae1
Dynamic Profile Name: svlan-dhcp-test
State: Active
Session ID: 1
VLAN Id: 0x8100.201
Login Time: 2011-11-30 00:18:04 PST

Effective shaping-rate: 31000000k

...
show subscribers aci-interface-set-name detail (Subscriber Sessions Using Specified ACI Interface Set)
user@host> show subscribers aci-interface-set-name aci-1003-ge-1/0/0.4001 detail
Type: VLAN
Interface: ge-1/0/0.
Dynamic Profile Name: aci-vlan-set-profile
State: Active
Session ID: 13
Agent Circuit ID: aci-ppp-vlan-10
Login Time: 2012-03-12 10:41:56 PDT
Type: PPPoE
User Name: ppphint2
MAC Address: 00:00:65:26:01:02
State: Active
Session ID: 14
Login Time: 2012-03-12 10:41:57 PDT
show subscribers agent-circuit-identifier detail (Subscriber Sessions Using Specified ACI Substring)
user@host> show subscribers agent-circuit-identifier aci-ppp-vlan detail
Type: VLAN
Interface: ge-1/0/0.
Dynamic Profile Name: aci-vlan-set-profile
State: Active
Session ID: 13
Login Time: 2012-03-12 10:41:56 PDT
Type: PPPoE
User Name: ppphint2


MAC Address: 00:00:65:26:01:02
State: Active
Session ID: 14
Login Time: 2012-03-12 10:41:57 PDT
show subscribers interface extensive

user@host> show subscribers interface demux0.1073741826 extensive
Type: VLAN
User Name: test1@test.com
Routing Instance: testnet
Dynamic Profile Name: profile-vdemux-relay-23qos
MAC Address: 00:00:6e:56:01:04
State: Active
Session ID: 12
VLAN Id: 0x8100.2902
Login Time: 2011-10-20 16:21:59 EST
Type: DHCP
User Name: test1@test.com
IP Address: 172.16.200.6
IP Netmask: 255.255.255.0
Routing Instance: testnet
MAC Address: 00:00:6e:56:01:04
State: Active
Session ID: 21
Login Time: 2011-10-20 16:24:33 EST
Service Sessions: 2
Service Session ID: 25

Service Session Name: SUB-QOS
State: Active
Service Session ID: 26

Service Session Name: service-cb-content
State: Active
IPv4 Input Filter Name: content-cb-in-demux0.1073741826-in
IPv4 Output Filter Name: content-cb-out-demux0.1073741826-out
show subscribers logical-system terse

user@host> show subscribers logical-system test1 terse

show subscribers physical-interface count

user@host> show subscribers physical-interface ge-1/0/0 count
Total subscribers: 3998, Active Subscribers: 3998
show subscribers routing-instance inst1 count

user@host> show subscribers routing-instance inst1 count
Total Subscribers: 188, Active Subscribers: 183
show subscribers stacked-vlan-id detail

user@host> show subscribers stacked-vlan-id 101 detail
Type: VLAN
Interface: ge-1/2/0.1073741824
Dynamic Profile Name: svlan-prof
State: Active
VLAN Id: 0x8100.100
Login Time: 2009-03-27 11:57:19 PDT
show subscribers stacked-vlan-id vlan-id detail (Combined Output)

user@host> show subscribers stacked-vlan-id 101 vlan-id 100 detail
Type: VLAN
Interface: ge-1/2/0.1073741824
State: Active
VLAN Id: 0x8100.100
Login Time: 2009-03-27 11:57:19 PDT
show subscribers stacked-vlan-id vlan-id interface detail (Combined Output for a Specific Interface)
user@host> show subscribers stacked-vlan-id 101 vlan-id 100 interface ge-1/2/0.* detail
Type: VLAN
Interface: ge-1/2/0.1073741824
State: Active
VLAN Id: 0x8100.100
Login Time: 2009-03-27 11:57:19 PDT
show subscribers user-name detail

user@host> show subscribers user-name larry1 detail
Type: DHCP
User Name: larry1
IP Netmask: 255.255.0.0
Dynamic Profile Name: foo
MAC Address: 00:10:94:00:00:01
State: Active
Session ID: 1

Login Time: 2011-11-07 08:25:59 PST

35 01 01 39 02 02 40 3d 07 01 00 10 94 00 00 01 33 04 00 00
00 3c 0c 15 63 6c 69 65 6e 74 5f 50 6f 72 74 20 2f 2f 32 2f
37 2d 30 2d 30 37 05 01 06 0f 21 2c
show subscribers vlan-id

user@host> show subscribers vlan-id 100
Interface IP Address User Name
ge-1/0/0.1073741824
ge-1/2/0.1073741825
show subscribers vlan-id detail

user@host> show subscribers vlan-id 100 detail
Type: VLAN
Interface: ge-1/0/0.1073741824
Dynamic Profile Name: vlan-prof-tpid
State: Active
VLAN Id: 100
Login Time: 2009-03-11 06:48:54 PDT
Type: VLAN
Interface: ge-1/2/0.1073741825
Dynamic Profile Name: vlan-prof-tpid
State: Active
VLAN Id: 100
Login Time: 2009-03-11 06:48:54 PDT
show subscribers vpi vci extensive (PPPoE-over-ATM Subscriber Session)

user@host> show subscribers vpi 40 vci 50 extensive
Type: PPPoE
User Name: testuser
IP Netmask: 255.255.0.0
Interface: pp0.0
MAC Address: 00:00:65:23:01:02
State: Active
Session ID: 2
ATM VPI: 40
ATM VCI: 50
Login Time: 2012-12-03 07:49:26 PST
IP Address Pool: pool_1
IPv6 Framed Interface Id: 200:65ff:fe23:102

show subscribers summary
Syntax show subscribers summary

<all>
< detail | extensive | terse>
<count>
<physical-interface physical-interface-name>
<logical-system logical-system pic | port | routing-instance routing-instance | slot>
Description Display summary information for subscribers.
Options all—(Optional) Display full subscriber summary.
detail | extensive | terse—(Optional) Display the specified level of output.
count—(Optional) Display the count of total subscribers and active subscribers for any
specified option.
logical-system—(Optional) Display subscribers whose logical system matches the

specified logical system.
physical-interface-name—(M120, M320, and MX Series routers only) (Optional) Display

a count of subscribers whose physical interface matches the specified physical
interface, by subscriber state, client type and LS:RI.
pic—(M120, M320, and MX Series routers only) (Optional) Display a count of subscribers
by PIC number and the total number of subscribers.
port—(M120, M320, and MX Series routers only) (Optional) Display a count of subscribers
by port number and the total number of subscribers.
routing-instance—(Optional) Display subscribers whose routing instance matches the

specified routing instance.
slot—(M120, M320, and MX Series routers only) (Optional) Display a count of subscribers
by FPC slot number and the total number of subscribers.
NOTE: Due to display limitations, logical system and routing instance output
values are truncated when necessary.

Level
Related • show subscribers on page 786

Documentation
List of Sample Output show subscribers summary on page 806

show subscribers summary all on page 806

show subscribers summary physical-interface on page 806
show subscribers summary physical-interface pic on page 807
show subscribers summary physical-interface port on page 807
show subscribers summary physical-interface slot on page 807
show subscribers summary pic on page 807
show subscribers summary pic (Aggregated Ethernet Interfaces) on page 808
show subscribers summary port on page 808
show subscribers summary slot on page 808
show subscribers summary terse on page 808
Output Fields Table 71 on page 805 lists the output fields for the show subscribers command. Output
Table 71: show subscribers summary Output Fields

Subscribers by State Number of subscribers summarized by state. The summary information includes the following:
• Init—Number of subscriber currently in the initialization state.

• Configured—Number of configured subscribers.
• Active—Number of active subscribers.
• Terminating—Number of subscribers currently terminating.
• Terminated—Number of terminated subscribers.
• Total—Total number of subscribers for all states.
Subscribers by Client Number of subscribers summarized by client type. Client types can include DHCP, L2TP, PPP, PPPOE,
Type STATIC-INTERFACE, and VLAN. Also displays the total number of subscribers for all client types
(Total).
Subscribers by LS:RI Number of subscribers summarized by logical system:routing instance (LS:RI) combination. Also
displays the total number of subscribers for all LS:RI combinations (Total).
Interface Interface associated with the subscriber. The router or switch displays subscribers whose interface
matches or begins with the specified interface.
The * character indicates a continuation of addresses for the same session.
For aggregated Ethernet interfaces, the output of the summary (pic | port | slot) options prefixes the
interface name with ae0:.
Count Count of subscribers displayed for each PIC, port, or slot when those options are specified with the
summary option. For an aggregated Ethernet configuration, the total subscriber count does not equal
the sum of the individual PIC, port, or slot counts, because each subscriber can be in more than one
aggregated Ethernet link.
Total Subscribers Total number of subscribers for all physical interfaces, all PICS, all ports, or all LS:RI slots.
IP Address/VLAN ID Subscriber IP address or VLAN ID associated with the subscriber in the form tpid.vlan-id
User Name Name of subscriber.
LS:RI Logical system and routing instance associated with the subscriber.

Sample Output
show subscribers summary
user@host> show subscribers summary
Subscribers by State
Init 3
Configured 2
Active 183
Terminating 2
Terminated 1
TOTAL 191
Subscribers by Client Type

DHCP 107
PPP 76
VLAN 8
TOTAL 191
show subscribers summary all

user@host> show subscribers summary all
Init 3
Configured 2
Active 183
Terminating 2
Terminated 1
TOTAL 191

DHCP 107
PPP 76
VLAN 8
TOTAL 191
Subscribers by LS:RI
default:default 1
default:ri1 28
default:ri2 16
ls1:default 22
ls1:riA 38
ls1:riB 44
logsysX:routinstY 42
TOTAL 191
show subscribers summary physical-interface

user@host> show subscribers summary physical-interface ge-1/0/0
Active: 3998
Total: 3998

DHCP: 3998

Total: 3998
default:default: 3998
Total: 3998
show subscribers summary physical-interface pic

user@host> show subscribers summary physical-interface ge-0/2/0 pic
Active: 4825
Total: 4825

DHCP: 4825
Total: 4825
Total: 4825
show subscribers summary physical-interface port

user@host> show subscribers summary physical-interface ge-0/3/0 port
Active: 4825
Total: 4825

DHCP: 4825
Total: 4825
Total: 4825
show subscribers summary physical-interface slot

user@host> show subscribers summary physical-interface ge-2/0/0 slot
Active: 4825
Total: 4825

DHCP: 4825
Total: 4825
Total: 4825
show subscribers summary pic

user@host> show subscribers summary pic
Interface Count
ge-1/0 1000
ge-1/3 1000
Total Subscribers: 2000

show subscribers summary pic (Aggregated Ethernet Interfaces)

user@host> show subscribers summary pic
Interface Count
ae0: ge-1/0 801
ae0: ge-1/3 801
show subscribers summary port

user@host> show subscribers summary port
Interface Count
ge-1 2000
show subscribers summary slot

user@host> show subscribers summary slot
Interface Count
ge-1 2000
show subscribers summary terse

user@host> show subscribers summary terse
ge-1/3/0.1073741824 100 default:default
demux0.1073741824 100.0.0.10 WHOLESALER-CLIENT default:default

PART 8
Index
• Index on page 811


$junos-cos-scheduler-shaping-rate predefined
variable................................................................................652
$junos-cos-scheduler-tx predefined
variable........................................................................159, 675
$junos-cos-shaping-mode predefined
Index variable.........................................................................561, 611
$junos-cos-shaping-rate predefined variable..........652
( ), in syntax descriptions...................................................xxx
Symbols < >, in syntax descriptions.................................................xxx
#, comments in configuration statements..................xxx [ ], in configuration statements.......................................xxx
$junos-cos-byte-adjust predefined { }, in configuration statements.......................................xxx
variable.....................................................503, 505, 561, 611 | (pipe), in syntax descriptions.........................................xxx
$junos-cos-byte-adjust-cell predefined
variable........................................................................505, 611 A
accounting statement
$junos-cos-byte-adjust-frame predefined
dynamic IGMP
variable.........................................................................561, 611
interface................................................................480
$junos-cos-delay-buffer-rate predefined
dynamic MLD interface............................................480
variable.................................................................................516
ACI (agent circuit identifier) interface sets
$junos-cos-excess-priority predefined
adjusting CoS shaping rate and overhead
variable................................................................................540
accounting..................................................................133
$junos-cos-excess-rate predefined variable.............542
applying CoS traffic shaping
$junos-cos-excess-rate-high predefined
attributes....................................................166, 168, 171
variable................................................................................543
bandwidth management overview.......................129
$junos-cos-excess-rate-low predefined
bandwidth management restrictions...................132
variable................................................................................544
CoS traffic shaping predefined variables............174
$junos-cos-guaranteed-rate predefined
defining...........................................................................586
variable................................................................................570
action statement..................................................................481
$junos-cos-overhead-accounting predefined
adf statement
variable..................................................................................611
dynamic firewalls........................................................482
$junos-cos-scheduler predefined
adjust-minimum statement............................................484
variable.......................................................................159, 647
adjust-percent......................................................................485
$junos-cos-scheduler-bs predefined
adjustment-control-profiles
variable.......................................................................159, 499
configuring......................................................................185
$junos-cos-scheduler-dropfile-any predefined
effective shaping rate.................................................183
variable........................................................................159, 521
overview...........................................................................183
$junos-cos-scheduler-dropfile-high predefined
viewing...................................................................185, 704
variable........................................................................159, 521
adjustment-control-profiles statement
$junos-cos-scheduler-dropfile-low predefined
CoS...................................................................................483
variable........................................................................159, 521
aggregate statement
$junos-cos-scheduler-dropfile-medium-high
hierarchical policer.....................................................486
predefined variable.................................................159, 521
aggregated Ethernet
$junos-cos-scheduler-dropfile-medium-low
targeted distribution of
predefined variable.................................................159, 521
subscribers..................................597, 639, 663, 664
$junos-cos-scheduler-excess-rate predefined
Aggregated Ethernet interfaces
variable.................................................................................541
targeted distribution status, displaying..............769
$junos-cos-scheduler-map predefined
variable................................................................................645
$junos-cos-scheduler-pri predefined
variable........................................................................159, 627

aggregated Ethernet interfaces without link buffer-size statement

protection dynamic CoS................................................................499
manually rebalancing subscribers ................147, 701 burst-size
periodically rebalancing subscribers ....................147 configuring for MIC and MPC interfaces..............136
rebalancing subscribers....................................147, 701 burst-size-limit statement................................................501
targeting subscribers...................................................147 hierarchical policer.....................................................500
anchor logical tunnel............................................................69 bytes
ANCP CoS statements................................................503, 505
shaping-rate adjustments for subscriber local dynamic CoS statements..............................503, 505
loops..............................................................................99 bytes statement
ancp statement CoS statements............................................................561
CoS...............................................................483, 487, 488
application statement.......................................................488 C
CoS.........................................................................483, 488 captive portal content delivery
apply-groups statement dynamic subscriber interfaces................................351
subscriber secure policy...........................................489 captive portal content delivery services......................782
apply-groups-except statement captive portal content delivery statements
subscriber secure policy...........................................489 application....................................................................488
Ascend-Data-Filter captive-portal-content-delivery...........................504
example of dynamic configuration.......................274 destination-address....................................................517
example of static configuration..............................277 destination-prefix-list................................................518
field descriptions.........................................................269 from..................................................................................562
multiple filters..............................................................268 match-direction...........................................................602
naming convention.....................................................268 rule....................................................................................643
verifying configuration................................................281 rule-set............................................................................644
Ascend-Data-Filters...................................................267, 272 services.............................................................................651
authentication statement term..................................................................................665
login.................................................................................490 then..................................................................................668
authentication-order statement traceoptions...................................................................672
access...............................................................................491 captive-portal-content-delivery statement.............504
authentication-server statement..................................492 cell-mode
CoS statements...........................................................505
B dynamic CoS statements........................................505
bandwidth management chassis statements
agent circuit identifier-based dynamic enhanced-policer........................................................538
VLANs..................................................................129, 132 class of service....................................................................3, 25
configuring..............................................................133 See also CoS
bandwidth statement........................................................493 class statement
bandwidth-limit statement assigning to user.........................................................506
policer..............................................................................495 login..................................................................................507
bandwidth-percent statement class-of-service statement
policer..............................................................................497 subscriber access.......................................................508
braces, in configuration statements..............................xxx classic filters
brackets components...................................................................232
angle, in syntax descriptions....................................xxx processing order...........................................................232
square, in configuration statements.....................xxx types..................................................................................231
broadband access networks classic firewall filters
IGMP model...................................................................337 configuration guidelines..................................233, 259

Index
classifiers statement shaping-rate adjustments for subscriber local

dynamic CoS................................................................508 loops
clear firewall command.....................................................691 configuration guidelines...................................100
clear igmp membership command..............................693 disabling.................................................................109
clear igmp statistics command.....................................696 enabling..................................................................104
clear mld membership command................................698 example...................................................................110
clear mld statistics command........................................699 overview...................................................................99
clear services captive-portal-content-delivery subscriber access
statistics command........................................................700 changing services................................................163
client sessions.......................................................................258 classifiers...............................................................220
color-aware statement.....................................................509 configuration guidelines........................................4
color-blind statement.........................................................510 configuration overview........................................32
comments, in configuration statements......................xxx configuring variables..........................................170
committed-burst-size statement....................................511 dynamic configuration overview.....................33
committed-information-rate statement......................513 hierarchical CoS hardware
configuration requirements.......................................................31
displaying interfaces.................................................................217
CoS...........................................................................702 overview......................................................................3
connection-limit statement..............................................515 rewrite rules...........................................................219
conventions traffic parameters.............................................11, 12
text and syntax.............................................................xxix traffic-control profile information,
CoS displaying....................................................................742
adjustment-control profile information, CoS statements
displaying...................................................................704 adjustment-control-profiles...................................483
configuration, displaying...........................................702 ancp.............................................................483, 487, 488
hierarchical scheduling..............................................573 application..........................................................483, 488
MX Series routers..................................................25 bytes......................................................................503, 505
three-level................................................................25 bytes statement...........................................................561
two-level...................................................................25 cell-mode.......................................................................505
implicit-hierarchy...........................................................25 effective-shaping-rate..............................................534
interface sets, displaying..........................................734 frame-mode statement............................................561
interfaces, displaying.................................................706 pppoe-tags...............................................483, 488, 624
mapping, displaying radius-coa.................................................483, 488, 635
schedulers to forwarding classes.................740 CPCD
maximum-hierarchy-levels........................................25 clear captive portal content delivery
RADIUS-provided parameters statistics.....................................................................700
configuring an access dynamic curly braces, in configuration statements....................xxx
profile..................................................................169 customer support.................................................................xxxi
example...................................................................179 contacting JTAC...........................................................xxxi
overview..................................................................159
reporting effective shaping rate..............................127 D
scheduler map information, displaying..............740 delay-buffer-rate statement
scheduler-hierarchy information, dynamic CoS..................................................................516
displaying..........................................................736, 738 destination-address statement.......................................517
shaping-rate adjustments for agent circuit subscriber secure policy.............................................517
identifier-based dynamic VLANs..............129, 132 destination-port statement
configuring..............................................................133 subscriber secure policy..................................518, 524
destination-prefix-list statement...................................518

DHCP snooping inet-precedence

example of DHCP relay agent dynamic classifiers............................................582
configuration............................................................399 dynamic rewrite rules........................................582
disable statement interface..........................................................................586
dynamic IGMP...............................................................519 interface-set.................................................................589
dynamic MLD.................................................................519 interfaces.........................................................................591
documentation loss-priority...................................................................600
comments on................................................................xxxi output-traffic-control-profile.................................610
drop-policy statement overhead-accounting..................................................611
subscriber secure policy...........................................520 priority..............................................................................627
drop-profile statement protocol...........................................................................632
dynamic CoS..................................................................521 rewrite-rules.................................................................640
RED....................................................................................521 scheduler........................................................................644
drop-profile-map statement scheduler-map............................................................645
dynamic CoS.................................................................522 scheduler-maps..........................................................646
dscp statement schedulers......................................................................647
dynamic classifiers......................................................523 shaping-rate..................................................................652
dynamic rewrite rules.................................................524 traffic-control-profiles...............................................674
dscp-ipv6 statement transmit-rate.................................................................675
dynamic classifiers......................................................525 unit....................................................................................682
dynamic rewrite rules.................................................525 vendor-specific-tags
DTCP See subscriber secure policy access-loop-encapsulation...............................684
dynamic CoS statements vlan-tag
buffer-size......................................................................499 dynamic classifiers............................................686
bytes......................................................................503, 505 dynamic rewrite rules........................................687
cell-mode.......................................................................505 dynamic firewall filters
class-of-service...........................................................508 applying fast update filters.....................................300
classifiers.......................................................................508 attaching statically created
delay-buffer-rate..........................................................516 any interface type...............................................246
drop-profile.....................................................................521 specific family type............................................245
drop-profile-map.........................................................522 basic syntax...................................................................234
dscp classic filters...................................................................231
dynamic classifiers.............................................523 components...............................................232, 256, 285
dynamic rewrite rules........................................524 configuration guidelines........................233, 259, 286
dscp-ipv6 configuring fast update filters................................288
dynamic classifiers.............................................525 configuring interface-shared...................................263
dynamic rewrite rules........................................525 examples........................................................................234
dynamic-class-of-service-options ......................526 fast update filter example.......................................289
excess-priority..............................................................540 fast update filters..............................................284, 290
excess-rate............................................................541, 542 fast update filters syntax..........................................287
excess-rate-high..........................................................543 ordering...........................................................................228
excess-rate-low...........................................................544 overview...........................................................................227
forwarding-class..........................................................557 permitting expected traffic......................................294
frame-mode statement............................................561 processing order........................................232, 257, 285
guaranteed-rate...........................................................570 types..................................................................................231
ieee-802.1 dynamic firewalls statements
dynamic classifiers.............................................574 adf.....................................................................................482
dynamic rewrite rules........................................575 family...............................................................................546
fast-update-filter........................................................550

Index
filter...................................................................................552 group-limit.....................................................................568
firewall.............................................................................555 group-policy..................................................................569
input.................................................................................584 immediate-leave.........................................................580
interface-shared..........................................................590 no-accounting.............................................................480
interface-specific........................................................590 oif-map...........................................................................608
match-order..................................................................603 passive..............................................................................613
output.............................................................................609 source..............................................................................655
post-service-filter........................................................623 source-count................................................................656
precedence....................................................................625 source-increment........................................................657
service.............................................................................648 ssm-map.......................................................................660
service-filter..................................................................649 static................................................................................662
service-set.....................................................................650 version.............................................................................686
shared-name................................................................653 dynamic MLD statements
term..................................................................................666 disable..............................................................................519
dynamic IGMP statements interface..........................................................................587
accounting.....................................................................480 mld...................................................................................604
disable..............................................................................519 dynamic profiles
group associating fast update filters...............................300
with source...........................................................564 associating service sets.............................................315
without source....................................................564 configuring for client access...................................338
group-limit......................................................................567 examples..............................................................265, 340
group-policy..................................................................568 dynamic profiles statements
igmp..................................................................................578 dynamic-profiles..........................................................527
immediate-leave..........................................................579 interface
interface..........................................................................585 dynamic routing options.................................588
no-accounting interfaces........................................................................592
interface................................................................606 mld...................................................................................604
oif-map multicast
interface.................................................................607 dynamic routing options.................................605
passive no-qos-adjust
interface..................................................................612 dynamic routing options..................................607
promiscuous-mode routing-options.............................................................641
interface..................................................................631 uid......................................................................................678
source uid-reference.................................................................678
interface.................................................................655 dynamic protocols
ssm-map overview...........................................................................337
interface................................................................660 dynamic service sets
static applying fast update filters.......................................315
interface..................................................................661 overview...........................................................................315
version dynamic subscribers
interface.................................................................685 interfaces statement..................................................592
dynamic MLD dynamic variables
overview..........................................................................343 configuring unique identifiers..................................252
dynamic MLD interface statements
accounting.....................................................................480
exclude............................................................................545
group................................................................................565
group-count..................................................................566
group-increment.........................................................566

dynamic VLAN fail filters

agent circuit identifier interface sets unicast RPF for subscriber interfaces
defining..................................................................586 configuring............................................................305
agent circuit identifier-based configuring overview.........................................304
adjusting CoS shaping rate and overhead example.................................................................305
accounting.........................................................133 fail-filter statement
bandwidth management overview..............129 unicast RPF....................................................................545
bandwidth management restrictions..........132 family statement
dynamic VLAN statements dynamic firewalls........................................................546
interface..........................................................................586 dynamic profiles..........................................................548
dynamic-class-of-service-options statement fast update filters..................................................................227
dynamic CoS.................................................................526 actions...................................................................290, 293
dynamic-profile parsing....................................................264 adding a term once......................................................291
dynamic-profiles applying to interfaces................................................300
interfaces statement..................................................592 associating to dynamic profiles............................300
dynamic IP demux.............................................592 basic syntax...................................................................287
dynamic-profiles statement.............................................527 components..................................................................285
configuration guidelines...........................................286
E configuring.....................................................................288
effective shaping rate reporting configuring match order............................................291
verifying configuration................................................128 configuring terms........................................................293
effective shaping rate, CoS conflict errors......................................................295, 298
reporting...........................................................................127 evaluating terms..........................................................296
effective-shaping-rate statement example..........................................................................289
CoS...................................................................................534 implied wildcard...........................................................297
enhanced-mode statement match conditions..............................................290, 292
firewall.............................................................................535 implied wildcard.................................................290
enhanced-mode-override statement names..............................................................................286
firewall.............................................................................537 only-at-create................................................................291
enhanced-policer statement..........................................538 overlapping terms.............................................295, 298
excess bandwidth distribution overview..........................................................................284
MIC and MPC interfaces............................................135 processing order..........................................................285
excess-burst-size statement...........................................539 fast-update-filter statement
excess-priority statement dynamic firewalls........................................................550
dynamic CoS................................................................540 filter precedence...................................................................257
excess-rate statement filter statement
dynamic scheduling....................................................541 dynamic firewalls........................................................552
dynamic traffic shaping............................................542 dynamic interface unit...............................................553
excess-rate-high statement firewall..............................................................................551
dynamic traffic shaping............................................543 filter-specific statement....................................................554
excess-rate-low statement filters
dynamic traffic shaping............................................544 parameterized..............................................................249
exclude statement verifying configuration......................................281, 333
dynamic MLD interface.............................................545 firewall
fast update filter actions..........................................293
F fast update filter match conditions......................292
fail filter statements statistics
fail-filter..........................................................................545 displaying...............................................................746

Index
firewall filters..........................................................................227 H
classic filters...................................................................231 hierarchical policer................................................................321
configuring fast update filters................................288 configuration statement for
fast update filters...............................................227, 284 aggregate..............................................................486
log information, displaying.......................................753 example............................................................................321
overview...........................................................................231 overview............................................................................317
statistics hierarchical-policer statement.........................................571
clearing....................................................................691 hierarchical-scheduler..........................................................25
See also dynamic firewall filters implicit-hierarchy.....................................................72, 74
firewall hierarchical-policer.............................................258 hierarchical-scheduler statement
firewall policer.......................................................................258 for subscriber interfaces............................................573
firewall statement HTTP redirect
dynamic profiles..........................................................555 configuring subscriber interfaces...........................351
flow-tap-dtcp statement..................................................557 remote operation flow....................................348, 350
font conventions...................................................................xxix HTTP service
forwarding-class statement example configuring attached to a dynamic
dynamic CoS.................................................................557 interface.....................................................................364
subscriber secure policy...........................................558 example configuring attached to a static
fpc statement interface.....................................................................356
MX Series routers........................................................559 HTTP_redirect
frame-mode statement example DA rewrite....................................................366
CoS statements............................................................561 example redundant multiservice...........................367
dynamic CoS statements.........................................561
from statement.....................................................................562 I
subscriber secure policy...........................................563 ieee-802.1 statement
dynamic classifiers......................................................574
G dynamic rewrite rules.................................................575
group statement if-exceeding statement
dynamic IGMP hierarchical policer......................................................576
with source...........................................................564 single-rate two-color policer...................................577
without source....................................................564 IGMP
dynamic MLD interface.............................................565 enabling...........................................................................578
group-count statement group membership, displaying...............................758
dynamic MLD interface.............................................566 interfaces, displaying..................................................762
group-increment statement network models............................................................337
dynamic MLD interface.............................................566 statistics, displaying...................................................766
group-limit statement version.............................................................................685
dynamic IGMP...............................................................567 igmp statement
dynamic MLD interface.............................................568 dynamic IGMP..............................................................578
group-policy statement IGMP statements
dynamic IGMP..............................................................568 promiscuous-mode
dynamic MLD interface.............................................569 interface..................................................................631
groups immediate-leave statement
IGMP membership, displaying................................758 dynamic IGMP...............................................................579
MLD dynamic MLD interface............................................580
clearing..................................................................698 implicit-hierarchy.......................................25, 66, 69, 72, 74
displaying................................................................771 inet-precedence statement
guaranteed-rate statement dynamic classifiers.....................................................582
dynamic CoS.................................................................570 dynamic rewrite rules................................................582

input statement logical interface statements

dynamic service sets.................................................584 family...............................................................................548
interface sets logical-bandwidth-policer statement.........................596
applying CoS traffic shaping logical-interface-fpc-redundancy statement
attributes....................................................166, 168, 171 aggregated Ethernet...................................................597
CoS traffic shaping predefined variables............174 logical-interface-policer statement.............................598
interface statement login statement....................................................................599
dynamic CoS................................................................586 loss-priority statement
dynamic IGMP..............................................................585 dynamic CoS................................................................600
dynamic MLD................................................................587
dynamic VLAN M
defining..................................................................586 manuals
multicast comments on................................................................xxxi
dynamic routing options.................................588 match conditions.................................................................256
interface-set fast update filters
dynamic implied wildcard.................................................290
configuring...............................................................211 match-direction statement.............................................602
interface-set statement match-order statement
dynamic CoS................................................................589 dynamic firewalls........................................................603
interface-shared statement max-queues-per-interface statement........................602
dynamic firewalls........................................................590 maximum-hierarchy-levels.................................................25
interface-specific statement maximum-hierarchy-levels 2.....................................64, 69
dynamic firewalls........................................................590 maximum-scheduler levels 2.............................................70
interfaces MIC and MPC interfaces
unit statement..............................................................679 burst-size.........................................................................136
interfaces statement excess bandwidth distribution................................135
dynamic CoS..................................................................591 MLD
dynamic profiles..........................................................592 enabling..........................................................................604
subscriber secure policy...........................................596 group membership
Internet Group Management Protocol See IGMP clearing..................................................................698
displaying................................................................771
J interfaces, displaying..................................................775
junos-subscriber-ip-address...........................................258 statistics
clearing..................................................................699
L displaying...............................................................779
L2TP LAC mld statement
subscriber secure policy............................................379 dynamic profiles..........................................................604
L2TP LNS MPLS pseudowire
subscriber secure policy............................................379 anchor logical tunnel....................................................69
lawful intercept See subscriber secure policy CoS
Layer 2 policer overview....................................................................63
hierarchical policer CoS configuration
overview...................................................................317 overview...................................................................69
license requirements hierarchical-scheduler.................................................63
subscriber secure policy............................................376 implicit-hierarchy.............................66, 67, 72, 74
log files maximum-scheduler levels 2...........................70
collecting for Juniper Networks Technical implicit-hierarchy...........................................................69
Support.......................................................................439 maximum-hierarchy-levels 2............................64, 69
ps device-name................................................70, 72, 74

Index
subscriber interfaces....................................................63 overhead-accounting statement

three-level scheduling dynamic CoS...................................................................611
configuring.........................................................72, 74
deployment scenario..........................................68 P
logical interfaces over a pseudowire parameterized filter: guidelines......................................259
interface set.........................................................74 parameterized filters..................................................227, 249
logical interfaces over a transport logical components..................................................................256
interface................................................................72 processing order.................................................256, 257
overview............................................................66, 67 parameterized policers......................................................249
Pseudowire Logical Interface Set....................67 parentheses, in syntax descriptions...............................xxx
Transport Logical Interface...............................66 passive statement
two-level scheduling dynamic IGMP
configuring...............................................................70 interface..................................................................612
overview...................................................................64 dynamic MLD interface..............................................613
multicast peak-burst-size statement...............................................614
configuration statements........................................605 peak-information-rate statement..................................616
multicast statement permissions statement.......................................................617
dynamic routing options..........................................605 physical interface policer
multicast traffic See subscriber secure policy configuration statement for.....................................618
separating from unicast.............................................147 physical-interface-policer statement...........................618
multicast-interception statement................................606 policer.......................................................................................258
policer statement
N configuring......................................................................619
no-accounting statement policer, hierarchical
dynamic IGMP configuration statement for......................................571
interface................................................................606 aggregate..............................................................486
dynamic MLD interface............................................480 example............................................................................321
no-qos-adjust statement overview............................................................................317
dynamic routing options..........................................607 policer, Layer 2
node adjustments hierarchical policer
configuring for shaping rate.....................................102 overview...................................................................317
non-link-protected aggregated Ethernet interfaces policers
manually rebalancing subscribers................147, 701 parameterized..............................................................249
periodically rebalancing subscribers.....................147 policy statement
rebalancing subscribers....................................147, 701 subscriber secure policy.........................581, 583, 621
policy-options prefix-list...................................................258
O policy-options statement.................................................622
OIF maps post-service-filter statement
separating multicast traffic.......................................147 dynamic service sets..................................................623
oif-map statement pppoe-tags statement
dynamic IGMP CoS...............................................................483, 488, 624
interface.................................................................607 precedence statement.......................................................625
dynamic MLD interface............................................608 premium statement
outbound packets................................................................257 hierarchical policer.....................................................626
output statement priority statement
dynamic service sets.................................................609 dynamic CoS.................................................................627
output-traffic-control-profile statement profile statement
dynamic CoS.................................................................610 subscriber access........................................................628

promiscuous-mode statement scheduler-hierarchy-interface

IGMP viewing.............................................................................736
interface..................................................................631 scheduler-hierarchy-interface-set
protocol statement viewing.............................................................................738
dynamic CoS.................................................................632 scheduler-map statement
subscriber secure policy...........................................632 dynamic CoS
pseudowire interface set......................................................74 association with traffic-control
Pseudowire Logical Interface Set.....................................67 profile.................................................................645
scheduler-maps statement
Q dynamic CoS
queue adjustments scheduler map configuration........................646
configuring for shaping rate..............................97, 103 schedulers statement
dynamic CoS.................................................................647
R service activations...............................................................258
RADIUS service sets
CoS parameters for initial services applying to interfaces.................................................315
configuring an access dynamic associating to dynamic profiles..............................315
profile..................................................................169 dynamic............................................................................315
example...................................................................179 service statement
overview..................................................................159 dynamic service sets.................................................648
RADIUS servers See subscriber secure policy service-filter statement
radius statement dynamic service sets.................................................649
subscriber access........................................................633 service-set statement
radius-coa statement dynamic service sets.................................................650
CoS...............................................................483, 488, 635 service-sets
radius-flow-tap service See subscriber secure policy verifying configuration................................................316
radius-flow-tap statement..............................................636 services sets
radius-server statement....................................................637 summary information, displaying.........................784
rate-limit statement...........................................................638 services statement...............................................................651
rebalance-periodic statement shaping-rate adjustments
aggregated Ethernet..................................................639 ANCP.................................................................................102
redundancy mechanisms for Virtual Chassis applications......................................................................97
module.............................................................................597 for subscriber local loops
request interface rebalance (Aggregated Ethernet configuration guidelines...................................100
for Subscriber Management) command.................701 disabling.................................................................109
reverse path forwarding (RPF) See unicast reverse enabling..................................................................104
path forwarding (RPF) example...................................................................110
rewrite-rules statement overview...................................................................99
dynamic CoS................................................................640 multicast.................................................................102, 103
routing-options statement queues..............................................................................103
dynamic profiles...........................................................641 scheduler nodes...........................................................102
RPF See unicast reverse path forwarding (RPF) shaping-rate statement
rpf-check statement...........................................................642 dynamic CoS.................................................................652
rule statement.......................................................................643 shared-name statement...................................................653
rule-set statement..............................................................644 show class-of-service adjustment-control-profile
command...........................................................................704
S show class-of-service command..................................702
scheduler statement show class-of-service interface command...............706
dynamic CoS................................................................644

Index
show class-of-service interface-set stateless firewall filters

command............................................................................734 examples
show class-of-service scheduler-hierarchy interface configuring enhanced mode...........................313
command............................................................................736 static statement
show class-of-service scheduler-hierarchy dynamic IGMP
interface-set command................................................738 interface..................................................................661
show class-of-service scheduler-map dynamic MLD interface.............................................662
command...........................................................................740 static subscribers
show class-of-service traffic-control-profile interfaces statement..................................................592
command............................................................................742 subscriber access
show firewall command....................................................746 subscriber information, displaying.......................786
show firewall log command.............................................753 subscriber summary information,
show firewall templates-in-use command................756 displaying..................................................................804
show igmp group command............................................758 subscriber interface statements
show igmp interface command......................................762 family...............................................................................548
show igmp statistics command.....................................766 interfaces........................................................................592
show interfaces targeting command...........................769 rpf-check........................................................................642
show mld group command................................................771 unit....................................................................................679
show mld interface command.........................................775 subscriber interfaces
show mld statistics command........................................779 applying CoS traffic shaping
show services captive-portal-content-delivery attributes....................................................166, 168, 171
command............................................................................782 captive portal content delivery
show services service-sets summary configuring .............................................................351
command...........................................................................784 CoS traffic shaping predefined variables............174
show subscribers command...........................................786 subscriber local loops
show subscribers summary command......................804 CoS shaping-rate adjustments
single-rate statement........................................................654 configuration guidelines...................................100
SNMPv3 traps disabling.................................................................109
subscriber secure policy...........................................409 enabling..................................................................104
subscriber secure policy configuration.................411 example...................................................................110
source statement overview...................................................................99
dynamic IGMP subscriber secure policy
interface.................................................................655 configuring DTCP-initiated......................................398
dynamic MLD interface.............................................655 configuring RADIUS-initiated..................................382
source-address statement configuring SNMPv3 traps.........................................411
subscriber secure policy...........................................656 DTCP................................................................................405
source-count statement architecture..........................................................400
dynamic MLD interface.............................................656 traffic mirroring interfaces..............................402
source-increment statement DTCP configuration...........................................420, 421
dynamic MLD interface.............................................657 L2TP LAC subscribers................................................379
source-ipv4-address statement.....................................657 L2TP LNS subscribers................................................379
source-port statement LAES compliance.......................................................409
subscriber secure policy...........................................658 license requirements..................................................376
ssh statement.......................................................................659 multicast traffic............................................................395
ssm-map statement multicast traffic configuration...............................396
dynamic IGMP overview..........................................................................375
interface................................................................660 RADIUS
dynamic MLD interface............................................660 architecture..........................................................384
traffic mirroring interfaces..............................386

RADIUS process traffic mirroring See subscriber secure policy

logged-in subscribers.............................388, 389 DTCP
RADIUS server configuration..................................383 subscriber secure policy..................................400
radius-flow-tap service.............................................383 traffic mirroring interfaces..............................402
radius-flow-tap service configuration.................376 RADIUS
RADIUS-initiated.........................................................392 architecture..........................................................384
SNMPv3 trap example................................................411 traffic mirroring interfaces..............................386
SNMPv3 traps..............................................................409 RADIUS process
system resources........................................................398 at subscriber login..............................................388
terminating logged-in subscribers.......................................389
RADIUS-initiated................................................393 traffic-control-profiles statement
tunnel configuration..................................................390 dynamic CoS.................................................................674
subscriber-leave-timer statement................................663 transmit-rate statement
subscribers dynamic CoS.................................................................675
displaying.......................................................................786 troubleshooting subscriber access
displaying summary..................................................804 collecting logs for Juniper Networks Technical
support, technical See technical support Support.......................................................................439
syntax conventions..............................................................xxix tunnel-services statement...............................................676
two-rate statement..............................................................677
T
targeted traffic U
separating multicast....................................................147 uid statement
targeted traffic distribution dynamic profile variables.........................................678
Virtual Chassis.............................................................664 uid substitution.....................................................................255
targeted-distribution statement uid-reference.........................................................................250
aggregated Ethernet.......................................663, 664 uid-reference statement
technical support dynamic profile variables.........................................678
collecting logs for........................................................439 unicast reverse path forwarding (RPF)
contacting JTAC...........................................................xxxi dynamic profiles for subscriber interfaces
term statement....................................................................665 configuring............................................................304
fast update filters........................................................666 overview.................................................................303
then statement....................................................................668 fail filter for subscriber interfaces
three-color policer...............................................................258 configuring............................................................305
three-color-policer statement........................................670 for subscriber interfaces
trace operations configuring overview.........................................304
collecting logs for Juniper Networks Technical example.................................................................305
Support.......................................................................439 unicast reverse path forwarding (RPF) statements
traceoptions statement fail-filter..........................................................................545
captive portal content delivery...............................672 unique identifiers (UIDs).........................................249, 250
traffic distribution mechanisms for Virtual Chassis unit statement
targeted distribution..................................................664 dynamic CoS.................................................................682
interfaces........................................................................679
user statement
access..............................................................................683

Index
V Virtual Chassis
variables, Junos OS predefined module redundancy...................................................597
dynamic CoS (schedulers) redundancy
$junos-cos-scheduler..............................159, 647 module....................................................................597
$junos-cos-scheduler-bs......................159, 499 targeted traffic distribution.....................................664
$junos-cos-scheduler-dropfile-any.....159, 521 vlan-tag statement
$junos-cos-scheduler-dropfile-high....159, 521 dynamic classifiers.....................................................686
$junos-cos-scheduler-dropfile-low.....159, 521 dynamic rewrite-rules................................................687
$junos-cos-scheduler-dropfile-medium-high.159,521
$junos-cos-scheduler-dropfile-medium-low.159,521 W
$junos-cos-scheduler-pri.......................159, 627 walled garden
$junos-cos-scheduler-tx........................159, 675 example configuring as an HTTP service
configuring an access dynamic rule................................................................................356
profile..................................................................169 example configuring as service filter....................355
example...................................................................179
for dynamic interface sets...............166, 171, 174
overview..................................................................159
dynamic CoS (traffic control profiles)
$junos-cos-byte-adjust.......503, 505, 561, 611
$junos-cos-byte-adjust-cell..................505, 611
$junos-cos-byte-adjust-frame..............561, 611
$junos-cos-delay-buffer-rate........................516
$junos-cos-excess-priority............................540
$junos-cos-excess-rate...................................542
$junos-cos-excess-rate-high........................543
$junos-cos-excess-rate-low..........................544
$junos-cos-overhead-accounting.................611
$junos-cos-scheduler-excess-rate..............541
$junos-cos-scheduler-map...........................645
$junos-cos-scheduler-shaping-rate...........652
$junos-cos-shaping-mode..............................611
$junos-cos-shaping-rate................................652
dynamic CoS (traffic-control-profiles)
$junos-cos-guaranteed-rate.........................570
configuring an access dynamic
profile..................................................................169
example...................................................................179
for dynamic interface sets...............166, 171, 174
overview..................................................................159
vendor-specific-tags access-loop-encapsulation
statement
dynamic CoS................................................................684
verification
aggregate route.............................................................153
version statement
dynamic IGMP
interface.................................................................685
dynamic MLD interface............................................686


Broadband Subscriber Services Feature Guide - 14.2

Uploaded by

Copyright:

Available Formats

Broadband Subscriber Services Feature Guide - 14.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Broadband Subscriber Services Feature Guide - 14.2

Uploaded by

Copyright:

Available Formats

Junos® OS

Copyright © 2015, Juniper Networks, Inc.

YEAR 2000 NOTICE

END USER LICENSE AGREEMENT

ii Copyright © 2015, Juniper Networks, Inc.

Part 1 Configuring Dynamic Class of Service

Copyright © 2015, Juniper Networks, Inc. iii

Chapter 3 Managing Different Types of Service Traffic for a Household Using

iv Copyright © 2015, Juniper Networks, Inc.

Chapter 6 Configuring Dedicated Queue Scaling with Hierarchical CoS or Per-Unit

Copyright © 2015, Juniper Networks, Inc. v

Configuring ANCP Functionality That Supports and Drives Shaping-Rate

vi Copyright © 2015, Juniper Networks, Inc.

Dynamic Profiles and Adjustment of CoS Shaping Rate and Overhead

Copyright © 2015, Juniper Networks, Inc. vii

Chapter 12 Applying CoS Using Parameters Received from RADIUS . . . . . . . . . . . . . . 159

viii Copyright © 2015, Juniper Networks, Inc.

Chapter 15 Applying CoS to Groups of Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . 195

Part 2 Configuring Dynamic Filters and Policers

Copyright © 2015, Juniper Networks, Inc. ix

Parameterized Filters Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . 258

x Copyright © 2015, Juniper Networks, Inc.

Avoiding Conflicts When Terms Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Part 3 Configuring Dynamic Multicast

Copyright © 2015, Juniper Networks, Inc. xi

Part 4 Configuring HTTP Redirect

Part 5 Configuring Subscriber Secure Policy

xii Copyright © 2015, Juniper Networks, Inc.

Chapter 36 Configuring Subscriber Secure Policy Support for IPv4 Multicast

Copyright © 2015, Juniper Networks, Inc. xiii

Verifying That Traffic Mirroring Was Stopped on the Subscriber

xiv Copyright © 2015, Juniper Networks, Inc.

Part 7 Configuration Statements and Operational Commands

Copyright © 2015, Juniper Networks, Inc. xv

xvi Copyright © 2015, Juniper Networks, Inc.

group-increment (Dynamic MLD Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

Copyright © 2015, Juniper Networks, Inc. xvii

overhead-accounting (Dynamic Traffic Shaping) . . . . . . . . . . . . . . . . . . . . . . . . . 611

xviii Copyright © 2015, Juniper Networks, Inc.

ssm-map (Dynamic IGMP Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Copyright © 2015, Juniper Networks, Inc. xix

show igmp interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762

xx Copyright © 2015, Juniper Networks, Inc.

Copyright © 2015, Juniper Networks, Inc. xxi

Chapter 10 Managing Excess Bandwidth Distribution and Traffic Bursts . . . . . . . . . . . 135

Part 2 Configuring Dynamic Filters and Policers

Part 5 Configuring Subscriber Secure Policy

xxii Copyright © 2015, Juniper Networks, Inc.

Part 1 Configuring Dynamic Class of Service

Copyright © 2015, Juniper Networks, Inc. xxiii

Chapter 6 Configuring Dedicated Queue Scaling with Hierarchical CoS or Per-Unit

Part 2 Configuring Dynamic Filters and Policers

xxiv Copyright © 2015, Juniper Networks, Inc.

Part 5 Configuring Subscriber Secure Policy

Part 7 Configuration Statements and Operational Commands

Copyright © 2015, Juniper Networks, Inc. xxv

Table 70: show subscribers Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

xxvi Copyright © 2015, Juniper Networks, Inc.

• Documentation and Release Notes on page xxvii