- play_arrow Subscriber Service Activation and Management
- play_arrow Subscriber Service Activation and Management
-
- play_arrow Configuring Dynamic Class of Service
- play_arrow CoS for Subscriber Access and Interfaces Overview
- play_arrow Configuring Scheduling and Shaping for Subscriber Access
- Configuring Traffic Scheduling and Shaping for Subscriber Access
- Configuring Schedulers in a Dynamic Profile for Subscriber Access
- Configuring Scheduler and Scheduler Map Sharing
- Example: Providing Unique Rate Configurations for Schedulers in a Dynamic Profile
- Example: Configuring Aggregate Scheduling of Queues for Residential Subscribers on Static IP Demux Interfaces
- Verifying the Scheduling and Shaping Configuration for Subscriber Access
- play_arrow Allocating Dedicated Queues for Each Logical Interface Using Per-Unit Scheduling
- play_arrow Configuring Hierarchical CoS Scheduling on MPLS Ethernet Pseudowire Subscriber Interfaces
- Enhanced Subscriber Management Subscriber Logical Interfaces or Interface Sets Over Underlying Logical Interfaces for a CoS scheduler Hierarchy
- Enhanced Subscriber Management Subscriber Logical Interfaces or Interface Sets Over MPLS Pseudowires for a CoS scheduler Hierarchy
- Configuring Layer 2 Subscriber Logical Interfaces for CoS Hierarchical Schedulers Using Dynamic Profiles for Differentiating Home and Access Node Networks
- Example: Configuring Layer 2 Subscriber Logical Interfaces for CoS Hierarchical Schedulers Using Static CoS for Differentiating Home and Access Node Networks
- play_arrow Configuring Dedicated Queue Scaling with Hierarchical CoS or Per-Unit Scheduling
- play_arrow Shaping Downstream Traffic Based on Frames or Cells
- Bandwidth Management for Downstream Traffic in Edge Networks Overview
- Configuring Dynamic Shaping Parameters to Account for Overhead in Downstream Traffic Rates
- Example: Configuring Dynamic Shaping Parameters to Account for Overhead in Downstream Traffic Rates
- Configuring Static Shaping Parameters to Account for Overhead in Downstream Traffic Rates
- Example: Configuring Static Shaping Parameters to Account for Overhead in Downstream Traffic Rates
- Setting Shaping Rate and Overhead Accounting Based on PPPoE Vendor-Specific Tags
- Configuring the Shaping Rate and Overhead Accounting Based on PPPoE Vendor-Specific Tags on Dynamic Subscriber Interfaces
- Reporting the Effective Shaping Rate for Subscribers
- Verifying the Effective Shaping Rate Reporting Configuration
- play_arrow Applying CoS to Households or Individual Subscribers Using ACI-Based Dynamic VLANs
- Applying CoS Attributes to VLANs Using Agent-Circuit-Identifiers
- Agent Circuit Identifier-Based Dynamic VLANs Bandwidth Management Overview
- Restrictions for Configuring Adjustment of CoS Shaping Rate and Overhead Accounting for Dynamic ACI Interface Sets
- Adjusting the CoS Shaping Rate and Overhead Accounting Parameters for Agent Circuit Identifier-Based Dynamic VLANs
- play_arrow Applying CoS to Households or Individual Subscribers Using Access Line Identifier Dynamic VLANs
- Applying CoS Attributes to VLANs Using Access-Line Identifiers
- Bandwidth Management Overview for Dynamic VLANs Based on Access-Line Identifiers
- Restrictions for Configuring Adjustment of CoS Shaping Rate and Overhead Accounting for Dynamic ALI Interface Sets
- Adjusting the CoS Shaping Rate and Overhead Accounting Parameters for Dynamic VLANs Based on Access-Line Identifiers
- play_arrow Managing Excess Bandwidth Distribution and Traffic Bursts
- play_arrow Applying CoS Using Parameters Received from RADIUS
- Subscriber Interfaces That Provide Initial CoS Parameters Dynamically Obtained from RADIUS
- Changing CoS Services Overview
- CoS Traffic Shaping Attributes for Dynamic Interface Sets and Member Subscriber Sessions Overview
- Guidelines for Configuring CoS Traffic Shaping Attributes for Dynamic Interface Sets and Member Subscriber Sessions
- Configuring Initial CoS Parameters Dynamically Obtained from RADIUS
- Configuring Static Default Values for Traffic Scheduling and Shaping
- Applying CoS Traffic-Shaping Attributes to Dynamic Interface Sets and Member Subscriber Sessions
- CoS Traffic Shaping Predefined Variables for Dynamic Interface Sets
- Example: Configuring Initial CoS Parameters Dynamically Obtained from RADIUS
- play_arrow Modifying a Subscriber’ s Shaping Characteristics After a Subscriber is Instantiated
- play_arrow Applying CoS to Groups of Subscriber Interfaces
- play_arrow Applying CoS to Subscriber Interfaces
- Applying Traffic Shaping and Scheduling to a Subscriber Interface in a Dynamic Profile
- Applying Minimal Shaping and Scheduling to Remaining Subscriber Traffic
- Applying a Rewrite Rule Definition to a Subscriber Interface in a Dynamic Profile
- Applying a Classifier to a Subscriber Interface in a Dynamic Profile
-
- 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
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.
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 1 shows the configuration options when determining enhanced network services mode usage.
Interface and Filter Configuration | Chassis Enhanced Mode Required | Firewall Filter Enhanced 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.
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.