- 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 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
HTTP Redirect Service 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 on an external device. The captive portal is often the initial page a subscriber sees after logging in to a subscriber session. The captive portal also receives and manages HTTP requests to unauthorized Web resources.
For example, the user might be redirected to a webpage that shows a company logo and network usage policy or to a page where the subscriber pays for services. The captive portal typically provides authentication and authorization services for redirected subscribers before granting access to protected servers outside of a walled garden.
A walled garden, also known as an allowlist, defines a group of servers where access is provided to subscribers without reauthorization through a captive portal. These walled gardens enable you to increase revenue by marketing various services to your customers.
Typical walled garden links are:
Vendor services, such as automobile rentals
Hotel and motel loyalty or corporate program portals
Room services
Local attractions and weather
This documentation uses the terms HTTP redirect service and captive portal content delivery (CPCD) service interchangeably.
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 cpcdd 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 response with a preconfigured redirect URL. The response message includes an HTTP status code. Starting in Junos OS Release 17.3R1, the status code that is returned depends on the HTTP version used by the HTTP client that sent the GET request. When the version is higher than HTTP 1.0, the redirect server returns the 307 (Temporary Redirect) status code. When the version is HTTP 1.0, the 302 (Found) status code is returned. In releases earlier than 17.3R1, the redirect server returns the 302 status code regardless of HTTP version. Both codes inform the HTTP client to use the original URL, rather than the redirect URL, for subsequent GET requests.
When the response to the HTTP request is sent to the subscriber, the original URL is preserved by optionally appending it to the end of the configured redirect URL. The maximum length of the redirect URL, including the appended original URL, is 128 bytes. Starting in Junos Release 17.3R1, the maximum length of the redirect URL is increased to 1360 bytes and the redirect server can append additional information about the subscriber to the redirect URL. The maximum length applies regardless of whether subscriber information is appended to the URL. To append the subscriber information, you can specify certain subscriber attributes in the VSAs returned in the RADIUS Accept-Access message in response to the subscriber login or in a RADIUS Change of Authorization (CoA) message. This applies for both Activate-Service (26-65) and Deactivate-Service (26-66) VSAs. The subscriber information is retrieved from the subscriber session database.
The control handler maintains a connection with the cpcdd process on the Routing Engine to learn configuration changes, such as the redirect URL and the rewrite IP destination and port. To achieve faster performance, the control handler maintains a cache of relevant configured entities, such as URLs, on a Modular Port Concentrator (MPC).
HTTP redirect services are supported for both IPv4 and IPv6. You can attach an HTTP redirect service or service set to either a static or dynamic interface. For dynamic subscriber management, you can attach HTTP services or service sets dynamically at subscriber login or by using a RADIUS change of authorization (CoA).
Starting in Junos OS Release 17.2R1, there are three methods to configure HTTP redirect services. Starting in Junos OS Release 19.3R2, HTTP redirect can also be configured on the MX-SPC3 services processing card if Next Gen Services are enabled. Table 1 lists the methods supported for HTTP redirect services and the Junos OS releases that support each method.
We recommend that you use Junos OS Release 15.1 and higher releases to implement HTTP redirect services.
Method | Junos OS Releases Supported | |
---|---|---|
MS-DPC-based | (Not supported for Next Gen Services on the MX-SPC3 services card) | |
Static | Releases earlier than 15.1 | |
Converged | Not supported | |
MS-MPC-based | (Not supported for Next Gen Services on the MX-SPC3 services card.) | |
Static | Starting in Junos OS Release 15.1 | |
Converged | Starting in Junos OS Release 17.2 | |
MX-SPC3-based | ||
Static | Starting in Junos OS Release 19.3R2 if Next Gen Services are enabled on the MX-SPC3 services card. | |
Converged | Starting in Junos OS Release 19.3R2 if Next Gen Services are enabled on the MX-SPC3 services card. | |
Routing Engine-based | ||
Static | All Junos OS releases | |
Converged | Starting in Junos OS Release 16.1R4 and 17.2 |
For all methods, you configure the walled garden as a static firewall service filter.
Services-Card-Based Captive Portal
- MS-MPC–Based Captive Portal
- MX-SPC3 Services Card-Based Captive Portal
- Walled Garden Configured as a Service Filter
MS-MPC–Based Captive Portal
Starting in Junos OS Release 15.1R4, the only line card and interface card combination that supports HTTP redirect services on MX Series routers is the Multiservices Modular Port Concentrator (MS-MPC) with a Multiservices Modular Interface Card (MS-MIC). This combination provides improved scaling and high performance. MS-MICs and MS-MPCs have enhanced memory (16 GB for MS-MIC, 32 GB per NPU of MS-MPC) and processing capabilities. The services interfaces on MS-MPCs and MS-MICs are identified in the configuration with an ms- prefix (for example, ms-1/2/1).
Throughout this documentation, the term MS-MPC–based refers to MPCs with MS-MICs installed and to MS-MICs alone when they are installed in MX Series routers that do not accept line cards.
MX-SPC3 Services Card-Based Captive Portal
Starting in Junos OS Release 19.3R2, you can configure HTTP redirect services if Next Gen Services are enabled on the MX-SPC3 services card. The services interfaces on MX-SPC3s are identified in the configuration with a vms- prefix (for example, vms-1/2/1).
Walled Garden Configured as a Service Filter
Packet flow for a services-card-based captive portal differs depending on how you configure the walled garden. HTTP traffic destined to servers within the walled garden does not flow to the services card. However, any HTTP traffic destined outside of the walled garden flows to the services card.
For subscriber requests contained within the first packet of data traffic, the system expects TCP proxy to generate a TCP SYN flag causing the data handler to perform a rule lookup and apply those rules to HTTP data flows.
For an HTTP rewrite condition—If the IP destination address is not provided in the policy, the control handler looks up the IP destination address.
For an HTTP redirect condition—TCP proxy is triggered to complete its three-way handshake.
For HTTP request packets.
For an HTTP rewrite condition—The control handler uses the cached IP destination address and modifies the data packet.
For an HTTP redirect condition—The control handler sends an HTTP 302 or 307 response with a preconfigured redirect URL.
Routing Engine-Based Captive Portal
The Routing Engine-based captive portal supports a walled garden as a firewall service filter for both static and converged services. As soon as the HTTP traffic matches the rules defined in the firewall service filter, the HTTP traffic is sent to the Routing Engine. The services interfaces on the Routing Engine are identified with an si- prefix (for example, si-1/1/0). The si- interface handles all redirect and rewrite traffic and services for the Routing Engine. The si- interface must be operational with a status of up to enable and activate the captive portal content delivery (CPCD) service. After the CPCD service is enabled, any change in the operational state of the si- interface does not affect existing CPCD services.
Converged Service Provisioning for HTTP Redirect Services
Starting in Junos OS Release 17.2R1, converged service provisioning is supported for both Routing Engine-Based and MS-MPC/MS-MIC–based captive portals. Starting in Junos OS Release 19.3R2, converged service provisioning is also supported for MX-SPC3 services card–based captive portals if Next Gen Services are enabled on the MX-SPC3 services card. Converged service provisioning means you can configure service provisioning in a dynamic profile. You can specify user-defined variables for services that are populated by means of a RADIUS VSA or a Change of Authorization (CoA) message.
For example, you might want to have a different redirect URL for each subscriber. You can create a redirect-url variable in the dynamic profile, then configure a service rule to redirect the matching subscriber to $redirect-url. When RADIUS authenticates the user, the Activate-Service VSA (26–65) provides the URL specific to that user.
Static Service Provisioning for HTTP Redirect Services
Starting in Junos OS
Release 17.4R1, static service provisioning is supported for both
Routing Engine-Based and MS-MPC/MS-MIC–based captive portals. Starting in Junos OS Release 19.3R2, static service
provisioning is also supported for MX-SPC3–based captive portals
if Next Gen Services are enabled on the MX-SPC3 services card. Static service provisioning means you can configure service provisioning
in a static profile. You can specify user-defined variables (for example, http://portal.wifi.example.com/xx?wlanuseraddr=%subsc-ip%&nasaddr=%nas-ip%&acname=%ac
-name%&url=%dest-url%&userlocation=%nas-port-id%&usermac=%mac-sa%&
session-id=%sess-id%&username=%user-name%&wlanuseraddrv6=%subsc-ipv6%
) for services that are populated by means of a RADIUS VSA or
a Change of Authorization (CoA) message.
In static CPCD, attributes in a redirect URL are not sent in the Juniper Networks VSAs, Activate-Service (26-65) and Deactivate-Service (26-66). You can configure it as shown in the following example:
captive-portal-content-delivery { rule redirect { match-direction input; term t1 { then { redirect url; } } } }
The tokens in the url such as “subsc-ip”, “nas-ip”, “ac-name” must be specified between “%” symbol. The order of tokens does not matter.
Following is a list of token with their significance:
%subsc-ip%—private IP address of the subscriber.
%nas-ip%—BNG IP address.
%ac-name%—It will be empty for the BNG.
%dest-url%—The original request url.
%nas-port-id%—Used for subscriber. This parameter must include interface name, pvlan and cvlan. The interface name could be physical or virtual interface name. For example, ge0/0/0 or ae0. The pvlan and cvlan range is 14095
%mac-sa%—WLAN client MAC address.
%sess-id%—session-id of subscriber.
%user-name%—username of a subscriber.
%subsc-ipv6%—subscriber IPv6 address (only IANA address). If IANA address is not specified for the subscriber, this field will be empty.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.