- play_arrow Subscriber Service Activation and Management
- play_arrow Subscriber Service Activation and Management
-
- play_arrow Configuring Dynamic Filters and Policers
- play_arrow Dynamic Firewall Filters Overview
- play_arrow Configuring Static Firewall Filters That Are Dynamically Applied
- play_arrow Streamlining Processing of Chains of Static Filters
- play_arrow Dynamically Attaching Static or Fast Update Filters to an Interface
- play_arrow Configuring Filters That Are Created Dynamically
- Parameterized Filters Overview
- Unique Identifiers for Firewall Variables
- Configuring Unique Identifiers for Parameterized Filters
- Sample Dynamic-Profile Configuration for Parameterized Filters
- Dynamic Profile After UID Substitutions for Parameterized Filters
- Multiple Parameterized Filters
- Parameterized Filter Processing Overview
- Parameterized Filters Configuration Considerations
- Guidelines for Creating and Applying Parameterized Filters for Subscriber Interfaces
- Parameterized Filter Match Conditions for IPv4 Traffic
- Parameterized Filter Match Conditions for IPv6 Traffic
- Parameterized Filter Nonterminating and Terminating Actions and Modifiers
- Firewall Filter Match Conditions for Protocol-Independent Traffic in Dynamic Service Profiles
- Firewall Filter Terminating and Nonterminating Actions for Protocol-Independent Traffic in Dynamic Service Profiles
- Interface-Shared Filters Overview
- Dynamically Attaching Filters Using RADIUS Variables
- Example: Implementing a Filter for Households That Use ACI-Based VLANs
- Example: Dynamic-Profile Parsing
- Example: Firewall Dynamic Profile
- Example: Configuring a Filter to Exclude DHCPv6 and ICMPv6 Control Traffic for LAC Subscriber
- play_arrow Using Ascend Data Filters to Implement Firewalls Based on RADIUS Attributes
- Ascend-Data-Filter Policies for Subscriber Management Overview
- Ascend-Data-Filter Attribute Fields
- Dynamically Applying Ascend-Data-Filter Policies to Subscriber Sessions
- Example: Configuring Dynamic Ascend-Data-Filter Support for Subscriber Access
- Example: Configuring Static Ascend-Data-Filter Support for Subscriber Access
- Verifying and Managing Dynamic Ascend-Data-Filter Policy Configuration
- play_arrow Configuring Fast Update Filters to Provide More Efficient Processing Over Classic Static Filters
- Fast Update Filters Overview
- Basic Fast Update Filter Syntax
- Configuring Fast Update Filters
- Example: Configuring Fast Update Filters for Subscriber Access
- Match Conditions and Actions in Fast Update Filters
- Configuring the Match Order for Fast Update Filters
- Fast Update Filter Match Conditions
- Fast Update Filter Actions and Action Modifiers
- Configuring Terms for Fast Update Filters
- Configuring Filters to Permit Expected Traffic
- Avoiding Conflicts When Terms Match
- Associating Fast Update Filters with Interfaces in a Dynamic Profile
- play_arrow Defending Against DoS and DDoS Attacks Using Unicast RPF and Fail Filters
- play_arrow Improving Scaling and Performance of Filters on Static Subscriber Interfaces
- play_arrow Configuring Dynamic Service Sets
- play_arrow Configuring Rate-Limiting Premium and Non-Premium Traffic on an Interface Using Hierarchical Policers
- play_arrow Monitoring and Managing Firewalls for Subscriber Access
-
- play_arrow Configuring Dynamic Multicast
- play_arrow Configuring Dynamic IGMP to Support IP Multicasting for Subscribers
- play_arrow Configuring Dynamic MLD to Enable Subscribers to Access Multicast Networks
-
- play_arrow Configuring Application-Aware Policy Control and Reporting
- play_arrow Configuring Application-Aware Policy Control
- Understanding Application-Aware Policy Control for Subscriber Management
- Understanding PCC Rules for Subscriber Management
- Configuring Application-Aware Policy Control for Subscriber Management
- Installing Services Packages for Subscriber Management Application-Aware Policy Management
- Configuring Service Data Flow Filters
- Configuring Policy and Charging Control Action Profiles for Subscriber Management
- Configuring Policy and Charging Control Rules
- Configuring a Policy and Charging Control Rulebase
- Configuring a Policy and Charging Enforcement Function Profile for Subscriber Management
- Identifying the Service Interface That Handles Subscriber Management Application-Aware Policy Control
- Configuring PCC Rule Activation in a Subscriber Management Dynamic Profile
- Enabling Direct PCC Rule Activation by a PCRF for Subscriber Management
- play_arrow Configuring Application Identification
- play_arrow Configuring Reporting for Application-Aware Data Sessions
- Logging and Reporting Function for Subscribers
- Log Dictionary for Template Types
- Configuring Logging and Reporting for Subscriber Management
- Installing Services Packages for Subscriber Management Logging and Reporting
- Configuring an LRF Profile for Subscribers
- Applying Logging and Reporting Configuration to a Subscriber Management Service Set
- Configuring the Activation of an LRF Rule by a PCC Rule
-
- play_arrow Configuring HTTP Redirect Services
- play_arrow Configuring Captive Portal Content Delivery Services for Redirected Subscribers
- HTTP Redirect Service Overview
- Remote HTTP Redirect Server Operation Flow
- Local HTTP Redirect Server Operation Flow (MX Series, ACX7100-48L, ACX7332 and ACX7348)
- Configuring MS-MPC-Based or MX-SPC3-Based Static HTTP Redirect Services
- Configuring MS-MPC-Based or MX-SPC3-Based Converged HTTP Redirect Services
- Configuring Routing Engine-Based, Static HTTP Redirect Services
- Configuring Routing Engine-Based, Converged HTTP Redirect Services
- Adding Subscriber Information to HTTP Redirect URLs
- How to Automatically Remove the HTTP Redirect Service After the Initial Redirect
- Example: Configuring HTTP Redirect Services Using a Next-Hop Method and Attaching It to a Static Interface
-
- play_arrow Configuring Subscriber Secure Policy
- play_arrow Configuring Subscriber Secure Policy Traffic Mirroring Overview
- play_arrow Configuring RADIUS-Initiated Subscriber Secure Policy Traffic Mirroring
- RADIUS-Initiated Subscriber Secure Policy Overview
- Subscriber Secure Policy Traffic Mirroring Architecture Using RADIUS
- RADIUS-Initiated Traffic Mirroring Interfaces
- RADIUS-Initiated Traffic Mirroring Process at Subscriber Login
- RADIUS-Initiated Traffic Mirroring Process for Logged-In Subscribers
- RADIUS Attributes Used for Subscriber Secure Policy
- Using the Packet Header to Track Subscribers on the Mediation Device
- Configuring RADIUS-Initiated Subscriber Secure Policy Mirroring Overview
- Guidelines for Configuring Subscriber Secure Policy Mirroring
- Configuring Support for Subscriber Secure Policy Mirroring
- Configuring RADIUS Server Support for Subscriber Secure Policy Mirroring
- Terminating RADIUS-Initiated Subscriber Traffic Mirroring
- play_arrow Configuring DTCP-Initiated Subscriber Secure Policy Traffic Mirroring
- DTCP-Initiated Subscriber Secure Policy Overview
- Subscriber Secure Policy Traffic Mirroring Architecture Using DTCP
- DTCP-Initiated Traffic Mirroring Interfaces
- DTCP-Initiated Traffic Mirroring Process
- DTCP Messages Used for Subscriber Secure Policy
- Packet Header for Mirrored Traffic Sent to Mediation Device
- Configuring DTCP-Initiated Subscriber Secure Policy Mirroring Overview
- Guidelines for Configuring Subscriber Secure Policy Mirroring
- Configuring Support for Subscriber Secure Policy Mirroring
- Configuring the Mediation Device as a User on the Router
- Configuring a DTCP-over-SSH Connection to the Mediation Device
- Configuring the Mediation Device to Provision Traffic Mirroring
- Disabling RADIUS-Initiated Subscriber Secure Policy Mirroring
- Example: Configuring Traffic That Is Mirrored Using DTCP-Initiated Subscriber Secure Policy
- Terminating DTCP-Initiated Subscriber Traffic Mirroring Sessions
- play_arrow Configuring DTCP Messages Used for DTCP-Initiated Subscriber Secure Policy Mirroring
- play_arrow Configuring Subscriber Secure Policy Support for IPv4 Multicast Traffic
- play_arrow Configuring Intercept-Related Information for Subscriber Secure Policy
-
- play_arrow Configuring Stateless, Rule-Based Services Using Application-Aware Access Lists
- play_arrow AACL Overview
- play_arrow Configuring AACL Rules
- play_arrow Example: Configuring AACL Rules
- play_arrow Example: Configuring AACL Rule Sets
- play_arrow Configuring Logging of AACL Flows
-
- play_arrow Remote Device and Service Management
- play_arrow Configuring Remote Device Services Management
- play_arrow Configuring TCP Port Forwarding for Remote Subscriber Services
- play_arrow Configuring IPFIX Mediation for Remote Device Monitoring
- play_arrow Collection and Export of Local Telemetry Data on the IPFIX Mediator
-
- play_arrow Troubleshooting
- play_arrow Contacting Juniper Networks Technical Support
- play_arrow Knowledge Base
-
- play_arrow Configuration Statements and Operational Commands
- [OBSOLETE] applications (Services AACL)
- [OBSOLETE] application-group-any
- [OBSOLETE] application-groups (Services AACL)
- [OBSOLETE] destination-address (Application Aware Access List)
- [OBSOLETE] destination-address-range
- [OBSOLETE] destination-prefix-list (Services AACL)
- [OBSOLETE] from
- [OBSOLETE] match-direction
- [OBSOLETE] nested-applications
- [OBSOLETE] rule
- [OBSOLETE] rule-set
- [OBSOLETE] source-address (AACL)
- [OBSOLETE] source-address-range
- [OBSOLETE] source-prefix-list
- [OBSOLETE] term
- [OBSOLETE] then (Application Aware Access List)
- Junos CLI Reference Overview
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.
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 theaggregate-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 1 lists the classification rule configuration for an IP demux subscriber interface with a VLAN underlying interface.
Table 1: IP Demux Classification Rules VLAN Underlying Interface Classifier Configuration
IP Demux Interface Classifier Configuration
Resulting Classifier Configuration
Layer 2
—
VLAN Layer 2
Layer 2
Layer 3
Demux Layer 3
Layer 3
—
Default
Layer 3
Layer 3
Demux Layer 3
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 2 lists the rewrite rule configuration for an IP demux subscriber interface with a VLAN underlying interface.
Table 2: IP Demux Rewrite Rules VLAN Underlying Interface Rewrite Rule Configuration
IP Demux Interface Rewrite Rule Configuration
Resulting Rewrite Rule Configuration
Layer 2
—
VLAN Layer 2
Layer 2
Layer 3
VLAN Layer 2 and demux Layer 3
Layer 3
—
Default
Layer 3
Layer 3
Demux Layer 3
An L2TP subscriber interface can implicitly inherit a classifier from the underlying interface.
Table 3 lists the classification rule configuration for an L2TP LAC subscriber interface with a VLAN underlying interface.
Table 3: L2TP Classification Rules VLAN Underlying Interface Classifier Configuration
L2TP LAC Classifier Configuration
Resulting Classifier 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 4 lists the rewrite rule configuration for an L2TP LAC subscriber interface with a VLAN underlying interface.
Table 4: L2TP LAC Rewrite Rules VLAN Underlying Interface Rewrite Rule Configuration
L2TP Interface Rewrite Rule Configuration
Resulting Rewrite Rule 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