Cisco 10000 Series Internet Router Service Selection Gateway Configuration Guide - Miscellaneous SSG Features [Cisco 10000 Series Routers]

Table Of Contents

Miscellaneous SSG Features

VPI/VCI Static Binding to a Service Profile

Restrictions for VPI/VCI Static Binding to a Service Profile

Configuration of VPI/VCI Static Binding to a Service Profile

RADIUS Virtual Circuit Logging

Configuration of RADIUS Virtual Circuit Logging

AAA Server Group Support for Proxy Services

Restrictions for AAA Server Group Support for Proxy Services

Configuration of AAA Server Group Support for Proxy Services

Configuration Example for AAA Server Group Support for Proxy Services

Packet Filtering

Downstream Access Control List—outacl

Upstream Access Control List—inacl

Restrictions for Packet Filtering

Configuration of Packet Filtering

Configuration Example for Packet Filtering

SSG Unconfig

Restrictions for SSG Unconfig

Prerequisites for SSG Unconfig

Configuration of SSG Unconfig

Configuration Examples for SSG Unconfig

SSG Enhancements for Overlapping Services

Service Translation

Restrictions for Service Translation

Prerequisites for Service Translation

Configuration of Service Translation

Configuration Example for Service Translation

Expansion of Service IDs

Restrictions for Expansion of Service IDs

Configuration Example for Expansion of Service IDs

Miscellaneous SSG Features

This chapter describes the following SSG features:

•VPI/VCI Static Binding to a Service Profile

•RADIUS Virtual Circuit Logging

•AAA Server Group Support for Proxy Services

•Packet Filtering

•SSG Unconfig

•SSG Enhancements for Overlapping Services

VPI/VCI Static Binding to a Service Profile

The VPI/VCI Static Binding to a Service Profile feature allows users accessing SSG through a VPI/VCI or a range of VPI/VCIs to access the server. When a user session arrives on a VPI/VCI or a VPI/VCI range and the session specifies the username but does not specify the domain name, SSG maps the user session to the service to which the VPI/VCI or VPI/VCI range is bound.

For more information, refer to the"Configuring VPI/VCI Indexing to Service Profile" section in the Node Route Processor—Service Selection Gateway Enhancements feature module.

Restrictions for VPI/VCI Static Binding to a Service Profile

The VPI/VCI Static Binding to a Service Profile feature has the following restrictions:

•The feature applies only to PPP sessions.

•You must statically configure the feature.

•SESM cannot map the VC to the service.

Configuration of VPI/VCI Static Binding to a Service Profile

To map a VC to a service, use the ssg vc-service-map command in global configuration mode. For more information, refer to the "Broadband Access: Service Selection Gateway Commands" section in the Cisco IOS Wide-Area Networking Command Reference, Release 12.2T.

RADIUS Virtual Circuit Logging

RADIUS Virtual Circuit (VC) Logging extends and modifies the RADIUS network access server (NAS) port field to carry VPI/VCI information. With RADIUS VC Logging enabled, the Cisco 10000 router (the SSG node) can send NAS port information to the RADIUS server, accurately recording the virtual path interface (VPI) and virtual circuit interface (VCI) of an incoming user or subscriber session. The VPI/VCI of the incoming permanent virtual circuit (PVC) is recorded at the point of entry on SSG, which offers the RADIUS client a unique VPI/VCI for each incoming PVC. This information is logged in the RADIUS accounting record that was created at session startup.

RADIUS VC Logging allows SSG to send NAS port information for an IP user on an ATM point-to-point VC or an Ethernet VLAN. SSG can also send NAS port information for PPPoX users.

For more information, refer to the RADIUS Virtual Circuit Logging, Release 11.3DB9 feature module.

Configuration of RADIUS Virtual Circuit Logging

To enable RADIUS VC Logging on the Cisco 10000 series router, use the following command in global configuration mode:
radius-server attribute nas-port format d 
This command selects the ATM VC extended format for the NAS port field.

For more information, refer to the RADIUS Virtual Circuit Logging, Release 11.3DB9 feature module.

AAA Server Group Support for Proxy Services

