Table Of Contents
SSG Logon and Logoff
Single Host Logon
Prerequisites for Single Host Logon
SSG Autologoff
Restrictions for SSG Autologoff
Configuration of SSG Autologoff
Configuration Example for SSG Autologoff
SSG Prepaid Idle Timeout
Service Authorization
Service Reauthorization
Restrictions for SSG Prepaid Idle Timeout
Prerequisites for SSG Prepaid Idle Timeout
Configuration of SSG Prepaid Idle Timeout
Configuration Example for SSG Prepaid Idle Timeout
SSG Session and Idle Timeout
SSG Logon and Logoff
The Cisco 10000 series router supports the following SSG features for logon and logoff related functions:
•
Single Host Logon
•
SSG Autologoff
•
SSG Prepaid Idle Timeout
•
SSG Session and Idle Timeout
This chapter describes each of SSG logon and logoff features.
Single Host Logon
The Single Host Logon feature enables users to enter authentication information only twice. To log on to a service through the SESM web application, a subscriber enters authentication information once for the PPP session and once for the service. The subscriber does not have to log on to the SESM. Instead, the SESM uses the PPP authenticated information from the SSG.
For non-PPP users, when a subscriber authenticates using the SESM application, the subscriber does not have to log on again for the remainder of the non-PPP session. However, the subscriber still has to log on to services. For more information, refer to Cisco Subscriber Edge Services Manager and Subscriber Policy Engine Installation and Configuration Guide.
Prerequisites for Single Host Logon
To use the Single Host Logon feature, you must install and configure Cisco SESM Release 3.1(1) or later.
SSG Autologoff
The SSG Autologoff feature enables SSG to verify connectivity with each host. SSG checks the status of the connection with each host at configured intervals. If SSG finds that a host is not reachable, SSG automatically initiates the logoff of that host. SSG has two methods of checking the connectivity of hosts: ARP ping and ICMP ping.
ARP ping
When autologoff is configured to use ARP ping, SSG periodically checks the ARP cache tables. If a table entry for a host is found, SSG forces ARP to refresh the entry and checks the entry again after a configured interval. If a table entry is not found, SSG initiates autologoff for the host. However, if any data traffic to or from the host occurred during the interval, SSG does not ping the host because the reachability of the host during that interval was established by the data traffic. ARP ping works in deployment scenarios in which all hosts are directly connected to the SSG through a broadcast interface such as an Ethernet interface or through a bridged interface such as an RBE interface.
ICMP ping
When SSG autologoff is configured to use ICMP ping, SSG pings the host to check connectivity until an ICMP response is obtained or the allowable number of tries is used up. If all the tries are used up and the ping was unsuccessful, then SSG initiates logoff for that host. SSG uses ICMP ping one time at each configured interval. If data traffic to or from the host is found during the interval, SSG does not ping the host because reachability was established by the data traffic. ICMP ping works in all types of deployment scenarios and supports overlapping IP users.
Restrictions for SSG Autologoff
The SSG Autologoff feature has the following restrictions:
•
Use only one method of SSG autologoff at a time: ARP ping or ICMP ping.
•
Use ARP ping only in deployment scenarios in which all hosts are directly connected to the SSG through a broadcast interface such as an Ethernet interface or through a bridged interface such as an RBE interface. ICMP ping works in all types of deployment scenarios.
•
ARP ping works only on hosts that have a MAC address.
•
ARP ping does not support overlapping IP addresses.
•
SSG autologoff that uses ARP ping does not work for hosts with static ARP entries.
•
If you configure both the idle timers and ICMP-based autologoff, you must set the autologoff interval to a value that is at least twice as long as the idle timeout interval. Otherwise, the ICMP messages reset the idle timer and the user is only logged out if the user does not respond to the ICMP ping.
Configuration of SSG Autologoff
To configure the SSG Autologoff feature, use the ssg auto-logoff command in global configuration mode. For more information, refer to the SSG Autologoff, Release 12.2(4)B feature module.
Configuration Example for SSG Autologoff
Example 3-1 shows how to enable autologoff with ARP ping.
Example 3-1 SSG Autologoff Using ARP Ping
ssg auto-logoff arp interval 60
Example 3-2 shows how to enable autologoff with ICMP ping.
Example 3-2 SSG Autologoff Using ICMP Ping
ssg auto-logoff icmp interval 60 packet 2 timeout 500
SSG Prepaid Idle Timeout
The SSG Prepaid Idle Timeout feature enhances the SSG and the SSG Prepaid feature by doing the following:
•
Enables SSG to return residual quotas (allotments of prepaid credit) to the billing server from services that a user is logged into but not actively using. The quota that is returned to the billing center can be applied to the quota for the services the user is actively using.
•
Enables a user's connection to services to be open even when the billing server returns a zero quota. The connection's status depends on the combination of the quota and the idle timeout value returned. Depending on the connection service, SSG requests the quota for a connection from the billing server at the following times:
–
After the user starts using a particular service
–
When the user runs out of quota
–
After the configured idle timeout value expires
•
Enables SSG to reauthorize a user before the user completely consumes the allocated quota. You can also configure SSG to not pass traffic during reauthorization, thus preventing revenue leaks in the event the billing server returns a zero quota for the user.
•
Enhances the handling of a returned zero quota from the billing server. If the billing server returns a zero quota and a nonzero idle timeout, the user has run out of credit for a service. When a user runs out of credit, the user is redirected to the billing server to replenish the quota. When the user is redirected to the billing server, the user's connection to the original service or services remains up, but any traffic passing through the connection is dropped. This enables the user to replenish the quota on the billing server without losing connections to services or having to perform additional service logons.
•
Enables SSG to notify the billing server when a connection fails. This enables the billing server to free quota that was reserved for the failed connection and to apply the quota immediately to some other active connection.
Without the SSG Prepaid Idle Timeout feature, traffic passed during reauthorization represents a revenue leak if the billing server returns a zero quota for the user. A configurable threshold value is used to prevent this. This value causes SSG to reauthorize a user's connection before the user completely consumes the allocated quota for a service.
Service Authorization
SSG sends a service authorization request to the billing server upon initial service authorization. Explicit service authorization is required whenever a user attempts to connect to a prepaid service to ensure that the user has sufficient credit to connect to that service. The billing server responds with the available quota (allotment of prepaid credit) to SSG. If the returned available quota is greater than zero or not present, SSG allows the user to connect to the service and begins metering based on the allotted quota. For this authorization, an Access-Request is generated once the service is identified as a prepaid service. The Access-Request is generated for service authorization regardless of the service type (for example, virtual private dial-up network (VPDN), passthrough, proxy, or tunnel).
The billing server responds to the service authorization Access-Request with an Access-Accept that defines the quota parameters for the connection. Authorization for a service is provided based on the presence and content of the Quota (Attribute 26) and the Idle Timeout (Attribute 28) vendor-specific attributes (VSAs) in the Access-Accept.
Service Reauthorization
SSG sends a service reauthorization request to the billing server at the following times:
•
When a prepaid user's quota is consumed
•
After the configured idle timeout expires
•
When the user's remaining quota reaches the configured threshold value
The SSG Prepaid Idle Timeout feature enables you to configure how traffic is handled during reauthorization. By default, traffic continues during reauthorization. If the billing server returns a zero quota in the reauthorization response, SSG disconnects the connection but the data that was in progress during the reauthorization goes through and is not accounted. You can configure SSG to either drop or forward traffic during reauthorization. You can also configure a threshold value, which configures SSG to reauthorize a connection with the billing server before a prepaid user's allocated quota is completely consumed.
By configuring the ssg prepaid reauthorization drop-packet command, SSG drops the traffic on a connection during reauthorization and the time used during the reauthorization is not accounted to that connection. SSG deducts the reauthorization times from the total session duration time and sends the Account Session Time (Attribute 46) in the Accounting Stop and Update packets.
If the billing server responds with a time-based connection to redirect the traffic, then SSG redirects TCP traffic. The time of the TCP redirection is also not accounted to the user's connection.
The reauthorization request for SSG Prepaid Idle Timeout is similar to the reauthorization request for SSG Prepaid. However, the SSG Prepaid Idle Timeout reauthorization request contains an additional attribute: Reauthorization Reason. If the Reauthorization Reason attribute is not present, the billing server assumes that the reason for the reauthorization request is Primary Quota Consumed. The values of the Reauthorization Reason attribute are the following:
•
Quota Consumed (QR0)
•
Idle Timer Expired (QR1)
For more information, refer to the SSG Prepaid Idle Timeout, Release 12.2(15)B feature module.
Restrictions for SSG Prepaid Idle Timeout
The SSG Prepaid Idle Timeout feature has the following restrictions:
•
The Cisco 10000 router supports only time-based SSG Prepaid for a service connection. Quotas are measured in seconds. You cannot change the unit of measure.
•
The Cisco 10000 router does not support returning a quota when the connection is idle.
•
After a user runs out of quota and then replenishes the quota at the billing server, SSG receives the updated quota and resumes the connection only after the next reauthorization.
Prerequisites for SSG Prepaid Idle Timeout
The SSG Prepaid Idle Timeout feature requires the following:
•
You must enable SSG accounting before you can use the SSG Prepaid feature. SSG accounting is enabled by default. If it has been disabled, reenable it by using the ssg accounting command in global configuration mode.
•
The SSG Prepaid feature requires the AAA server to support prepaid billing.
•
You must configure the SSG to send Attribute 55 in accounting requests.
Configuration of SSG Prepaid Idle Timeout
To configure the SSG Prepaid Idle Timeout feature, configure the SSG Prepaid and SSG TCP Redirect features. For more information, refer to the SSG Prepaid, Release 12.2(4)B feature module and the SSG TCP Redirect for Services, Release 12.2(4)B feature module.
Configuration Example for SSG Prepaid Idle Timeout
Example 3-3 shows how to configure the SSG Prepaid feature to provide the prepaid billing server with session ID and time-stamp information.
Example 3-3 SSG Prepaid Service
radius-server attribute 44 include-in-access-req
radius-server attribute 55 include-in-acct-req
Example 3-4 shows how to configure the SSG TCP Redirect feature. The commands configure a captive portal group called "DefaultRedirectGroup," add two servers to "DefaultRedirectGroup," and redirect prepaid users to the newly created captive portal.
Example 3-4 SSG TCP Redirect
server-group DefaultRedirectGroup
redirect prepaid-user to DefaultRedirectGroup
Example 3-5 shows how to configure the SSG TCP Redirect feature for a specific service. The commands redirect all prepaid service traffic to the captive portal group called "InternetRedirectGroup" and configure the captive portal group as the server group used for redirecting prepaid traffic.
Example 3-5 SSG Service-Specific TCP Redirect
server-group InternetRedirectGroup
The service profile for InternetRedirectGroup is shown here:
(Optional) You can configure SSG to reauthorize a prepaid user's connection before the user has completely consumed the allotted quota for a service. To do this, enter the global-configuration commands shown below to configure a time-based or a volume-based threshold value. Example 3-6 shows how to configure a threshold time value of 10 seconds. Example 3-7 shows how to configure threshold volume value of 2000 bytes.
Example 3-6 SSG Threshold Time
ssg prepaid threshold time 10
Example 3-7 SSG Threshold Volume
ssg prepaid threshold volume 2000
SSG Session and Idle Timeout
In a dial-up networking or bridged (non-PPP) network environment, a user can disconnect from the network access server (NAS) and release the IP address without logging out from the SSG. When this happens, the SSG continues to allow traffic to pass from that IP address, which can create a problem if the another user obtains the same IP address. SSG provides two mechanisms to prevent this problem from occurring:
•
Session-Timeout RADIUS attribute—Specifies the maximum length of time for which a host or connection object can remain continuously active.
•
Idle-Timeout RADIUS attribute—Specifies the maximum length of time for which a session or connection can remain idle before it is disconnected.
The Session-Timeout and Idle-Timeout attributes are used in either a user or service profile. In a user profile, the attribute applies to the user session. In a service profile, the attribute applies individually to each service connection.