|
|
This document describes the Service Selection Gateway feature in Cisco IOS Release 12.2(11)T. It contains the following sections:
 |
Note Significant changes were made in SSG functionality in Cisco IOS Release 12.2(4)B. For a summary of the differences between SSG in Cisco IOS Release 12.2(2)B and Cisco IOS Release 12.2(4)B and later releases, please see the section "New and Changed SSG Functionality in Cisco IOS Release 12.2(4)B and Later Releases" later in this document. |
Service Selection Gateway (SSG) is a switching solution for service providers who offer intranet, extranet, and Internet connections to subscribers using broadband access technology such as digital subscriber lines (DSL), cable modems, or wireless to allow simultaneous access to network services.
SSG works in conjunction with the Cisco Service Selection Dashboard (SSD) or its successor product, the Cisco Subscriber Edge Services Manager (SESM). Together with the SESM or SSD, SSG provides subscriber authentication, service selection, and service connection capabilities to subscribers of Internet services. Subscribers interact with an SESM or SSD web application using a standard Internet browser.
The SESM operates in two modes:
This document provides information on general SSG configuration that applies to the SESM in both LDAP mode and RADIUS mode. It also provides RADIUS-specific configuration information that applies only to the SESM in RADIUS mode or the SSD.
If your deployment uses the SESM in LDAP mode, refer to these documents for additional information about LDAP-mode topics:
|
Note The SESM and SSD functionality described in this document is available only with SSG. In the remainder of this document, all references to the SESM also apply to the SSD unless a clear distinction is made. |
Figure 1 is a diagram of a sample network topology including SSG. This is an end-to-end, service-oriented DSL deployment consisting of digital subscriber line access multiplexers (DSLAMs), asymmetric digital subscriber line (ADSL) modems, and other internetworking components and servers. SSG resides in a router that is serving as a broadband aggregator. The broadband aggregator acts as a central control point for Layer 2 and Layer 3 services, including services available through ATM virtual circuits (VCs), virtual private dial-up networks (VPDNs), and normal routing methods.
SSG communicates with the authentication, authorization, and accounting (AAA) management network where RADIUS, Dynamic Host Configuration Protocol (DHCP), and Simple Network Management Protocol (SNMP) servers reside and with the Internet service provider (ISP) network, which may connect to the Internet, corporate networks, and value-added services.
A licensed version of SSG works with SESM to present to subscribers a menu of network services that can be selected from a single graphical user interface (GUI). This functionality improves flexibility and convenience for subscribers and enables service providers to bill subscribers for connect time and services used, rather than charging a flat rate.
When SSG is used with the SESM, the user opens an HTML browser and accesses the URL of the SESM web server application. The SESM forwards the user login information to SSG, which forwards the information either to the AAA server, for the SSD or SESM in RADIUS mode, or to the RADIUS-DESS Proxy (RDP) component of the SESM, for the SESM in LDAP mode.
Based on the contents of the Access-Accept response, the SESM presents a menu of services that the user is authorized to use, and the user selects one or more of the services. SSG then creates an appropriate connection for the user and optionally starts RADIUS accounting for the connection.
Note that when a non-PPP user, such as in a bridged-networking environment, disconnects from a service without logging out, the connection remains open and the user can reaccess the service without going through the login procedure. This is because no direct connection (PPP) exists between the subscribers and SSG. To prevent non-PPP users from being logged in to services indefinitely, be sure to configure the Session-Timeout and/or Idle-Timeout RADIUS attributes.
SSG supports the features and functionality described in the following sections:
SSG works with the Cisco SESM. The SESM is a specialized web server that allows users to log in to and disconnect from multiple pass-through and proxy services through a standard web browser.
After the user opens a web browser, SSG allows access to a single IP address or subnet, referred to as the default network. This is typically the IP address of the SESM. The SESM prompts the user for a username and password. After the user is authenticated, the SESM presents a list of available services.
The SESM provides all the functionality of its predecessor product, the SSD. The SESM also introduces the following functionality:
SSG is designed to work with RADIUS-based AAA servers that accept vendor-specific attributes (VSAs).
SSG using the SESM in LDAP mode can use an LDAP directory as the data repository for service, subscriber, and policy information.
SSG supports the following types of service:
SSG can forward traffic through any interface by means of normal routing or a next-hop table. Because Network Address Translation (NAT) is not performed for this type of traffic, overhead is reduced. Pass-through service is ideal for standard Internet access.
When a subscriber requests access to a proxy service, SSG proxies the Access-Request packet to the remote AAA server. Upon receiving an Access-Accept packet from the remote RADIUS server, the SSG logs the subscriber in. To the remote AAA server, SSG appears as a client.
Iif the RADIUS server assigns an IP address to the subscriber during remote authentication, SSG performs NAT between the assigned IP address and the real IP address of the subscriber. If the remote RADIUS server does not assign an IP address, NAT is not performed.
When a user selects a proxy service, there is another prompt for username and password. After authentication, the service is accessible until the user logs out from the service, logs out from the SESM, or times out.
When enabled, transparent pass-through allows unauthenticated subscriber traffic to be routed through SSG in either direction. Filters can be specified to control transparent pass-through traffic. These are some of the applications for this feature:
PPP Termination Aggregation (PTA) can be used only by PPP-type users. AAA is performed exactly as in the proxy service type. A subscriber logs in to a service by using a PPP dialer application with a username of the form `user@service'. SSG recognizes `@service' as a service profile and loads the service profile from the local configuration or a AAA server. SSG forwards the AAA request to the remote RADIUS server as specified by the RADIUS-Server attribute of the service profile. An address is assigned to the subscriber through RADIUS attribute 8 or Cisco-AVpair "ip:addr-pool." NAT is not performed, and all user traffic is aggregated to the remote network. With PTA, users can access only one service. Users do not have access to the default network or the SESM.
Whereas PTA terminates the PPP session into a single routing domain, PTA-MD terminates the PPP sessions into multiple IP routing domains, thus supporting a wholesale Virtual Private Network (VPN) model in which each domain is isolated from the other by an ATM core and has the capability to support overlapping IP addresses.
SSG uses Cisco IOS access control lists (ACLs) to prevent users, services, and pass-through traffic from accessing specific IP addresses and ports.
When an ACL attribute is added to a service profile, all users of that service are prevented from accessing the specified IP address, subnet mask, and port combinations through the service.
When an ACL attribute is added to a user profile, it applies globally to all traffic for the user.
Upstream and downstream attributes, including the Upstream Access Control List and Downstream Access Control List attributes, can be added to a special pseudo-service profile that can be downloaded to SSG from a RADIUS server. Additionally, locally configured ACLs can be used. After the ACLs have been defined, they are applied to all traffic passed by the transparent pass-through feature.
When users are accessing multiple services, SSG must determine the services for which the packets are destined. To do this, SSG uses an algorithm to create a service access order list that is stored in the user's host object. This list contains services that are currently open and the order in which they are to be searched. The algorithm that creates this list orders the open services based on the closest matching network address.
The Next-Hop Gateway attribute is used to specify the next hop key for a service. Each SSG uses its own next-hop gateway table, which associates this key with an actual IP address.
Note that this attribute overrides the IP routing table for packets destined to a service.
When SSG receives a Domain Name Server (DNS) request, it performs domain name matching by using the Domain Name attribute from the service profiles of the currently logged-in services.
If a match is found, the request is redirected to the DNS server for the matched service.
If a match is not found and the user is logged in to a service that has Internet connectivity, the request is redirected to the first service in the user's service access order list that has Internet connectivity. Internet connectivity is defined as a service containing a Service Route attribute of 0.0.0.0/0.
If a match is not found and the user is not logged in to a service that has Internet connectivity, the request is forwarded to the DNS server defined in the client's TCP/IP stack.
SSG can be configured to work with a single DNS server or with two servers in a fault-tolerant configuration. By means of an internal algorithm, DNS requests are switched to the secondary server if the primary server fails to respond with a DNS reply within a certain time limit.
In a dial-up networking or bridged (non-PPP) network environment, a user can disconnect from the NAS and release the IP address without logging out from SSG. If this happens, SSG continues to allow traffic to pass from that IP address, and this can be a problem if the IP address is obtained by another user.
SSG provides two mechanisms to prevent this problem from occurring:
The Session-Timeout and Idle-Timeout attributes can be used in either a user or service profile. In a user profile, the attribute applies to the user's session. In a service profile, the attribute applies individually to each service connection.
SSG services can be configured for concurrent or sequential access. Concurrent access allows users to log in to this service while simultaneously connected to other services. Sequential access requires that the user log out of all other services before accessing a service configured for sequential access.
Concurrent access is recommended for most services. Sequential access is ideal for services for which security is important, such as corporate intranet access, or for which there is a possibility of overlapping address space.
SSG supports enhanced high system availability (EHSA) redundancy. You can configure this chassis redundancy at the slot level of the router for adjacent slot or subslot pairs. For example, if you have SSGs installed in slots 1 and 2, you can set a preferred device between the two. To ensure that configuration is consistent between redundant SSGs, you can configure automatic synchronization between the two SSGs. You can also manually force the primary and secondary devices in a redundant pair to switch roles.
SSG supports Layer 2 Tunnel Protocol (L2TP). When a subscriber selects a service through SESM, the router serves as an L2TP access concentrator (LAC) and sends the PPP session through the service-specific L2TP tunnel. If the tunnel does not already exist, the LAC creates the proper tunnel to the L2TP network server (LNS).
SSG can be enabled to forward packets locally between directly connected subscribers.
To log in to a service through the SESM, a subscriber has to log in only twice: once for the PPP session and once for the service.
IP Control Protocol (IPCP) subnet support allows SSG to populate a host's DHCP server with a pool of IP addresses. The PPP session from the host is terminated at the SSG. During IPCP negotiations, SSG uses the IPCP subnet mask negotiation option to send a range of IP addresses to the customer premises equipment (CPE) device at the host network. The CPE assigns IP addresses to the users in the SSG's domain, thus avoiding the need for NAT at the CPE device.
To enable IPCP subnet mask, the Framed-IP-Netmask attribute (standard RADIUS attribute 9) and Framed-IP-Address attribute (standard RADIUS attribute 8) must be included in the user profile. The Framed-IP-Netmask value is passed during IPCP negotiation as an option.
Two important aspects of providing internetworking services to a user are the access technology and the service itself. In a traditional service-provider environment, the service and access technologies are tightly joined, imposing difficulties in rolling out new services dynamically and restricting the service provider to flat billing based on the access technology.
SSG separates the service and access technologies, enabling subscribers to choose dynamically from a selection of services and service providers to implement service- and usage-based billing strategies.
SSG with SESM provides the following benefits:
SSG with SESM allows a service provider to create a branded web portal that presents subscribers with a menu of services. Subscribers can log in to and disconnect from different services using a web browser. This web-based service selection method takes advantage of the ubiquity of web browsers and eliminates problems related to client software (such as license fees, distribution logistics, and an increased customer support burden).
Cisco SSG allows subscribers to select services dynamically. SSG then switches the subscriber traffic to the selected services. SSG monitors user connections, service login and logout, and user activity per service. By providing per-connection accounting, SSG enables service providers to bill subscribers for connection time and services used rather than charging a flat rate.
Open access is an important trend in the access-provider industry. Regulators in an increasing number of countries are demanding that access providers provide equal-access service to Internet service providers (ISPs) other than their own. SSG can enable access providers to deploy services to multiple ISPs and allow the consumer to choose dynamically the ISP they would like to use.
SSG provides users with access to multiple simultaneous services, such as the Internet, gaming servers, connectivity to corporate networks, and the luxury of differential service selection. Users can dynamically connect to and disconnect from any of the services available to them.
SSG does not process multicast packets. Multicast packets are handled by Cisco IOS software.
Virtual path identifier (VPI)/virtual channel identifier (VCI) indexing to service profile works only for PPP over ATM (PPPoA) and PPP over Ethernet (PPPoE) over ATM.
For information about configuring SSD and SESM, see the following documents:
For more information about configuring RADIUS, refer to the following documents:
For more information about configuring L2TP, refer to the following documents:
The following platforms are supported in Cisco IOS Release 12.2(4)B:
The following platforms are supported in Cisco IOS Release 12.2(11)T:
Support for the Service Selection Gateway feature in Cisco IOS Release 12.2(11)T depends on the availability of the c7200-g4js-mz image.
Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.
To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register .
Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Feature Navigator home page at the following URL:
No new or modified standards are supported by this feature.
No new or modified MIBs are supported by this feature.
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
No new or modified RFCs are supported by this feature.
SSG is supported on enhanced ATM, Ethernet, and Fast Ethernet interfaces.
IP CEF must be enabled before SSG will work.
If you want to perform Layer 3 service selection, you must install and configure the Cisco SESM as described in the Cisco Subscriber Edge Services Manager and Subscriber Policy Engine Installation and Configuration Guide .
In order to use the Single Host Logon feature, you must install and configure Cisco SESM or Cisco SSD version 2.5 or a later version.
To achieve 2000 L2TP sessions, you need at least 128 MB of DRAM.
The tasks in the following sections describe how to enable SSG and configure SSG features. Each task in the list is identified as either required or optional.
The following tasks apply to SSG when used with SSD or with SESM in RADIUS or LDAP mode:
SSG is disabled by default. To enable SSG, enter the following command in global configuration mode:
To verify that SSG is enabled, enter the show running-config command.
You can configure local service profiles in addition to the service profiles on the remote RADIUS server. See the section "Configuring RADIUS Profiles" for information on configuring service profiles on the remote RADIUS server.
|
Note This task is optional. |
To configure a local service profile, use the following commands beginning in global configuration mode:
To verify that local service profiles have been configured correctly, enter the show running-config command.
To configure security for SSG, use the following commands in global configuration mode:
| 1UDP = User Datagram Protocol |
To verify that security has been configured correctly, enter the show running-config command.
To configure the first IP address or subnet that users are able to access without authentication, use the following command in global configuration mode:
To verify that the default network has been configured correctly, enter the show running-config command.
When an interface is configured as an SSG uplink or downlink interface, non-SSG traffic is not allowed to pass through that interface.
If you are going to use PPP to connect subscribers to SSG, you do not have to configure any downlink interfaces. If you are using non-PPP connections, such as bridging or LAN, you must configure at least one downlink interface.
To configure a downlink interface, use the following command in global configuration mode:
Configure all interfaces that are connected to services as uplink interfaces. To configure an uplink interface, use the following command in global configuration mode:
To verify that interfaces have been configured correctly, enter the show ssg direction command.
|
Note Every service must be bound to an uplink interface. If the service binding is not defined in the next-hop table, then the service must be bound by using the ssg bind service command. |
To configure services, use the following commands in global configuration mode:
To verify that services have been bound to interfaces correctly, enter the show ssg service command. To verify that the service search order and maximum services have been configured correctly, enter the show running-config command. To verify all mappings between services and IP addresses, enter the show ssg next-hop command.
SSG user-profile caching allows SSG to cache the user profiles of non-PPP users. User profiles of PPP and RADIUS proxy users are always cached by SSG by default. In situations in which the user profile is not available from other sources, SSG user-profile caching makes the user profile available for RADIUS status queries, providing support for single-sign-on functionality and for failover from one SESM to another.
|
Note If you are using SSG with the SESM in LDAP mode, you may want to disable SSG user-profile caching in order to save memory and improve scalability. SSG user-profile caching is required only when the SESM is used in RADIUS mode. |
To enable SSG user-profile caching, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
To verify that SSG is configured to support user-profile caching, enter the show running-config command.
SSG supports intermittent RADIUS accounting updates. When a user logs in to SSG, SSG sends an accounting start record to the local RADIUS server. When a user logs in to a service, SSG sends a connection start record to the local RADIUS server and to the remote RADIUS proxy server. During the time that the user is logged in to SSG, SSG sends accounting update records at specified intervals to the appropriate server. When a user logs out of a service, SSG sends a connection stop record to the local RADIUS server and to the remote RADIUS proxy server. When a user logs out of SSG, SSG sends an accounting stop record to the local RADIUS server. See the section "Configuration Examples" for more information.
|
Note This task is optional. |
To configure SSG to send accounting updates to the accounting server, use the following commands in interface configuration mode:
To verify that SSG is configured to support RADIUS accounting, enter the show running-config command.
SSG works with CEF switching technology to provide maximum Layer 3 switching performance. Because CEF is topology-driven rather than traffic-driven, its performance is unaffected by network size or dynamics.
|
Note CEF is disabled by default. |
To enable IP CEF, use the following command in global configuration mode:
To verify that CEF has been enabled, enter the show running-config and show ip cef commands.
SSG uses Cisco IOS Network Address Translation (NAT) to map the inside IP addresses of subscribers to the outside IP addresses from the destination service networks. This version of NAT replaces the SSG NAT used in Cisco IOS Release 12.0(3)DC.
To configure Cisco IOS NAT, you must specify an inside interface from which clients connect to the SSG and an outside interface from which services are accessed. To specify the desired inside and outside interfaces, use the following commands in interface or subinterface configuration mode:
|
Note This task is optional. |
| Command | Purpose |
|---|---|
Specifies the inside interface from which clients access SSG. |
|
Specifies the outside interface from which services are accessed. |
To verify that inside and outside ports have been specified correctly, enter the show running-config command. To view your NAT addresses, enter the show ip nat translations command.
|
Note VPI/VCI indexing to service profile works only for PPPoA and PPPoE over ATM. |
SSG supports virtual path identifier/virtual channel identifier (VPI/VCI) closed user groups by allowing VPI/VCIs to be bound to a given service. All users accessing SSG through the VPI/VCI or a range of VPI/VCIs will be able to access the service. You can specify whether users are allowed to access only the bound service or other additional services to which they subscribe. A closed user group service can be selected only through the VPI/VCI and not by entering the domain name in the username of a PPP session.
|
Note This task is optional. |
To configure VPI/VCI closed user groups, you must map VPI/VCIs to a given service. To map VCs to service names, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
To view service-name-to-VC mappings, enter the show running-config and show ssg vc-service-map commands.
|
Note Before configuring this feature, see the prerequisites for Layer 2 Tunnel Protocol. |
SSG can be configured to support L2TP, so that when a subscriber selects a service through the SESM, the router serves as a LAC and sends the PPP session through the service-specific L2TP tunnel. If the tunnel does not already exist, the LAC creates the proper tunnel to the LNS.
To configure SSG to support L2TP, perform the tasks in the following sections:
To configure SSG as a LAC, use the following command in global configuration mode:
To verify the LAC configuration, enter the show running-config command.
The following vendor-specific attributes are used by the SSG to support L2TP:
For general information on configuring RADIUS profiles for SSG, see the section "Configuring RADIUS Profiles."
Table 1 lists the Cisco-AVpair attributes used in the service profile to configure VPDN.
| 1LNS = L2TP network server. |
Table 2 lists the Account-Info attributes used in the user profile to subscribe the user to a VPDN service.
Table 3 lists the Service-Info attributes used in the service profile to define the L2TP service parameter.
To verify the RADIUS profiles, refer to the user documentation for your RADIUS server.
To configure the L2TP network server (LNS), use the following commands beginning in global configuration mode.
| 1PAP = Password Authentication Protocol
2CHAP = Challenge Handshake Authentication Protocol |
To monitor and maintain the SSG support of L2TP, use the following commands in privileged EXEC mode:
To enable SSG to forward packets locally, use the following command in global configuration mode:
To verify that you have enabled local forwarding, enter the show running-config command.
|
Note This section applies if you are using SSG with the SESM in RADIUS mode or with the SSD. If you are using SSG with the SESM in LDAP mode, see the Cisco Distributed Administration Tool Guide for information on creating and maintaining subscriber, service, and policy information in an LDAP directory, including defining a tunnel service profile. |
SSG uses vendor-specific RADIUS attributes to define RADIUS profiles. You must customize the RADIUS dictionary of the AAA server to incorporate the SSG vendor-specific attributes described in the section "SSG Vendor-Specific Attributes."
You must set up user and service RADIUS profiles on the AAA server as described in this section. Service profiles can also be defined locally as described in the section "Configuring Local Service Profiles." Optionally, you can set up pseudo-service profiles. The following profiles are described:
These profiles contain RADIUS attributes that define specific AAA elements. The syntax for these attributes is described in this section.
Table 4 lists vendor-specific attributes used by SSG. By sending an Access-Request packet with the vendor-specific attributes shown in the table, the SESM can send requests to SSG to log in and log out an account and disconnect and connect services. The vendor ID for all of the Cisco-specific attributes is 9.
| AttrID | VendorID | SubAttrID | SubAttrName | SubAttrDataType |
|---|---|---|---|---|
The following sections describe the format of each subattribute.
|
Note All RADIUS attributes are case sensitive. |
The Cisco-AVpair attributes are used in user and service profiles to configure ACLs and L2TP.
| Attribute | Description |
|---|---|
Downstream Access Control List (outacl) |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user. |
Specifies the secret (the password) used for L2TP tunnel authentication. |
|
Upstream Access Control List (inacl) |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. |
Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections. |
|
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group. |
The Account-Info attributes are used in user profiles and service group profiles.
User profiles define the password, services, and groups to which the user is subscribed.
Service group profiles contain a list of services and service groups and can be used to create sophisticated directory structures for locating and logging in to services. When a user is subscribed to a service group, the user is automatically subscribed to all services and groups within that service group. A service group profile includes the name of the service group, the password, the service type (outbound), a list of services, and a list of other service groups.
The Service-Info attributes are used to define a service. The following attributes define the parameters for a service.
| Attribute | Description |
|---|---|
(Optional) Specifies the primary and secondary DNS servers for this service. |
|
(Optional) Specifies domain names that get DNS resolution from the DNS server specified in DNS Server Address. |
|
Enables usage of the full username (user@service) in the RADIUS authentication and accounting requests. This attribute is supported by SSG with the SSD or the SESM in RADIUS mode. |
|
Specifies the PPP MTU size of SSG as a LAC. By default, the PPP MTU size is 1500 bytes. Note The SESM in LDAP mode does not support the use of this attribute. |
|
(Required for proxy services) Specifies the remote RADIUS server that SSG uses to authenticate and authorize a service login for a proxy service type. This attribute is supported by SSG with the SSD or the SESM in RADIUS mode. |
|
Allows user-defined information to be included in the RADIUS authentication and accounting requests. This attribute is supported by SSG with the SSD or the SESM in RADIUS mode. |
|
(Optional) Provides a description of the service that is displayed to the user. |
|
(Optional) Specifies whether the user is able to log in to this service while simultaneously connected to other services (concurrent) or cannot access any other services while using this service (sequential). The default is concurrent. |
|
(Optional) Specifies the next-hop key for this service. Each SSG uses its own next-hop gateway table that associates this key with an actual IP address. For information on creating a next-hop gateway table, see the section "Next-Hop Gateway Pseudo-Service Profile." |
|
(Required) Specifies networks that exist for the service. Multiple instances of this attribute can occur within a single user profile. |
|
(Optional) Specifies the URL displayed in the SESM HTTP address field when the service opens. |
|
Indicates the username provided by the SESM user to log in to the service and presented for authentication with the home gateway. |
|
(Optional) Indicates whether the service is proxy (requiring remote authentication) or pass-through (not requiring authentication). The default is pass-through. |
The Control-Info attribute is used to define lists or tables of information.
| Attribute | Description |
|---|---|
RADIUS user profiles contain a password, a list of subscribed services and groups, and access control lists.
Table 9 describes attributes that appear in RADIUS user profiles.
| Attribute | Description |
|---|---|
| Cisco-AVPair Attributes | |
Downstream Access Control List (outacl) |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user. |
Upstream Access Control List (inacl) |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. |
| Account-Info Attributes | |
(Reply attribute) Automatically logs a user in to a service when the user logs in to SSG. |
|
(Optional) The URL for the user's preferred Internet home page. |
|
(Reply attribute) Subscribes the user to a service group. Multiple instances of this attribute can occur within a single user profile. Use one attribute for each service group to which the user is subscribed. |
|
(Reply attribute) Subscribes the user to a service. There can be multiple instances of this attribute within a single user profile. Use one attribute for each service to which the user is subscribed. |
|
| Standard Attributes1 | |
Indicates the IP net mask to be configured for the user when the user is a router to a network. This attribute value results in the adding of a static route for Framed-IP-Address with the mask specified. |
|
(Reply attribute) Specifies, in seconds, the maximum length of time for which a connection can remain idle. |
|
(Reply attribute) Specifies, in seconds, the maximum length of the user's session. |
|
| 1Standard attributes are described in detail in RFC 2138. |
The Downstream Access Control List attribute specifies either a Cisco IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.
|
Note Multiple instances of the Downstream Access Control List attribute can occur within a single profile. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and are executed in that order. |
The Upstream Access Control List attribute specifies either a Cisco IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.
|
Note Multiple instances of the Upstream Access Control List attribute can occur within a single profile. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and executed in that order. |
The Auto Service attribute subscribes the user to a service and automatically logs the user in to the service when the user accesses the SESM. A user profile can have more than one Auto Service attribute.
Username used to access the service. Required for proxy services. |
|
Password used to access the service. Required for proxy services. |
|
Note The user must be subscribed to this service. |
The Home URL attribute specifies the URL for the user's preferred Internet home page. This attribute is optional.
If the SESM web application is designed to use HTML frames, the Home URL attribute also specifies whether the home page is displayed in a new browser window or in a frame in the current (SESM) window, as follows:
|
Note In a frameless application, both H and U cause a new browser window to open for the home page. The New World Service Provider (NWSP) application is a frameless application. |
In user profiles, the Service Group attribute subscribes a user to a service group. In service group profiles, this attribute lists the service subgroups that belong to the service group.
|
Note Multiple instances of this attribute can occur within a user or service-group profile. Use one attribute for each service subgroup. |
In user profiles, the Service Name attribute subscribes the user to the specified service. In service-group profiles, this attribute lists services that belong to the service group.
|
Note Multiple instances of this attribute can occur within a user or service profile. Use one attribute for each service. |
The following is an example of a user profile. The profile is formatted for use with a freeware RADIUS server:
The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:
Service profiles include password, service type (outbound), type of service (pass-through or proxy), service access mode (sequential or concurrent), DNS server IP address, networks that exist in the service domain, access control lists, and other optional attributes.
Table 10 describes attributes that appear in RADIUS service profiles.
| Attribute | Description |
|---|---|
| Cisco-AVPair Attributes | |
Downstream Access Control List |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user. |
Upstream Access Control List |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. |
Specifies the secret (the password) used for L2TP tunnel authentication. |
|
Specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections. |
|
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group. |
|
Specifies the number of seconds for the hello keepalive interval. Hello packets are sent when no data has been sent on a tunnel for the number of seconds configured here. |
|
| Service-Info Attributes | |
(Optional) Specifies the primary and/or secondary DNS servers for this service. |
|
(Optional) Specifies domain names that get DNS resolution from the DNS servers specified in DNS Server Address. |
|
Enables usage of the full username (user@service) in the RADIUS authentication and accounting requests. |
|
Specifies the PPP MTU size of SSG as a LAC. By default, the PPP MTU size is 1500 bytes. Note The SESM in LDAP mode does not support the use of this attribute. |
|
(Required for proxy services) Specifies the remote RADIUS servers used by SSG to authenticate and authorize a service login for a proxy service type. |
|
Specifies whether SSG uses the CHAP or PAP protocol to authenticate users for proxy services. |
|
Allows user-defined information to be included in the RADIUS authentication and accounting requests. |
|
(Optional) Provides a description of the service. The description is displayed to the user. |
|
(Optional) Specifies whether the user is able to log in to this service while simultaneously connected to other services (concurrent) or cannot access any other services while using this service (sequential). The default is concurrent. |
|
(Optional) Specifies the next-hop key for this service. Each SSG uses its own next-hop gateway table that associates this key with an actual IP address. For information on creating a next-hop gateway table, see the section "Next-Hop Gateway Pseudo-Service Profile." |
|
(Required) Specifies networks that exist for the service. Multiple instances of this attribute can occur within a single user profile. |
|
(Optional) Specifies the URL displayed in the SESM HTTP address field when the service opens. |
|
(Optional) Indicates whether the service is proxy (requiring remote authentication) or pass-through ( not requiring authentication). The default is pass-through. |
|
| Standard Attributes1 | |
(Reply attribute) Specifies, in seconds, the maximum length of time for which a service connection can remain idle. |
|
(Reply attribute) Specifies, in seconds, the maximum length of the session. |
|
Specifies the level of service (check attribute). Must be "outbound." |
|
| 1Standard attributes are described in detail in RFC 2138. |
The Downstream Access Control List attribute specifies either a Cisco IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.
|
Note Multiple instances of the Downstream Access Control List attribute can occur within a single profile. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and are executed in that order. |
The Upstream Access Control List attribute specifies either a Cisco IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.
|
Note Multiple instances of the Upstream Access Control List attribute can occur within a single profile. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and are executed in that order. |
The L2TP Tunnel Password attribute is the secret (the password) used for L2TP tunnel authentication.
The VPDN IP Address attribute specifies the IP addresses of the home gateways (LNSes) to receive the L2TP connections.
Groups IP addresses on the left side of the slash in higher priority than those on the right side of the slash. |
||
In the following example, the LAC sends the first PPP session through a tunnel to 10.1.1.1, the second PPP session to 10.2.2.2, and the third to 10.3.3.3. The fourth PPP session is sent through the tunnel to 10.1.1.1, and so forth. If the LAC fails to establish a tunnel with any of the IP addresses in the first group, then it attempts to connect to those in the second group (10.4.4.4 and 10.5.5.5).
The VPDN Tunnel ID attribute specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group, as shown in Step 7 in the section "Configuring the LNS."
The L2TP Hello Interval attribute specifies the number of seconds for the hello keepalive interval. Hello packets are sent when no data has been sent on a tunnel for the number of seconds configured here.
The DNS Server Address attribute specifies the primary and secondary DNS servers for this service. If two servers are specified, SSG can send DNS requests to the primary DNS server until performance is diminished or it fails (failover). This attribute is optional.
The Domain Name attribute specifies domain names that get DNS resolution from the DNS servers specified in the DNS server address. This attribute is optional.
Use the DNS Resolution attribute to specify domain names that get DNS resolution from this DNS server. For more information, see the section "Service Access Order."
|
Note Multiple instances of the Domain Name attribute can occur within a single service profile. |
The Full Username attribute indicates that the RADIUS authentication and accounting requests use the full username (user@service). This attribute is supported by SSG with the SSD or the SESM in RADIUS mode.
The size of the full username is limited to the smaller of the following values:
|
Note The SESM in LDAP mode does not support use of the MTU Size attribute. |
The MTU Size attribute specifies the PPP MTU size of SSG as a LAC. By default, the PPP MTU size is 1500 bytes.
The RADIUS Server attribute is supported by SSG with the SSD or the SESM in RADIUS mode.
The RADIUS Server attribute enables AAA server group support for proxy services, which allows you to configure multiple AAA servers. You can configure each remote RADIUS server with timeout and retransmission parameters. SSG will perform failover among the servers in the predefined group.
This attribute specifies the remote RADIUS servers that SSG uses to authenticate, authorize, and perform accounting for a service login for a proxy service type. SSG automatically creates a AAA server group that contains the remote RADIUS server for this service profile. This attribute is used only in proxy service profiles and is required.
The Service Authentication Type attribute specifies whether SSG uses the CHAP or PAP protocol to authenticate users for proxy services.
The Service-Defined Cookie attribute enables you to include user-defined information in RADIUS authentication and accounting requests. This attribute is supported by SSG with the SSD or the SESM in RADIUS mode.
Information of your choice that you wish to include in the RADIUS authentication and accounting requests. The size of the user-defined string is limited to the smaller of the following values: |
|
Note SSG does not parse or interpret the value of the Service-Defined Cookie. You must configure the proxy RADIUS server to interpret this attribute. |
|
Note SSG supports only one Service-Defined Cookie per RADIUS service profile. |
The Service Description attribute describes the service. This attribute is optional.
The Service Mode attribute defines whether the user is able to log in to a service while simultaneously connected to other services (concurrent) or cannot access any other services while using this service (sequential). The default is concurrent. This attribute is optional.
The Service Next-Hop Gateway attribute specifies the next-hop key for a service. Each SSG uses its own next-hop gateway table, which associates this key with an actual IP address. For information on creating a next-hop gateway table, see the section "Next-Hop Gateway Table Entry." This attribute is optional.
The Service Route attribute specifies networks available to the user for a service. This attribute is required.
Use the Service Route attribute to specify networks that exist for a service. For more information, see the section "Service Access Order."
|
Note An Internet service is typically specified as "R0.0.0.0;0.0.0.0" in the service profile. |
|
Note There can be multiple instances of the Service Route attribute within a single service profile. |
The Service URL attribute specifies the URL that is displayed in the SESM HTTP address field when the service opens. This attribute is optional.
If the SESM web application is designed to use HTML frames, then this attribute also specifies whether the service is displayed in a new browser window or in a frame in the current (SESM) window, as follows:
The Type of Service attribute indicates whether the service is proxy, tunnel, or pass-through. This attribute is optional.
P—Pass-through. Indicates that the user's packets are forwarded through the SSG. This is the default. |
The following is an example of a service profile. The profile is formatted for use with a freeware RADIUS server:
The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:
The following is an example of a proxy RADIUS service profile. This profile contains the Service-Defined Cookie attribute and a Full Username attribute.
Service group profiles contain a list of services and service groups and can be used to create directory structures for locating and logging in to services. When a user is subscribed to a service group, the user is automatically subscribed to all services and groups within that service group. A service-group profile includes the password and the service type (outbound) as check attributes and a list of services and a list of service groups as reply attributes.
Table 11 describes attributes that can be used in SSG service-group profiles.
| 1Standard attributes are described in detail in RFC 2138. |
The Group Description attribute provides a description of the service group to the SESM. If this attribute is omitted, the service group profile name is used.
In user profiles, the Service Group attribute subscribes a user to a service group. In service group profiles, this attribute lists the service subgroups that belong to the service group.
|
Note Multiple instances of the Service Group attribute can occur within a user or service-group profile. Use one attribute for each service subgroup. |
In user profiles, the Service Name attribute subscribes the user to the specified service. In service-group profiles, this attribute lists services that belong to the service group.
|
Note Multiple instances of the Service Name attribute can occur within a user or service profile. Use one attribute for each service. |
The following is an example of a service-group profile. The profile is formatted for use with a freeware RADIUS server:
The following is the same service-group profile, formatted for CiscoSecure ACS for UNIX:
This section describes pseudo-service profiles that are used to define variable-length tables or lists of information in the form of services. There are currently two types of pseudo-service profiles: Transparent Pass-Through Filter and Next-Hop Gateway. The following sections describe both profiles.
Transparent pass-through is designed to allow unauthenticated traffic (users or network devices that have not logged in to the SSG through the SESM) to be routed through normal Cisco IOS processing.
Table 12 lists the Cisco AVPair attributes that appear within transparent pass-through filter pseudo-service profiles. The Cisco-AVpair attributes are used to configure ACLs.
| Attribute | Description |
|---|---|
Downstream Access Control List |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user. |
Upstream Access Control List |
Specifies either a Cisco IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user. |
The Downstream Access Control List attribute specifies either a Cisco IOS standard access control list or an extended access control list to be applied to downstream traffic going to the user.
|
Note Multiple instances of the Downstream Access Control List attribute can occur within a single profile. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and are executed in that order. |
This attribute specifies either a Cisco IOS standard access control list or an extended access control list to be applied to upstream traffic coming from the user.
|
Note Multiple instances of the Upstream Access Control List attribute can occur within a single profile. Use one attribute for each access control list statement. Multiple attributes can be used for the same ACL. Multiple attributes are downloaded according to the number specified and are executed in that order. |
The Transparent Pass-Through Filter pseudo-service profile allows or denies access to IP addresses and ports accessed through the transparent pass-through feature.
To define what traffic can pass through, SSG downloads the Transparent Pass-Through Filter pseudo-service profile. This profile contains a list of ACL attributes. Each item contains an IP address or range of IP addresses and a list of port numbers and specifies whether traffic is allowed or denied.
To create a filter for transparent pass-through, create a profile that contains ACL attributes that define what can and cannot be accessed.
You can also create ACLs locally. For more information, see the ssg pass-through command in the Service Selection Gateway Commands document.
The following is an example of the Transparent Pass-Through Filter pseudo-service profile. The profile is formatted for use with a freeware RADIUS server:
The following is the same profile as above, formatted for CiscoSecure ACS for UNIX:
Because multiple SSGs might access services from different networks, each service profile can specify a next-hop key, which is any string identifier, rather than an actual IP address. For each SSG to determine the IP address of the next hop, each SSG downloads its own next-hop gateway table, which associates keys with IP addresses. Table 13 describes the attribute that can be used in Next-Hop Gateway pseudo-service profiles.
Because multiple SSGs might access services from different networks, each service profile specifies a next-hop key rather than an actual IP address. For each SSG to determine the IP address of the next hop, each SSG downloads its own next-hop gateway table, which associates keys with IP addresses. For information on defining next-hop keys, see the section "Service Next-Hop Gateway."
|
Note The Next-Hop Gateway Table Entry attribute is used only in Next-Hop Gateway pseudo-service profiles and should not appear in service profiles or user profiles. |
Use this attribute to create a next-hop gateway table for the selected SSG.
To define the IP address of the next hop for each service, SSG downloads a special service profile that associates the next-hop gateway key for each service with an IP address.
To create a next-hop gateway table, create a service profile and give it any name. Use this attribute to associate service keys with their IP addresses. When you have finished, repeat this process for each SSG.
For more information, see the ssg next-hop command reference page later in this document.
To create a next-hop gateway table, create a profile and give it any name. Use the Next-Hop Gateway Entry attribute to associate service keys with their IP addresses. When you have finished, repeat this process for each SSG if the next-hop IP addresses are different. For an example next-hop gateway pseudo-service profile, see the section "Transparent Pass-Through Filter Pseudo-Service Profile Example."
For more information, see the ssg next-hop command reference page later in this document.
The following is an example of the Next-Hop Gateway pseudo-service profile. The profile is formatted for use with a freeware RADIUS server:
The following is the same Next-Hop Gateway pseudo-service profile, formatted for CiscoSecure ACS for UNIX:
|
Note This section applies if you are using SSG with the SSD or the SESM in RADIUS or LDAP mode. |
This section describes events that generate RADIUS accounting records and the attributes associated with the accounting records sent from SSG to the accounting server.
When a user logs in, SSG sends a RADIUS accounting request on behalf of the user to the accounting server. The following example shows the information contained in the RADIUS accounting-request record:
Table 14 describes the attributes shown in the display.
When a user logs out, the SSG sends a RADIUS accounting request on behalf of the user to the accounting server. The following example shows the information contained in the RADIUS accounting-request record:
Table 15 describes the attributes shown in the display.
When a user accesses a service, SSG sends a RADIUS Accounting-Request to the accounting server. The following example shows the information contained in the RADIUS Accounting-Request record:
Table 16 describes the attributes shown in the display.
When a user terminates a service, SSG sends a RADIUS Accounting-Request to the accounting server. The following example shows the information contained in the RADIUS Accounting-Request record:
Table 17 describes the attributes shown in the display.
The following attributes are used for accounting purposes only. They do not appear in profiles.
The Service User attribute provides the username used by the SESM user to log in to the service and presented for authentication with the home gateway.
|
Note The Service User attribute is used only for accounting purposes and does not appear in profiles. |
The Service Name attribute defines the name of the service.
|
Note The Service Name attribute is used only for accounting purposes and does not appear in profiles. |
Current RADIUS standards support the counting of up to only 32 bits of information with the ACCT-Output-Octets attribute. Standards such as ADSL have much higher throughput.
In order for the accounting server to keep track of and bill for usage, SSG uses the Octets Output attribute.
The Octets Output attribute keeps track of how many times the 32-bit integer rolls over and the value of the integer when it overflows for outbound data.
Value in the 32-bit integer when the stop record is generated and the service or user is logged out. |
Use the Octets Output attribute to keep accurate track of and bill for usage. To calculate the actual number of bytes of data represented by the Octets Output values, use the following formula:
In the following example, rollover is 2 and value is 153 (2 * 232 + 153 = 8589934745):
|
Note The Octets Output attribute is used only for accounting purposes and does not appear in profiles. |
Current RADIUS standards support the counting of up to only 32 bits of information with the ACCT-Input-Octets attribute. Standards such as ADSL have much higher throughput.
In order for the accounting server to keep track of and bill for usage, SSG uses the Octets Input attribute.
The Octets Input attribute keeps track of how many times the 32-bit integer rolls over and the value of the integer when it overflows for inbound data.
Value in the 32-bit integer when the stop record is generated and the service or user is logged out. |
Use the Octets Input attribute to keep accurate track of and bill for usage. To calculate the actual number of bytes of data represented by the Octets Input values, use the following formula:
In the following example, rollover is 3 and value is 151 (3 * 232 + 151 = 12884902039):
|
Note The Octets Input attribute is used only for accounting purposes and does not appear in profiles. |
To monitor and maintain SSG, use the following commands in privileged EXEC mode:
To troubleshoot communication between the RADIUS server and SSG, enter the debug radius command.
This section provides the following configuration examples:
The configuration examples in this section support the network topology shown in Figure 2. These examples apply to SSG used with the SSD or the SESM in RADIUS mode.
The following example shows how to configure SSG for security:
The following example shows how to configure the default network:
The following example shows how to configure uplink and downlink interfaces:
The following example shows how to configure services:
The following is an example service profile as it would appear on the RADIUS server. It is formatted for CiscoSecure ACS for UNIX.
The following example shows how to configure the order in which SSG searches for a service profile:
The following example shows how to configure SSG to download the next-hop table from a RADIUS server:
The following is an example next-hop table as it would appear on the RADIUS server. It is formatted for CiscoSecure ACS for UNIX.
The following example shows how to set the maximum number of services per user:
The following example shows how to configure a local service profile:
The following example shows how to configure a transparent pass-through filter:
The following is an example transparent pass-through filter as it would appear on the RADIUS server. It is formatted for CiscoSecure ACS for UNIX.
The following example shows how to configure redundancy:
The following example shows how to configure the SSG accounting interval:
The following example RADIUS accounting records are sent to the appropriate server every 600 seconds while the user is logged in to the SSG:
The following example shows how to enable IP CEF:
The following example shows how to configure Cisco IOS NAT:
The following examples show how to configure SSG for L2TP services:
The following example shows how to configure the LAC:
The following example shows a basic RADIUS user profile for SSG support of L2TP:
The following example shows a basic RADIUS service profile for SSG support of L2TP:
The following example shows a basic LNS configuration:
The following example shows how to map a service name to a VC:
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2 command reference publications.
To configure an attribute in a local service profile, use the attribute command in profile configuration mode. To delete an attribute from a service profile, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
Use this command to configure attributes in local service profiles.
For the Service Selection Gateway (SSG) Open Garden feature, use this command to configure the Service Route, DNS Server Address, and Domain Name attributes in a local service profile before adding the service to the open garden.
Examples
In the following example, the Cisco-AVpair Upstream Access Control List (inacl) attribute is configured in the local service profile called cisco.com:
In the following example, the Session-Timeout attribute is deleted from the local service profile called cisco.com:
In the following example, an open garden service called "opencisco.com" is defined.
Related Commands
| Command | Description |
|---|---|
Designates a service, defined in a local service profile, to be an open garden service. |
To remove the connections of a given host and a service name, use the clear ssg connection command in privileged EXEC mode.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
Examples
The following example shows how to remove the service connection for Service1 to host 192.168.1.1, connected through Fast Ethernet:
Related Commands
To remove or disable a given host or subscriber, use the clear ssg host command in privileged EXEC mode.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
Examples
The following example shows how to remove the connection for host 192.168.1.1:
Related Commands
| Command | Description |
|---|---|
Displays the information about a subscriber and current connections of the subscriber. |
To remove the next-hop table, use the clear ssg next-hop command in privileged EXEC mode.
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
If you use this command to clear the next-hop table, nothing appears when you use the show ssg next-hop command. However, the next-hop table will still appear in the running configuration. To remove the next-hop table from the running configuration, use the no form of the ssg next-hop command.
Examples
The following example shows how to remove the next-hop table:
Related Commands
| Command | Description |
|---|---|
To remove the downloaded filter for transparent pass-through, use the clear ssg pass-through-filter command in privileged EXEC mode.
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
Removing the filter allows unauthenticated traffic to pass through the Service Selection Gateway in either direction without modification. If you use this command to clear the downloaded transparent pass-through filter, nothing will be displayed when you use the show ssg pass-through-filter command. However, the transparent pass-through filter will still appear in the running configuration. To remove the transparent pass-through filter from the running configuration, use the no form of the ssg pass-through command.
Examples
The following example shows how to remove the downloaded transparent pass-through filter:
Related Commands
To remove all pending commands, use the clear ssg pending-command command privileged EXEC mode.
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
Use this command to clear pending commands.
Examples
The following example shows how to clear pending commands:
Related Commands
| Command | Description |
|---|---|
To remove a service, use the clear ssg service command in privileged EXEC mode.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
Use this command to remove services.
Examples
The following example shows how to remove a service called Perftest:
Related Commands
| Command | Description |
|---|---|
Displays service names that have been bound to interfaces and the interfaces to which they have been bound. |
|
To display all error messages for control modules, use the debug ssg ctrl-errors command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
Use this command to show error messages for the control modules. These modules include all those that manage the user authentication and service login and logout (RADIUS, PPP, Subblock, and Accounting). An error message is the result of an error detected during normal execution.
Examples
The following output is generated by using the debug ssg ctrl-errors command when a host logs in to and logs out from a service:
Related Commands
| Command | Description |
|---|---|
To display all event messages for control modules, use the debug ssg ctrl-events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
This command displays event messages for the control modules, which include all modules that manage the user authentication and service login and logout (RADIUS, PPP, Subblock, and Accounting). An event message is an informational message generated during normal execution.
Examples
The following output is generated by the debug ssg ctrl-events command when a host logs in to a service:
Related Commands
| Command | Description |
|---|---|
To display packet contents handled by control modules, use the debug ssg ctrl-packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
Use this command to show packet messages for the control modules. These modules include all those that manage the user authentication and service login and logout (RADIUS, PPP, Subblock, and Accounting). A packet message displays the contents of a package.
Examples
The following output is generated by using the debug ssg ctl-packets command when a host logs out of a service:
Related Commands
| Command | Description |
|---|---|
To display all data-path packets, use the debug ssg data command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
The debug ssg data command shows packets for the data modules. These modules include all those that forward data packets (Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), tunneling, fast switching, IP stream, and multicast).
Examples
The following output is generated by using the debug ssg data command when a host logs in to and out of a service:
Related Commands
| Command | Description |
|---|---|
To display all data-path packets for Network Address Translation (NAT) processing, use the debug ssg data-nat command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
The debug ssg data-nat command displays packets for the data modules. These modules include all those that forward NAT data packets.
Examples
The following output is generated by using the debug ssg data-nat command when a host logs in to and out of a service:
Related Commands
| Command | Description |
|---|---|
To display all error messages for the system modules, use the debug ssg errors command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
The debug ssg errors command displays error messages for the system modules, which include the basic Cisco IOS and other support modules (such as Object Model, Timeout, and Initialization). An error message is the result of an error detected during normal execution.
Examples
The following output is generated by using the debug ssg errors command when a PPP over Ethernet (PPPoE) client logs in with an incorrect password:
Related Commands
| Command | Description |
|---|---|
To display event messages for system modules, use the debug ssg events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
The debug ssg events command displays event messages for the system modules, which include the basic Cisco IOS modules and other support modules (such as Object Model, Timeout, and Initialization). An event message is an informational message that appears during normal execution.
Examples
The following output is generated by using the debug ssg events command when a PPP over Ethernet (PPPoE) client logs in with the username "username" and the password "cisco":
Related Commands
| Command | Description |
|---|---|
To display packet contents handled by system modules, use the debug ssg packets command in privileged EXEC mode. To disable debugging output, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Command Modes
Command History
Usage Guidelines
The debug ssg packets command displays packet messages for the system modules, which include the basic Cisco IOS and other support modules (Object Model, Timeout, Initialization, etc.). A packet message displays the contents of a package.
Examples
The following output is generated by using the debug ssg packets command when a user is running a telnet session to 192.168.250.12 and pinging 192.168.250.11:
Related Commands
| Command | Description |
|---|---|
To display service names that have been bound to interfaces and the IP addresses to which they have been bound, use the show ssg binding command in privileged EXEC mode.
Syntax Description
Command Modes
Command History
Usage Guidelines
Use this command to display services and the interfaces to which they have been bound.
Examples
The following example shows all service names that have been bound to interfaces:
Related Commands
| Command | Description |
|---|---|
To display the connections of a given host and a service name, use the show ssg connection command in privileged EXEC mode.
Syntax Description
IP address of an active Service Selection Gateway (SSG) connection. This is always a subscribed host. |
|
(Optional) The IP address through which the host is connected. |
Command Modes
Command History
Examples
The following example shows the service connection for the autologon service to host 10.3.6.1:
Related Commands
| Command | Description |
|---|---|
To display the direction of all interfaces for which a direction has been specified, use the show ssg direction privileged EXEC command.
Syntax Description
Command Modes
Command History
Usage Guidelines
Use this command to show all interfaces that have been specified as uplinks or downlinks.
Examples
The following example shows the direction of all interfaces that have been specified as uplinks or downlinks.
Related Commands
| Command | Description |
|---|---|
To display the information about a subscriber and current connections of the subscriber, use the show ssg host command in privileged EXEC mode.
Syntax Description
Defaults
If no argument is provided, all current connections are displayed.
Command Modes
Command History
Examples
The following example shows all active hosts:
The following example shows information about host 10.3.1.1:
The following example shows two host objects with the same IP address:
In this case, use the interface argument to uniquely identify the host:
Note that the output produced by this command is the same as that produced by the command without the interface argument. The interface argument is used only to uniquely identify a host when there are overlapping host IP addresses.
The following example shows the usernames logged in to the active hosts:
Related Commands
| Command | Description |
|---|---|
Beginning in Cisco IOS Release 12.2(4)B, this command is no longer supported.
To display the next-hop table, use the show ssg next-hop command in privileged EXEC mode.
Syntax Description
Command Modes
Command History
Usage Guidelines
Use this command to display all next-hop IP addresses.
Examples
The following example shows the next-hop table:
Related Commands
| Command | Description |
|---|---|
To display the downloaded filter for transparent pass-through, use the show ssg pass-through-filter command in privileged EXEC mode.
Syntax Description
Command Modes
Command History
Usage Guidelines
Use this command to display the downloaded transparent pass-through filter. The filter prevents pass-through traffic from accessing the specified IP address and subnet mask combinations. The filter is set using the ssg pass-through command.
To display a filter defined on the command line, use the show running-config command.
Examples
The following example shows the pass-through filter:
Related Commands
| Command | Description |
|---|---|
To display current pending commands, such as next-hop or filters, use the show ssg pending-command command in privileged EXEC mode.
Syntax Description
This command has no keywords or arguments.
Command Modes
Command History
Usage Guidelines
Use this command to display the current pending commands.
Examples
The following example shows the pending commands:
Related Commands
| Command | Description |
|---|---|
To display the information for a service, use the show ssg service privileged EXEC command.
Syntax Description
(Optional) Name of an active Service Selection Gateway (SSG) service. |
|
(Optional) Word or phrase used to determine what lines will be shown. |
|
Defaults
If no service name is provided, the command displays information for all services.
Command Modes
Command History
Usage Guidelines
Use this command to display connection information for a service.
Examples
The following example shows the information for the service called serv1-proxy:
Related Commands
| Command | Description |
|---|---|
Displays service names that have been bound to interfaces and the interfaces to which they have been bound. |
|
To display virtual circuit (VC)-to-service-name mappings, use the show ssg vc-service-map command in global configuration mode.
Syntax Description
(Optional) Virtual path identifier (VPI)/virtual channel identifier (VCI) value, including the slash, for example, 3/33. |
|
Command Modes
Command History
Usage Guidelines
Use this command to display VC-to-service-name mappings.
Examples
The following example shows the VCs mapped to the service name "Worldwide":
Related Commands
| Command | Description |
|---|---|
To enable SSG accounting, use the ssg accounting command in global configuration mode. To disable SSG accounting interval, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Defaults
Accounting is enabled by default.
Command Modes
Command History
Usage Guidelines
The ssg accounting command enables the sending of start, stop, and interim accounting records for hosts and connections.
Examples
The following example shows how to re-enable SSG accounting if it has been disabled:
Related Commands
| Command | Description |
|---|---|
Specifies the interval at which accounting updates are sent to the accounting server. |
To specify the interval at which accounting updates are sent to the accounting server, use the ssg accounting interval command in global configuration mode. To disable the accounting interval, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
Usage Guidelines
Use this command to specify the interval at which accounting updates are sent to the accounting server.
Examples
The following example shows how to specify that Service Selection Gateway will send an accounting update to the accounting server every 60 seconds:
Related Commands
| Command | Description |
|---|---|
To specify an interface as a downlink or uplink interface, use the ssg bind direction command in global configuration mode. To disable the directional specification for the interface, use the no form of this command.
Syntax Description
Defaults
All interfaces are configured as uplink interfaces by default.
Command Modes
Command History
Usage Guidelines
Use this command to specify an interface as downlink or uplink. An uplink interface is an interface to services; a downlink interface is an interface to subscribers.
Examples
The following example shows how to specify an ATM interface as a downlink interface:
Related Commands
| Command | Description |
|---|---|
Displays service names that have been bound to interfaces and the interfaces to which they have been bound. |
To specify the interface for a service, use the ssg bind service command in global configuration mode. To unbind the service and the interface, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
Use this command to bind a service to an interface.
Examples
The following example shows the interface for the service defined as MyService:
Related Commands
| Command | Description |
|---|---|
Displays service names that have been bound to interfaces and the interfaces to which they have been bound. |
|
To specify the default network IP address or subnet and mask, use the ssg default-network command in global configuration mode. To disable the default network IP address and mask, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
| Release | Modification |
|---|---|
This command was introduced on the Cisco 6400 node route processor. |
|
This command was integrated into Cisco IOS Release 12.2(4)B. |
Usage Guidelines
Use this command to specify the first IP address or subnet that users will be able to access without authentication. This is the address where the Cisco Service Selection Dashboard (SSD) resides. After users enter the URL for the Cisco SSD, they will be prompted for a username and password. A mask provided with the IP address specifies the range of IP addresses that users will be able to access without authentication.
Examples
The following example shows a default network IP address, 192.168.1.2, and mask 255.255.255.255:
Beginning in Cisco IOS Release 12.2(4)B, this command is no longer supported.
To enable Service Selection Gateway (SSG), use the ssg enable command in global configuration mode. To disable NRP-SSG, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
This command was integrated into Cisco IOS Release 12.2(4)B. |
|
This command was integrated into Cisco IOS Release 12.2(11)T. |
Examples
The following example shows how to enable SSG:
Beginning in Cisco IOS Release 12.2(4)B, this command is no longer supported.
Beginning in Cisco IOS Release 12.2(4)B, this command is no longer supported.
Beginning in Cisco IOS Release 12.2(4)B, this command is no longer supported.
To enable Service Selection Gateway (SSG) to forward packets locally, use the ssg local-forwarding global configuration command. To disable local forwarding, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Defaults
Command Modes
Command History
Examples
The following example enables local forwarding.
To set the maximum number of services per user, use the ssg maxservice global configuration command. To reset the maximum number of services per user to the default, use the no form of this command.
Syntax Description
Defaults
The default maximum number of services per user is 20.
Command Modes
Command History
Usage Guidelines
Use this command to limit the number of services to which a user can be logged on simultaneously.
Examples
The following example shows how to set the maximum number of services per user to 10:
Beginning in Cisco IOS Release 12.2(4)B, this command is no longer supported.
To download the next-hop table from a RADIUS server, use the ssg next-hop command in global configuration mode. To remove the command from the configuration, use the no form of this command.
Syntax Description
Defaults
If no profile name and password are provided, the previous profile specified with this command is downloaded. If no previous profile was specified, an error message is generated.
Command Modes
Command History
Usage Guidelines
When this command is used, an entry is made in the running configuration. When the configuration is reloaded, the next-hop table is automatically downloaded. If the no form of this command is used to remove the command from the running configuration, a next-hop table will not be automatically downloaded when the configuration is reloaded.
Examples
The following example shows how to download the next-hop table called "MyProfile" from a RADIUS server:
Related Commands
| Command | Description |
|---|---|
To enable transparent pass-through, use the ssg pass-through command in global configuration mode. To disable transparent pass-through, use the no form of this command
Syntax Description
Defaults
Transparent pass-through is disabled by default.
Command Modes
Command History
Usage Guidelines
Use this command to enable transparent pass-through if you want to allow unauthenticated traffic to pass through the SSG in either direction without modification. If you want all traffic to be authenticated by the SSG, use this command to disable transparent pass-through. You can use the filter option to prevent pass through traffic from accessing the specified IP address and subnet mask combinations.
Use the no form of this command to remove a transparent pass-through filter that was configured at the command line. This will also remove it from the running configuration.
Examples
The following example shows how to enable ssg transparent pass-through and download a pass-through filter from the AAA server called "filter01":
Related Commands
To enable caching of user profiles for non-PPP users, use the ssg profile-cache command in global configuration mode. To disable caching of user profiles, use the no form of this command.
Syntax Description
This command has no arguments or keywords.
Defaults
User-profile caching is not enabled.
Command Modes
Command History
| Release | Modification |
|---|---|
This command was integrated into Cisco IOS Release 12.2(4)B. |
|
This command was integrated into Cisco IOS Release 12.2(11)T. |
Usage Guidelines
The ssg profile-cache command allows Service Selection Gateway (SSG) to cache the user profiles of non-PPP users. User profiles of PPP and RADIUS proxy users are always cached by SSG by default. In situations in which the user profile is not available from other sources, SSG user-profile caching makes the user profile available for RADIUS status queries, providing support for single-sign-on functionality and for failover from one Subscriber Edge Services Manager (SESM) to another.
In order for a user profile to be cached, the ssg profile-cache command must be configured before account login occurs. Once the user authentication has been done (as part of the account login), the host object is created, and the user profile is cached.
|
Note If you are using SSG with the SESM in Lightweight Directory Access Protocol (LDAP) mode, you may want to disable SSG user-profile caching in order to save memory and improve scalability. SSG user-profile caching is required only when SSG is used with the SESM in RADIUS mode. |
Examples
The following example shows how to enable user-profile caching:
To enable communications with the Cisco Service Selection Dashboard (SSD) and specify port numbers and secret keys for receiving packets, use the ssg radius-helper command in global configuration mode. To disable communications with the Cisco SSD, use the no form of this command.
Syntax Description
| 1UDP = User Datagram Protocol |
Defaults
The default port number for acct-port is 1646.
The default port number for auth-port is 1645.
Command Modes
Command History
Usage Guidelines
You must use this command to specify a key so that SSG can communicate with the Cisco SSD.
Examples
The following example shows how to enable communication with the Cisco SSD:
To specify the password for downloading a service profile, use the ssg service-password command in global configuration mode. To disable the password, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
This command sets the password required to authenticate with the authentication, authorization, and accounting (AAA) server and download a service profile.
Examples
The following example shows how to set the password for downloading a service profile:
To specify the order in which Service Selection Gateway (SSG) searches for a service profile, use the ssg service-search-order command in global configuration mode. To disable the search order, use the no form of this command.
Syntax Description
Search for service profiles in local Flash memory, then on a RADIUS server. |
|
Search for service profiles on a RADIUS server, then in local Flash memory. |
Defaults
The default search order is remote; that is, SSG searches for service profiles on the RADIUS server.
Command Modes
Command History
Usage Guidelines
SSG can search for service profiles in local Flash memory, on a remote RADIUS server, or both. The possible search orders are:
Examples
The following example shows how to set the search order to local remote, so that SSG will always look for service in Flash memory first, then on the RADIUS server:
Related Commands
| Command | Description |
|---|---|
To map virtual circuits (VCs) to service names, use the ssg vc-service-map command in global configuration mode. To disable VC-to-service-name mapping, use the no form of this command.
Syntax Description
Defaults
The service mapping is non-exclusive by default.
Command Modes
Command History
Usage Guidelines
Use this command to map VCs to service names. If you specify a VC-to-service-name mapping as exclusive, specifying a username will log you in to the mapped service. However, specifying username@service will not log you in. If you specify a mapping as nonexclusive, specifying a username will log you in to the mapped service. However, username@service1 will log you in to service1.
Examples
The following example shows how to map all users coming into SSG on VPI/VCI 3/33 to the service "Worldwide" exclusively:
Related Commands
| Command | Description |
|---|---|
Beginning in Cisco IOS Release 12.2(4)B, this command is no longer supported.
This section summarizes the differences between SSG in Cisco IOS Release 12.2(2)B and earlier releases and Cisco IOS Release 12.2(4)B and later releases. It includes the following sections:
Table 18 summarizes the new and changed SSG functionality and behavior in Cisco IOS Release 12.2(4)B and later releases. Note that all of the new and changed SSG functionality in Cisco IOS Release 12.2(4)B is also present in Cisco IOS Release 12.2(11)T.
Beginning in Cisco IOS Release 12.2(4)B, the following commands are obsolete and are no longer supported:
AAA—authentication, authorization, and accounting. A framework of security services that provide the method for identifying users (authentication), for remote access control (authorization), and for collecting and sending security server information used for billing, auditing, and reporting (accounting).
address mask—A bit mask used to select bits from an Internet address for subnet addressing. The mask is 32 bits long and selects the network portion of the Internet address and one or more bits of the local portion. Sometimes called subnet mask.
ADSL—asymmetric digital subscriber line. A digital subscriber line (DSL) technology in which the transmission of data from server to client is much faster than the transmission from the client to the server.
CEF—Cisco Express Forwarding. Advanced Layer 3 IP switching technology that optimizes network performance and scalability for networks with large and dynamic traffic patterns, such as the Internet, on networks characterized by intensive web-based applications or interactive sessions.
CHAP—Challenge Handshake Authentication Protocol. Security feature supported on lines using PPP encapsulation that prevents unauthorized access. Compare with PAP.
DHCP—Dynamic Host Configuration Protocol. Protocol that provides a mechanism for allocating IP addresses dynamically so that addresses can be reused when hosts no longer need them.
DNS—Domain Name Server. The part of the distributed database system for resolving a fully qualified domain name into the four-part IP number used to route communications across the Internet.
DSLAM—digital subscriber line access multiplexer. A device that connects many digital subscriber lines to a network by multiplexing the DSL traffic onto one or more network trunk lines.
IPCP—IP Control Protocol. Protocol that establishes and configures IP over PPP.
L2TP—Layer 2 Tunnel Protocol. An Internet Engineering Task Force (IETF) standards track protocol defined in RFC 2661 that provides tunneling of PPP.
LAC—L2TP access concentrator. A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP network server (LNS).
LNS—L2TP network server. A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP access concentrator (LAC).
NAS—network access server. A device providing local network access to users across a remote access network such as the PSTN.
NAT—Network Address Translation. A mechanism for reducing the need for globally unique IP addresses. NAT allows an organization with addresses that are not globally unique to connect to the Internet by translating those addresses into globally routable address space.
NRP—node route processor. One of the component modules used in the Cisco 6400 series. This module is the Layer 3 element for the Cisco 6400 series and is responsible for implementing the routing function.
NSP—node switch processor. One of the component modules used in the Cisco 6400 series. This module is responsible for all ATM switching and control functions within the Cisco 6400 series.
octet—A networking term that identifies 8 bits. In TCP/IP, it is used instead of byte because some systems have bytes that are not equal to 8 bits.
PAP—Password Authentication Protocol. Authentication protocol that allows PPP peers to authenticate one another. Unlike CHAP, PAP passes the password and host name or username in the clear (unencrypted). PAP is supported only on PPP lines. Compare with CHAP.
PTA—PPP Termination Aggregation. A method of aggregating IP traffic by terminating PPP sessions and aggregating the IP traffic into a single routing domain.
PTA-MD—PTA Multi-Domain. A method of aggregating IP traffic by terminating PPP sessions and aggregating the IP traffic into a VPN or multiple IP routing domains.
SSD—Service Selection Dashboard. The SSD is a customizable web-based application that works with the Cisco SSG to allow end customers to log in to and disconnect from proxy and pass-through services through a standard web browser. After the customer logs in to the service provider's network, an HTML dashboard is populated with the services authorized for that user.
SSG—Service Selection Gateway.
subnet mask—32-bit address mask used in IP to indicate the bits of an IP address that are being used for the subnet address.
VC—virtual connection. A link that seems and behaves like a dedicated point-to-point line or a system that delivers packets in sequence, as happens on an actual point-to-point network.
VCI—virtual channel identifier. A 16-bit field in the header of an ATM cell. The VCI, together with the VPI, is used to identify the next destination of a cell as it passes through a series of ATM switches on its way to its destination.
VPI—virtual path identifier. An 8-bit field in the header of an ATM cell. The VPI, together with the VCI, is used to identify the next destination of a cell as it passes through a series of ATM switches on its way to its destination.
Posted: Wed Jan 15 12:53:38 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