The AAA Server Group Support for Proxy Services feature allows you to configure multiple AAA servers for redundancy. The RADIUS Server attribute enables AAA server group support for proxy services. Each group is associated with a service that requires proxy RADIUS AAA. You can configure each remote RADIUS server with timeout and retransmission parameters. When necessary, the SSG performs failover among the servers in the predefined group.

The RADIUS Server attribute specifies the remote RADIUS servers that SSG uses to authenticate, authorize, and perform accounting for a service login for a proxy service type. This attribute is used only in service profiles and is required. SSG automatically creates an AAA server group that contains the remote RADIUS server for this service profile.

For more information, refer to the Service Selection Gateway, Release 12.2(15)B feature module.

Restrictions for AAA Server Group Support for Proxy Services

The AAA Server Group Support for Proxy Services feature has the following restriction:

•The RADIUS Server attribute is supported only by SSG with SESM in RADIUS mode.

Configuration of AAA Server Group Support for Proxy Services

To configure AAA Server Group Support for Proxy Services, use the RADIUS Server attribute. This Service-Info vendor-specific attribute (VSA) is used to specify the remote RADIUS servers that SSG uses to authenticate and authorize a service login for a proxy service type.

The RADIUS Server attribute has the following syntax:
Service-Info =
"SRadius-server-address;auth-port;acct-port;secret-key[;retrans;timeout;deadtime]"
For more information, refer to the Service Selection Gateway, Release 12.2(15)B feature module.

Configuration Example for AAA Server Group Support for Proxy Services

The following example shows how to configure the RADIUS Server attribute to specify the remote RADIUS servers SSG uses for authentication and authorization of service login for a proxy service type:
Service-Info = "S192.168.1.1;1645;1646;cisco"
Packet Filtering

The Cisco 10000 series router supports per-user access control lists (ACLs) to prevent users from accessing specific IP addresses and ports. When an ACL attribute is added to a user profile, the attribute applies globally to all the user's traffic.

User profiles define the services and service groups to which a user is subscribed. RADIUS user profiles contain a password, a list of subscribed services and groups, access control lists, and timeouts. User profiles are configured on the RADIUS server or directly on the Cisco 10000 series router. The RADIUS server or SESM downloads the user profiles to the router. For more information about RADIUS user profiles and the attributes included in them, refer to the Service Selection Gateway, Release 12.2(15)B feature module.

SSG accepts Cisco IOS ACLs and SSG ACLs. SSG ACLs take precedence over Cisco IOS ACLs when both Cisco IOS and SSG ACLs are configured on the same SSG interface. The following Cisco-AV pair attributes are used to specify either a Cisco IOS standard ACL or an extended ACL to be applied to either downstream or upstream traffic:

•Downstream Access Control List—outacl

•Upstream Access Control List—inacl

Downstream Access Control List—outacl

Specifies either a Cisco IOS standard ACL or an extended ACL to be applied to downstream traffic going to the user.
Cisco-AVpair = "ip:outacl[#number]={standard-access-control-list | 
extended-access-control-list}"
Upstream Access Control List—inacl

Specifies either a Cisco IOS standard ACL or an extended ACL to be applied to upstream traffic coming from the user.
Cisco-AVpair = "ip:inacl[#number]={standard-access-control-list | 
extended-access-control-list}"
Restrictions for Packet Filtering

Packet filtering for SSG has the following restrictions:

•SSG accepts only the permit and deny actions for a per-user ACL. You can place ACLs on user traffic for both the input and output directions that are similar to existing Cisco IOS ACLs; however, the log option is not accepted.

•SSG supports mini-ACLs with eight or less access control entries (ACEs). The ACEs can be extended ACEs.

•SSG does not support turbo ACLs applied to SSG users. Turbo ACLs have more than eight ACEs defined.

•To support some SSG features, SSG prepends ACEs on user ACLs. Because the number of ACEs is restricted to a maximum of eight, the number of ACEs that you can define is therefore reduced in some cases. For example, for the Port-Bundle Host Key feature, an ACE is required on both the host input and output ACL. This allows seven ACEs that you can define.

•SSG does not support the ability to apply per-service (connection level) ACLs. ACLs for QoS classification are not applicable to SSG host interfaces.

