Cisco 10000 Series Internet Router Service Selection Gateway Configuration Guide - Service Connection [Cisco 10000 Series Routers]

Table Of Contents

Service Connection

SSG AutoDomain

Restrictions for SSG AutoDomain

Configuration of SSG AutoDomain

Configuration Example for SSG AutoDomain

SSG Prepaid

Restrictions for SSG Prepaid

Configuration of SSG Prepaid

Configuration Example for SSG Prepaid

SSG Open Garden

Restrictions for SSG Open Garden

Configuration of SSG Open Garden

Configuration Example for SSG Open Garden

SSG Port-Bundle Host Key

Restrictions for SSG Port-Bundle Host Key

Prerequisites for SSG Port-Bundle Host Key

Configuration of SSG Port-Bundle Host Key

Exclude Networks

Mutually Exclusive Service Selection

Configuration of Mutually Exclusive Service Selection

Configuration Example for Mutually Exclusive Service Selection

Service Connection

The Cisco 10000 series router supports the following SSG features for service connection:

•SSG AutoDomain

•SSG Prepaid

•SSG Open Garden

•SSG Port-Bundle Host Key

•Exclude Networks

•Mutually Exclusive Service Selection

This chapter describes the SSG features for service connection.

SSG AutoDomain

The SSG AutoDomain feature allows users to automatically connect to a service based on the domain part of the structured username specified in an Access-Request. When SSG AutoDomain is configured, user authentication is performed at the service (for example, at the AAA server within a corporate network), instead of at the network access server (NAS).

The domain portion of the structured username is the portion after the @ in the username. For example, the domain in the username "abc@cisco.com" is "cisco.com". Users can bypass the Service Selection Dashboard (SSD) and access a service, such as a corporate intranet. SSG AutoDomain on the Cisco 10000 router supports login operations from the Subscriber Edge Services Manager (SESM) application.

AutoDomain uses a heuristic to determine the service into which the user is logged. The host object is not activated until successfully authenticated with the service. If the autoservice connection fails for any reason, the user login is rejected.

The AutoDomain service first checks for a structured username. If AutoDomain is enabled and the received Access-Request specifies a structured username, the username is used for AutoDomain selection. If the Access-Request does not specify a username or the specified username is a member of the domain name exclusion list, then no AutoDomain is selected and normal SSG user login proceeds. You can define the domain name exclusion list by using the exclude command in SSG-auto-domain configuration mode.

When you enable AutoDomain, an AutoDomain profile is downloaded from the local AAA server. This profile specifies an outbound service and the password is the globally configured service password.

You can configure SSG AutoDomain in basic or extended mode. In basic mode, the AutoDomain profile downloaded from the AAA server is a service profile. This service profile is a proxy or VPDN service. If the AutoDomain service profile is a proxy service, SSG authenticates the user to the appropriate domain AAA server with the authentication information found in the Access-Request received from the RADIUS client. If the downloaded AutoDomain service profile is a tunnel service, a PPP session is regenerated into an L2TP tunnel for the selected service. If the returned SSG-specific attributes do not indicate the type of service required, SSG treats this service as a VPDN service.

In extended AutoDomain mode, the downloaded profile is a "virtual user" profile that contains one autoservice to an authenticated service such as a proxy or VPDN. The host object is not activated until the user is authenticated at the proxy or VPDN service. If the "virtual user" profile does not have exactly one autoservice or the autoservice is not authenticated, the AutoDomain login is rejected.

If you configure basic SSG AutoDomain with a nonauthenticated service type (for example, passthrough), SSG rejects the login request because AutoDomain bypasses user authentication at the local AAA server and requires that authentication be performed elsewhere.

For more information, refer to the SSG AutoDomain, Release 12.2(4)B feature module.

Restrictions for SSG AutoDomain

SSG AutoDomain has the following restrictions:

•Restricted DHCP support—DHCP requests for IP address assignment must be done before RADIUS negotiation.

•Passthrough services—Because local authentication at the network access server (NAS) is bypassed, AutoDomain is available only for services that perform authentication (for example, proxy or VPDN services).

•"Virtual-user" profiles can contain only one AutoLogon service.

•If an Access-Request does not contain an IP address, you must configure a local per-domain or global IP address pool.

Configuration of SSG AutoDomain

To enable SSG AutoDomain and enter SSG autodomain configuration mode, use the ssg auto-domain command in global configuration mode. To verify the configuration, use the show running-config command in privileged EXEC mode.

