Dynamic Profiles for Subscriber Management
Dynamic Profiles Overview
A dynamic profile is a set of characteristics that acts as a kind of template that enables you to create, update, or remove a configuration that you can use to provide dynamic subscriber access and services for broadband applications. Using these profiles enables you to consolidate all of the common attributes of a client or a group of clients and apply the attributes or dynamically created objects simultaneously. After profiles are created, they reside on the router in a profile library.
You can manage subscribers dynamically with two kinds of dynamic profiles: client profiles and service profiles. Both profile types are configured at the [edit dynamic-profiles] hierarchy level and are independent of each other. Whether you use dynamic service profiles in addition to your dynamic client profiles depends on how you support differentiation among subscribers and how you package your subscriber services.
Dynamic profile terminology is potentially confusing.
A dynamic client profile can also correctly be referred to as a dynamic subscriber profile.
Although dynamic client profiles are sometimes referred to as client access profiles, that term causes confusion with the access profiles configured at the [edit access profile profile-name] hierarchy level. Access profiles are used to configure authentication, accounting, and authorization parameters for subscriber access, some session attributes, and client-specific properties for L2TP and PPP sessions. Access profiles are applied at various configuration levels with the access-profile statement.
Dynamic Client Profiles and Dynamic Service Profiles
The major differences between dynamic client and dynamic service profiles are the following:
A dynamic client profile is provisioned and applied to the client application configuration; for example, DHCP, DHCPv6, L2TP LNS, PPPoE, static subscribers, and VLANs. The contents of the profile are applied to the logical interface for the subscriber session. Most often, dynamic client profiles enable the dynamic instantiation of logical interfaces to which the profile is applied, but client profiles can also be applied to static subscriber logical interfaces.
A dynamic client profile can include any of the stanzas under [edit dynamic-profiles profile-name], except for variables variable-name.
Dynamic service profiles include only service-related configurations, which are a subset of the configurations available in dynamic client profiles. They do not include other configuration attributes for a subscriber session. You cannot use a service profile to create or modify a logical interface. A dynamic service profile functions as a supplement to dynamic client profiles that is used after the creation of logical interfaces.
A dynamic service profile can include the following stanzas under [edit dynamic-profiles profile-name]: class-of-service, firewall, protocols, services, and variables.
Dynamic client profiles and dynamic service profiles also differ in the types of variables they can use:
Dynamic client profiles can include predefined-variable-defaults, which define default values for Juniper Networks predefined variables that are included in the profile. The default values in the profile are used when RADIUS does not return a value for the variable. See Dynamic Variables Overview and Configuring Default Values for Predefined Variables in a Dynamic Profile for information about predefined variables.
Dynamic service profiles can include user-defined variables that act like parameters in a function call. The variable values can be provided by the RADIUS server to support more specialized customization per subscriber. You can also set default values for these variables to be used when RADIUS does not provide the value. See User-Defined Variables in Dynamic Profiles for information about user-defined variables.
Dynamic client profiles do not include user-defined variables. Dynamic service profiles do not include predefined-variable-defaults.
Table 1 lists the types of variables supported by access profiles and service profiles.
Table 1: Types of Variables Supported in Dynamic Profiles
Type of Dynamic Profile
Junos OS Predefined Variable (Local)
Junos OS Predefined Variable (RADIUS)
Table 2 lists the default values, expressions, and unique identifiers supported by access profiles and service profiles.
Table 2: Default Values and Expressions Supported in Dynamic Profiles
Type of Dynamic Profile
Yes (RADIUS predefined variables only)
Yes (Schedulers and Scheduler maps only)
Yes (User-defined variables only)
Yes (Service activation only)
Yes (Firewall filters only)
Dynamically Applying Services to Subscriber Sessions
You can configure services to be applied to subscriber sessions in several ways:
Include service configurations for the subscriber session in a dynamic client profile. For example, you can configure Layer 2 services such as Class of Service (CoS) and Layer 3 services such as dynamic firewall filters. Layer 3 services are applied for the negotiated address family for DHCP, DHCPv6, and PPPoE subscribers. See Changing CoS Services Overview.
A dynamic client profile cannot reference a dynamic service profile. It can only directly include service configurations.
Apply a dynamic service profile using your RADIUS configuration. The Juniper Networks Activate-Service VSA (26-65), returned in the RADIUS Access-Accept message when the subscriber authenticates, can reference a dynamic service profile and optionally pass additional parameters for the service. For DHCP and PPPoE sessions, this service profile is applied when the session’s address family is activated. See Dynamic Service Management with RADIUS.
You can use another Juniper Networks VSA, Deactivate-Service (26-66), to deactivate services in the Access Accept message.
Apply a service profile with a Juniper Networks VSA in a RADIUS Change of Authorization (CoA) message. You can use a CoA message to activate (VSA 26-65) or deactivate (VSA 26-66) services. For example, a subscriber may opt in or out of a service after the session is established. See RADIUS-Initiated Change of Authorization (CoA) Overview.
Apply a dynamic service profile by including the service-profile statement to reference the profile in the configurations for DHCP local server, DHCP relay agent, L2TP, or static subscribers. For example, see Specifying the Static Subscriber Group Service Profile, Configuring an L2TP Tunnel Group for LNS Sessions with Inline Services Interfaces, and Configuring an L2TP Access Profile on the LNS.
Dynamic Profile Overrides
Starting in Junos OS Release 14.1, you can specify a different dynamic profile in the RADIUS Client-Profile-Name VSA [26-174] to have RADIUS override a configured client dynamic profile. RADIUS returns this VSA to AAA with other client session attributes in the Access-Accept message. AAA subsequently overrides the corresponding profile name attribute in the session database entry for the client, and this new profile is instantiated instead of the originally configured profile.
Dynamic Profile Version Creation
You can create new versions of dynamic profiles that are currently in use by subscribers. Dynamic profile version creation is enabled at the [edit system] hierarchy level. When enabled, you can create multiple versions of any dynamic profiles on the router. Any subscriber that logs in following a dynamic profile modification uses the latest version of the dynamic profile. Subscribers that are already active continue to use the older version of the dynamic profile until they log out or their session terminates.
When creating versions of dynamic profiles, keep the following in mind:
You must enable or disable dynamic profile version creation before creating or using any dynamic profiles on the router. Enabling or disabling dynamic profile version creation after dynamic profiles are configured is not supported.
Before you can enable or disable dynamic profile version creation for a router on which any dynamic profiles are configured, you must first remove all dynamic profiles from the router configuration.
Each version of a dynamic profile is stored in the profile database as a new profile.
The name of the new profile version is derived by appending a string to the original base dynamic profile name. This string contains two dollar sign ($) characters to identify the version field of the profile name. These two characters are followed by numerical characters that represent the “version number” of the dynamic profile (for example, 01).
The version number of the dynamic profile is automatically generated by the system.
The dynamic profile that you modify is always stored as the latest version. You cannot create a modified dynamic profile and save it as an earlier version. For example, if you modify version three of a dynamic profile while it is in use, the dynamic profile is saved as version four.
You can only modify the latest version of a dynamic profile.
The maximum value for the version number is 99999. However, for each profile, only 10 active versions are supported at a time.
If the dynamic profile version that you modify is not in use by any subscriber, the profile is overwritten with committed changes without creating a new version.
After reaching the 99999th modified version of a dynamic profile, any further modifications to the dynamic profile result in overwriting that final version. If the final version is in use, any modification attempts fail upon commit.
You can delete a dynamic profile only when none of its versions are in use.
The dynamic profile version feature supports graceful restart and unified ISSU.
Dynamic Profile Semantic Checking
Variables are applied to dynamic profiles dynamically and cannot be checked with existing CLI commands. Semantic checking validates some variables in dynamic profiles to help identify potential configuration errors.
Semantic checks are performed during commit and during profile instantiation. Commit time checks ensure that variables appear in the correct location within the dynamic profile. Checks performed before profile instantiation ensure that the values that replace the variables are correct. The checks performed on the values include the following:
Variable type validation
Existence of variables where they are mandatory
Variable matching to regular expressions
A commit time check failure results in an error message being displayed and logged in the /var/log/messages file and the commit failing. An instantiation failure results in an error being logged in the /var/log/messages file and the profile instantiation failing.
Configuring a Basic Dynamic Profile
This topic describes how to create a basic dynamic profile. 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.
Before you configure dynamic profiles for initial client access:
- Configure the necessary router interfaces that you want
DHCP clients to use when accessing the network.
See DHCP Subscriber Interface Overview for information about the types of interfaces you can use with dynamic profiles and how to configure them.
- Configure all RADIUS values that you want the profiles to use when validating DHCP clients for access to the multicast network.
To configure a basic dynamic profile:
- Name the profile.user@host# edit dynamic-profiles basic-profile
- Define the interface-name 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# edit interfaces $junos-interface-ifd-name
- Define the unit statement with the internal
[edit dynamic-profiles basic-profile interfaces "$junos-interface-ifd-name"]user@host# set unit $junos-underlying-interface-unit
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.
or[edit dynamic-profiles basic-profile interfaces "$junos-interface-ifd-name"]user@host# set unit $junos-interface-unit