•SSG ACLs take precedence over Cisco IOS ACLs. If you configure a Cisco IOS ACL on an SSG interface by using the ip access-group command, the router applies the ACL as long as an SSG ACL is not applied to the interface in the same direction. If an SSG ACL is applied to the interface in the same direction, the router applies the SSG ACL.

Configuration of Packet Filtering

To configure SSG ACLs, use the following Cisco-AV pair attributes:

•Downstream Access Control List (outacl)
Cisco-AVpair = "ip:outacl[#number]={standard-access-control-list | 
extended-access-control-list}"
•Upstream Access Control List (inacl)
Cisco-AVpair = "ip:inacl[#number]={standard-access-control-list | 
extended-access-control-list}"
For more information, refer to the Service Selection Gateway, Release 12.2(15)B feature module.

Configuration Example for Packet Filtering

The following is an example of a downstream ACL (outacl):
Cisco-AVpair = "ip:outacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
The following is an example of an upstream ACL (inacl):
Cisco-AVpair = "ip:inacl#101=deny tcp 192.168.1.0 0.0.0.255 any eq 21"
SSG Unconfig

The SSG Unconfig feature enhances your ability to disable SSG at any time and releases the data structures and system resources created by SSG when SSG is unconfigured.

SSG Unconfig removes SSG allocated resources when you globally disable SSG after it was enabled. When you enable SSG, the SSG subsystem in the Cisco IOS software acquires system resources that are never released, even after you disable SSG. The SSG Unconfig feature enables you to release and clean up system resources when SSG is not in use by entering the no ssg enable force-cleanup command.

The SSG Unconfig feature also enhances several IOS commands to allow you to delete all host objects, a range of host objects, or all service objects (connection objects). Enhancements to the show ssg host command allow you to display information about an interface and its IP address when you enable host-key mode on that interface. For more information about the SSG commands, refer to the Cisco 10000 Series Routers Command Quick Reference Guide.

For more information about the SSG Unconfig feature, refer to the SSG Unconfig, Release 12.2(15)B feature module and the Service Selection Gateway, Release 12.2(15)B feature module.

Restrictions for SSG Unconfig

SSG Unconfig clears all SSG resources on the system. Therefore, if you no longer need to run SSG features on the router, instead of using SSG Unconfig enter the no ssg enable force-cleanup command after all users are logged out.

Prerequisites for SSG Unconfig

You must enable SSG before you configure SSG Unconfig.

Configuration of SSG Unconfig

To configure SSG Unconfig, perform any of the following optional tasks:

•Unconfigure SSG and release system resources by entering the no ssg enable force-cleanup command in global configuration mode.

•Remove one or more SSG host objects by entering the clear ssg host command in privileged EXEC configuration mode.

•Remove one or more SSG service objects by entering the clear ssg service command in privileged EXEC configuration mode.

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

Configuration Examples for SSG Unconfig

Example 11-1 shows how to unconfigure SSG and release system resources.

Example 11-1 Unconfiguring SSG and Releasing System Resources
Router(config)# no ssg enable force-cleanup
04:35:02: Delete all active host objects. It may take some time, please wait.
04:35:-02: ssg_unconfig_proc: UNCONFIGURATION COMPLETE
Example 11-2 shows how to remove all host objects associated with a downlink interface and then verify that all host objects on that interface are removed.

Example 11-2 Removing Host Objects on an Interface
Router# clear ssg host range 0.0.0.0 255.255.255.255 FastEthernet0/1
Router# show ssg host FastEthernet0/1
##Total HostObject Count:0
For more configuration examples, refer to the SSG Unconfig, Release 12.2(15)B feature module.

SSG Enhancements for Overlapping Services

Overlapping services are services for which the route prefix of one service matches or is contained within the route prefix of another service. For example, the service definition 172.16.253.0/24 overlaps with the service definition 172.16.0.0/16 because the prefix 172.16 is contained in both definitions. The definition 0.0.0.0/0 overlaps all other possible services.

In releases prior to Cisco IOS Release 12.2(16)BX2, the Cisco 10000 router does not allow users to be subscribed to a service if that service overlaps another service to which a different user is subscribed.