For more information, refer to the SSG AutoDomain, Release 12.2(4)B feature module.

Configuration Example for SSG AutoDomain

Example 6-1 shows a sample configuration for SSG AutoDomain. In the example, AutoDomain is configured for extended-mode, and the called-station-id(APN) is used to select the AutoDomain service. If the service assigns an IP address, then SSG performs Network Address Translation (NAT) on the connection.

The example creates an AutoDomain exclude list by downloading the profile "ssg-auto-domain-exclude-profile" from the AAA server (the download password is "cisco"). The configuration also includes two exclude entries: cisco (exclude APN), and motorola (exclude domain name).

Example 6-1 SSG AutoDomain
ssg auto-domain
  mode extended
  select called-station-id
  nat user-address
  download exclude-profile ssg-auto-domain-exclude-profile cisco
  exclude apn cisco
  exclude domain motorola
Example 6-2 shows the format for defining a new vendor-specific attribute, SSG Control-Info VSA(253), which is required for the AutoDomain exclude profile on the AAA server.

Example 6-2 AutoDomain Exclude Profile SSG VSA Format
code: 253, 'X' 
     len: > 4 
     +-+-+-+-+-+-+-+-+-+-+...-+
     |a|b|  c  |d|e|f|p|  g   |
     +-+-+-+-+-+-+-+-+-+-+...-+
     a = 26  (Radius attribute for vendor specific)
     b = len (length of the Radius vendor-specific)
     c = 9 (Cisco vendor ID)
     d = 253 (sub-attribute ID for Service-Info)
     e = len (length of the vendor-specific filter)
     p = 'X' (Excluded Name List Entry Flag)
     g = "A<apn-name>" or (Add this name to APN exclude list)
           "D<domain-name>" (Add this name to Domain name exclude list)
Example 6-3 shows a sample configuration for an AutoDomain exclude file.

Example 6-3 AutoDomain Exclude File Format
user = ssg-auto-domain-exclude-profile{
 radius=SSGDictionary {
 check_items= {
 2=cisco
 }  
 reply_attributes= {
 9,253="XDcisco" 
 9,253="XDmotorola"
 9,253="XAalcatel"
 9,253="XAnokia" 
 }
 }
 }
SSG Prepaid

The SSG Prepaid feature allows a user to connect to a service if the user has prepaid for the service. SSG checks a subscriber's available credit to determine whether to connect the subscriber to the service and how long the connection can last. The billing server administers the subscriber's credit as a series of quotas. These quotas are allotments of available credit and represent the duration of use, expressed in seconds.

Note The Cisco 10000 series router does not support quotas that are based on allowable data volume. The router supports only time-based quotas.

To obtain the first quota for a connection, SSG submits an authorization request to the AAA server. The AAA server contacts the prepaid billing server, which forwards the quota values to SSG. SSG then monitors the connection to track the quota usage. When the quota runs out, SSG performs reauthorization. During reauthorization, the billing server can provide SSG with an additional quota if there is available credit. If no further quota is provided, SSG logs off the user.

For more information, refer to the SSG Prepaid, Release 12.2(4)B feature module.

Restrictions for SSG Prepaid

The SSG Prepaid feature has the following restrictions:

•Quotas are measured in seconds. You cannot change the unit of measure.

•The Cisco 10000 router supports only time-based SSG Prepaid for a service connection.

Configuration of SSG Prepaid

To configure SSG to provide the prepaid billing server with session ID and time-stamp information, use the radius-server attribute command in global configuration mode. The command syntax is:
radius-server attribute 44 include-in-access-req (Accounting Session ID)
radius-server attribute 55 include-in-acct-req (Event-Timestamp)
To configure a global prepaid server group for authorization, use the aaa group server radius command in global configuration mode and then use the ssg aaa group prepaid command in global configuration mode to attach the global prepaid server group to the SSG. The command syntax is:
aaa group server radius group-name
ssg aaa group prepaid group-name
For more information, refer to the SSG Prepaid, Release 12.2(4)B feature module.

Configuration Example for SSG Prepaid

Example 6-4 configures a global prepaid server group named ssg_prepaid and attaches the server group to the SSG.

Example 6-4 Attaching a Global Prepaid Server Group to the SSG
Router(config)# aaa group server radius ssg_prepaid
Router(config-sg)# server 1.2.3.4 auth-port 1645 acct-port 1646
Router(config-sg)# exit
Router(config)# ssg aaa group prepaid ssg_prepaid
SSG Open Garden

