Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Understanding the Subscriber Profiles for Client Sessions per PTSP Partition

    Subscriber profiles for service activation enables you to specify which service plug-ins become activated on a per-subscriber basis. Previously, the only control mechanism for specifying service activation was to attach a service-set configuration to a selected interface or route. The new utility allows you to enable or disable services based on the subscriber associated with every data flow. As a result, you can apply differentiated services to different sets of subscribers. You can exercise the control mechanism in one of two ways: by using a CLI operational command or a RADIUS attribute.

    Note: This feature applies only to MP-SDK services and does not depend on the specific services enabled or disabled, except that PTSP must be included in the chain.

    The procedure consists of three steps:

    1. Configure a service set that includes all the services to be applied to flows. You can include a default subscriber profile that controls which services are and are not active by default. The default profile applies to all subscribers until overridden for a specific subscriber. In the absence of a default subscriber profile, all services specified in the service set are applied by default. You can also include one or more alternative subscriber profiles that can be implemented to override the default profile. The following sample configuration illustrates these components:
      services {service-set ss1 {application-identification-profile appidr1;idp-profile idpr1;aacl-rules aaclr1;hcm_rules hcmr1;sfw_rules sfwr1;subscriber-profile {sp1;}interface-service {service-interface ms-3/0/0.0;}}}subscriber-profile sp1 {disable HCM;enable IDP {concurrent-data-sessions 10;}disable AACL;max-data-sessions-per-subscriber {limit 10;exceed-action [ syslog drop ];}}subscriber-profile sp2 {enable HCM;disable IDP;enable AACL,max-data-sessions-per-subscriber {limit 100;exceed-action [ syslog ];}}

      Initially, all traffic reaching the service plane under service set ss1 receives all the services configured in service set ss1 that are enabled by the default subscriber profile sp1 applied to it. In the example, APPID, stateful firewall, and IDP are enabled, whereas HCM and AACL are disabled. However IDP is enabled for only at most 10 sessions concurrently. Beyond that threshold, IDP is also disabled. Also, because of the max-data-sessions-per-subscriber setting, any subscriber is allowed a maximum of ten concurrent data sessions. Beyond that threshold, data sessions are logged and dropped.

    2. There are two ways to dynamically override the default subscriber profile associated with a particular PTSP subscriber:
      • CLI operational command
      • RADIUS attribute or VSA in an access-accept message.

      From the previous example, assume that the subscriber profile for subscriber X is dynamically set to sp2. After that, any new data session associated with subscriber X has a different set of services applied to it. In the example, it would be APPID, stateful firewall, HCM, and AACL. Also, because the max-data-sessions-per-subscriber setting changes to 100, subscriber X now has no upper limit on the number of concurrent data sessions, although if that number crosses the 100 threshold, the threshold-crossing event is logged.

      The following examples illustrate the dynamic override settings:

      Operational command

      user@router>request services subscriber clear subscriber-profile client-id client-iduser@router>request services subscriber set subscriber-profile subscriber-profile-name client-id client-id

      RADIUS configuration

      user@router# set system services packet-triggered-subscribers partition-radius foo subscriber-service-profile attribute-26.4874.31
    3. Processing of a new data session at the service plane takes place as follows, with respect to subscriber profiles:
      1. A new flow starts. MP-SDK sends a SESSION-INTEREST event to the service plug-ins. The first plug-in in the chain is the subscribers (PTSP) plug-in.
      2. The subscribers plug-in matches the flow to its subscriber by searching its database. It sets the subscriber ID in the session metadata.
      3. The subscriber plug-in checks for the corresponding subscriber profile and which services are enabled. It then sets the services mask of enabled and disabled services in the session metadata.
      4. MP-SDK or JSF invokes only the services that are enabled per the services mask. The other services are skipped, even if configured in the service set.

      Note: : Subscriber-profile changes affect only the upcoming flows. Existing flows remain unaffected.

    Modified: 2015-02-05