To enable service providers to use existing overlapping definitions, the Cisco 10000 router provides the following SSG enhancements:

•Service Translation—Translates overlapping service definitions to a set of non-overlapping service definitions.

•Expansion of Service IDs—Expands the number of service IDs supported from seven to 15. The router uses service IDs to determine which services a user is subscribed to and how to police the user traffic.

For more information, see the following sections:

•Service Translation

•Expansion of Service IDs

Service Translation

The service translation mechanism translates overlapping service definitions to a set of non-overlapping service definitions that are used internally to the router. Instead of using the service definitions that the Cisco Subscriber Edge Services Manager (SESM) downloads, the router uses the translated network sets to provide the desired behavior. A network set can contain a single unique prefix or multiple unique prefixes.

To further clarify service translation for the Cisco 10000 router, consider the following example in which services that are defined in SESM are converted to sets (for example, service networks). The Cisco 10000 router uses these sets internally to provide the desired behavior. The following services are defined in the example:

ssg bind service Default_256 <next hop ssg>
0.0.0.0/0.0.0.0

ssg bind service Bronze_256 <next hop ssg>
10.58.253.0/255.255.255.0
10.58.254.0/255.255.255.0

ssg bind service Silver_512 <next hop ssg>
10.58.253.0/255.255.255.0
10.58.254.0/255.255.255.0
10.58.102.6/255.255.255.255

ssg bind service Gold_2048 <next hop ssg>
10.58.253.0/255.255.255.0
10.58.254.0/255.255.255.0
10.58.102.6/255.255.255.255

ssg bind service Platinum_1024 <next hop ssg>
10.58.253.0/255.255.255.0

Because network sets for services must be unique, the following network sets are defined internally:

Set1
0.0.0.0/0.0.0.0

Set2
10.58.253.0/255.255.255.0

Set3
10.58.254.0/255.255.255.0

Set4
10.58.102.6/255.255.255.255

The service translation mechanism then internally converts the services to the following sets:

Service Default_256
Set1

Service Bronze_256
Set2 and set3

Service Silver_512
Set2, set3, and set4

Service Gold_2048
Set2, set3, and set4

Service Platinum_1024
Set2

Policing of user traffic is based on the service to which the user is assigned. For example, using the services and sets defined above, if user A is subscribed to Default_256 at 256 Kbps, user A traffic is policed at 256 Kbps for all services. If user B is subscribed to Default_256 at 256 Kbps and Platinum_1024 at 1024 Kbps, user B traffic to the service 10.58.253.0/255.255.255.0 is policed at 1024 Kbps, but all other user B traffic is policed at 256 Kbps.

In the previous example, each set contains a single prefix. However, network sets can also contain multiple prefixes. For example, consider the following service definitions:

ssg bind service Bronze_256 <next hop ssg>
10.58.253.0/255.255.255.0
10.58.254.0/255.255.255.0

ssg bind service Default_256 <next hop ssg>
10.58.253.0/255.255.255.0
10.58.254.0/255.255.255.0
10.58.102.6/255.255.255.255
10.58.102.7/255.255.255.255

Based on the service definitions, the service translation mechanism internally defines the following network sets:

Set1
10.58.253.0/255.255.255.0
10.58.254.0/255.255.255.0

Set2
10.58.102.6/255.255.255.255
10.58.102.7/255.255.255.255

The service translation mechanism then internally converts the services to the following sets:

Service Bronze_256
Set1

Service Silver_512
Set1 and set2

The service translation mechanism also provides for the translation of services that are complete subsets of one another. For example, consider the following service definitions:

ssg bind service A_1 <next hop ssg>
10.58.253.0/255.255.255.0

ssg bind service B_256 <next hop ssg>
10.58.0.0/255.255.0.0

Based on the service definitions, service A_1 is a subset of service B_256. Therefore, the service translation mechanism creates the following two sets and internally converts the services to sets:

Set1
10.58.253.0/255.255.255.0

Set2
10.58.0.0/255.255.0.0

Service A_1
Set1

Service B_256
Set1 and set2

