Downloads |
Table Of Contents
Implementing SSG: Initial Tasks
Prerequisites for Implementing SSG
Restrictions for Implementing SSG
How to Establish Initial SSG Communication
SSG and Cisco Express Forwarding
System Resource Cleanup When SSG Is Unconfigured
Configuring SSG Interface Direction
Uplink Interface Redundancy Overview
Downlink Interface Redundancy Overview
SSG Uplink Interface Redundancy Topologies
Setting SSG Interface Direction for an Individual Interface
Setting the Direction on an ATM Subinterface (with PVC or PVC Range)
Verifying SSG Interface Binding
Configuring the Default Network
Processing of Default Network Traffic
Configuring SSG-SESM API Communication
Configuring SSG Port-Bundle Host-Key Functionality
Port-Bundle Host-Key Mechanism
Benefits of SSG Port-Bundle Host-Key
Prerequisites for SSG Port-Bundle Host-Key
Restrictions for SSG Port-Bundle Host-Key
Configuring the SSG Port-Bundle Host-Key
Verifying SSG Port-Bundle Host-Key Configuration
Configuring SSG to AAA Server Interaction
Monitoring and Maintaining Initial SSG Communication
Troubleshooting Initial SSG Communication
Configuration Examples for Establishing Initial SSG Communication
SSG Interface Direction: Examples
SSG Interface Redundancy: Examples
SSG Port-Bundle Host-Key Configuration: Example
SSG and AAA Server Interaction Configuration: Example
Establishing Initial SSG Communication: Example
Feature Information for Implementing SSG
Implementing SSG: Initial Tasks
First Published: May 2, 2005Last Updated: October 2, 2009
Note
Effective with Cisco IOS Release 15.0(1)M, this feature is not available in Cisco IOS software.
This document describes the initial tasks you need to perform to enable SSG on the router and to establish SSG communication with other key components of the network, including Subscriber Edge Services Manager (SESM) and the authentication, authorization, and accounting (AAA) server.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Implementing SSG" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
Prerequisites for Implementing SSG
Knowledge
Before configuring SSG, you should understand the concepts in Overview of SSG.
Interfaces
SSG is supported on all logical and physical interfaces on which Cisco Express Forwarding (CEF) switching is supported. This includes physical interfaces such as ATM, Ethernet, and Packet-over-SONET (POS), and logical interfaces such as GRE, 802.1q virtual LANs, and Point-to-Point Protocol (PPPoX).
CEF Switching
IP CEF must be enabled globally before SSG will work.
Cisco Subscriber Edge Services Manager
If you want to perform Layer 3 service selection, you must install and configure Cisco SESM as described in the Cisco Subscriber Edge Services Manager Administration and Configuration Guide.
AAA or LDAP
An authentication, authorization, and accounting (AAA) RADIUS server or LDAP server are typically used to authenticate subscribers and to store subscriber and service profiles.
Restrictions for Implementing SSG
SSG does not process IP multicast packets. IP multicast packets will be handled by Cisco IOS software in the traditional way.
How to Establish Initial SSG Communication
To enable SSG and establish SSG communication with other network devices, perform the tasks in the following sections:
•
•
•
–
–
•
•
Enabling SSG
Perform this task to enter global configuration and enable SSG on the router.
Note
SSG and Cisco Express Forwarding
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. CEF must be enabled for SSG to work.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
System Resource Cleanup When SSG Is Unconfigured
When you enable SSG, the SSG subsystem in Cisco IOS software acquires system resources that are never released unless the router is rebooted. To release and clean up system resources acquired by SSG, use the no ssg enable force-cleanup command.
Configuring SSG Interface Direction
Before you can configure SSG interfaces, you need to understand the following concepts:
•
•
•
Perform the following tasks to configure SSG interfaces:
•
•
•
Interface Direction
SSG implements service selection through selective routing of IP packets to destination networks on a per-subscriber basis. SSG uses the concept of interface direction (uplink or downlink) to help determine the forwarding path of incoming packets. An uplink interface is an interface towards the services; a downlink interface is an interface towards the subscribers. You can configure interface direction for a single interface or a range of subinterfaces at once.
Uplink Interface Redundancy Overview
In SSG, each service is associated with an uplink interface, configured by binding the service to the next-hop or to an interface. When a subscriber chooses to use a service, SSG connects the subscriber to the service through the associated uplink interface. SSG interface redundancy allows services to be associated with more than one interface to protect against link failures.
When redundant interfaces are configured for a service, the distance metric assigned to the service binding is used to determine the order in which SSG selects the interface to be used to reach a service. The interface for the service binding with the lowest metric is the primary interface. The interface for the service binding with the second-lowest weight is the secondary interface, and so on.
If a failure occurs on an active interface, SSG recognizes the failure and switches the traffic to the interface associated with the next-lowest metric. When the primary uplink interface or next hop becomes available again, SSG switches traffic back to the primary interface.
Note
If a host has a connection that uses NAT to one of the services on a set of redundant uplink interfaces, all traffic from a user to any of the uplink interfaces uses NAT.
SSG interface redundancy can be configured for pass-through and proxy services, including open garden services, walled garden services, and the default network. This feature is supported on all physical and logical interfaces that SSG supports.
SSG uplink interface redundancy is configured by binding a service to more than one interface or next hop and grouping the redundant interfaces to ensure that SSG treats them similarly. See the "Configuring Services for Subscribers" module for information about how to bind services. To group redundant uplink interfaces, see the "Setting SSG Interface Direction for an Individual Interface" section
Downlink Interface Redundancy Overview
Subscriber traffic can be received by SSG on any of the downlink configured interfaces, which allows for downlink interface redundancy.
The SSG Downlink Interface Redundancy feature can be configured with or without the Port-Bundle Host-Key (PBHK) feature. When PBHK is disabled, downlink interface redundancy is the default behavior. When PBHK is enabled, you must disable SSG's support of overlapping host IP addresses with the no host overlap command. For more information on configuring PBHK, see the "Configuring SSG Port-Bundle Host-Key Functionality" section.
SSG Uplink Interface Redundancy Topologies
The SSG Interface Redundancy feature supports uplink interface redundancy in the following network topologies:
•
•
•
•
Multiple Next Hops per Service
Figure 1 shows an example of SSG interface redundancy configured to support multiple next-hop IP addresses per service. In this type of topology, each next hop is routable on a different uplink interface. SSG forwards traffic to the appropriate next hop on the basis of the distance metric assigned to it.
Figure 1 Multiple Next Hops per Service: Sample Topology
Multiple Uplink Interfaces with a Single Next Hop
Figure 2 shows an example of SSG interface redundancy configured to support multiple uplink interfaces that share a single next hop. In this type of topology, routing to the service is governed by the active route to the next-hop IP address, as dictated by the global routing table.
Figure 2 Multiple Uplink Interfaces with a Single Next Hop: Sample Topology
Multiple Uplink Interfaces with No Next Hop
Figure 3 shows an example of SSG interface redundancy configured to support multiple uplink interfaces that are directly connected to the service.
Figure 3 Multiple Uplink Interfaces with No Next Hop: Sample Topology
Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops
Figure 4 shows an example of SSG interface redundancy configured to support an uplink interface that is directly connected to the service and an uplink interfaces with a next hop.
Figure 4 Combination of Directly Connected Uplink Interfaces and Interfaces with Next Hops: Sample Topology
Restrictions
When you configure a range of ATM permanent virtual circuits (PVCs) using the range command, you cannot use the ssg direction command on an individual subinterface. All members of a range must have the same direction.
An interface that does not exist will not be created as a result of the ssg direction command.
Before you can change a direction from uplink to downlink, or the opposite, you must use the no ssg direction command to clear the direction. If you do not, you will receive an error message similar to the following:
Changing direction from Downlink to Uplink is denied for interface interfacePlease use `no ssg direction downlink' to clear the previous bind directionSetting SSG Interface Direction for an Individual Interface
Perform this task to configure interface direction for an individual interface.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Setting the Direction on an ATM Subinterface (with PVC or PVC Range)
Uplink or downlink direction can be set on ATM subinterfaces (both point-to-point and multipoint) similar to any other interface (as explained in Setting SSG Interface Direction for an Individual Interface). However, if the point-to-point ATM subinterface contains a PVC range, this will result in several ATM subinterfaces getting created implicitly, as explained in the guide: ATM PVC Range and Routed Bridge Encapsulation Subinterface Grouping. In this case, all ATM subinterfaces in this PVC range will inherit the same SSG bind direction.
Perform this task to configure a range of subinterfaces as uplink or downlink. An uplink interface is an interface to services; a downlink interface is an interface to subscribers.
Restrictions
All subinterfaces in a range must have the same direction. If you try to specify the direction of an interface that is part of a PVC range, you receive an error similar to the following:
PVC Range: Configuring interface is not allowed.SUMMARY STEPS
1.
2.
3.
or
4.
DETAILED STEPS
Verifying SSG Interface Binding
Perform this task to verify the binding of SSG interfaces.
SUMMARY STEPS
1.
DETAILED STEPS
Step 1
show ssg interface [brief] [interface-type interface-number]
Example:Router# show ssg interface briefDisplays information about SSG interfaces.
Example
The following examples of output for the show ssg interface command show information about SSG interface binding:
Router# show ssg interfaceInterface: Ethernet1/1Bind Direction: DownlinkBinding Type: StaticInterface: ATM4/0.40Bind Direction: DownlinkBinding Type: StaticInterface: ATM4/0.140Bind Direction: UplinkBinding Type: StaticServices bound: NONERouter# show ssg interface briefInterface Direction Binding TypeEthernet1/1 Downlink StaticATM4/0.40 Downlink StaticATM4/0.140 Uplink StaticConfiguring the Default Network
SSG allows all users, even unauthenticated users, to access the default network. Typically, SESM belongs to the default network. However, other types of servers, such as DNS/DHCP servers or TCP-Redirect servers, can also be part of the default network. Perform this task to specify an IP address or an IP subnet as the default network.
Processing of Default Network Traffic
Traffic to and from the default network requires special processing by SSG. This is because traffic to and from SESM (Captive Portal and NWSP) requires special processing, and SSG cannot distinguish between SESM and non-SESM traffic. To reduce processing overhead for SSG, we recommend that you define the SESM server as the default network and place other servers in the Open Garden network.
Note
Packets from a User and Destined for the Default Network
If the port-bundle host-key is:
•
•
Packets from the Default Network and Destined for an SSG User
SSG forwards the packets through the RP if either of the following conditions are met:
•
•
Otherwise, SSG forwards the packets through the PXF forwarding engine.
SUMMARY STEPS
1.
DETAILED STEPS
Configuring SSG-SESM API Communication
To support subscriber login, subscriber logout, and service selection, SSG acts as a server listening for RADIUS-based SESM commands. Perform this task to establish communication between SSG and SESM.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring SSG Port-Bundle Host-Key Functionality
Before you configure the SSG Port-Bundle Host-Key (PBHK) feature, you should understand the following concepts:
•
•
•
•
Perform the following tasks to configure SSG Port-Bundle Host-Key functionality
•
•
Port-Bundle Host-Key Mechanism
When the SSG Port-Bundle Host-Key feature is enabled, SSG performs port-address translation (PAT) and network-address translation (NAT) on the HTTP traffic between the subscriber and the SESM server. The operation of changing the subscriber's IP address and port is commonly known as a port-map operation, and the mappings between the original and changed IP address and port are known as port-mappings.
When a subscriber sends traffic to the SESM server, SSG creates a port map that changes the source IP address to a configured SSG source IP address and the source TCP port to a port allocated by SSG. SSG assigns a range of ports, known as a port-bundle, to each subscriber because one subscriber can have several simultaneous TCP sessions when accessing a web page. The assigned host-key, or combination of SSG source IP address and port-bundle, uniquely identifies each subscriber.
When the Port-Bundle Host-Key feature is not enabled, the subscriber is uniquely identified by their IP address. When the SESM server sends a reply to the subscriber, SSG translates the destination IP address and TCP port to the subscriber's actual IP address.
The host-key is carried in RADIUS packets sent between the SESM server and SSG in the Subscriber IP vendor-specific attribute (VSA), and uniquely identifies the subscriber. Table 1 describes the Subscriber IP VSA. When the SESM server sends a reply to the subscriber, SSG translates the destination IP address and destination TCP port according to the port map.
For each new subscriber, SSG assigns a new port-bundle. The number of port-bundles is limited, but you can assign multiple SSG source IP addresses to accommodate more subscribers. If the subscriber logs in, SSG maintains the port-bundles as long as the host is active. If the subscriber does not log in, SSG will recycle the port-bundle after a period of inactivity.
For each new TCP session between a subscriber and the SESM server, SSG uses one port from the port bundle for the port mapping. Port mappings are flagged as eligible for reuse on the basis of inactivity timers, but are not explicitly removed once assigned. The number of port bundles is limited, but you can assign multiple SSG source IP addresses to accommodate more subscribers.
Port-Bundle Length
The port-bundle length determines the number of ports that are assigned to one subscriber (number-of-ports = 2 ^ port-bundle length). By default, the port-bundle length is 4 bits, which yields 16 ports available for each subscriber. The maximum port-bundle length is 10 bits, which would support 1024 concurrent sessions to SESM. See Table 2 for available port-bundle length values, the number of ports-per-bundle, and the number of bundles-per-IP address. Increasing the port-bundle length can be useful when you see frequent error messages about running out of ports in a port bundle.
Note
Benefits of SSG Port-Bundle Host-Key
Scalable with Multiple Subscriber Subnets
Without the SSG Port-Bundle Host-Key feature, SESM must be provisioned for a static mapping between subscriber subnets and SSG IP addresses. The SSG Port-Bundle Host-Key feature eliminates the need for static mapping because the host-key contains the SSG's IP address, which SESM uses to identify which SSG is servicing the subscriber.
Reliable and Just-in-Time Notification to Cisco SSD of Subscriber State Changes
Without the SSG Port-Bundle Host-Key feature, SSG uses an asynchronous messaging mechanism to immediately notify the SESM server of subscriber state changes in SSG (such as session timeouts or idle timeout events).
The SSG Port-Bundle Host-Key feature replaces the asynchronous messaging mechanism with an implicit and reliable notification mechanism that uses the base port of a port bundle to alert the SESM server of a state change. The SESM server can then query SSG for the true state of the subscriber and update the cached object or send the information back to the subscriber.
Support for Overlapped PPP Subscribers
With the SSG Port-Bundle Host-Key feature, PPP users can have overlapped IP addresses while using SESM for service selection.
Prerequisites for SSG Port-Bundle Host-Key
The SSG Port-Bundle Host-Key feature requires Cisco SESM Release 3.1(1) or higher.
A default network must be configured and routable from SSG in order to configure the Port-Bundle Host-Key commands:
Note
Restrictions for SSG Port-Bundle Host-Key
The SSG Port-Bundle Host-Key feature has the following restrictions:
•
•
•
•
•
•
•
•
•
Configuring the SSG Port-Bundle Host-Key
To use SSG port-bundle host-key functionality, you must enable the feature, specify the subscriber traffic to be port-mapped, and specify the SSG source IP addresses. You can also optionally specify the port-bundle length. Perform this task to configure the SSG port-bundle host-key functionality.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Verifying SSG Port-Bundle Host-Key Configuration
Perform this task to verify SSG port-bundle host-key configuration and operation.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Step 1
Step 2
Router# show ssg port-map statusBundle-length = 4Bundle-groups:-IP Address Free Bundles Reserved Bundles In-use Bundles70.13.60.2 4032 0 0Use the show ssg port-map status command with the free, reserved, or inuse keyword to display port bundles with the specified status:
Router# show ssg port-map status inuseBundle-group 70.13.60.2 has the following in-use port-bundles:Port-bundle Subscriber Address Interface64 10.10.3.1 Virtual-Access2Step 3
Router# show ssg port-map ip 70.13.60.2 port 64State = IN-USESubscriber Address = 10.10.3.1Downlink Interface = Virtual-Access2Port-mappings:-Subscriber Port: 3271 Mapped Port: 1024Subscriber Port: 3272 Mapped Port: 1025Subscriber Port: 3273 Mapped Port: 1026Subscriber Port: 3274 Mapped Port: 1027Subscriber Port: 3275 Mapped Port: 1028
Configuring SSG to AAA Server Interaction
SSG communicates with a AAA server for authorization, authentication and accounting using the RADIUS protocol. SSG and the AAA server interact to authenticate subscribers, and to retrieve subscriber and service profiles. Perform this task to configure the shared key between SSG and the AAA server.
Prerequisites
In order for SSG to communicate with SESM and the AAA servers, the AAA servers must be configured correctly. See the Cisco IOS Security Configuration Guide and Cisco IOS Security Command Reference for the AAA and RADIUS commands and tasks for configuring AAA servers.
SUMMARY STEPS
1.
DETAILED STEPS
Monitoring and Maintaining Initial SSG Communication
Perform this task to monitor and maintain initial SSG communication. The commands do not have to be entered in a particular order.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Troubleshooting Initial SSG Communication
Perform the following steps to troubleshoot the communication between SSG and the AAA server:
SUMMARY STEPS
1.
2.
DETAILED STEPS
Configuration Examples for Establishing Initial SSG Communication
This section contains the following examples:
•
•
•
•
•
SSG Interface Direction: Examples
Setting the Direction of a Single Interface: Example
The following example shows how to configure Fast Ethernet interface 1/0 as a downlink interface:
ip cefssg enable!interface FastEthernet 1/0ssg direction downlinkSetting the Direction of a Range of PVCs: Example
The following example show how to create a range called "MyRange" and set the direction of all subinterfaces in the range to downlink:
ip cefssg enable!interface ATM 1/0.1 point-to-pointrange MyRange pvc 1/32 1/42exitssg direction downlink
SSG Interface Redundancy: Examples
Service Bound to Multiple Uplink Interfaces: Example
In the following example, a service called "sample-service" is bound to two uplink interfaces: ATM interface 1/0.1 is the primary interface, and ATM interface 1/0.2 is the secondary interface. Both interfaces are configured as members of groupA.
ip cefssg enable!ssg bind service sample-service atm 1/0.1ssg bind service sample-service atm 1/0.2 100!interface ATM 1/0.1 point-to-pointip address 10.1.0.1 255.255.0.0ssg direction uplink member groupA!interface ATM 1/0.2 point-to-pointip address 10.2.0.1 255.255.0.0ssg direction uplink member groupA!Service Bound to Next Hop with Multiple Uplink Interfaces: Example
In the following example, a service called "sample-serviceA" is bound to next-hop gateway 10.1.1.1. Next-hop gateway 10.1.1.1 is reachable through two uplink interfaces: ethernet interface 1/0 and Ethernet interface 2/0. The group name "service-groupA" indicates that both interfaces share the same service ("sample-serviceA").
For any services bound to either of the two interfaces, downstream traffic from the service is accepted on either interface.
ip cefssg enable!ssg bind service sample-serviceA 10.1.1.1!interface ethernet 1/0ip address 10.0.1.1 255.255.255.0ssg direction uplink member service-groupA!interface ethernet 2/0ip address 10.0.2.1 255.255.255.0ssg direction uplink member service-groupA!ip route 10.1.1.1 255.255.255.255 eth 1/0 10ip route 10.1.1.1 255.255.255.255 eth 2/0 20!Service Bound to Multiple Next Hops: Example
Service Bound to Multiple Next Hops: Example
In the following example, a service called "serviceB" is bound to two next-hop gateways, 10.0.0.1 and 20.0.0.1, that are reachable through two uplink interfaces, Ethernet interface 1/0 and Ethernet interface 2/0 respectively. The group name "groupB" indicates that both interfaces share the same service ("serviceB").
For any services bound to either of the two interfaces, downstream traffic from the service is accepted on either interface.
ip cefssg enable!ssg bind service serviceB 10.0.0.1ssg bind service serviceB 20.0.0.1!interface ethernet 1/0ip address 10.0.0.2 255.255.255.0ssg direction uplink member groupB!interface ethernet 2/0ip address 20.0.0.2 255.255.255.0ssg direction uplink member groupB!SSG Port-Bundle Host-Key Configuration: Example
In the following example, packets that match the specified TCP port range or that are permitted by access list 100 will be port-mapped. Loopback interface 1 is specified as the SSG source IP address.
ssg port-mapdestination range 8080 to 10100 ip 10.13.6.100port-map destination access-list 100port-map source ip Loopback1SSG and AAA Server Interaction Configuration: Example
In the following example, AAA and SSG features are enabled and configured to establish the interaction between the two.
! enable aaa; enable groups for PPP authentication,! service-profile authorization/download, l2tp authorization and! accounting method-list (in the order shown below)!aaa new-modelaaa authentication ppp default group radiusaaa authorization network default group radiusaaa authorization network ssg_aaa_author_internal_list noneaaa accounting network default start-stop group radius!! Enables CEFip cef!! Enables SSGssg enable### Configures password for service-profile downloadssg service-password servicecisco!! Configures SSG communication with the RADIUS server!radius-server host 192.168.2.62 auth-port 1812 acct-port 1813 key ciscoradius-server key ciscoradius-server vsa send accountingradius-server vsa send authenticationEstablishing Initial SSG Communication: Example
The following example illustrates all the tasks that must be completed to enable SSG and establish initial communication with other network devices.
!! Configures AAA and enables communication with the AAA serveraaa new-model!! Configures login accessaaa authentication banner CCCCC !!! Cisco SSG !!! aaa authentication fail-message CCC !!! Unauthorized Access Is Not Permitted !!!aaa authentication password-prompt Password:aaa authentication username-prompt Username:aaa authentication login default local group radiusaaa authentication login console local!! Configures PPP authentication, service-profile authorization,! l2tp tunnel authorization, accounting-listaaa authentication ppp default group radiusaaa authorization network default group radiusaaa authorization network ssg_aaa_author_internal_list noneaaa accounting network default start-stop group radius!aaa nas port extendedaaa session-id common!!! Enables CEFip cef!! Enables SSGssg enable! Configures the default networkssg default-network 192.168.2.0 255.255.255.0! Configures the shared key between SSG and the AAA serverssg service-password servicecisco!! Configures SSG-SESM API communicationssg radius-helper auth-port 1812 acct-port 1813ssg radius-helper key cisco!! Configures SSG port-bundle host-keyssg port-mapdestination range 80 to 80 ip 192.168.2.55destination range 443 to 443 ip 192.168.2.55destination range 8090 to 8101 ip 192.168.2.55source ip Loopback10source ip Loopback11!! Configures an interface towards services (uplink interface)interface FastEthernet1/0.1description SSG-Service internetencapsulation dot1Q 10ip address 10.1.1.41 255.255.255.0ip nat outsideip nbar protocol-discoveryno ip mroute-cachessg direction uplink!! Configures an interface towards subscribers (downlink interface)interface FastEthernet2/0.1description Subscriber Accessencapsulation dot1Q 70ip address 10.1.1.1 255.255.255.0ssg direction downlink!! Configures SSG communication with the RADIUS serverradius-server attribute 44 include-in-access-reqradius-server attribute 55 include-in-acct-reqradius-server attribute nas-port format dradius-server host 192.168.2.62 auth-port 1812 acct-port 1813 key ciscoradius-server retransmit 5radius-server timeout 30radius-server key ciscoradius-server vsa send accountingradius-server vsa send authentication!Additional References
The following sections provide references related to establishing SSG connectivity.
Related Documents
Configuring SESM
Cisco Subscriber Edge Services Manager documentation
RADIUS commands
RADIUS configuration tasks
"Configuring RADIUS" chapter in the Cisco IOS Security Configuration Guide
SSG commands
MIBs
Technical Assistance
Feature Information for Implementing SSG
Table 3 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the table.
For information on a feature in this technology that is not documented here, see the Service Selection Gateway Features Roadmap.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 3 Feature Information for Implementing SSG: Initial Tasks
Initial SSG Communication
12.0(3)DC
12.3(4)B
12.2(11)T
12.3T
12.4The Initial SSG Communication feature comprises initial tasks you need to perform to enable SSG on the router and to establish SSG communication with other key components of the network, including Subscriber Edge Services Manager (SESM) and the authentication, authorization, and accounting (AAA) server.
The following sections provide information about this feature:
•
SSG Direction Configuration for Interfaces and Ranges
12.2T
12.3(4)TSSG implements service selection through selective routing of IP packets to destination networks on a per-subscriber basis. SSG uses the concept of interface direction (uplink or downlink) to help determine the forwarding path of incoming packets. An uplink interface is an interface towards the services; a downlink interface is an interface towards the subscribers.
The following section provides information about this feature:
SSG Interface Redundancy
12.3(8)T
SSG interface redundancy allows services to be associated with more than one interface to protect against link failures.
The following section provides information about this feature:
•
•
•
SSG Port-Bundle Host-Key
12.3(4)B
12.2(11)T
12.3T
12.4The SSG Port-Bundle Host Key feature enhances communication and functionality between the Service Selection Gateway (SSG) and the Cisco Subscriber Edge Services Manager (SESM) by introducing a mechanism that uses the host source IP address and source port to identify and monitor subscribers.
The following sections provide information about this feature:
•
SSG Unconfig
12.2T
12.3(4)TThe Unconfig feature releases and cleans up system resources acquired by SSG.
The following section provides information about this feature:
•
The following command was introduced by this feature: no ssg enable force-cleanup.
Implementing SSG: Initial Tasks
15.0(1)M
This feature was removed in Cisco IOS Release 15.0(1)M.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Pulse, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, and Flip Gift Card are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Fast Step, Follow Me Browsing, FormShare, GainMaker, GigaDrive, HomeLink, iLYNX, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0908R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2005-2009 Cisco Systems, Inc. All rights reserved.