An Open Garden is a collection of networks or web sites that subscribers can access as long as they have physical access to the network. Subscribers do not have to provide authentication information before accessing the networks in an Open Garden. The network is not restricted by service selection, subscription, or policing.

Figure 6-1 shows a network topology that includes Open Garden networks.

Figure 6-1 Open Garden Network Topology

If SSG receives a packet from a subscriber that is destined for the Open Garden, SSG forwards the packet even if the subscriber is not authenticated. SSG forwards all packets destined for the Open Garden whether or not the subscriber is authenticated.

If SSG receives a packet from a subscriber that is not destined for the Open Garden and the subscriber is not authenticated, SSG drops the packet. If the subscriber is authenticated, SSG forwards the packet.

While most SSG services must be bound to an interface or next-hop address, it is not necessary to bind Open Garden services that are directly connected to the SSG router. Service binding is mandatory, however, for Open Garden services that are routed through a next-hop address.

For more information, refer to the SSG Open Garden, Release 12.2(4)B feature module.

Restrictions for SSG Open Garden

The SSG Open Garden feature has the following restrictions:

•RADIUS accounting records are not created for Open Garden services.

•The Cisco 10000 router supports the creation of Open Garden services by using local profiles only; you cannot use RADIUS profiles.

•The Cisco 10000 router does not support overlapping Open Garden service networks.

Configuration of SSG Open Garden

To designate a service as an Open Garden service, use the ssg open-garden command in global configuration mode. For more information on configuring an Open Garden, refer to the SSG Open Garden, Release 12.2(4)B feature module.

Configuration Example for SSG Open Garden

The following example defines two services named og1 and og2 and adds them to the Open Garden.
!
ssg open-garden og1
ssg open-garden og2
!
local-profile og1
attribute 26 9 251 "Oopengarden1.com"
attribute 26 9 251 "D10.13.1.5"
attribute 26 9 251 "R10.1.1.0;255.255.255.0
local-profile og2
attribute 26 9 251 "Oopengarden2.com"
attribute 26 9 251 "D10.14.1.5"
attribute 26 9 251 "R10.2.1.0;255.255.255.0"
attribute 26 9 251 "R10.3.1.0;255.255.255.0"
!
ssg bind service og2 10.5.5.1
SSG Port-Bundle Host Key

The SSG Port-Bundle Host Key feature enhances communication and functionality between SSG and SESM by introducing a mechanism that uses the host source IP address and source port to identify and monitor subscribers.

With the SSG Port-Bundle Host Key feature, SSG performs port-address translation (PAT) and network-address translation (NAT) on the HTTP traffic between the subscriber and the SESM server. When a subscriber sends an HTTP packet to the SESM server, SSG creates a port map that changes the source IP address to a configured SSG source IP address and changes the source TCP port to a port allocated by SSG. SSG assigns a bundle of ports to each subscriber because one subscriber can have several simultaneous TCP sessions when accessing a web page. The assigned host key, or combination of port-bundle and SSG source IP address, uniquely identifies each subscriber. The host key is carried in RADIUS packets sent between the SESM server and SSG in the Subscriber IP vendor-specific attribute (VSA). When the SESM server sends a reply to the subscriber, SSG translates the destination IP address and destination TCP port according to the port map.

For each TCP session between a subscriber and the SESM server, SSG uses one port from the port bundle as the port map. Port mappings are flagged as eligible for reuse on the basis of inactivity timers, but are not explicitly removed once assigned. The number of port bundles is limited, but you can assign multiple SSG source IP addresses to accommodate more subscribers.

SSG assigns the base port of the port bundle to a port map only if SSG has no state information for the subscriber or if the state of the subscriber has changed. When the SESM server sees the base port of a port bundle in the host key, SESM queries SSG for new subscriber state information.

For more information, refer to the SSG Port-Bundle Host Key, Release 12.2(4)B feature module.

Restrictions for SSG Port-Bundle Host Key

The SSG Port-Bundle Host Key feature has the following restrictions:

•You must separately enable the SSG Port-Bundle Host Key feature at the SESM and at all connected SSG nodes.

•To enable the SSG Port-Bundle Host Key feature, you must reload SSG and restart the SESM.

•When you change the port-bundle length, the change does not take effect until after the router reloads.

•All SSG source IP addresses configured using the ssg port-map source ip command must be routable in the management network where the SESM resides.

•For each SESM server, all connected SSG nodes must have the same port-bundle length.