Assume that user1 is subscribed to service B_256 at 256 Kbps and user2 is subscribed to service A_1 at 1 Mbps. Internally, user1 is subscribed to both set1 and set2. However, policing of the aggregate traffic to either set1 or set2 is at an aggregate rate of 256 Kbps because policing of user traffic is based on the service to which the user is assigned. User1 is subscribed to service B_256; therefore, policing is at a rate of 256 Kbps.

Restrictions for Service Translation

Service translation has the following restrictions:

•Network sets for services must be unique.

•If the service definitions from SESM change, the user must be disconnected and then reconnected before the service translation mechanism can properly translate the new service definitions.

Prerequisites for Service Translation

Enable service translation before SESM downloads overlapping service definitions.

Configuration of Service Translation

To enable service translation on the router, enter the following command in global configuration mode:

Command

Purpose

Router(config)# ssg service-overlap

Enables service translation and indicates to the router to use the translated sets to provide the desired network behavior.

Configuration Example for Service Translation

The following example shows how the service translation mechanism translates the services defined in SESM to sets (for example, service networks). The router uses the sets internally to provide the desired behavior.

Service Definitions

ssg bind service DEF_256 <next hop ssg>
0.0.0.0/0.0.0.0

ssg bind service A_256 <next hop ssg>
10.16.25.0/255.255.255.0
10.16.26.0/255.255.255.0

ssg bind service B_512 <next hop ssg>
10.16.25.0/255.255.255.0
10.16.26.0/255.255.255.0
10.16.102.1/255.255.255.0

ssg bind service C_2048 <next hop ssg>
10.16.25.0/255.255.255.0
10.16.26.0/255.255.255.0
10.16.102.1/255.255.255.0

ssg bind service D_1024 <next hop ssg>
10.16.25.0/255.255.255.0

Internal Network Sets

Set1
0.0.0.0/0.0.0.0

Set2
10.16.25.0/255.255.255.0

Set3
10.16.26.0/255.255.255.0

Set4
10.16.102.1/255.255.255.0

Services-to-Sets Conversion

Service DEF_256
Set1

Service A_256
Set2 and Set3

Service B_512
Set2, set3, and set4

Service C_2048
Set2, set3, and set4

Service D_1024
Set2

Expansion of Service IDs

The Cisco 10000 router uses service IDs to determine which services a user is subscribed to and how to police the user traffic. A user can be subscribed to a maximum of seven services. However, service translation can result in more than seven network sets. To support the service translation mechanism, the expansion of service IDs enhancement expands the number of service IDs supported from seven to 15.

Restrictions for Expansion of Service IDs

The expansion of service IDs enhancement has the following restrictions:

•When service translation is used, the Cisco 10000 router supports a maximum of 15 sets per SSG VRF. If all of the users are configured in the same VRF, the router supports a maximum of 15 network sets per system.

•A user can be subscribed to a maximum of seven services and a maximum of 15 network sets.

Configuration Example for Expansion of Service IDs

The following example shows how service IDs are expanded to allow a user to be subscribed to more than seven sets. In this example, the user is subscribed to five services, which is within the seven-services limit. After service translation, the user is subscribed to eight sets, which is within the expanded service IDs limit of 15 network sets.

Service Definitions:

ssg bind service Rate-1 <next hop ssg>
0.0.0.0/0.0.0.0

ssg bind service Rate-2 <next hop ssg>
10.58.252.0/255.255.255.0
10.58.253.0/255.255.255.0
10.58.254.0/255.255.255.0
10.58.102.6/255.255.255.255

ssg bind service Rate-3 <next hop ssg>
10.58.251.0/255.255.255.0

ssg bind service Rate-4 <next hop ssg>
10.58.250.0/255.255.255.0

ssg bind service Rate-5 <next hop ssg>
10.58.249.0/255.255.255.0

Network Sets:

Set1
0.0.0.0/0.0.0.0

Set2
10.58.252.0/255.255.255.0

Set3
10.58.253.0/255.255.255.0

Set4
10.58.254.0/255.255.255.0

Set5
10.58.102.6/255.255.255.255

Set6
10.58.251.0/255.255.255.0

Set7
10.58.250.0/255.255.255.0

Set8
10.58.249.0/255.255.255.0