Dynamic Profiles for Subscriber Management

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 2 lists the default values, expressions, and unique identifiers supported by access profiles and service profiles.

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.

  Note:

  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.

  Note:

  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:

• Range validation

• 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.