•RFC 1483, local bridged, or routed clients cannot have overlapping IP addresses, even across different interfaces.

•Enabling the SSG Port-Bundle Host Key feature requires additional PXF processing.

•The Cisco 10000 router's SSG software and forwarding software handle multiple users attached to a single Cisco IOS interface in different ways, which could result in users receiving services that they did not select. After the first user logs on, all subsequent user logon attempts are rejected. Although the logon is rejected and thus the ability to select services, all users can access the services to which the first user is subscribed. User traffic is not rejected, only the user's authorization attempt. The traffic from all users is logged in the statistics of the first user. Traffic to the second and subsequent user(s) is treated as transparent passthrough and is forwarded to these users, but it does not affect the SSG accounting. The ssg show host command displays the first user.

•For users attached to multipoint interfaces on the access side, the Cisco 10000 router authorizes the first user and then rejects the authorization attempts of subsequent users. The router only rejects the authorization attempts, not the user traffic. The router treats all subsequent users as the first user logged on, allowing access to the services to which the first user is subscribed. However, subsequent users cannot select services. The traffic from all users is logged in the statistics of the first user. Traffic to the second and subsequent user(s) is treated as transparent passthrough and is forwarded to these users, but it does not affect the SSG accounting. The ssg show host command displays the first user.

Prerequisites for SSG Port-Bundle Host Key

The SSG Port-Bundle Host Key feature has the following requirements:

•The Cisco 10000 router supports the SSG Port-Bundle Host Key feature for Cisco SESM Release 3.1(1) or later.

•A default network must be configured and routable from SSG.

Configuration of SSG Port-Bundle Host Key

The port-bundle host key is disabled by default. To enable the host key and enter the SSG port map configuration mode, use the ssg port-map enable command in global configuration mode.

After you enable the host key, perform the following configuration tasks:

•Specify the subscriber traffic to be port-mapped by using the following command in SSG port configuration mode:
Router(config-ssg-port)# destination range start-port to end-port [ip A.B.C.D]
•Specify the SSG source IP addresses by using the following command in SSG port configuration mode:
Router(config-ssg-port)# source ip {interface | ip-address}
•Specify the length of the port bundle by using the following command in SSG port configuration mode:
Router(config-ssg-port)# length port-bundle length
For more information on configuring the SSG Port-Bundle Host Key feature, refer to the SSG Port-Bundle Host Key, Release 12.2(4)B feature module.

Exclude Networks

The Exclude Networks feature allows you to specify networks to which users cannot automatically log on. To add names to the autodomain download exclusion list, use the download exclude-profile command in SSG autodomain configuration mode.

For more information, refer to the SSG AutoDomain, Release 12.2(4)B feature module.

Mutually Exclusive Service Selection

The Mutually Exclusive Service Selection feature restricts a subscriber to accessing only one service at a time in a specified group of services.

A service group is a collection of services defined in a service group profile. A subscription to a service group implies subscription to all of the services in the group. It also implies the ability to select all of the services in the group. However, when a group is defined as mutually exclusive, SESM limits service selection to one service at a time within the group.

A SESM configuration option controls the SESM action when a subscriber is already logged into one service and then selects another service in the group:

•SESM can automatically request SSG to disconnect the first service and connect the new service.

•SESM can prompt the subscriber to log off the first service. After the subscriber logs off, SESM requests the connection to the other service.

Note SESM waits for the first service to be disconnected before requesting connection to the new service. If the connection to the new service fails, the subscriber is not connected to either service.

Configuration of Mutually Exclusive Service Selection

You define a mutually exclusive service group in a service group profile by using the Account-Info attribute. The value TE indicates that the service group is mutually exclusive.

For more information, refer to the "Configuring Service Group Profiles" section in Appendix D, Configuring RADIUS in the Cisco Subscriber Edge Services Manager and Subscriber Policy Engine Installation and Configuration Guide, Release 3.1(3).

Configuration Example for Mutually Exclusive Service Selection

Example 6-5 shows a mutually exclusive service group configuration that uses a Merit RADIUS format.

Example 6-5 Configuring a Mutually Exclusive Service Selection Group
MutexGrp1 Password = "groupcisco", Service-Type = Outbound
Account-Info = "IBandwidth-QoS",
Account-Info = "Nbw-gold",
Account-Info = "Nbw-silver",
Account-Info = "Nbw-bronze",
Account-Info = "TE"

	Cisco 10000 Series Internet Router Service Selection Gateway Configuration Guide
	Service Connection
