- 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 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 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
Example: Using DTCP Messages to Trigger, Verify, and Remove Traffic Mirroring for Subscribers
This example shows how to create DTCP messages to do the following:
Trigger a drop policy if one does not already exist.
Remove an existing drop policy.
Trigger traffic mirroring for two subscribers based on interface ID.
Verify that subscriber traffic on the two interfaces is being mirrored.
Remove 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 ENABLE Messages to Trigger a Drop Policy
This section shows 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.
ENABLE DTCP/0.7 Csource-ID: ft-user1 Criteria-ID: 1 X-Drop: T1 Flags: STATIC Seq: 1 Authentication-Info: c16d2d9d1679facf0c4a66683af6114d341e4033 DTCP/0.7 200 OK SEQ: 7 CRITERIA-ID: 2 TIMESTAMP: 2011-02-13 15:56:49.609
Creating DTCP DISABLE Messages to Remove a Drop Policy
This section shows the DTCP attributes used in DISABLE messages to cause the router to remove an existing a drop policy created with a prior DTCP ENABLE command.
DISABLE DTCP/0.8 Csource-ID: ft-user Criteria-ID: 8 X-Drop-Policy: drop_pol Flags: STATIC Seq: 1 Authentication-Info: 963aa01c38c531f63fb410afd058c018be4d0230 DTCP/0.8 200 OK SEQ: 1 CRITERIA-COUNT: 1 TIMESTAMP: 2022-01-24 11:58:47.927
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.2.168 X-JTap-Cdest-Dest-Port: 65535 X-JTap-Cdest-Source-Address: 198.51.100.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-Dest-Address: 192.0.2.168 X-JTap-Cdest-Dest-Port: 65535 X-JTap-Cdest-Source-Address: 198.51.100.10 X-JTap-Cdest-Source-Port: 50000 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-JTap-Cdest-Dest-Address: 203.0.113.112 X-JTap-Cdest-Dest-Port: 7899 X-JTap-Cdest-Source-Address: 192.0.2.9 X-JTap-Cdest-Source-Port: 12321 X-Username: testuser X-MD-Intercept-Id: 55667789 Flags: STATIC DTCP/0.7 200 OK SEQ: 100 CRITERIA-ID: 1
Creating DTCP ENABLE Messages to Trigger Traffic Mirroring
This section shows 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.
ENABLE DTCP/0.8 Csource-ID: ft-user1 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: 203.0.113.224 FLAGS: BOTH X-JTAP-CDEST-DEST-ADDRESS: 192.0.2.168 X-JTAP-CDEST-DEST-PORT: 65535 X-JTAP-CDEST-SOURCE-ADDRESS: 198.51.100.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 CSOURCE-ADDRESS: 203.0.113.224 FLAGS: BOTH X-JTAP-CDEST-DEST-ADDRESS: 192.0.2.168 X-JTAP-CDEST-DEST-PORT: 65535 X-JTAP-CDEST-SOURCE-ADDRESS: 198.51.100.10 X-JTAP-CDEST-SOURCE-PORT: 50000 X-JTAP-CDEST-TTL: 64 X-INTERFACE-ID: demux0.30010001 /*subscriber interface*/ X-MD-INTERCEPT-ID: 0x0101010130010001 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 removed.
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