Classifying Subscribers (SRC CLI)

Changes that you make to subscriber classification scripts do not affect subscriber sessions that are already established. One effect of this behavior is that static IP subscriber sessions are not closed if the classification script is changed in a way that would no longer cause the SAE to load a profile for certain subscribers.

On JunosE routers that use the COPS-PR or COPS XDR router drivers, you can create a subscriber session for the router interface to start services such as script services and aggregate services. The SAE creates the router interface, but does not install any policies on it. You can create a subscriber classification rule, but not an interface classification rule for this interface.

Use the following configuration statements to define subscriber classification scripts:

A classification script can contain either a target and a condition or a script. If you do not define a script, the classifier must have both a target and a condition.

To define subscriber classification scripts:

1. From configuration mode, enter the subscriber classifier configuration. In this sample procedure, the subscriber classifier is configured in the west-region SAE group.
   user@host# edit shared sae group west-region subscriber-classifier
2. Create a rule for the subscriber classifier. You can create multiple rules for the classifier.
   [edit shared sae group west-region subscriber-classifier]user@host# edit rule rule-2
3. Configure either a target or a script for the rule.
   • Configure the target for the rule. If you configure a target, see Subscriber Classification Targets.
     [edit shared sae group west-region subscriber-classifier rule rule-2]user@host# set target target

     If you configured a target for the rule, you must configure a match condition for the rule. You can create multiple conditions for the rule. See Subscriber Classification Conditions.

     [edit shared sae group west-region subscriber-classifier rule rule-2]user@host# edit condition name
   • Configure the script for the rule.
     [edit shared sae group west-region subscriber-classifier rule rule-2]user@host# edit script

     (Optional) You can specify a script target.

     [edit shared sae group west-region subscriber-classifier rule rule-2 script]user@host# set script-value

     (Optional) You can include a script that has already been created.

     [edit shared sae group west-region subscriber-classifier rule rule-2 script]user@host# set include include

     where include is a reference to an existing script that is included in the script you are configuring.

4. (Optional) Change the order of rules.
   [edit shared sae group west-region subscriber-classifier]user@host# insert rule rule-5 before rule-4
5. (Optional) Rename a rule.
   [edit shared sae group west-region subscriber-classifier]user@host# rename rule rule-5 to Retailer
6. (Optional) Verify the classifier rule configuration.

   [edit shared sae group west-region subscriber-classifier rule rule-2]
   user@host# show 
   target <-unauthenticatedUserDn->;
   condition {
     "loginType == \"ADDR\"";
     "loginType == \"AUTHADDR\"";
   }

7. (Optional) Verify the subscriber classifier configuration.

   [edit shared sae group west-region subscriber-classifier]
   user@host# show 
   rule rule-1 {
     script "# User Classification script
   #
   # The following attributes MAY be available for comparison.
   #  Attributes that are not available will have the value \"\" (empty string).
   #
   #   loginType: one of \"INTF\", \"AUTHINTF\", \"ADDR\", \"AUTHADDR\",
   #              \"PORTAL\", \"ASSIGNEDIP\"
   #   userName:  Everything before the \"@\" in the user's login name.
   #   domainName: Everything after the \"@\" in the user's login name.
   #   serviceBundle: A RADIUS VSA available if the login event involves
   #                  authentication with a properly configured RADIUS server.
   #   radiusClass: The RADIUS class of user's ERX interface.
   #   virtualRouterName: The name of the user's virtual router.
   #   interfaceName: The name of the user's ERX interface (e.g.
   #                  \"fastEthernet3/1.0\")
   #   ifAlias: The alias of the user's ERX interface, as configured on the ERX.
   #   ifDesc: The description of the user's ERX interface, as configured on
   #           the ERX.
   #   nasPortId: The user's ERX interface including Layer 2 access information
   #              (e.g. \"fastEthernet 3/1.0:3\")
   #   macAddress: The MAC address of the user, if he is a DHCP user.
   #   retailerDn: Generated by SSP for backwards compatibility; see below.
   #
   #  The loginType value available to this user classifier script will be
   #  one of the following:
   #
   #  \"INTF\":
   #  An INTF login is triggered every time an interface comes up and the
   #  interface classifier script determines that SAE should manage that
   #  interface, and the interface has not been authenticated by the router.
   #
   #  \"AUTHINTF\":
   #  An AUTHINTF login is triggered every time an authenticated
   #  interface comes up, for example as a result of an authenticated PPP
   #  session.
   #
   #  \"ADDR\":
   #  An ADDR login is triggered every time an `unauthenticated' IP
   #  address is handed out by the DHCP server in the ERX.
   #
   #  \"AUTHADDR\":
   #  An AUTHADDR login is triggered every time an `authenticated' IP
   #  address is handed out by the DHCP server in the ERX.
   #
   #  \"PORTAL\":
   #  A PORTAL login is triggered every time the portal API is invoked to
   #  login a user.
   #
   #  See the customer documentation for a description of the values
   #  for each login type available in the script.
   #       
   #  One of the values available during some types of logins is the
   #  `retailerDn'.  This is a generated value available for backwards
   #  compatibility with previous versions of SAE.  SAE generates this
   #  value as follows:
   #       
   #  The retailerDn value is generated by, first, determining an
   #  effective user domain name, and second, locating the retailer
   #  entry in LDAP that contains that effective domain name.  If no
   #  such retailer exists, the retailerDn value will be \"\".
   #
   #  The effective user domain name is the first of the following that yields
   #  a result:
   #       
   #  1. For PPP, PORTAL, and PUBLIC logins where a non-empty domainName
   #     is supplied, that non-empty domain name is used as the effective
   #     domain name.
   #
   #  2. For INTF logins, and for PPP, PORTAL, and PUBLIC logins where a
   #     non-empty domain name is not supplied, the effective domain name
   #     is the name of the user's virtual router, unless that effective
   #     domain does not exist in some retailer in LDAP.
   #
   #  3. If neither step 1 nor step 2 yields an effective domain name,
   #     \"default\" is used as the effective domain name.
   #          

   ";
   }
   rule rule-2 {
     target <-unauthenticatedUserDn->;
     condition {
       "loginType == \"ADDR\"";
       "loginType == \"AUTHADDR\"";
     }
   }
   rule rule-3 {
     target <-retailerDn->??sub?(uniqueID=<-userName->);
     condition {
       "retailerDn != \"\"";
       "& userName != \"\"";
     }
   }

Related Documentation

• Classifying Subscribers (C-Web Interface)
• Sending DHCP Options to the JunosE Router
• Example: Subscriber Classification Scripts for Static IP Subscriber
• Classification Scripts Overview
• Subscribers Overview