Cisco 10000 Series Internet Router Service Selection Gateway Configuration Guide About This Guide Service Selection Gateway Overview Scaling and Performance SSG Logon and Logoff Authentication and Accounting Service Selection Methods Service Connection Service Profiles and Cached Service Profiles SSG Hierarchical Policing Interface Configuration SSG TCP Redirect Miscellaneous SSG Features Monitoring and Maintaining SSG SSG Implementation Notes Configuration Example for SSG Glossary Index	Download this chapter Service Connection Download the complete book Cisco 10000 Series Router Service Selection Gateway Configuration Guide (PDF - 1 MB) Table Of Contents Service Connection SSG AutoDomain Restrictions for SSG AutoDomain Configuration of SSG AutoDomain Configuration Example for SSG AutoDomain SSG Prepaid Restrictions for SSG Prepaid Configuration of SSG Prepaid Configuration Example for SSG Prepaid SSG Open Garden Restrictions for SSG Open Garden Configuration of SSG Open Garden Configuration Example for SSG Open Garden SSG Port-Bundle Host Key Restrictions for SSG Port-Bundle Host Key Prerequisites for SSG Port-Bundle Host Key Configuration of SSG Port-Bundle Host Key Exclude Networks Mutually Exclusive Service Selection Configuration of Mutually Exclusive Service Selection Configuration Example for Mutually Exclusive Service Selection Service Connection The Cisco 10000 series router supports the following SSG features for service connection: •SSG AutoDomain •SSG Prepaid •SSG Open Garden •SSG Port-Bundle Host Key •Exclude Networks •Mutually Exclusive Service Selection This chapter describes the SSG features for service connection. SSG AutoDomain The SSG AutoDomain feature allows users to automatically connect to a service based on the domain part of the structured username specified in an Access-Request. When SSG AutoDomain is configured, user authentication is performed at the service (for example, at the AAA server within a corporate network), instead of at the network access server (NAS). The domain portion of the structured username is the portion after the @ in the username. For example, the domain in the username "abc@cisco.com" is "cisco.com". Users can bypass the Service Selection Dashboard (SSD) and access a service, such as a corporate intranet. SSG AutoDomain on the Cisco 10000 router supports login operations from the Subscriber Edge Services Manager (SESM) application. AutoDomain uses a heuristic to determine the service into which the user is logged. The host object is not activated until successfully authenticated with the service. If the autoservice connection fails for any reason, the user login is rejected. The AutoDomain service first checks for a structured username. If AutoDomain is enabled and the received Access-Request specifies a structured username, the username is used for AutoDomain selection. If the Access-Request does not specify a username or the specified username is a member of the domain name exclusion list, then no AutoDomain is selected and normal SSG user login proceeds. You can define the domain name exclusion list by using the exclude command in SSG-auto-domain configuration mode. When you enable AutoDomain, an AutoDomain profile is downloaded from the local AAA server. This profile specifies an outbound service and the password is the globally configured service password. You can configure SSG AutoDomain in basic or extended mode. In basic mode, the AutoDomain profile downloaded from the AAA server is a service profile. This service profile is a proxy or VPDN service. If the AutoDomain service profile is a proxy service, SSG authenticates the user to the appropriate domain AAA server with the authentication information found in the Access-Request received from the RADIUS client. If the downloaded AutoDomain service profile is a tunnel service, a PPP session is regenerated into an L2TP tunnel for the selected service. If the returned SSG-specific attributes do not indicate the type of service required, SSG treats this service as a VPDN service. In extended AutoDomain mode, the downloaded profile is a "virtual user" profile that contains one autoservice to an authenticated service such as a proxy or VPDN. The host object is not activated until the user is authenticated at the proxy or VPDN service. If the "virtual user" profile does not have exactly one autoservice or the autoservice is not authenticated, the AutoDomain login is rejected. If you configure basic SSG AutoDomain with a nonauthenticated service type (for example, passthrough), SSG rejects the login request because AutoDomain bypasses user authentication at the local AAA server and requires that authentication be performed elsewhere. For more information, refer to the SSG AutoDomain, Release 12.2(4)B feature module. Restrictions for SSG AutoDomain SSG AutoDomain has the following restrictions: •Restricted DHCP support—DHCP requests for IP address assignment must be done before RADIUS negotiation. •Passthrough services—Because local authentication at the network access server (NAS) is bypassed, AutoDomain is available only for services that perform authentication (for example, proxy or VPDN services). •"Virtual-user" profiles can contain only one AutoLogon service. •If an Access-Request does not contain an IP address, you must configure a local per-domain or global IP address pool. Configuration of SSG AutoDomain To enable SSG AutoDomain and enter SSG autodomain configuration mode, use the ssg auto-domain command in global configuration mode. To verify the configuration, use the show running-config command in privileged EXEC mode. For more information, refer to the SSG AutoDomain, Release 12.2(4)B feature module. Configuration Example for SSG AutoDomain Example 6-1 shows a sample configuration for SSG AutoDomain. In the example, AutoDomain is configured for extended-mode, and the called-station-id(APN) is used to select the AutoDomain service. If the service assigns an IP address, then SSG performs Network Address Translation (NAT) on the connection. The example creates an AutoDomain exclude list by downloading the profile "ssg-auto-domain-exclude-profile" from the AAA server (the download password is "cisco"). The configuration also includes two exclude entries: cisco (exclude APN), and motorola (exclude domain name). Example 6-1 SSG AutoDomain ssg auto-domain mode extended select called-station-id nat user-address download exclude-profile ssg-auto-domain-exclude-profile cisco exclude apn cisco exclude domain motorola Example 6-2 shows the format for defining a new vendor-specific attribute, SSG Control-Info VSA(253), which is required for the AutoDomain exclude profile on the AAA server. Example 6-2 AutoDomain Exclude Profile SSG VSA Format code: 253, 'X' len: > 4 +-+-+-+-+-+-+-+-+-+-+...-+ \|a\|b\| c \|d\|e\|f\|p\| g \| +-+-+-+-+-+-+-+-+-+-+...-+ a = 26 (Radius attribute for vendor specific) b = len (length of the Radius vendor-specific) c = 9 (Cisco vendor ID) d = 253 (sub-attribute ID for Service-Info) e = len (length of the vendor-specific filter) p = 'X' (Excluded Name List Entry Flag) g = "A<apn-name>" or (Add this name to APN exclude list) "D<domain-name>" (Add this name to Domain name exclude list) Example 6-3 shows a sample configuration for an AutoDomain exclude file. Example 6-3 AutoDomain Exclude File Format user = ssg-auto-domain-exclude-profile{ radius=SSGDictionary { check_items= { 2=cisco } reply_attributes= { 9,253="XDcisco" 9,253="XDmotorola" 9,253="XAalcatel" 9,253="XAnokia" } } } SSG Prepaid The SSG Prepaid feature allows a user to connect to a service if the user has prepaid for the service. SSG checks a subscriber's available credit to determine whether to connect the subscriber to the service and how long the connection can last. The billing server administers the subscriber's credit as a series of quotas. These quotas are allotments of available credit and represent the duration of use, expressed in seconds. Note The Cisco 10000 series router does not support quotas that are based on allowable data volume. The router supports only time-based quotas. To obtain the first quota for a connection, SSG submits an authorization request to the AAA server. The AAA server contacts the prepaid billing server, which forwards the quota values to SSG. SSG then monitors the connection to track the quota usage. When the quota runs out, SSG performs reauthorization. During reauthorization, the billing server can provide SSG with an additional quota if there is available credit. If no further quota is provided, SSG logs off the user. For more information, refer to the SSG Prepaid, Release 12.2(4)B feature module. Restrictions for SSG Prepaid The SSG Prepaid feature has the following restrictions: •Quotas are measured in seconds. You cannot change the unit of measure. •The Cisco 10000 router supports only time-based SSG Prepaid for a service connection. Configuration of SSG Prepaid To configure SSG to provide the prepaid billing server with session ID and time-stamp information, use the radius-server attribute command in global configuration mode. The command syntax is: radius-server attribute 44 include-in-access-req (Accounting Session ID) radius-server attribute 55 include-in-acct-req (Event-Timestamp) To configure a global prepaid server group for authorization, use the aaa group server radius command in global configuration mode and then use the ssg aaa group prepaid command in global configuration mode to attach the global prepaid server group to the SSG. The command syntax is: aaa group server radius group-name ssg aaa group prepaid group-name For more information, refer to the SSG Prepaid, Release 12.2(4)B feature module. Configuration Example for SSG Prepaid Example 6-4 configures a global prepaid server group named ssg_prepaid and attaches the server group to the SSG. Example 6-4 Attaching a Global Prepaid Server Group to the SSG Router(config)# aaa group server radius ssg_prepaid Router(config-sg)# server 1.2.3.4 auth-port 1645 acct-port 1646 Router(config-sg)# exit Router(config)# ssg aaa group prepaid ssg_prepaid SSG Open Garden An Open Garden is a collection of networks or web sites that subscribers can access as long as they have physical access to the network. Subscribers do not have to provide authentication information before accessing the networks in an Open Garden. The network is not restricted by service selection, subscription, or policing. Figure 6-1 shows a network topology that includes Open Garden networks. Figure 6-1 Open Garden Network Topology If SSG receives a packet from a subscriber that is destined for the Open Garden, SSG forwards the packet even if the subscriber is not authenticated. SSG forwards all packets destined for the Open Garden whether or not the subscriber is authenticated. If SSG receives a packet from a subscriber that is not destined for the Open Garden and the subscriber is not authenticated, SSG drops the packet. If the subscriber is authenticated, SSG forwards the packet. While most SSG services must be bound to an interface or next-hop address, it is not necessary to bind Open Garden services that are directly connected to the SSG router. Service binding is mandatory, however, for Open Garden services that are routed through a next-hop address. For more information, refer to the SSG Open Garden, Release 12.2(4)B feature module. Restrictions for SSG Open Garden The SSG Open Garden feature has the following restrictions: •RADIUS accounting records are not created for Open Garden services. •The Cisco 10000 router supports the creation of Open Garden services by using local profiles only; you cannot use RADIUS profiles. •The Cisco 10000 router does not support overlapping Open Garden service networks. Configuration of SSG Open Garden To designate a service as an Open Garden service, use the ssg open-garden command in global configuration mode. For more information on configuring an Open Garden, refer to the SSG Open Garden, Release 12.2(4)B feature module. Configuration Example for SSG Open Garden The following example defines two services named og1 and og2 and adds them to the Open Garden. ! ssg open-garden og1 ssg open-garden og2 ! local-profile og1 attribute 26 9 251 "Oopengarden1.com" attribute 26 9 251 "D10.13.1.5" attribute 26 9 251 "R10.1.1.0;255.255.255.0 local-profile og2 attribute 26 9 251 "Oopengarden2.com" attribute 26 9 251 "D10.14.1.5" attribute 26 9 251 "R10.2.1.0;255.255.255.0" attribute 26 9 251 "R10.3.1.0;255.255.255.0" ! ssg bind service og2 10.5.5.1 SSG Port-Bundle Host Key The SSG Port-Bundle Host Key feature enhances communication and functionality between SSG and SESM by introducing a mechanism that uses the host source IP address and source port to identify and monitor subscribers. With the SSG Port-Bundle Host Key feature, SSG performs port-address translation (PAT) and network-address translation (NAT) on the HTTP traffic between the subscriber and the SESM server. When a subscriber sends an HTTP packet to the SESM server, SSG creates a port map that changes the source IP address to a configured SSG source IP address and changes the source TCP port to a port allocated by SSG. SSG assigns a bundle of ports to each subscriber because one subscriber can have several simultaneous TCP sessions when accessing a web page. The assigned host key, or combination of port-bundle and SSG source IP address, uniquely identifies each subscriber. The host key is carried in RADIUS packets sent between the SESM server and SSG in the Subscriber IP vendor-specific attribute (VSA). When the SESM server sends a reply to the subscriber, SSG translates the destination IP address and destination TCP port according to the port map. For each TCP session between a subscriber and the SESM server, SSG uses one port from the port bundle as the port map. Port mappings are flagged as eligible for reuse on the basis of inactivity timers, but are not explicitly removed once assigned. The number of port bundles is limited, but you can assign multiple SSG source IP addresses to accommodate more subscribers. SSG assigns the base port of the port bundle to a port map only if SSG has no state information for the subscriber or if the state of the subscriber has changed. When the SESM server sees the base port of a port bundle in the host key, SESM queries SSG for new subscriber state information. For more information, refer to the SSG Port-Bundle Host Key, Release 12.2(4)B feature module. Restrictions for SSG Port-Bundle Host Key The SSG Port-Bundle Host Key feature has the following restrictions: •You must separately enable the SSG Port-Bundle Host Key feature at the SESM and at all connected SSG nodes. •To enable the SSG Port-Bundle Host Key feature, you must reload SSG and restart the SESM. •When you change the port-bundle length, the change does not take effect until after the router reloads. •All SSG source IP addresses configured using the ssg port-map source ip command must be routable in the management network where the SESM resides. •For each SESM server, all connected SSG nodes must have the same port-bundle length. •RFC 1483, local bridged, or routed clients cannot have overlapping IP addresses, even across different interfaces. •Enabling the SSG Port-Bundle Host Key feature requires additional PXF processing. •The Cisco 10000 router's SSG software and forwarding software handle multiple users attached to a single Cisco IOS interface in different ways, which could result in users receiving services that they did not select. After the first user logs on, all subsequent user logon attempts are rejected. Although the logon is rejected and thus the ability to select services, all users can access the services to which the first user is subscribed. User traffic is not rejected, only the user's authorization attempt. The traffic from all users is logged in the statistics of the first user. Traffic to the second and subsequent user(s) is treated as transparent passthrough and is forwarded to these users, but it does not affect the SSG accounting. The ssg show host command displays the first user. •For users attached to multipoint interfaces on the access side, the Cisco 10000 router authorizes the first user and then rejects the authorization attempts of subsequent users. The router only rejects the authorization attempts, not the user traffic. The router treats all subsequent users as the first user logged on, allowing access to the services to which the first user is subscribed. However, subsequent users cannot select services. The traffic from all users is logged in the statistics of the first user. Traffic to the second and subsequent user(s) is treated as transparent passthrough and is forwarded to these users, but it does not affect the SSG accounting. The ssg show host command displays the first user. Prerequisites for SSG Port-Bundle Host Key The SSG Port-Bundle Host Key feature has the following requirements: •The Cisco 10000 router supports the SSG Port-Bundle Host Key feature for Cisco SESM Release 3.1(1) or later. •A default network must be configured and routable from SSG. Configuration of SSG Port-Bundle Host Key The port-bundle host key is disabled by default. To enable the host key and enter the SSG port map configuration mode, use the ssg port-map enable command in global configuration mode. After you enable the host key, perform the following configuration tasks: •Specify the subscriber traffic to be port-mapped by using the following command in SSG port configuration mode: Router(config-ssg-port)# destination range start-port to end-port [ip A.B.C.D] •Specify the SSG source IP addresses by using the following command in SSG port configuration mode: Router(config-ssg-port)# source ip {interface \| ip-address} •Specify the length of the port bundle by using the following command in SSG port configuration mode: Router(config-ssg-port)# length port-bundle length For more information on configuring the SSG Port-Bundle Host Key feature, refer to the SSG Port-Bundle Host Key, Release 12.2(4)B feature module. Exclude Networks The Exclude Networks feature allows you to specify networks to which users cannot automatically log on. To add names to the autodomain download exclusion list, use the download exclude-profile command in SSG autodomain configuration mode. For more information, refer to the SSG AutoDomain, Release 12.2(4)B feature module. Mutually Exclusive Service Selection The Mutually Exclusive Service Selection feature restricts a subscriber to accessing only one service at a time in a specified group of services. A service group is a collection of services defined in a service group profile. A subscription to a service group implies subscription to all of the services in the group. It also implies the ability to select all of the services in the group. However, when a group is defined as mutually exclusive, SESM limits service selection to one service at a time within the group. A SESM configuration option controls the SESM action when a subscriber is already logged into one service and then selects another service in the group: •SESM can automatically request SSG to disconnect the first service and connect the new service. •SESM can prompt the subscriber to log off the first service. After the subscriber logs off, SESM requests the connection to the other service. Note SESM waits for the first service to be disconnected before requesting connection to the new service. If the connection to the new service fails, the subscriber is not connected to either service. Configuration of Mutually Exclusive Service Selection You define a mutually exclusive service group in a service group profile by using the Account-Info attribute. The value TE indicates that the service group is mutually exclusive. For more information, refer to the "Configuring Service Group Profiles" section in Appendix D, Configuring RADIUS in the Cisco Subscriber Edge Services Manager and Subscriber Policy Engine Installation and Configuration Guide, Release 3.1(3). Configuration Example for Mutually Exclusive Service Selection Example 6-5 shows a mutually exclusive service group configuration that uses a Merit RADIUS format. Example 6-5 Configuring a Mutually Exclusive Service Selection Group MutexGrp1 Password = "groupcisco", Service-Type = Outbound Account-Info = "IBandwidth-QoS", Account-Info = "Nbw-gold", Account-Info = "Nbw-silver", Account-Info = "Nbw-bronze", Account-Info = "TE"
	© 1992-2008 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.